Bug 9830 - After resume from hibernation, DVB-T tuners are find in reverse order than they were found while booting
Summary: After resume from hibernation, DVB-T tuners are find in reverse order than th...
Status: CLOSED CODE_FIX
Alias: None
Product: v4l-dvb
Classification: Unclassified
Component: dvb-usb (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Cijoml Cijomlovic Cijomlov
URL:
Keywords:
Depends on:
Blocks: 7216
  Show dependency tree
 
Reported: 2008-01-27 01:39 UTC by Cijoml Cijomlovic Cijomlov
Modified: 2008-12-06 05:05 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.24
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Cijoml Cijomlovic Cijomlov 2008-01-27 01:39:08 UTC
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
Comment 1 Anonymous Emailer 2008-01-27 02:16:06 UTC
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?
Comment 2 Rafael J. Wysocki 2008-01-27 03:04:07 UTC
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.
Comment 3 Cijoml Cijomlovic Cijomlov 2008-01-27 03:09:58 UTC
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 :(
Comment 4 Rafael J. Wysocki 2008-01-27 03:26:43 UTC
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).
Comment 5 Alan Stern 2008-01-28 07:22:47 UTC
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.
Comment 6 Natalie Protasevich 2008-06-02 14:47:38 UTC
Cijoml, did you have chance to try debug as suggested in #4 and #5? Or have you tested with the latest kernel? - thanks.
Comment 7 Michael Krufky 2008-06-02 15:46:13 UTC
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.
Comment 8 Cijoml Cijomlovic Cijomlov 2008-06-02 23:09:29 UTC
nice thanks for letting me know - I will try.
Comment 9 Cijoml Cijomlovic Cijomlov 2008-12-06 05:05:40 UTC
seems to be fixed :-)

Note You need to log in before you can comment on or make changes to this bug.