> >>1. Is it necessary to print the following message during regular boot?
> >> swsusp: Suspend partition has wrong signature?
> >> It is a bit annoying and I believe it will confuse some swsusp
> >> users.
> > Hmm, feel free to provide a patch. (I need something to try git on :-).
> I'll have a look over the weekend.
I already have something from Seife in my queue.
> >>2. PCMCIA related hangs during swsusp.
> >> swsusp hangs after freeing memory when either cardmgr is running
> >> or pcmcia cards are *physically* inserted. It is insufficient
> >> to do a 'cardctl eject' the cards must be removed, too, for
> >> swsusp not to hang. I do suspect some problem with the
> >> 'pccardd' kernel threads.
> > Did it work with any older kernel? Which driver is it? yenta?
> 188.8.131.52 works ok and, yes, its yenta. Some excerpt from lspci:
> 00:0b.0 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
> 00:0b.1 CardBus bridge: Texas Instruments PCI7420 CardBus Controller
Can you try some more binary search?
> >>3. Sometimes during the search for the suspend hang reason the system
> >> went during suspend into a lightshow of:
> >> eth0: Too much work at interrupt!
> >> and some line that ends in:
> >> release_console_sem+0x13d/0x1c0)
> >> The start of the line is not readable as it just flickers by in
> >> the eth0 message limbo. NIC is a built in RTL-8169 Gigabit Ethernet
> >> (rev 10). Oh, no chance for a serial console capture as there's no
> >> built in serial device in this laptop.
> > How repeatable is that? Will NIC work okay if you rmmod/insmod its driver?
> Happens with a probability of about 10% to 20%. I did comment out the
> 'Too much work...' printk in r8169.c which results in the following
> effect: no more message from the network driver (expected), no other
> printk related to release_console_sem or anything else unusal, but write
> to disk in the case the problem seems to happen is suddenly quite slow
> and suspend eventually succeeds.
Well, I guess that's expected. If r8169 is looping somewhere with too
much work, no wonder it slows suspend down.
> As the nic driver is built into the kernel insmod/rmmod currently won't
> do:-) Nevertheless there doesn't seem to be any strange behaviour after
> resume though I didn't really try to use the nic then.
> There is, however, definitely no such problem with the nic in 184.108.40.206.
Well, try putting nic driver from 220.127.116.11 into latest kernel and see
I assume your kernel command line and config stayed the same, right?