this diff is largely a mechanical change.
firstly, it makes struct bufq a member of the softc for devices
that use it, rather than it being a pointer to something that needs
to be allocated at attach. since all these devices need a bufq to
operate, it makes sense to have it allocated as part of
On Sun, Aug 29, 2010 at 10:26:14PM +1000, David Gwynne wrote:
this diff is largely a mechanical change.
firstly, it makes struct bufq a member of the softc for devices
that use it, rather than it being a pointer to something that needs
to be allocated at attach. since all these devices need
He get $219,249 Last Month
Works on ANY Computer
Profiting 112 Minutes From NOW
$4,191 In First 7 Days
$219,249 Last Month
Only 234 Copies Available - If You Don't Get Results, You'll Get A Full Refund
AND $100
Join Now : http://thenewsdetail.info
Please test this diff on all pcmcia cards and machines you can find,
and report the results directly to me (ie. test the zaurus with brand
new -current code, apm i386 laptops, and the other non-suspending
cases such as amd64/i386 acpi - but don't test suspend there).
PLEASE do this very soon
unless someone fixes mclgeti in this driver in the next 24 hours, this should
go in.
this has my ok on august 31.
On 28/08/2010, at 4:07 AM, Thordur I Bjornsson wrote:
As seen on misc@, and also by myself sometime ago, but I forgot about
it as work got hectic and I was moving.
Anyways,
unless someone fixes mclgeti in this driver in the next 24 hours, this should
go in.
this has my ok on august 31.
It is a very nasty bug.
But we should also remember that machines with vr(4) interfaces
are pretty slow, and benefit tremendously from MCLGETI. So it is
a crying shame to see
