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:Hi Bjorn,
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
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.
A bziped file containing the output from acpidump is attached.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
Attachment:
acpidump.out.bz2
Description: BZip2 compressed data