On 03/07/13 17:30, Bjorn Helgaas wrote: > On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton wrote: >> >> >> On 03/06/13 23:45, Bjorn Helgaas wrote: >>> >>> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton >>> 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. > > OK. There are several potential problems here. > > 1) The change to make scandvb find some channels. This is probably a > cx23885 or linux-media issue, and I can't help with that. > > 2) TV picture/sound quality problem. Again, probably a cx23885 driver > issue, and I can't help with that. > I'm not going to use the card and I don't have the time (or patience) to submit the change again. > 3) HVR-1400 not being recognized when inserted. This is a PCI hotplug > issue, and I *can* help with this. I don't know what your hardware > is, but in general, pciehp should take care of this. If it doesn't, > or if you have to use an argument like "pcie_ports=native", we should > fix this. > > 4) Oops when removing HVR-1400 ExpressCard. From the backtrace, I > assume the cx23885 driver is still bound to the device when you remove > the card. It'd be nice if the driver could handle the device going > away, but I'm not surprised that it doesn't. > Nor am I, but it's hardly plug and play, is it. With Windows I can plug and unplug the card at will without crashing the system. > If you unbind the driver before removing the card, the oops should not > happen. You should be able to do this manually with something like > this (with the address of your device, of course): > > # echo 0000:05:00.0 > /sys/bus/pci/drivers/cx23885/unbind > > It would also be nice if there were a good user interface for doing > this, e.g., something like "Safely remove hardware" on Windows. But I > don't know what it is on Linux. > Thanks, I'll look into that and see if I can write a little panel applet to provide a UI. > So 3) is the thing I might be able to help with. If there's still a > problem here (and even having to boot with an argument is a problem), > let's start by collecting complete dmesg logs, with and without your > "pcie_ports" option. Boot without the card installed, then insert it > and remove it. If you can use something like v3.9-rc1 with > CONFIG_HOTPLUG_PCI_PCIE=y, that would be ideal. > OK, I've gathered these logs using a kernel built from a pull of Linus' tree this afternoon (v3.9-rc1-108-g9f22578). Also, the cx23885 driver is still blacklisted to avoid unnecessary noise and the chance of an oops if the card springs out again when I insert it. The driver does load if it's not blacklisted (and the pcie_ports=native option is present). The two logs are attached. As you will see, nothing at all happens when the pcie_ports=native option is absent. The nf_conntrack message is normally the last one from a normal boot. Chris > Bjorn >