From: Len B. <len...@in...> - 2004-02-17 06:57:41
|
On Mon, 2004-02-16 at 08:17, Thorsten Zachmann wrote: > Hello > On Monday 16 February 2004 07:10, Brown, Len wrote: > > >I tried pci=noacpi. No diference. > > >If I understand you right, I should wait a little bit before dealing > > >with this powersaving stuff. > > > > If the NIC were now working before attempting suspend/resume, then we'd > > need to get that fixed first. However, I think you're saying that the > > NIC _does_ work under normal conditions, and the failure is only after > > returning from S3. yes? > > > > It looks like I have the same problem on my Tecra S1. After a suspend (S3) the > network and sound are no longer working. > A ethereal trace shows that the interface still sends arp requests but is > unable to receive something. If I look at /proc/interrupts the counter for > the interrupt where the network card is connected is no longer incremented. > > > So this seems suspend/resume specific, and your use of pci=noacpi > > further suggests it has nothing to do with the initial interrupt > > assignments. > > pci=noacpi also didn't change the situation. > > > We've got a number of post-resume failures, and this issue is rising on > > the priority list -- so I expect we'll spend some time looking at it > > soon. > > I tried out the patches from bug report 1409 and 1661 but nothing changed. > > Please let me know if there is any information that I can provide to track the > problem down? need /proc/interrupts -- PIC or APIC mode? network interrupt shared with ACPI, other devices, or dedicated interrupt? We'll probably have to dump out the state of the interrupt controller after resume. for IOAPIC we can do that with print_IO_APIC. for PIC mode we'll need something else. -Len |