2005-09-13 09:58:37

by Jan De Luyck

[permalink] [raw]
Subject: ACPI S3 and ieee1394 don't get along

Hello lists,

Running kernel 2.6.13.1, no patches.

Yesterday, after putting my laptop into S3 and reviving it at home, the firewire interface was
unusable, no response when plugging in my external disk, loading sbp2 manually didn't trigger anything.

At this point I unloaded the ohci1394 module, and reloaded it:

Sep 12 16:59:52 precious kernel: ieee1394: Node removed: ID:BUS[0-00:1023] GUID[00c09f00000c8dfa]
Sep 12 16:59:52 precious kernel: ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]
Sep 12 16:59:53 precious kernel: ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]
Sep 12 16:59:57 precious kernel: ohci1394: $Rev: 1299 $ Ben Collins <[email protected]>
Sep 12 16:59:57 precious kernel: ACPI: PCI Interrupt 0000:02:07.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
Sep 12 16:59:57 precious kernel: PCI: Setting latency timer of device 0000:02:07.0 to 64
Sep 12 16:59:57 precious kernel: ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]
Sep 12 16:59:57 precious kernel: ohci1394: fw-host0: Runaway loop while stopping context: ...
Sep 12 16:59:58 precious last message repeated 3 times
Sep 12 16:59:58 precious kernel: ohci1394: fw-host0: OHCI-1394 165.165 (PCI): IRQ=[10] MMIO=[d0209000-d02097ff] Max Packet=[65536]
Sep 12 16:59:58 precious kernel: ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]
Sep 12 17:00:01 precious last message repeated 29 times
Sep 12 17:00:01 precious kernel: ohci1394: fw-host0: Serial EEPROM has suspicious values, attempting to setting max_packet_size to 512 bytes
Sep 12 17:00:02 precious kernel: ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]
Sep 12 17:00:31 precious last message repeated 2 times
Sep 12 17:00:39 precious kernel: ieee1394: Initialized config rom entry `ip1394'
Sep 12 17:00:39 precious kernel: ohci1394: $Rev: 1299 $ Ben Collins <[email protected]>
Sep 12 17:00:39 precious kernel: ACPI: PCI Interrupt 0000:02:07.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
Sep 12 17:00:40 precious kernel: ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]
Sep 12 17:00:40 precious kernel: ohci1394: fw-host0: Runaway loop while stopping context: ...
Sep 12 17:00:40 precious last message repeated 3 times
Sep 12 17:00:40 precious kernel: ohci1394: fw-host0: OHCI-1394 165.165 (PCI): IRQ=[10] MMIO=[d0209000-d02097ff] Max Packet=[65536]
Sep 12 17:00:40 precious kernel: ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]
Sep 12 17:00:43 precious last message repeated 29 times
Sep 12 17:00:43 precious kernel: ohci1394: fw-host0: Serial EEPROM has suspicious values, attempting to setting max_packet_size to 512 bytes
Sep 12 17:00:44 precious kernel: ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]

clearly it didn't really got back it's old state when returning from S3. Rebooting helped, but that's
what i'm trying to avoid by using S3 :p

lspci for the firewire interface:

0000:02:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
Subsystem: Acer Incorporated [ALI]: Unknown device 001f
Flags: bus master, medium devsel, latency 64, IRQ 10
Memory at d0209000 (32-bit, non-prefetchable) [size=2K]
Memory at d0200000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2

I saw this thread: http://marc.theaimsgroup.com/?l=linux1394-user&m=111262313930798&w=2 tho I'm not sure if it's relevant to this.

Any patches I might try? The linux1394.org site still is down, so nothing to dig on there ;)

For the firewire maintainers: great job you're doing on it!

Jan

--
Smoking is the leading cause of statistics.


2005-09-13 10:22:21

by Pavel Machek

[permalink] [raw]
Subject: Re: ACPI S3 and ieee1394 don't get along

Hi!

> Running kernel 2.6.13.1, no patches.
>
> Yesterday, after putting my laptop into S3 and reviving it at home, the firewire interface was
> unusable, no response when plugging in my external disk, loading sbp2 manually didn't trigger anything.
>

Last time I checked, you could still break ohci1394 be repeatedly
loading it and unloading it. Fix that first...
Pavel

--
if you have sharp zaurus hardware you don't need... you know my address

2005-09-14 00:18:28

by Stefan Richter

[permalink] [raw]
Subject: Re: ACPI S3 and ieee1394 don't get along

Jan De Luyck wrote:
> after putting my laptop into S3 and reviving it at home, the firewire
> interface was unusable, no response when plugging in my external disk,
> loading sbp2 manually didn't trigger anything.
[...]
> I saw this thread:
> http://marc.theaimsgroup.com/?l=linux1394-user&m=111262313930798&w=2
> tho I'm not sure if it's relevant to this.

IEEE 1394 power management (i.e. management of bus power consumption or
of other nodes' internal power states) is not related to ACPI suspend/
resume of the local controller AFAICS.

According to your log, the cause is to be looked for in ohci1394's
purely hardware related parts or perhaps even outside of the ieee1394
subsystem.
--
Stefan Richter
-=====-=-=-= =--= -===-
http://arcgraph.de/sr/

2005-09-14 00:20:45

by Stefan Richter

[permalink] [raw]
Subject: Re: ACPI S3 and ieee1394 don't get along

Pavel Machek wrote:
> Last time I checked, you could still break ohci1394 be repeatedly
> loading it and unloading it.

Do you have details available on that?

I never saw such a bug with the two PCI OHCI controllers I can currently
test. I'm not running any isochronous applications though.
--
Stefan Richter
-=====-=-=-= =--= -===-
http://arcgraph.de/sr/

2005-09-14 05:10:12

by Jan De Luyck

[permalink] [raw]
Subject: Re: ACPI S3 and ieee1394 don't get along

On Wednesday 14 September 2005 02:17, Stefan Richter wrote:
> Jan De Luyck wrote:
> > after putting my laptop into S3 and reviving it at home, the firewire
> > interface was unusable, no response when plugging in my external disk,
> > loading sbp2 manually didn't trigger anything.
>
> [...]
>
> > I saw this thread:
> > http://marc.theaimsgroup.com/?l=linux1394-user&m=111262313930798&w=2
> > tho I'm not sure if it's relevant to this.
>
> IEEE 1394 power management (i.e. management of bus power consumption or
> of other nodes' internal power states) is not related to ACPI suspend/
> resume of the local controller AFAICS.

I thought so. It was the only thing even remotely relevant I found on the mailinglists tho.

> According to your log, the cause is to be looked for in ohci1394's
> purely hardware related parts or perhaps even outside of the ieee1394
> subsystem.

I've attached the lspci -vvx before and after suspending to S3. There are a lot of differences,
but I have no idea how to interprete them :/

Here's what the diff gives:
devilkin@precious:/tmp$ diff -Nur before-s3 after-s3
--- before-s3 2005-09-14 07:05:58.797920320 +0200
+++ after-s3 2005-09-14 07:05:10.226304328 +0200
@@ -1,16 +1,15 @@
0000:02:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB21 IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
Subsystem: Acer Incorporated [ALI]: Unknown device 001f
- Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B-
+ Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
- Latency: 64 (500ns min, 1000ns max), Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 10
- Region 0: Memory at d0209000 (32-bit, non-prefetchable) [size=2K]
- Region 1: Memory at d0200000 (32-bit, non-prefetchable) [size=16K]
+ Region 0: [virtual] Memory at d0209000 (32-bit, non-prefetchable) [size=2K]
+ Region 1: [virtual] Memory at d0200000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
- Status: D0 PME-Enable- DSel=0 DScale=0 PME+
-00: 4c 10 26 80 16 01 10 02 00 10 00 0c 08 40 00 00
-10: 00 90 20 d0 00 00 20 d0 00 00 00 00 00 00 00 00
+ Status: D0 PME-Enable- DSel=0 DScale=0 PME-
+00: 4c 10 26 80 02 00 10 02 00 10 00 0c 00 00 00 00
+10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 25 10 1f 00
-30: 00 00 00 00 44 00 00 00 00 00 00 00 0a 01 02 04
+30: 00 00 00 00 44 00 00 00 00 00 00 00 00 01 02 04


--
Honi soit la vache qui rit.


Attachments:
(No filename) (2.76 kB)
after-s3 (939.00 B)
before-s3 (990.00 B)
Download all attachments

2005-09-14 08:47:07

by Pavel Machek

[permalink] [raw]
Subject: Re: ACPI S3 and ieee1394 don't get along

Hi!

> >Last time I checked, you could still break ohci1394 be repeatedly
> >loading it and unloading it.
>
> Do you have details available on that?
>
> I never saw such a bug with the two PCI OHCI controllers I can currently
> test. I'm not running any isochronous applications though.

I asked around and it seems to be gone in recent kernels. So sorry
about the noise.
Pavel
--
if you have sharp zaurus hardware you don't need... you know my address

2005-09-14 20:55:30

by Pavel Machek

[permalink] [raw]
Subject: Re: ACPI S3 and ieee1394 don't get along

Hi!

> > > after putting my laptop into S3 and reviving it at home, the firewire
> > > interface was unusable, no response when plugging in my external disk,
> > > loading sbp2 manually didn't trigger anything.
> >
> > [...]
> >
> > > I saw this thread:
> > > http://marc.theaimsgroup.com/?l=linux1394-user&m=111262313930798&w=2
> > > tho I'm not sure if it's relevant to this.
> >
> > IEEE 1394 power management (i.e. management of bus power consumption or
> > of other nodes' internal power states) is not related to ACPI suspend/
> > resume of the local controller AFAICS.
>
> I thought so. It was the only thing even remotely relevant I found on the mailinglists tho.
>
> > According to your log, the cause is to be looked for in ohci1394's
> > purely hardware related parts or perhaps even outside of the ieee1394
> > subsystem.
>
> I've attached the lspci -vvx before and after suspending to S3. There are a lot of differences,
> but I have no idea how to interprete them :/

pci_save_state/pci_restore_state missing somewhere?
Pavel

--
if you have sharp zaurus hardware you don't need... you know my address

2005-09-15 14:21:08

by Lukas Hejtmanek

[permalink] [raw]
Subject: Re: ACPI S3 and ieee1394 don't get along

Hello,

I found, that if you insert module ohci1394 before S3, than everything is ok
after resume.

Next, if you do not do that, then after resume modprobe ohci1394 fails:
(I added dump_stack() to see what happened)
ohci1394: $Rev: 1299 $ Ben Collins <[email protected]>
ACPI: PCI Interrupt 0000:01:01.1[B] -> GSI 16 (level, low) -> IRQ 16
ohci1394: fw-host0: Set PHY Reg timeout [0xffffffff/0x00004000/100]
[pg0+526438805/1069020160] set_phy_reg+0xc5/0xe0 [ohci1394]
[pg0+526440116/1069020160] ohci_initialize+0xb4/0x330 [ohci1394]
[pg0+526449792/1069020160] ohci_irq_handler+0x0/0x850 [ohci1394]
[request_irq+142/192] request_irq+0x8e/0xc0
[pg0+526457413/1069020160] ohci1394_pci_probe+0x455/0x6b0 [ohci1394]
[pg0+526449792/1069020160] ohci_irq_handler+0x0/0x850 [ohci1394]
[__pci_device_probe+95/112] __pci_device_probe+0x5f/0x70
[pci_device_probe+47/96] pci_device_probe+0x2f/0x60
[driver_probe_device+56/208] driver_probe_device+0x38/0xd0
[__driver_attach+0/80] __driver_attach+0x0/0x50
[__driver_attach+65/80] __driver_attach+0x41/0x50
[bus_for_each_dev+93/128] bus_for_each_dev+0x5d/0x80
[driver_attach+37/48] driver_attach+0x25/0x30
[__driver_attach+0/80] __driver_attach+0x0/0x50
[bus_add_driver+132/240] bus_add_driver+0x84/0xf0
[pci_register_driver+109/128] pci_register_driver+0x6d/0x80
[pg0+524607503/1069020160] ohci1394_init+0xf/0x11 [ohci1394]
[sys_init_module+330/512] sys_init_module+0x14a/0x200
[syscall_call+7/11] syscall_call+0x7/0xb
ohci1394: fw-host0: Runaway loop while stopping context: ...

However, module is loaded but nonfunctional. BUT if you do S3 again, then after
resume module can be unloaded and next modprobe ohci1394 is now working! (Tested
right now.)

--
Luk?? Hejtm?nek