On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton <[email protected]> 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
On 03/06/13 23:45, Bjorn Helgaas wrote:
> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton <[email protected]> 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.
Anyway, here's most of a call trace from an oops I triggered a few
minutes ago. (The screen went blank,so I didn't get it all)
cx23885_sram_channel_dump+0x20b/0x220
cx23885_video_irq+0xf3/0x1c0
cx23885_irq+0x39b/0x7e0
queue_interrupt_event+0x46/0x70
cpuidle_wrap_enter+0x38/0x90
handle_irq_event_percpu+0x2e/0x140
io_apic_modify_irq.isra.17+0x4a/0x60
handle_irq_event+0x34/0x60
unmask_irq+0x20/0x20
handle_fasteoi_irq+0x46/0xd0
<IRQ>
do_irq+0x3d/0xc0
get_next_timer_interrupt+0x1af/0x2b0
common_interrupt+0x2c/0x31
The top three functions are the same as in my first oops report. From
there down it is different, but, I've changed a few things in my kernel
config since then. I've also attached the .config.
Let me know if I can provide any additional diagnostics.
Chris
On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton <[email protected]> wrote:
>
>
> On 03/06/13 23:45, Bjorn Helgaas wrote:
>>
>> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton <[email protected]>
>> 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.
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.
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.
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.
Bjorn
On 03/07/13 17:30, Bjorn Helgaas wrote:
> On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton <[email protected]> wrote:
>>
>>
>> On 03/06/13 23:45, Bjorn Helgaas wrote:
>>>
>>> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton <[email protected]>
>>> 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
>
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton <[email protected]> wrote:
>
>
> On 03/07/13 17:30, Bjorn Helgaas wrote:
>>
>> On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton <[email protected]>
>> wrote:
>>>
>>>
>>>
>>> On 03/06/13 23:45, Bjorn Helgaas wrote:
>>>>
>>>>
>>>> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton
>>>> <[email protected]>
>>>> 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
On 03/08/13 00:39, Bjorn Helgaas wrote:
> On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton <[email protected]> wrote:
>>
>>
>> On 03/07/13 17:30, Bjorn Helgaas wrote:
>>>
>>> On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton <[email protected]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 03/06/13 23:45, Bjorn Helgaas wrote:
>>>>>
>>>>>
>>>>> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton
>>>>> <[email protected]>
>>>>> 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
>
[+cc Rafael, in case the _OSC thing rings a bell with him]
On Fri, Mar 8, 2013 at 3:44 AM, Chris Clayton <[email protected]> wrote:
> On 03/08/13 00:39, Bjorn Helgaas wrote:
>> On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton <[email protected]>
>> wrote:
>>> On 03/07/13 17:30, Bjorn Helgaas wrote:
>>>> 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.
>>>> 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.
Thanks. I opened this bug report:
https://bugzilla.kernel.org/show_bug.cgi?id=54981 to keep track of
your logs.
Here's your _OSC method from the acpidump:
Method (_OSC, 4, Serialized) {
...
If (LAnd (LEqual (Arg0, GUID), NEXP))
... # normal case
Else {
Or (CDW1, 0x04, CDW1) # "unrecognized UUID" error
Return (Local0)
}
It fails with "unrecognized UUID" if either (1) we supply the wrong
UUID or (2) "NEXP" is false. I have no idea what NEXP is; your
DSDT.dsl never sets it, so maybe it's related to a BIOS setup option
or something? I found a BIOS manual [1] but didn't see anything
likely. I guess it might be worth you looking, or maybe trying a
"reset to defaults" if it's not too destructive for you. You don't
have a copy of Windows on that box, do you? I *assume* hotplug would
work fine with Windows and maybe we could figure out what it is doing
differently.
Bjorn
[1] http://solutions.us.fujitsu.com/www/content/pdf/SupportGuides/AH530_BIOS_Guide_FPC58-2843-01_rA.pdf
Hi Bjorn,
On 03/08/13 22:57, Bjorn Helgaas wrote:
> [+cc Rafael, in case the _OSC thing rings a bell with him]
>
> On Fri, Mar 8, 2013 at 3:44 AM, Chris Clayton <[email protected]> wrote:
>> On 03/08/13 00:39, Bjorn Helgaas wrote:
>>> On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton <[email protected]>
>>> wrote:
>>>> On 03/07/13 17:30, Bjorn Helgaas wrote:
>
>>>>> 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.
>
>>>>> 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.
>
> Thanks. I opened this bug report:
> https://bugzilla.kernel.org/show_bug.cgi?id=54981 to keep track of
> your logs.
>
Excellent, thanks.
> Here's your _OSC method from the acpidump:
>
> Method (_OSC, 4, Serialized) {
> ...
> If (LAnd (LEqual (Arg0, GUID), NEXP))
> ... # normal case
> Else {
> Or (CDW1, 0x04, CDW1) # "unrecognized UUID" error
> Return (Local0)
> }
>
> It fails with "unrecognized UUID" if either (1) we supply the wrong
> UUID or (2) "NEXP" is false. I have no idea what NEXP is; your
> DSDT.dsl never sets it, so maybe it's related to a BIOS setup option
> or something? I found a BIOS manual [1] but didn't see anything
> likely. I guess it might be worth you looking, or maybe trying a
> "reset to defaults" if it's not too destructive for you. You don't
As the manual showed, there aren't too many user-changeable settings in
the BIOS on this machine, so I tried a "reset to defaults".
Unfortunately, it made no difference.
> have a copy of Windows on that box, do you? I *assume* hotplug would
> work fine with Windows and maybe we could figure out what it is doing
> differently.
>
Yes, I have Windows 7 Home Premium (64 bit), although, as I said
previously, I rarely boot it. One occasion when I usually do is when I
buy new hardware. The hotplug works fine in Windows with the two
expresscards that I own.
I'm happy to help work out what's different on Windows, but I have no
diagnostic tools installed, so I might need some hand-holding. One
immediate difference is that my Windows installation is 64bit whereas my
linux installation is 32 bit.
Thanks for your help so far,
Chris
> Bjorn
>
> [1] http://solutions.us.fujitsu.com/www/content/pdf/SupportGuides/AH530_BIOS_Guide_FPC58-2843-01_rA.pdf
>
On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton <[email protected]> wrote:
> Hi Bjorn,
>
>
> On 03/08/13 22:57, Bjorn Helgaas wrote:
>>
>> [+cc Rafael, in case the _OSC thing rings a bell with him]
>>
>> On Fri, Mar 8, 2013 at 3:44 AM, Chris Clayton <[email protected]>
>> wrote:
>>>
>>> On 03/08/13 00:39, Bjorn Helgaas wrote:
>>>>
>>>> On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton <[email protected]>
>>>> wrote:
>>>>>
>>>>> On 03/07/13 17:30, Bjorn Helgaas wrote:
>>>> 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.
>>
>>
>> Thanks. I opened this bug report:
>> https://bugzilla.kernel.org/show_bug.cgi?id=54981 to keep track of
>> your logs.
>>
>
> Excellent, thanks.
>
>
>> Here's your _OSC method from the acpidump:
>>
>> Method (_OSC, 4, Serialized) {
>> ...
>> If (LAnd (LEqual (Arg0, GUID), NEXP))
>> ... # normal case
>> Else {
>> Or (CDW1, 0x04, CDW1) # "unrecognized UUID" error
>> Return (Local0)
>> }
>>
>> It fails with "unrecognized UUID" if either (1) we supply the wrong
>> UUID or (2) "NEXP" is false. I have no idea what NEXP is; your
>> DSDT.dsl never sets it, so maybe it's related to a BIOS setup option
>> or something? I found a BIOS manual [1] but didn't see anything
>> likely. I guess it might be worth you looking, or maybe trying a
>> "reset to defaults" if it's not too destructive for you. You don't
>
>
> As the manual showed, there aren't too many user-changeable settings in the
> BIOS on this machine, so I tried a "reset to defaults". Unfortunately, it
> made no difference.
Yeah, no surprise, I guess, since it works fine in Windows with the
current BIOS settings.
I looked at the DSDTs from several other machines and quite a few of
them use similar NEXP tests. NEXP is in the GNVS area, which is
apparently used for communication between BIOS/ACPI/SMI, and I think
it means "Native PCIe support." The BIOS probably initializes it,
possibly based on the machine type or something.
The _OSC description (ACPI 5.0 sec 6.2.10.3) is pretty clear that if a
host bridge doesn't have an _OSC method, the OS should not use
features like PCIe native hotplug. That's why the Linux pciehp driver
isn't doing anything here. It's possible that Windows is using PCIe
native hotplug anyway (maybe they figure "unrecognized UUID" is
different from _OSC being completely absent), or maybe there's some
way it could be using ACPI hotplug (though I *think* that would
require some more methods that your box doesn't suppy).
My guess is the former, and maybe we can figure out a way to relax
Linux's strictness around _OSC handling.
Bjorn
On Tue, Mar 12, 2013 at 4:20 PM, Bjorn Helgaas <[email protected]> wrote:
> On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton <[email protected]> wrote:
>> On 03/08/13 22:57, Bjorn Helgaas wrote:
>>> Thanks. I opened this bug report:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=54981 to keep track of
>>> your logs.
Hi Chris,
The current Linux acpiphp driver doesn't do anything unless it finds
devices with _EJ0 or _RMV methods, and your DSDT has neither. But I
think that implementation is incorrect because I'm not convinced that
those methods are required in order to do hotplug via ACPI. For
example, your DSDT *does* have an _L01 method that does notifications
to the root ports. I suspect that hotplug events on your box generate
an SCI that invokes that method. Linux basically ignores the
resulting notify events, and I suspect that hotplug works on Windows
because it is paying attention to them.
Can you build a kernel with CONFIG_ACPI_DEBUG=y, do the following, and
attach all the output to the bugzilla?
1) Boot with empty ExpressCard slot (without using "pcie_ports=native")
2) # echo 0x00010004 > /sys/module/acpi/parameters/debug_layer
3) # echo 0x08000004 > /sys/module/acpi/parameters/debug_level
4) # lspci -vv
5) # setpci -s 1c.3 0x42.w
6) # setpci -s 1c.3 0x5a.w
7) # setpci -s 1c.3 0xd8.l
8) Insert ExpressCard
9) # setpci -s 1c.3 0x5a.w
10) # dmesg
Here's what I think we'll see:
- Slot Implemented (bit 8 of XCAP at 0x42) set, indicating a slot is
implemented below this root port
- Hot Plug SCI Enable (bit 30 of MPC at 0xd8) set, indicating that the
root port should generate an SCI whenever a hotplug event is detected
- Presence Detect State (bit 6 of SLTSTS at 0x5a) change from 0 with
the slot empty to 1 with the slot occupied
- pciehp doing nothing (since _OSC didn't grant the OS permission to
use PCIe native hotplug)
- dmesg indication of the SCI, leading to a Bus Check notification to
\_SB.PCI0.RP04, which is the 1c.3 root port leading to the ExpressCard
slot
A Bus Check notification means we're supposed to re-enumerate starting
at that device. If we *did* re-enumerate, we would find the new
ExpressCard.
Thanks,
Bjorn
Hi Bjorn,
Sorry I meant to reply to your mail so that copy recipients will know
the outcome of the things you asked me to do. But then I forgot. Doh!
You should have received the attachment notification from bugzilla, I think.
On 03/15/13 22:48, Bjorn Helgaas wrote:
> On Tue, Mar 12, 2013 at 4:20 PM, Bjorn Helgaas <[email protected]> wrote:
>> On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton <[email protected]> wrote:
>>> On 03/08/13 22:57, Bjorn Helgaas wrote:
>
>>>> Thanks. I opened this bug report:
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=54981 to keep track of
>>>> your logs.
>
> Hi Chris,
>
> The current Linux acpiphp driver doesn't do anything unless it finds
> devices with _EJ0 or _RMV methods, and your DSDT has neither. But I
> think that implementation is incorrect because I'm not convinced that
> those methods are required in order to do hotplug via ACPI. For
> example, your DSDT *does* have an _L01 method that does notifications
> to the root ports. I suspect that hotplug events on your box generate
> an SCI that invokes that method. Linux basically ignores the
> resulting notify events, and I suspect that hotplug works on Windows
> because it is paying attention to them.
>
> Can you build a kernel with CONFIG_ACPI_DEBUG=y, do the following, and
> attach all the output to the bugzilla?
>
> 1) Boot with empty ExpressCard slot (without using "pcie_ports=native")
> 2) # echo 0x00010004 > /sys/module/acpi/parameters/debug_layer
> 3) # echo 0x08000004 > /sys/module/acpi/parameters/debug_level
> 4) # lspci -vv
> 5) # setpci -s 1c.3 0x42.w
> 6) # setpci -s 1c.3 0x5a.w
> 7) # setpci -s 1c.3 0xd8.l
> 8) Insert ExpressCard
> 9) # setpci -s 1c.3 0x5a.w
> 10) # dmesg
>
> Here's what I think we'll see:
>
> - Slot Implemented (bit 8 of XCAP at 0x42) set, indicating a slot is
> implemented below this root port
> - Hot Plug SCI Enable (bit 30 of MPC at 0xd8) set, indicating that the
> root port should generate an SCI whenever a hotplug event is detected
> - Presence Detect State (bit 6 of SLTSTS at 0x5a) change from 0 with
> the slot empty to 1 with the slot occupied
> - pciehp doing nothing (since _OSC didn't grant the OS permission to
> use PCIe native hotplug)
> - dmesg indication of the SCI, leading to a Bus Check notification to
> \_SB.PCI0.RP04, which is the 1c.3 root port leading to the ExpressCard
> slot
>
As far as I can see, your predicted outcomes where correct. I've added
the logs to the bugzilla report.
> A Bus Check notification means we're supposed to re-enumerate starting
> at that device. If we *did* re-enumerate, we would find the new
> ExpressCard.
>
> Thanks,
> Bjorn
>
Thanks,
Chris
On Tue, Mar 19, 2013 at 9:46 AM, Chris Clayton <[email protected]> wrote:
> Hi Bjorn,
>
> Sorry I meant to reply to your mail so that copy recipients will know the
> outcome of the things you asked me to do. But then I forgot. Doh! You should
> have received the attachment notification from bugzilla, I think.
>
>
> On 03/15/13 22:48, Bjorn Helgaas wrote:
>>
>> On Tue, Mar 12, 2013 at 4:20 PM, Bjorn Helgaas <[email protected]>
>> wrote:
>>>
>>> On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton <[email protected]>
>>> wrote:
>>>>
>>>> On 03/08/13 22:57, Bjorn Helgaas wrote:
>>
>>
>>>>> Thanks. I opened this bug report:
>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=54981 to keep track of
>>>>> your logs.
>>
>>
>> Hi Chris,
>>
>> The current Linux acpiphp driver doesn't do anything unless it finds
>> devices with _EJ0 or _RMV methods, and your DSDT has neither. But I
>> think that implementation is incorrect because I'm not convinced that
>> those methods are required in order to do hotplug via ACPI. For
>> example, your DSDT *does* have an _L01 method that does notifications
>> to the root ports. I suspect that hotplug events on your box generate
>> an SCI that invokes that method. Linux basically ignores the
>> resulting notify events, and I suspect that hotplug works on Windows
>> because it is paying attention to them.
>>
>> Can you build a kernel with CONFIG_ACPI_DEBUG=y, do the following, and
>> attach all the output to the bugzilla?
>>
>> 1) Boot with empty ExpressCard slot (without using "pcie_ports=native")
>> 2) # echo 0x00010004 > /sys/module/acpi/parameters/debug_layer
>> 3) # echo 0x08000004 > /sys/module/acpi/parameters/debug_level
>> 4) # lspci -vv
>> 5) # setpci -s 1c.3 0x42.w
>> 6) # setpci -s 1c.3 0x5a.w
>> 7) # setpci -s 1c.3 0xd8.l
>> 8) Insert ExpressCard
>> 9) # setpci -s 1c.3 0x5a.w
>> 10) # dmesg
>>
>> Here's what I think we'll see:
>>
>> - Slot Implemented (bit 8 of XCAP at 0x42) set, indicating a slot is
>> implemented below this root port
>> - Hot Plug SCI Enable (bit 30 of MPC at 0xd8) set, indicating that the
>> root port should generate an SCI whenever a hotplug event is detected
>> - Presence Detect State (bit 6 of SLTSTS at 0x5a) change from 0 with
>> the slot empty to 1 with the slot occupied
>> - pciehp doing nothing (since _OSC didn't grant the OS permission to
>> use PCIe native hotplug)
>> - dmesg indication of the SCI, leading to a Bus Check notification to
>> \_SB.PCI0.RP04, which is the 1c.3 root port leading to the ExpressCard
>> slot
>>
>
> As far as I can see, your predicted outcomes where correct. I've added the
> logs to the bugzilla report.
Yes, it behaved exactly as I expected. I attached a few more details
of the analysis to the bug report
(https://bugzilla.kernel.org/show_bug.cgi?id=54981). I think we need
to rework acpiphp to fix this. We will fix it, but I don't know who
will do it, or when it will happen. My list is growing faster than I
can deal with :(
Thanks very much for your excellent data collection!
Bjorn
Hello again, Bjorn.
On 04/01/13 18:28, Bjorn Helgaas wrote:
<snip>
>>> Hi Chris,
>>>
>>> The current Linux acpiphp driver doesn't do anything unless it finds
>>> devices with _EJ0 or _RMV methods, and your DSDT has neither. But I
>>> think that implementation is incorrect because I'm not convinced that
>>> those methods are required in order to do hotplug via ACPI. For
>>> example, your DSDT *does* have an _L01 method that does notifications
>>> to the root ports. I suspect that hotplug events on your box generate
>>> an SCI that invokes that method. Linux basically ignores the
>>> resulting notify events, and I suspect that hotplug works on Windows
>>> because it is paying attention to them.
>>>
>>> Can you build a kernel with CONFIG_ACPI_DEBUG=y, do the following, and
>>> attach all the output to the bugzilla?
>>>
>>> 1) Boot with empty ExpressCard slot (without using "pcie_ports=native")
>>> 2) # echo 0x00010004 > /sys/module/acpi/parameters/debug_layer
>>> 3) # echo 0x08000004 > /sys/module/acpi/parameters/debug_level
>>> 4) # lspci -vv
>>> 5) # setpci -s 1c.3 0x42.w
>>> 6) # setpci -s 1c.3 0x5a.w
>>> 7) # setpci -s 1c.3 0xd8.l
>>> 8) Insert ExpressCard
>>> 9) # setpci -s 1c.3 0x5a.w
>>> 10) # dmesg
>>>
>>> Here's what I think we'll see:
>>>
>>> - Slot Implemented (bit 8 of XCAP at 0x42) set, indicating a slot is
>>> implemented below this root port
>>> - Hot Plug SCI Enable (bit 30 of MPC at 0xd8) set, indicating that the
>>> root port should generate an SCI whenever a hotplug event is detected
>>> - Presence Detect State (bit 6 of SLTSTS at 0x5a) change from 0 with
>>> the slot empty to 1 with the slot occupied
>>> - pciehp doing nothing (since _OSC didn't grant the OS permission to
>>> use PCIe native hotplug)
>>> - dmesg indication of the SCI, leading to a Bus Check notification to
>>> \_SB.PCI0.RP04, which is the 1c.3 root port leading to the ExpressCard
>>> slot
>>>
>>
>> As far as I can see, your predicted outcomes where correct. I've added the
>> logs to the bugzilla report.
>
> Yes, it behaved exactly as I expected. I attached a few more details
> of the analysis to the bug report
> (https://bugzilla.kernel.org/show_bug.cgi?id=54981). I think we need
> to rework acpiphp to fix this. We will fix it, but I don't know who
> will do it, or when it will happen. My list is growing faster than I
> can deal with :(
>
I see that there has been quite a bit of work in the acpiphp area
recently. Is any of it intended to fix (or ease the subsequent fixing
of) this bug report, please?
It's not a big deal if it isn't - I do have a system that, via kernel
command line arguments, recognises expresscard devices when I plug them
into the slot. But when the release comes along that includes the
reworking of acpiphp that you mentioned, I will give extra attention to
hotplugging when I try out the -rc kernels on my laptop.
Thanks
> Thanks very much for your excellent data collection!
>
It's my pleasure!
> Bjorn
>
On Tue, Jul 9, 2013 at 3:35 AM, Chris Clayton <[email protected]> wrote:
> Hello again, Bjorn.
>
> On 04/01/13 18:28, Bjorn Helgaas wrote:
>
> <snip>
>
>
>>>> Hi Chris,
>>>>
>>>> The current Linux acpiphp driver doesn't do anything unless it finds
>>>> devices with _EJ0 or _RMV methods, and your DSDT has neither. But I
>>>> think that implementation is incorrect because I'm not convinced that
>>>> those methods are required in order to do hotplug via ACPI. For
>>>> example, your DSDT *does* have an _L01 method that does notifications
>>>> to the root ports. I suspect that hotplug events on your box generate
>>>> an SCI that invokes that method. Linux basically ignores the
>>>> resulting notify events, and I suspect that hotplug works on Windows
>>>> because it is paying attention to them.
>>>>
>>>> Can you build a kernel with CONFIG_ACPI_DEBUG=y, do the following, and
>>>> attach all the output to the bugzilla?
>>>>
>>>> 1) Boot with empty ExpressCard slot (without using "pcie_ports=native")
>>>> 2) # echo 0x00010004 > /sys/module/acpi/parameters/debug_layer
>>>> 3) # echo 0x08000004 > /sys/module/acpi/parameters/debug_level
>>>> 4) # lspci -vv
>>>> 5) # setpci -s 1c.3 0x42.w
>>>> 6) # setpci -s 1c.3 0x5a.w
>>>> 7) # setpci -s 1c.3 0xd8.l
>>>> 8) Insert ExpressCard
>>>> 9) # setpci -s 1c.3 0x5a.w
>>>> 10) # dmesg
>>>>
>>>> Here's what I think we'll see:
>>>>
>>>> - Slot Implemented (bit 8 of XCAP at 0x42) set, indicating a slot is
>>>> implemented below this root port
>>>> - Hot Plug SCI Enable (bit 30 of MPC at 0xd8) set, indicating that the
>>>> root port should generate an SCI whenever a hotplug event is detected
>>>> - Presence Detect State (bit 6 of SLTSTS at 0x5a) change from 0 with
>>>> the slot empty to 1 with the slot occupied
>>>> - pciehp doing nothing (since _OSC didn't grant the OS permission to
>>>> use PCIe native hotplug)
>>>> - dmesg indication of the SCI, leading to a Bus Check notification to
>>>> \_SB.PCI0.RP04, which is the 1c.3 root port leading to the ExpressCard
>>>> slot
>>>>
>>>
>>> As far as I can see, your predicted outcomes where correct. I've added
>>> the
>>> logs to the bugzilla report.
>>
>>
>> Yes, it behaved exactly as I expected. I attached a few more details
>> of the analysis to the bug report
>> (https://bugzilla.kernel.org/show_bug.cgi?id=54981). I think we need
>> to rework acpiphp to fix this. We will fix it, but I don't know who
>> will do it, or when it will happen. My list is growing faster than I
>> can deal with :(
>>
>
> I see that there has been quite a bit of work in the acpiphp area recently.
> Is any of it intended to fix (or ease the subsequent fixing of) this bug
> report, please?
The problem on your system is that acpiphp doesn't work correctly
because it expects a certain combination of _ADR/_EJ0/_RMV methods,
and your system doesn't quite match. Rafael's acpiphp work is
definitely addressing that issue, but I don't know whether he's made
it far enough yet.
I doubt that work will appear in a v3.11-rc release, though. More
likely it will appear in -next fairly soon and will first appear in
Linus' tree in v3.12-rc1. So if you want to test it, either try out
-next or wait for v3.12-rc1.
> It's not a big deal if it isn't - I do have a system that, via kernel
> command line arguments, recognises expresscard devices when I plug them into
> the slot. But when the release comes along that includes the reworking of
> acpiphp that you mentioned, I will give extra attention to hotplugging when
> I try out the -rc kernels on my laptop.
Thanks! We'll certainly appreciate any testing reports.
Bjorn