opposed to returning the top of the old chain when there was one and
the top of the newly allocated chain if there was no old chain.
Actually, it should be noted that prior to this fix, although the
comment above m_getm() advertised that m_getm() would return the
top of the old chain (if an old chain was being passed in) it
actually [wrongly] was returning the tail mbuf in the old chain
instead. This is a bug but since the one use of m_getm() in
the tree luckily did not depend on the behavior, it happened
to work out without notice.
Harti Brandt pointed out that the advertised behavior was actually
not the real behavior and so this change makes m_getm() ALWAYS
return the newly allocated chain (and fixes the comment). This
is less confusing and is the best course of action as then the
caller is always able to have both a reference to the top of
the original chain (because it's passing it in in the call) and
a reference to the newly attached chain. Although the API is
slightly modified, I don't think that any third-party code uses
m_getm() and if it does, it surely can't be working properly
because the old behavior was bogus.
API bug pointed out by: Harti Brandt <brandt@fokus.fraunhofer.de>
To fix scsi, don't wait for ithreads if we're dumping, it makes the
debugger sad.
To fix ata, use what appears to be a polling method if we're dumping,
I stole this from tmm but added code to ensure that this change is
only in effect while dumping.
Tested by: des
for the agp module, and add agp to the list of modules to compile for alpha.
Add an alpha_mb() to agp_flush_cache for alpha -- it's not correct but may
improve the situation, and it's what linux and NetBSD do.
we can have additional different types of bridges.
o remove now bogus comment.
o Don't clear CARD_OK when we can't attach a card.
o minor style nits
# this make kldload of cardbus drivers work for me when the card is
# present on boot.
o chip_name arrays ifdef'd out.
o use the OLDCARD-like get/put functions so we can support differnt types
of mappings.
o Write the beggings of is this a valid exca device and introduce more
chipset support.
# this is partially a wip, but also needed because some other cahnges I've
# made require some of these changes.
previous revision fixed the panic, I found the problem exits in
another part of the function by investigating the crom dump sent by him.
The search was started in the middle of bus info block and the
routine misunderstood the EUI64 as a crom entry. This problem is fixed.
PR: kern/48129
Fix incorrect type mask included in a logical unit number and check
the validity of the lun.
