Message-ID: <5138C03C.8080600@googlemail.com>
Date:	Thu, 07 Mar 2013 16:28:44 +0000
From:	Chris Clayton <chris2553@...glemail.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	Martin Mokrejs <mmokrejs@...d.natur.cuni.cz>,
	Yijing Wang <wangyijing@...wei.com>,
	Yijing Wang <wangyijing0307@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org
Subject: Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner



On 03/06/13 23:45, Bjorn Helgaas wrote:
> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton <chris2553@...glemail.com> wrote:
>
>> My usb3 expresscard device has arrived and I get an oops with that too, if I
>> remove it without unloading the driver first. I guess it shouldn't be a
>> surprise that the driver isn't expecting the device to disappear.
>>
>> As I mentioned, I have some trouble with the WinTV-HVR-1400 card, which
>> sometimes pops out again, if I push it into the slot too hard (but I'm
>> geeting better at that with practice). So what I've done (with the usb3 card
>> too) to avoid the oopsen is blacklist the driver in
>> /etc/modprobe.d/blacklist.conf and then load them when I'm sure the card is
>> properly inserted. Not exactly hotplug, but at least I don't have to reboot
>> because of an oops- and it's not something I'm doing several times an hour.
>
> Hi Chris,
>
> What's the current state of this?  It sounds to me like it still
> doesn't work out of the box.  Having to blacklist the driver and load
> it manually is a completely unacceptable user experience.  If you have
> to manually choose acpiphp over pciehp, that is also unacceptable.
>
> So if you're still limping along with hacky workarounds like this, I'd
> like to pursue this more and see if we can't figure out a better
> solution.
>
> Bjorn
>
Hi Bjorn,

If I unblacklist the driver, insert the HVR-1400 card and then remove 
it, I still get the oops. This is with kernel 3.8.2. I no longer get the 
oops with the USB3 card, but I don't know how or when that was fixed.

I stopped working on it when, after finding the workaround to the oops 
and then spending many many hours figuring out a fix so that scandvb 
would find some channels, no one on the linux-media list seemed 
interested in the fix. On top of that, even though scanning now finds 
all the available channels, the quality of the TV picture and sound is 
very poor indeed. I didn't want to bang my head against the linux-media 
wall again, so I abandoned the card and now use a USB TV stick, which 
gives is much better results than the card. It's a pity because the card 
also supports an analog signal which means I can watch the RF output 
from my satellite box, which I have piped around the house. Anyway, the 
linux-media folks are not your problem and if I want to watch satellite 
TV on my laptop, I can make one of my rare visits to Windows (where the 
picture and sound are good).

Having said (ranted?) all that, I would be more than happy to help fix 
the oops. After I first reported it, I realised that I didn't have a 
hotplug driver loaded. With help from Yijing Wang, we eventually managed 
to get the card recognised and drivers loaded when it is inserted. That 
doesn't help with the oops, though. I now have the pciehp driver 
compiled statically onto the kernel (and pass pcie_ports=native to the 
kernel), but removing the card with the cx23885 driver loaded always 
results in an oops. I originally reported this to the linux-media list 
because functions from the cx23885 driver are at the top of the call 
trace, but only Martin responded with some hotplug-related suggestions, 
which is what swung discussion the way of the linux-pci list.

Anyway, here's most of a call trace from an oops I triggered a few 
minutes ago. (The screen went blank,so I didn't get it all)

cx23885_sram_channel_dump+0x20b/0x220
cx23885_video_irq+0xf3/0x1c0
cx23885_irq+0x39b/0x7e0
queue_interrupt_event+0x46/0x70
cpuidle_wrap_enter+0x38/0x90
handle_irq_event_percpu+0x2e/0x140
io_apic_modify_irq.isra.17+0x4a/0x60
handle_irq_event+0x34/0x60
unmask_irq+0x20/0x20
handle_fasteoi_irq+0x46/0xd0
<IRQ>
do_irq+0x3d/0xc0
get_next_timer_interrupt+0x1af/0x2b0
common_interrupt+0x2c/0x31

The top three functions are the same as in my first oops report. From 
there down it is different, but, I've changed a few things in my kernel 
config since then. I've also attached the .config.

Let me know if I can provide any additional diagnostics.

Chris

Download attachment "config-3.8.2" of type "application/x-troff-man" (82313 bytes)

Powered by blists - more mailing lists