On 03/08/13 00:39, Bjorn Helgaas wrote:
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. BjornHi 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
Attachment:
acpidump.out.bz2
Description: BZip2 compressed data
