another function, always doing a page 0 MODE SENSE to get the block
descriptor if we use READ CAPACITY, and use SMS_DBD on the page 4/5 MODE
SENSE. This does one extra command in some cases, but it separates and
simplifies the code a little.
Why do we prefer READ CAPACITY over READ FORMAT CAPACITIES? Two reasons:
1) It's much older and is much less likely to have had its command code
abused, and is thus "safer" to try first. 2) ALL of my USB flash readers
and pen drives screw up their capacity descriptors -- mostly off-by-one
errors in the size (they return the maximum LBA number instead, a la READ
CAPACITY, which has *never* been how READ FORMAT CAPACITIES was documented
in the MMC spec), and one returns the "no media" code on slots that have
media inserted (despite returning almost-correct data otherwise)!
F*** me with a chainsaw.
This wasn't an error, on this chipset we have the SATA controller on function
0 of the IDE controller, not the pcib bridge.
Fix provided by Stephen Degler.
when an old ffs filesytem is first mounted (as a result, df reports disk
full on old ffs filesystem or mfs created by old binary). Problem first
noticed by onoe san.
filter or not. We only need to run the filter for bridge_forward() and
bridge_broadcast(). If we also run it for bridge_output(), we will run
the filter twice outbound per packet, so don't.
In bridge_ipf(), make sure we don't run m_cat() on a single mbuf chain
by checking to see (and remembering) if we need to m_split() the mbuf.
This fixes bridge + ipfilter on sparc.
Fixes PR kern/22063.
during a read(v)/write(v). If that happeded, we either passed a NULL
pointer or a pointer to something uninitialized as iov to ktrace,
or we got a memory leak. In read/write (w/o -v) we zero-initialize
the iov now to limit damage, in the -v calls the (dynamically allocated)
pointer is checked after the I/O.
jdolecek