Bug 9830

Reply-To: akpm@linux-foundation.org

> On Sun, 27 Jan 2008 01:39:10 -0800 (PST) bugme-daemon@bugzilla.kernel.org
> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=9830
> 
>            Summary: After resume from hibernation, DVB-T tuners are find in
>                     reverse order than they were found while booting
>            Product: Drivers
>            Version: 2.5
>      KernelVersion: 2.6.24
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: high
>           Priority: P1
>          Component: USB
>         AssignedTo: greg@kroah.com
>         ReportedBy: cijoml@volny.cz
> 
> 
> Latest working kernel version: unknown
> Earliest failing kernel version: 2.6.23
> Distribution: Debian stable
> Hardware Environment: Pentium M laptop, 2 dvb-t dongles
> Software Environment: Debian stable, 2.6.24-vanilla
> Problem Description:
> 
> I own 2 DVB-T dongles which are connected to 2 external antenas. When booting
> system discovers them i some order, when I suspend to disk and resume back
> system finds them in revers order. This is maybe acceptable with different
> devices, but when using it with external antennas I need physically swap
> cables! 
> Dongle's drivers also don't have suspend/resume methods.
> 
> Steps to reproduce:
> 
> suspend/resume see dmesg
> 
> usb 4-4: new high speed USB device using ehci_hcd and address 32
> usb 4-4: configuration #1 chosen from 1 choice
> dvb-usb: found a 'Leadtek Winfast DTV Dongle (STK7700P based)' in cold state,
> will try to load a firmware
> dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.10.fw'
> dib0700: firmware started successfully.
> dvb-usb: found a 'Leadtek Winfast DTV Dongle (STK7700P based)' in warm state.
> i2c-adapter i2c-5: SMBus Quick command not supported, can't probe for chips
> dvb-usb: will pass the complete MPEG2 transport stream to the software
> demuxer.
> DVB: registering new adapter (Leadtek Winfast DTV Dongle (STK7700P based))
> i2c-adapter i2c-6: SMBus Quick command not supported, can't probe for chips
> DVB: registering frontend 0 (DiBcom 7000MA/MB/PA/PB/MC)...
> MT2060: successfully identified (IF1 = 1220)
> input: IR-receiver inside an USB DVB receiver as
> /devices/pci0000:00/0000:00:1d.7/usb4/4-4/input/input24
> dvb-usb: schedule remote query interval to 150 msecs.
> dvb-usb: Leadtek Winfast DTV Dongle (STK7700P based) successfully initialized
> and connected.
> usb 1-2: new full speed USB device using uhci_hcd and address 11
> usb 1-2: configuration #1 chosen from 1 choice
> usb 4-1: USB disconnect, address 30
> dvb-usb: generic DVB-USB module successfully deinitialized and disconnected.
> usb 4-1: new high speed USB device using ehci_hcd and address 33
> usb 4-1: configuration #1 chosen from 1 choice
> dvb-usb: found a 'WideView WT-220U PenType Receiver (Typhoon/Freecom)' in
> warm
> state.
> dvb-usb: will use the device's hardware PID filter (table count: 15).
> DVB: registering new adapter (WideView WT-220U PenType Receiver
> (Typhoon/Freecom))
> DVB: registering frontend 1 (WideView USB DVB-T)...
> input: IR-receiver inside an USB DVB receiver as
> /devices/pci0000:00/0000:00:1d.7/usb4/4-1/input/input25
> dvb-usb: schedule remote query interval to 300 msecs.
> dvb-usb: WideView WT-220U PenType Receiver (Typhoon/Freecom) successfully
> initialized and connected.
> dvb-usb: recv bulk message failed: -110

hm.  Do we think this is a driver-cre thing, or a DVB thing?  Or even a USB
thing?

On Sunday, 27 of January 2008, Andrew Morton wrote:
> > On Sun, 27 Jan 2008 01:39:10 -0800 (PST) bugme-daemon@bugzilla.kernel.org
> wrote:
>>
> > Latest working kernel version: unknown
> > Earliest failing kernel version: 2.6.23
> > Distribution: Debian stable
> > Hardware Environment: Pentium M laptop, 2 dvb-t dongles
> > Software Environment: Debian stable, 2.6.24-vanilla
> > Problem Description:
> > 
> > I own 2 DVB-T dongles which are connected to 2 external antenas. When
> booting
> > system discovers them i some order, when I suspend to disk and resume back
> > system finds them in revers order. This is maybe acceptable with different
> > devices, but when using it with external antennas I need physically swap
> > cables! 
> > Dongle's drivers also don't have suspend/resume methods.

Ah.  Maybe they don't need them ...
 
> hm.  Do we think this is a driver-cre thing, or a DVB thing?  Or even a USB
> thing?

I suspect it may be a USB thing.

However, it's strange anyway, because devices are resumed in the same order in
which they are registered, at least on the PM core level.

Hi Rafael,

I thinik suspend/resume methods are needed because when suspend and kaffeine playing after resume it doesn't even load firmware (it should load firmware, tune to propher frequency etc...) until kaffeine is closed. But it is different think - I can live with killing kaffeine first, but resuming with different order makes me really crazy :(

Let's try to see what's going on.

Please apply the patches from:
http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.24/patches/
(at least up to patch 11) on top of 2.6.24.  With that installed try:

# echo core > /sys/power/pm_test
# echo disk > /sys/power/state

and see if the devices will come up in the reverse order.  If that happens, please attach full dmesg (including the boot sequence).

You can get some more useful information by building a kernel with CONFIG_USB_DEBUG enabled.  Attach the complete dmesg log for a suspend/resume cycle.  I suspect the problem is that your DVB devices aren't being suspended at all -- they are being powered down.

Cijoml, did you have chance to try debug as suggested in #4 and #5? Or have you tested with the latest kernel? - thanks.

Kernel 2.6.26 introduces the adapter_nr module option to dvb adapter drivers.  You can use this module option to enforce device minor.

If you don't want to wait for 2.6.26, then feel free to update to the latest v4l-dvb drivers hosted on linuxtv.org

You could also use udev, instead.... but adapter_nr module option is _much_ more user-friendly.

nice thanks for letting me know - I will try.

seems to be fixed :-)