2004-10-07 18:19:50

by Soeren Sonnenburg

[permalink] [raw]
Subject: hang after resume with adb: starting probe task.

As of at least kernel version 2.6.9-rc2 I pretty often see the kernel
hang after returning from sleep mode hanging with the message "adb:
starting with probe task". This still happens with 2.6.9-rc3 but never
happened with 2.6.8.1.

Thats what is on the screen when it hangs (no more possible to enter
xmon):

http://fortknox.dyndns.org/pics/oopses/adb.jpg

Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.


2004-10-07 23:10:55

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: hang after resume with adb: starting probe task.

On Fri, 2004-10-08 at 04:14, Soeren Sonnenburg wrote:
> As of at least kernel version 2.6.9-rc2 I pretty often see the kernel
> hang after returning from sleep mode hanging with the message "adb:
> starting with probe task". This still happens with 2.6.9-rc3 but never
> happened with 2.6.8.1.

I doubt it has anything to do with ADB. The ADB probe is asynchronous,
it's more something that is coming back at the same time that is
crashing, maybe ethernet link, or USB... Can you try without anything
plugged in ethernet if you had anything of course ? and with nothing
in USB as well ?

Ben.


2004-10-08 11:20:22

by Soeren Sonnenburg

[permalink] [raw]
Subject: Re: hang after resume with adb: starting probe task.

On Fri, 2004-10-08 at 08:58 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2004-10-08 at 04:14, Soeren Sonnenburg wrote:
> > As of at least kernel version 2.6.9-rc2 I pretty often see the kernel
> > hang after returning from sleep mode hanging with the message "adb:
> > starting with probe task". This still happens with 2.6.9-rc3 but never
> > happened with 2.6.8.1.
>
> I doubt it has anything to do with ADB. The ADB probe is asynchronous,
> it's more something that is coming back at the same time that is
> crashing, maybe ethernet link, or USB... Can you try without anything
> plugged in ethernet if you had anything of course ? and with nothing
> in USB as well ?

Actually there was nothing plugged into the ethernet nor usb port. Could
it also be the airport failing ? I still use orinoco cvs, i.e. airport
0.15rc2HEAD, but that one also on 2.6.8.1.

I now have a more or less reliable way of making this pbook crash: put
it to sleep and wake it up as soon it is sleeping.

HTH
Soeren
--
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." Benjamin Franklin

2004-10-09 01:04:18

by Benjamin Herrenschmidt

[permalink] [raw]
Subject: Re: hang after resume with adb: starting probe task.


> Actually there was nothing plugged into the ethernet nor usb port. Could
> it also be the airport failing ? I still use orinoco cvs, i.e. airport
> 0.15rc2HEAD, but that one also on 2.6.8.1.
>
> I now have a more or less reliable way of making this pbook crash: put
> it to sleep and wake it up as soon it is sleeping.

Difficult to say at this point. One thing possible is to add printk's
(or more violent btext_drawstring) when calling the sleep / wakeup
callbacks of drivers in drivers/base/power/* and drivers/macintosh/via-pmu.c
and try to figure where precisely it dies.

Ben.


2004-10-14 10:47:18

by Soeren Sonnenburg

[permalink] [raw]
Subject: Re: hang after resume with adb: starting probe task.

On Sat, 2004-10-09 at 11:03 +1000, Benjamin Herrenschmidt wrote:
> > Actually there was nothing plugged into the ethernet nor usb port. Could
> > it also be the airport failing ? I still use orinoco cvs, i.e. airport
> > 0.15rc2HEAD, but that one also on 2.6.8.1.
> >
> > I now have a more or less reliable way of making this pbook crash: put
> > it to sleep and wake it up as soon it is sleeping.
>
> Difficult to say at this point. One thing possible is to add printk's
> (or more violent btext_drawstring) when calling the sleep / wakeup
> callbacks of drivers in drivers/base/power/* and drivers/macintosh/via-pmu.c
> and try to figure where precisely it dies.

Well, I now realize that I turned on CONFIG_USB_SUSPEND which also
caused slightly different kernel messages. I turned this option off
again and had no crash since then (for 4 days).


w/o CONFIG_USB_SUSPEND:
========================
eth1: Airport entering sleep mode
eth0: suspending, WakeOnLan disabled
radeonfb: suspending to state: 3...
agpgart: Putting AGP V2 device at 0000:00:0b.0 into 0x mode
agpgart: Putting AGP V2 device at 0000:00:10.0 into 0x mode
radeonfb: switching to D2 state...
cpufreq: resume failed to assert current frequency is what timing core thinks it
is.
radeonfb: switching to D0 state...
radeonfb: resumed !
eth1: get_wireless_stats() called while device not present
enable_irq(27) unbalanced
enable_irq(28) unbalanced
eth0: resuming
eth1: get_wireless_stats() called while device not present
eth1: Airport waking up
ide_pmac: Set UDMA timing for mode 4, reg: 0x0c50038c
hda: Enabling Ultra DMA 4
hdc: MDMA, cycleTime: 120, accessTime: 90, recTime: 30
hdc: Set MDMA timing for mode 2, reg: 0x00011d26
hdc: Enabling MultiWord DMA 2
adb: starting probe task...
adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
ADB keyboard at 2, handler 1
ADB mouse at 3, handler set to 4 (trackpad)
adb: finished probe task...
PHY ID: 2060e1, addr: 0

with CONFIG_USB_SUSPEND:
========================
ohci_hcd 0001:10:19.0: Unlink after no-IRQ? Different ACPI or APIC settings may help.
ohci_hcd 0001:10:18.0: Unlink after no-IRQ? Different ACPI or APIC settings may help.
eth1: Airport entering sleep mode
eth0: suspending, WakeOnLan disabled
radeonfb: suspending to state: 3...
agpgart: Putting AGP V2 device at 0000:00:0b.0 into 0x mode
agpgart: Putting AGP V2 device at 0000:00:10.0 into 0x mode
radeonfb: switching to D2 state...
cpufreq: resume failed to assert current frequency is what timing core thinks it is.
radeonfb: switching to D0 state...
radeonfb: resumed !
enable_irq(27) unbalanced
enable_irq(28) unbalanced
eth0: resuming
eth1: Airport waking up
ide_pmac: Set UDMA timing for mode 4, reg: 0x0c50038c
hda: Enabling Ultra DMA 4
hdc: MDMA, cycleTime: 120, accessTime: 90, recTime: 30
hdc: Set MDMA timing for mode 2, reg: 0x00011d26
hdc: Enabling MultiWord DMA 2
hub 1-0:1.0: reactivate --> -22
hub 2-0:1.0: reactivate --> -22
adb: starting probe task...
adb devices: [2]: 2 c4 [3]: 3 1 [7]: 7 1f
ADB keyboard at 2, handler 1
ADB mouse at 3, handler set to 4 (trackpad)
adb: finished probe task...
PHY ID: 2060e1, addr: 0

Soeren
--
Sometimes, there's a moment as you're waking, when you become aware of
the real world around you, but you're still dreaming.