On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton <chris2553@xxxxxxxxxxxxxx> wrote: > > > On 03/07/13 17:30, Bjorn Helgaas wrote: >> >> On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton <chris2553@xxxxxxxxxxxxxx> >> wrote: >>> >>> >>> >>> On 03/06/13 23:45, Bjorn Helgaas wrote: >>>> >>>> >>>> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton >>>> <chris2553@xxxxxxxxxxxxxx> >>>> 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. >> 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? 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. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
