On 03/08/13 00:39, Bjorn Helgaas wrote: > On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton wrote: >> >> >> 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. > > I agree 100%, that sucks, and we should be able to do better. I > opened https://bugzilla.kernel.org/show_bug.cgi?id=54961 for this > issue. Hopefully a cx88 driver person will take a look. > Thanks and sorry, Bjorn. I didn't intend to offload that task onto someone else. The linux-media guys have so far been rather unresponsive on my problems with the card, and I didn't want to waste any more time on it. Let's see what happens - I won't be holding my breath, though :-) >>> 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. > > Perfect, thanks! > > It looks like something's going wrong when we evaluate _OSC. Can you > collect an acpidump from your machine? > A bziped file containing the output from acpidump is attached. > It's possible your machine just doesn't want us to use pciehp. Can > you set CONFIG_HOTPLUG_PCI_ACPI=y and try again (without > pcie_ports=native this time)? You can test with a different > ExpressCard if you want; this part of the problem isn't related to the > HVR-1400. > Ok. With the same kernel as I used yesterday I've run two tests. Firstly with both pciehp and acpiphp built statically into the kernel and secondly with only acpiphp (both without pcie_ports=native). In neither case was my pciexpress usb3 card detected when I plugged it in - that is, the last line output by dmesg is the normal one from nf_conntrack. I also turned on acpiphp debug and inserted the card, but again there was no new output. Chris > Bjorn >