History log of /openbsd-src/sys/dev/ic/mpi.c (Results 51 – 75 of 226)
Revision Date Author Comments
# a4a8c504 26-Aug-2012 dlg <dlg@openbsd.org>

htole64 works as good as htole32 twice for dma virtual addresses.


# fb44949a 16-Jan-2012 dlg <dlg@openbsd.org>

mpi_get_ccb and mpi_put_ccb are only called via iopools now, so change
their types to fit the iopools api rather than doing awful typecasts to
shove them into iopool_init.


# 3ba30b1b 17-Jul-2011 matthew <matthew@openbsd.org>

Backout a bunch of my SCSI commits from c2k11. At least one of these
is causing problems when trying to boot sparc64 from an isp(4).

Verified to fix the sparc64/isp(4) regression by krw@; ok deraad

Backout a bunch of my SCSI commits from c2k11. At least one of these
is causing problems when trying to boot sparc64 from an isp(4).

Verified to fix the sparc64/isp(4) regression by krw@; ok deraadt@

show more ...


# f35acd0c 08-Jul-2011 matthew <matthew@openbsd.org>

First batch of converting SCSI HBAs from setting saa_targets and
saa_luns instead of adapter_buswidth and luns in the prototype link.

ok dlg@, miod@


# e6ca3d0d 17-Jun-2011 mk <mk@openbsd.org>

M_WAITOK cleanup of two cases:

1) Allocating with M_WAITOK, checking for NULL, and calling panic() is
pointless (malloc() will panic if it can't allocate) so remove the check
and the call.

2) Alloc

M_WAITOK cleanup of two cases:

1) Allocating with M_WAITOK, checking for NULL, and calling panic() is
pointless (malloc() will panic if it can't allocate) so remove the check
and the call.

2) Allocating with M_WAITOK, checking for NULL, and then gracefully
handling failure to allocate is pointless. Instead also pass M_CANFAIL
so malloc() doesn't panic so we can actually handle it gracefully.

1) was done using Coccinelle.

Input from oga.

ok miod.

show more ...


# a9852d1a 27-Apr-2011 dlg <dlg@openbsd.org>

if getting the RAID header fails, dont stop the midlayer from trying to
issues scsi commands against that target. it might be a normal device and
the firmware is just being picky about which headers

if getting the RAID header fails, dont stop the midlayer from trying to
issues scsi commands against that target. it might be a normal device and
the firmware is just being picky about which headers you can fetch.

tested by and ok deraadt@

show more ...


# 97cf327f 27-Apr-2011 dlg <dlg@openbsd.org>

configure fc controllers to fail io as fast as possible when cables are
yanked. we want to reschedule them down active paths rather than wait for
a minute while mpi decides that a path isnt coming ba

configure fc controllers to fail io as fast as possible when cables are
yanked. we want to reschedule them down active paths rather than wait for
a minute while mpi decides that a path isnt coming back.

discussed with and tested by deraadt@

show more ...


# 0b5efc6c 27-Apr-2011 dlg <dlg@openbsd.org>

return XS_RESET to the midlayer if the command was killed for some reason
rather than the default of XS_DRIVER_STUFFUP. mpath(4) likes this better
when you unplug paths.


# bb28c276 27-Apr-2011 dlg <dlg@openbsd.org>

rework the scanning of fibre channel ports to match how linux does it.
some fc parts dont like the header requests against missing devices with
bus addressing, so now we do the magic iteration over a

rework the scanning of fibre channel ports to match how linux does it.
some fc parts dont like the header requests against missing devices with
bus addressing, so now we do the magic iteration over active ports.

the original problem was reported by deraadt@
lots of testing and debugging by deraadt@
tested on fc929 and fc949 adapters

show more ...


# 5e676cfc 04-Mar-2011 mikeb <mikeb@openbsd.org>

Peek at the interrupt status register before poking with the reply post
queue. In some situations this prevents us from reading a garbled reply.
If this commit breaks your mpi, please report ASAP.

Peek at the interrupt status register before poking with the reply post
queue. In some situations this prevents us from reading a garbled reply.
If this commit breaks your mpi, please report ASAP.

The issue was reported and the fix was verified by Emeric Boit. Thanks!
Ok dlg, kettenis, marco (who warned us and wanted to test more)

show more ...


# c7d988b2 01-Mar-2011 dlg <dlg@openbsd.org>

back out r1.162, the one that bumps openings up on sas and fc
devices.

my theory is that some devices report queue full conditions in ways
the firmware doesnt understand, or some firmwares default t

back out r1.162, the one that bumps openings up on sas and fc
devices.

my theory is that some devices report queue full conditions in ways
the firmware doesnt understand, or some firmwares default to NOT
doing the queue full handling internally. either way it reports
queue full conditions as faulted io which gets passed up to the
block layer as errors.

this makes us conservative again and safe.

this fixes panics from ajacout

ok sthen@ deraadt@

show more ...


# 48c5f595 24-Sep-2010 dlg <dlg@openbsd.org>

vol_list in mpi_get_raid is never used.


# 5aae8953 21-Sep-2010 dlg <dlg@openbsd.org>

tweak the sas io unit to use 32 openings when talking to sata disks if the
firmware has it configured lower.


# 7806ac8d 20-Sep-2010 krw <krw@openbsd.org>

Use SSD_ERRCODE_CURRENT instead of magic 0x70.

ok dlg@ matthew@


# 7a304427 14-Sep-2010 dlg <dlg@openbsd.org>

allow devices on fc and sas adapters to use all the openings the chip can
provide. spi parts are still limited.

ok krw@


# 3f6b51f0 13-Sep-2010 dlg <dlg@openbsd.org>

if a busy sas device is unplugged, the pending io on that device will
never complete.

when we get a detach event from the firmware, we currently deactivate the
device and then request the scsi midla

if a busy sas device is unplugged, the pending io on that device will
never complete.

when we get a detach event from the firmware, we currently deactivate the
device and then request the scsi midlayer attempt to detach the device.
this diff now deactivates the device and then resets the target, forcing
the ioc to complete the pending operations. once the reset has completed
we then request a detach of the kernel device.

this lets me hotplug busy sas disks without leaking scsi_xfers or bufs or
anything.

show more ...


# ca4902a4 13-Sep-2010 dlg <dlg@openbsd.org>

dont reuse the event notifications ccbs id for the acknowledgement.


# 2bd7b213 13-Sep-2010 dlg <dlg@openbsd.org>

im not convinced we only have one outstanding event to ack at a time. this
steals^Wleverages the code used in mpii for handling a list of events to
acknowlede.

tested by hotplugging sas disks.


# 05160703 10-Sep-2010 dlg <dlg@openbsd.org>

implement handling of rescan events on fc controllers. allows "hotplug" of
fc devices.


# 0520459d 27-Aug-2010 dlg <dlg@openbsd.org>

get some format strings and variables right in debug output


# 859d5ed4 07-Aug-2010 krw <krw@openbsd.org>

No "\n" needed at the end of panic() strings.

Bogus chunks pointed out by matthew@ and miod@. No cookies for
marco@ and jasper@.

ok deraadt@ miod@ matthew@ jasper@ macro@


# 108d5ecb 06-Jul-2010 dlg <dlg@openbsd.org>

if we get an event notification that requires acknowledgement while
we're busy, we might not be able to allocate a ccb via scsi_ioh_get
if the pool is empty. this means we wont ack the event, which i

if we get an event notification that requires acknowledgement while
we're busy, we might not be able to allocate a ccb via scsi_ioh_get
if the pool is empty. this means we wont ack the event, which in
turn means we wont receive further event notifications.

this cuts the event ack code over to using a scsi_iohandler. the
eventack iohandler will be called as soon as a ccb becomes available
for it to use. this guarantees reliable event handling and
acknowledgement, despite how busy the controller might be.

this has bugging me ever since i wrote the event handling code.
tested by hotplugging sata disks.

show more ...


# d0186c77 06-Jul-2010 dlg <dlg@openbsd.org>

move the last direct users of mpi_{get,put}_ccb over to using the scsi
ioh wrappers.


# a0870786 01-Jul-2010 matthew <matthew@openbsd.org>

Change scsibus(4)'s scsi_link array to an SLIST to save memory on
sparsely populated buses.

ok dlg@, krw@


# 8952d2e0 28-Jun-2010 krw <krw@openbsd.org>

Remove all adapter-specific 'struct scsi_device's. They are never used. First
step in elminating 'struct scsi_device' entirely.

Spotted and initial diff from matthew@.

ok matthew@ dlg@ deraadt@ mar

Remove all adapter-specific 'struct scsi_device's. They are never used. First
step in elminating 'struct scsi_device' entirely.

Spotted and initial diff from matthew@.

ok matthew@ dlg@ deraadt@ marco@ miod@

show more ...


12345678910