Hi.

I think you'll find that the 'bad: scheduling while atomic' reports are
completely unrelated to whether the drivers works after suspend or not;
they simply reflect that drivers_resume is being called with
preempt_count > 0 (IRQs/preempt not reenabled after copying the image or
fpu not released).

Regards,

Nigel

On Thu, 2004-01-15 at 04:47, Mauro Andreolini wrote:
> Daniele Venzano wrote:
> 
>  >
>  >I added support for sis900 and the bash was being killed even before the
>  >driver had any support for suspend/resume.
>  >I reported that same problem (shell being killed) some time ago, there 
> was
>  >some follow up, but if I remember right no solution was found at the
>  >time.
>  >
>  >>>bad: scheduling while atomic!
>  >>>Call Trace:
>  >>> [<c0119d16>] schedule+0x586/0x590
>  >>> [<c0124f5c>] __mod_timer+0xfc/0x170
>  >>> [<c0125ab3>] schedule_timeout+0x63/0xc0
>  >>> [<c0125a40>] process_timeout+0x0/0x10
>  >>> [<c01da44b>] pci_set_power_state+0xeb/0x190
>  >>> [<ec947823>] sis900_resume+0x63/0x130 [sis900]
>  >>> [<c01dc9a6>] pci_device_resume+0x26/0x30
>  >
>  >
>  >I'll check this, the card keeps working after resume or not ?
>  >
>  >Thanks, bye.
>  >
> Hi Daniele,
> 
> the card does _not_ work after resume, both on 2.6.1-rc2 vanilla and 
> with Pavel's patch.
> I have to manually
> 
> rmmod sis900
> modprobe sis900
> ifconfig <ip> eth0 up
> 
> After that, it starts working again.
> 
> Bye
> Mauro Andreolini
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
My work on Software Suspend is graciously brought to you by
LinuxFund.org.