I've just acquired this buggy piece of hardware otherwise known as a
NetGear WG111v2. I googled and eventually found an explanation in the
form of source code here:
http://www.gelato.unsw.edu.au/lxr/source/include/linux/etherdevice.h#L93.
It seems linux rejects the hardware MAC address because

I compiled my kernel (2.6.11) with the floppy driver as a module - so it
is not loaded on boot. When the floppy driver is laoded, the LED
behaves as expected. When I unload it, the LED stays in its current
state. So if I do this...
# modprobe floppy; sleep 5; dd if=/dev/fd0 count=1

Query: register vpllB
I have a question about your patch: you added chip-vpllB and
chip-vpllB2 (presumably taken from the X driver). Do you know their
purpose, and did you find them to be necessary or useful?
Possible patch to add supported cards
I discovered that since your patch, some

I asked on LKML about extending the list of supported cards for the
rivafb driver to include GeForce/Quadro FX boards. I suspect the lack
of response was down to two factors:
a) Not addressing the maintainer
b) Lack of a patch
Hence this email!
Without this patch, the only supported FX board

Dude you completely forgot the important parts of the code!!
Sorry I didn't reply to you in that previous e-mail before, I was
busy, but those vplB and 'format' stuff WAS important, without it, I
got strange distortions on screen and refreshes were lagged... The
ONLY things you can remove

I've tried adding the format and vpllB but I can't see any difference.
...
I'll get 2.6.6 (the version your patch applies to) and try with and
without your full patch. Hopefully I'll be able to see the difference.
Otherwise I might have to ask you to try the trivial and full patches
I'm

On 20/01/05 08:48:02, Alan Jenkins wrote:
I have noticed a similar message, and so has someone else on the list:
http://groups-beta.google.com/group/fa.linux.kernel/browse_thread/thread/1bfcbbca2d508bb3/cb69d674510d215a?q=%22bad:+scheduling+while+atomic!%22+suspend_done=%2Fgroup%2Ffa.linux.kernel

On Thu, 2005-01-20 at 10:19 +0100, Rafael J. Wysocki wrote:
On Thursday, 20 of January 2005 09:49, Alan Jenkins wrote:
On 20/01/05 08:48:02, Alan Jenkins wrote:
I have noticed a similar message, and so has someone else on the list:
http://groups-beta.google.com/group/fa.linux.kernel

Try without preempt for an ugly workaround.
Check.
??? Sorry, I do not understand.
My fault. I mean disabling preempt gets rid of the warnings.
Ok, looks like I should enable PREEMPT here.
But resume succeeds at the end, no? We'll probably need to fix those
warnings, but driver model has

On Thu, Aug 25, 2005 at 12:32:50AM -0400, [EMAIL PROTECTED] wrote:
Right, but it would be nice to have that option if initramfs
using tmpfs becomes part of the kernel.
But it's not needed so why add bloat?
I'm not subscribed, so sorry if this doesn't fall into the original
thread.

stop after 5 seconds
The interruptible wait was added to blk_queue_enter in
commit 3ef28e83ab15 ("block: generic request_queue reference counting").
Before then, the interruptible wait was only in blk-mq, but I don't think
it could ever have been correct.
Cc: sta...@vger.kernel.

> jbd2/sda1-8(PID=2271) is stuck waiting for journal commit operation.
> I don't know how this thread is involved to this problem.
It feels like it should be a necessary link in the chain. This is the
filesystem underneath the loop device. If that hangs, we would expect
the loop device to