lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5138F6B6.8050208@googlemail.com>
Date:	Thu, 07 Mar 2013 20:21:10 +0000
From:	Chris Clayton <chris2553@...glemail.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
CC:	Martin Mokrejs <mmokrejs@...d.natur.cuni.cz>,
	Yijing Wang <wangyijing@...wei.com>,
	Yijing Wang <wangyijing0307@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner



On 03/07/13 17:30, Bjorn Helgaas wrote:
> On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton <chris2553@...glemail.com> wrote:
>>
>>
>> On 03/06/13 23:45, Bjorn Helgaas wrote:
>>>
>>> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton <chris2553@...glemail.com>
>>> 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
>

View attachment "dmesg-with-arg" of type "text/plain" (40467 bytes)

View attachment "dmesg-without-arg" of type "text/plain" (39455 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ