Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Tue, Jul 9, 2013 at 3:35 AM, Chris Clayton wrote: > Hello again, Bjorn. > > On 04/01/13 18:28, Bjorn Helgaas wrote: > > > > 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 0x0804 > /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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hello again, Bjorn. On 04/01/13 18:28, Bjorn Helgaas wrote: 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 0x0804 > /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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Tue, Jul 9, 2013 at 3:35 AM, Chris Clayton chris2...@gmail.com 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 0x0804 /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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
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 0x0804 /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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Tue, Mar 19, 2013 at 9:46 AM, Chris Clayton 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 >> wrote: >>> >>> On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton >>> 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 0x0804 > /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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Tue, Mar 19, 2013 at 9:46 AM, Chris Clayton chris2...@googlemail.com 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 bhelg...@google.com wrote: On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton chris2...@googlemail.com 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 0x0804 /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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
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 wrote: On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton 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 0x0804 > /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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
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 bhelg...@google.com wrote: On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton chris2...@googlemail.com 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 0x0804 /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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Tue, Mar 12, 2013 at 4:20 PM, Bjorn Helgaas wrote: > On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton > 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 0x0804 > /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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Tue, Mar 12, 2013 at 4:20 PM, Bjorn Helgaas bhelg...@google.com wrote: On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton chris2...@googlemail.com 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 0x0804 /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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton 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
>> wrote:
>>>
>>> On 03/08/13 00:39, Bjorn Helgaas wrote:
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Sat, Mar 9, 2013 at 2:20 AM, Chris Clayton chris2...@googlemail.com 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 chris2...@googlemail.com
wrote:
On 03/08/13 00:39, Bjorn Helgaas wrote:
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton chris2...@googlemail.com
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
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 wrote:
On 03/08/13 00:39, Bjorn Helgaas wrote:
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
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 chris2...@googlemail.com wrote:
On 03/08/13 00:39, Bjorn Helgaas wrote:
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton chris2...@googlemail.com
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
[+cc Rafael, in case the _OSC thing rings a bell with him]
On Fri, Mar 8, 2013 at 3:44 AM, Chris Clayton wrote:
> On 03/08/13 00:39, Bjorn Helgaas wrote:
>> On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton
>> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
[+cc Rafael, in case the _OSC thing rings a bell with him]
On Fri, Mar 8, 2013 at 3:44 AM, Chris Clayton chris2...@googlemail.com wrote:
On 03/08/13 00:39, Bjorn Helgaas wrote:
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton chris2...@googlemail.com
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton wrote: > > > On 03/07/13 17:30, Bjorn Helgaas wrote: >> >> On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton >> wrote: >>> >>> >>> >>> On 03/06/13 23:45, Bjorn Helgaas wrote: On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton 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. >>
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton wrote: > > > On 03/06/13 23:45, Bjorn Helgaas wrote: >> >> On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton >> 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 :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 -- To
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton chris2...@googlemail.com wrote: On 03/06/13 23:45, Bjorn Helgaas wrote: On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton chris2...@googlemail.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. 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 :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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Thu, Mar 7, 2013 at 1:21 PM, Chris Clayton chris2...@googlemail.com wrote: On 03/07/13 17:30, Bjorn Helgaas wrote: On Thu, Mar 7, 2013 at 9:28 AM, Chris Clayton chris2...@googlemail.com wrote: On 03/06/13 23:45, Bjorn Helgaas wrote: On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton chris2...@googlemail.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. 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
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On Thu, Jan 31, 2013 at 5:09 AM, Chris Clayton chris2...@googlemail.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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Chris Clayton wrote: > Hi Martin, > > On 01/28/13 21:02, Martin Mokrejs wrote: >> Hi Chris, >> >> Chris Clayton wrote: >>> Hi Martin, >>> >>> On 01/28/13 12:12, Martin Mokrejs wrote: Chris Clayton wrote: >>> >>> I've struggled with this a little. For some reason, the expresscard >>> doesn't always stay properly inserted in the slot when I insert it. >>> Now that hotplug is working, the modules are being loaded and when >>> the card pops out again, I get an oops because, of course, the driver >>> is running and the card disappears. Perhaps the driver can be made a >>> bit more robust to sudden disappearance of the card. I'll report the >> >> Yes, I had or maybe still have same issues here. I used to get an Oops >> for sata_sil24 card weird behavior for USB3.0 NEC-based card. It was >> fine always for a VIA-based firewire card and serial PL2303-based one. >> I found out it is better if a usb device is connected to the USB card >> because if that slips out then the libata layer quickly realizes that. >> If there was no device connected, the usb waits too long before it removes >> the usb hub from the system. And if you plugin the card meanwhile >> back into the slot, weird thing happen. >> > 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. I avoided the oopses when a USB device to connected to the express card. Nevertheless, you should report it to linux-usb and linux-pci mailing lists, along with the oops stacktrace (under a new thread). Maybe you suffer from another Oops. > > 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. Yeah, i also my way around - not fiddle much with the cards and if they slip out during insertion, don't re-plug them too quickly (at least with the USB3 card and SATA card I had problems). BTW, if you remove a card, you are supposed to push the card into the slot so it gets ejected. Do not just pull it out (what I did in the beginnings). I was told that is not the right way (probably affects the PresDet status). Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Martin, On 01/28/13 21:02, Martin Mokrejs wrote: Hi Chris, Chris Clayton wrote: Hi Martin, On 01/28/13 12:12, Martin Mokrejs wrote: Chris Clayton wrote: [snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. BTW, I have with acpiphp on 3.7.4: ls -la /sys/bus/pci_express/devices total 0 drwxr-xr-x 2 root root 0 Jan 28 13:07 . drwxr-xr-x 4 root root 0 Jan 28 13:07 .. $ ls -la /sys/bus/pci/devices/slots **typo** It should be /sys/bus/pci/slots. ls: cannot access /sys/bus/pci/devices/slots: No such file or directory $ With acpiphp, I get /sys/bus/pci_express/devices populated but /sys/bus/pci/slots is empty. OK, I haven't realized the typo, but I have here with acpiphp: # ls -laR /sys/bus/pci/slots /sys/bus/pci/slots: total 0 drwxr-xr-x 3 root root 0 Jan 27 17:14 . drwxr-xr-x 5 root root 0 Jan 25 15:56 .. drwxr-xr-x 2 root root 0 Jan 27 17:14 1 /sys/bus/pci/slots/1: total 0 drwxr-xr-x 2 root root0 Jan 27 17:14 . drwxr-xr-x 3 root root0 Jan 27 17:14 .. -r--r--r-- 1 root root 4096 Jan 28 21:31 adapter -r--r--r-- 1 root root 4096 Jan 27 17:14 address -rw-r--r-- 1 root root 4096 Jan 28 21:31 attention -r--r--r-- 1 root root 4096 Jan 28 21:31 cur_bus_speed -r--r--r-- 1 root root 4096 Jan 28 21:31 latch -r--r--r-- 1 root root 4096 Jan 28 21:31 max_bus_speed lrwxrwxrwx 1 root root0 Jan 28 21:31 module -> ../../../../module/acpiphp -rw-r--r-- 1 root root 4096 Jan 28 21:31 power # And for me hotplug also works (as far as I can tell). ;-) Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Would be fine if you could re-do the PresDet checks and confirm whether it is also broken for you under pciehp. I've struggled with this a little. For some reason, the expresscard doesn't always stay properly inserted in the slot when I insert it. Now that hotplug is working, the modules are being loaded and when the card pops out again, I get an oops because, of course, the driver is running and the card disappears. Perhaps the driver can be made a bit more robust to sudden disappearance of the card. I'll report the Yes, I had or maybe still have same issues here. I used to get an Oops for sata_sil24 card weird behavior for USB3.0 NEC-based card. It was fine always for a VIA-based firewire card and serial PL2303-based one. I found out it is better if a usb device is connected to the USB card because if that slips out then the libata layer quickly realizes that. If there was no device connected, the usb waits too long before it removes the usb hub from the system. And if you plugin the card meanwhile back into the slot, weird thing happen. 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. Chris oops later. Anyway, to run these tests I built a kernel without the dvb card's drivers, effectively simulating the situation I had before Yijing got hotplug working for me. The card popping out may also have affected these diffs a bit because, for example, the first one has the CorrErr flag changed, possibly because I had to have two or more goes at getting the card to lock in the slot. Yesterday that diff showed no changes. Anyway, here are the diffs: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt 262c262 < DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- --- DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- 295c295 < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 --- 40: 10 80 42 01 00 80 00 00 00 00 11 00 12 3c 12 04 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt BTW, with the NEC-based card only after every second removal of the card I got into PresDet- state. So, on every other diff attempt you won't see a difference! But we are talking about acpiphp here (unlike pciehp) and with that I also have no problems.
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Martin, On 01/28/13 21:02, Martin Mokrejs wrote: Hi Chris, Chris Clayton wrote: Hi Martin, On 01/28/13 12:12, Martin Mokrejs wrote: Chris Clayton wrote: [snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. BTW, I have with acpiphp on 3.7.4: ls -la /sys/bus/pci_express/devices total 0 drwxr-xr-x 2 root root 0 Jan 28 13:07 . drwxr-xr-x 4 root root 0 Jan 28 13:07 .. $ ls -la /sys/bus/pci/devices/slots **typo** It should be /sys/bus/pci/slots. ls: cannot access /sys/bus/pci/devices/slots: No such file or directory $ With acpiphp, I get /sys/bus/pci_express/devices populated but /sys/bus/pci/slots is empty. OK, I haven't realized the typo, but I have here with acpiphp: # ls -laR /sys/bus/pci/slots /sys/bus/pci/slots: total 0 drwxr-xr-x 3 root root 0 Jan 27 17:14 . drwxr-xr-x 5 root root 0 Jan 25 15:56 .. drwxr-xr-x 2 root root 0 Jan 27 17:14 1 /sys/bus/pci/slots/1: total 0 drwxr-xr-x 2 root root0 Jan 27 17:14 . drwxr-xr-x 3 root root0 Jan 27 17:14 .. -r--r--r-- 1 root root 4096 Jan 28 21:31 adapter -r--r--r-- 1 root root 4096 Jan 27 17:14 address -rw-r--r-- 1 root root 4096 Jan 28 21:31 attention -r--r--r-- 1 root root 4096 Jan 28 21:31 cur_bus_speed -r--r--r-- 1 root root 4096 Jan 28 21:31 latch -r--r--r-- 1 root root 4096 Jan 28 21:31 max_bus_speed lrwxrwxrwx 1 root root0 Jan 28 21:31 module - ../../../../module/acpiphp -rw-r--r-- 1 root root 4096 Jan 28 21:31 power # And for me hotplug also works (as far as I can tell). ;-) Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Would be fine if you could re-do the PresDet checks and confirm whether it is also broken for you under pciehp. I've struggled with this a little. For some reason, the expresscard doesn't always stay properly inserted in the slot when I insert it. Now that hotplug is working, the modules are being loaded and when the card pops out again, I get an oops because, of course, the driver is running and the card disappears. Perhaps the driver can be made a bit more robust to sudden disappearance of the card. I'll report the Yes, I had or maybe still have same issues here. I used to get an Oops for sata_sil24 card weird behavior for USB3.0 NEC-based card. It was fine always for a VIA-based firewire card and serial PL2303-based one. I found out it is better if a usb device is connected to the USB card because if that slips out then the libata layer quickly realizes that. If there was no device connected, the usb waits too long before it removes the usb hub from the system. And if you plugin the card meanwhile back into the slot, weird thing happen. 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. Chris oops later. Anyway, to run these tests I built a kernel without the dvb card's drivers, effectively simulating the situation I had before Yijing got hotplug working for me. The card popping out may also have affected these diffs a bit because, for example, the first one has the CorrErr flag changed, possibly because I had to have two or more goes at getting the card to lock in the slot. Yesterday that diff showed no changes. Anyway, here are the diffs: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt 262c262 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- --- DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- 295c295 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 --- 40: 10 80 42 01 00 80 00 00 00 00 11 00 12 3c 12 04 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt no difference BTW, with the NEC-based card only after every second removal of the card I got into PresDet- state. So, on every other diff attempt you won't see a difference! But we are talking about acpiphp here (unlike pciehp) and with that I also have no problems.
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Chris Clayton wrote: Hi Martin, On 01/28/13 21:02, Martin Mokrejs wrote: Hi Chris, Chris Clayton wrote: Hi Martin, On 01/28/13 12:12, Martin Mokrejs wrote: Chris Clayton wrote: I've struggled with this a little. For some reason, the expresscard doesn't always stay properly inserted in the slot when I insert it. Now that hotplug is working, the modules are being loaded and when the card pops out again, I get an oops because, of course, the driver is running and the card disappears. Perhaps the driver can be made a bit more robust to sudden disappearance of the card. I'll report the Yes, I had or maybe still have same issues here. I used to get an Oops for sata_sil24 card weird behavior for USB3.0 NEC-based card. It was fine always for a VIA-based firewire card and serial PL2303-based one. I found out it is better if a usb device is connected to the USB card because if that slips out then the libata layer quickly realizes that. If there was no device connected, the usb waits too long before it removes the usb hub from the system. And if you plugin the card meanwhile back into the slot, weird thing happen. 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. I avoided the oopses when a USB device to connected to the express card. Nevertheless, you should report it to linux-usb and linux-pci mailing lists, along with the oops stacktrace (under a new thread). Maybe you suffer from another Oops. 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. Yeah, i also my way around - not fiddle much with the cards and if they slip out during insertion, don't re-plug them too quickly (at least with the USB3 card and SATA card I had problems). BTW, if you remove a card, you are supposed to push the card into the slot so it gets ejected. Do not just pull it out (what I did in the beginnings). I was told that is not the right way (probably affects the PresDet status). Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Chris Clayton wrote: > Hi Martin, > > On 01/28/13 12:12, Martin Mokrejs wrote: >> Chris Clayton wrote: >>> >>> [snip] >>> [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 >>> ^^ >>>**typo** >>> I've run the test again with pcie_ports=native and the directories now get >>> populated. Even better though, is that when I plug in the card, hotplug >>> **works** and the card's drivers are loaded. >> >> BTW, I have with acpiphp on 3.7.4: >> >> ls -la /sys/bus/pci_express/devices >> total 0 >> drwxr-xr-x 2 root root 0 Jan 28 13:07 . >> drwxr-xr-x 4 root root 0 Jan 28 13:07 .. >> $ ls -la /sys/bus/pci/devices/slots > > **typo** > It should be /sys/bus/pci/slots. > >> ls: cannot access /sys/bus/pci/devices/slots: No such file or directory >> $ >> > With acpiphp, I get /sys/bus/pci_express/devices populated but > /sys/bus/pci/slots is empty. OK, I haven't realized the typo, but I have here with acpiphp: # ls -laR /sys/bus/pci/slots /sys/bus/pci/slots: total 0 drwxr-xr-x 3 root root 0 Jan 27 17:14 . drwxr-xr-x 5 root root 0 Jan 25 15:56 .. drwxr-xr-x 2 root root 0 Jan 27 17:14 1 /sys/bus/pci/slots/1: total 0 drwxr-xr-x 2 root root0 Jan 27 17:14 . drwxr-xr-x 3 root root0 Jan 27 17:14 .. -r--r--r-- 1 root root 4096 Jan 28 21:31 adapter -r--r--r-- 1 root root 4096 Jan 27 17:14 address -rw-r--r-- 1 root root 4096 Jan 28 21:31 attention -r--r--r-- 1 root root 4096 Jan 28 21:31 cur_bus_speed -r--r--r-- 1 root root 4096 Jan 28 21:31 latch -r--r--r-- 1 root root 4096 Jan 28 21:31 max_bus_speed lrwxrwxrwx 1 root root0 Jan 28 21:31 module -> ../../../../module/acpiphp -rw-r--r-- 1 root root 4096 Jan 28 21:31 power # > >> And for me hotplug also works (as far as I can tell). ;-) >> >>> >>> Excellent! Thank you so much for your help (and patience) Martin and Yijing. >>> >>> Now to solving why running scandvb doesn't find any TV channels. >> >> Would be fine if you could re-do the PresDet checks and confirm whether it >> is also broken >> for you under pciehp. > > I've struggled with this a little. For some reason, the expresscard > doesn't always stay properly inserted in the slot when I insert it. > Now that hotplug is working, the modules are being loaded and when > the card pops out again, I get an oops because, of course, the driver > is running and the card disappears. Perhaps the driver can be made a > bit more robust to sudden disappearance of the card. I'll report the Yes, I had or maybe still have same issues here. I used to get an Oops for sata_sil24 card weird behavior for USB3.0 NEC-based card. It was fine always for a VIA-based firewire card and serial PL2303-based one. I found out it is better if a usb device is connected to the USB card because if that slips out then the libata layer quickly realizes that. If there was no device connected, the usb waits too long before it removes the usb hub from the system. And if you plugin the card meanwhile back into the slot, weird thing happen. > oops later. Anyway, to run these tests I built a kernel without the > dvb card's drivers, effectively simulating the situation I had before > Yijing got hotplug working for me. The card popping out may also have > affected these diffs a bit because, for example, the first one has > the CorrErr flag changed, possibly because I had to have two or more > goes at getting the card to lock in the slot. Yesterday that diff > showed no changes. Anyway, here are the diffs: > > diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt > 262c262 > < DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ > TransPend- > --- >> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ >> TransPend- > 295c295 > < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 > --- >> 40: 10 80 42 01 00 80 00 00 00 00 11 00 12 3c 12 04 > > > diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt > > BTW, with the NEC-based card only after every second removal of the card I got into PresDet- state. So, on every other diff attempt you won't see a difference! But we are talking about acpiphp here (unlike pciehp) and with that I also have no problems. > > = > diff lspci.before_insertion.txt lspci.after_1st_removal.txt > 112c112 > < 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 08 c0 > --- >> 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 00 c0 > 262,263c262,263 > < DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ > TransPend- > < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <1us, L1 <16us > --- >> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ >> TransPend- >> LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Martin, On 01/28/13 12:12, Martin Mokrejs wrote: Chris Clayton wrote: [snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. BTW, I have with acpiphp on 3.7.4: ls -la /sys/bus/pci_express/devices total 0 drwxr-xr-x 2 root root 0 Jan 28 13:07 . drwxr-xr-x 4 root root 0 Jan 28 13:07 .. $ ls -la /sys/bus/pci/devices/slots **typo** It should be /sys/bus/pci/slots. ls: cannot access /sys/bus/pci/devices/slots: No such file or directory $ With acpiphp, I get /sys/bus/pci_express/devices populated but /sys/bus/pci/slots is empty. And for me hotplug also works (as far as I can tell). ;-) Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Would be fine if you could re-do the PresDet checks and confirm whether it is also broken for you under pciehp. I've struggled with this a little. For some reason, the expresscard doesn't always stay properly inserted in the slot when I insert it. Now that hotplug is working, the modules are being loaded and when the card pops out again, I get an oops because, of course, the driver is running and the card disappears. Perhaps the driver can be made a bit more robust to sudden disappearance of the card. I'll report the oops later. Anyway, to run these tests I built a kernel without the dvb card's drivers, effectively simulating the situation I had before Yijing got hotplug working for me. The card popping out may also have affected these diffs a bit because, for example, the first one has the CorrErr flag changed, possibly because I had to have two or more goes at getting the card to lock in the slot. Yesterday that diff showed no changes. Anyway, here are the diffs: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt 262c262 < DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- --- > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- 295c295 < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 --- > 40: 10 80 42 01 00 80 00 00 00 00 11 00 12 3c 12 04 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt = diff lspci.before_insertion.txt lspci.after_1st_removal.txt 112c112 < 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 08 c0 --- > 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 00 c0 262,263c262,263 < DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us --- > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us 265c265 < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 < LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt- 273c273 < Changed: MRL- PresDet- LinkState- --- > Changed: MRL- PresDet- LinkState+ 295,296c295,296 < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 < 50: 03 00 01 10 60 b2 1c 00 28 00 00 00 00 00 00 00 --- > 40: 10 80 42 01 00 80 00 00 00 00 11 00 12 3c 12 04 > 50: 40 00 11 50 60 b2 1c 00 28 00 00 01 00 00 00 00 === diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt diff lspci.before_insertion.txt lspci.after_insertion.txt 112c112 < 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 08 c0 --- > 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 00 c0 263c263 < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us --- > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us 265c265 < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 < LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- 272,273c272,273 < SltSta: Status: AttnBtn-
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On 2013/1/28 20:12, Martin Mokrejs wrote: > Chris Clayton wrote: >> >> [snip] >> >>> [chris:~]$ cat /proc/cmdline >>> root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 >> ^^ >> **typo** >> I've run the test again with pcie_ports=native and the directories now get >> populated. Even better though, is that when I plug in the card, hotplug >> **works** and the card's drivers are loaded. > > BTW, I have with acpiphp on 3.7.4: > > ls -la /sys/bus/pci_express/devices > total 0 > drwxr-xr-x 2 root root 0 Jan 28 13:07 . > drwxr-xr-x 4 root root 0 Jan 28 13:07 .. > $ ls -la /sys/bus/pci/devices/slots > ls: cannot access /sys/bus/pci/devices/slots: No such file or directory > $ > > And for me hotplug also works (as far as I can tell). ;-) Right, only pciehp (pcie nativa hotplug) need to bind pcie port devices. Acpiphp (acpi pci hotplug) don't need pcie port devices, it just depend the firmware in your machine, also acpiphp can support both pci hotplug and pcie hotplug. pciehp only support pcie device hotplug. > >> >> Excellent! Thank you so much for your help (and patience) Martin and Yijing. >> >> Now to solving why running scandvb doesn't find any TV channels. > > Would be fine if you could re-do the PresDet checks and confirm whether it is > also broken > for you under pciehp. > > Martin > > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Chris Clayton wrote: > > [snip] > >> [chris:~]$ cat /proc/cmdline >> root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 > ^^ > **typo** > I've run the test again with pcie_ports=native and the directories now get > populated. Even better though, is that when I plug in the card, hotplug > **works** and the card's drivers are loaded. BTW, I have with acpiphp on 3.7.4: ls -la /sys/bus/pci_express/devices total 0 drwxr-xr-x 2 root root 0 Jan 28 13:07 . drwxr-xr-x 4 root root 0 Jan 28 13:07 .. $ ls -la /sys/bus/pci/devices/slots ls: cannot access /sys/bus/pci/devices/slots: No such file or directory $ And for me hotplug also works (as far as I can tell). ;-) > > Excellent! Thank you so much for your help (and patience) Martin and Yijing. > > Now to solving why running scandvb doesn't find any TV channels. Would be fine if you could re-do the PresDet checks and confirm whether it is also broken for you under pciehp. Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
[snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Chris [snip] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On 2013/1/28 19:01, Chris Clayton wrote: > [no one screamed, so linux-media ml dropped] > > Hi Martin, > > On 01/28/13 10:56, Martin Mokrejs wrote: >> >> >> Chris Clayton wrote: >>> Hi Yijing, >>> >>> On 01/28/13 02:40, Yijing Wang wrote: Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. From the sysinfo you provide, there are no pcie port devices under /sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter "pcie_ports=native" and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. >>> Sorry, I've tried your suggestion, but the two directories are still empty. >>> >>> I verified the test environment as follows: >>> >>> [chris:~]$ uname -a >>> Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 >>> GNU/Linux >>> [chris:~]$ grep acpiphp /boot/System.map-3.7.4 >>> [chris:~]$ modinfo acpiphp >>> modinfo: ERROR: Module acpiphp not found. >>> [chris:~]$ modinfo pciehp >>> filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko >>> license:GPL >>> description:PCI Express Hot Plug Controller Driver >>> author: Dan Zink , Greg Kroah-Hartman >>> , Dely Sy >>> depends: >>> intree: Y >>> vermagic: 3.7.4 SMP preempt mod_unload CORE2 >>> parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto >>>pcie - Use PCIe based slot detection >>>acpi - Use ACPI for slot detection >>>auto(default) - Auto select mode. Use acpi option if duplicate >>>slot ids are found. Otherwise, use pcie option >>> (charp) >>> parm: pciehp_debug:Debugging mode enabled or not (bool) >>> parm: pciehp_poll_mode:Using polling mechanism for hot-plug >>> events or not (bool) >>> parm: pciehp_poll_time:Polling mechanism frequency, in seconds >>> (int) >>> parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) >>> [chris:~]$ cat /proc/cmdline >>> root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 Oh, should "pcie_ports=native" not "pciehp_ports=native". >>> [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 >>> [chris:~]$ lsmod >>> Module Size Used by >>> pciehp 19907 0 >>> [...] >>> >>> You will notice that the kernel I have used is 3.7.4. I hope that's a >>> suitable kernel for your tests. I've moved away from the 3.8 development >>> kernel onto one that's stable and on which Martin has identified a >>> solution. I see Greg KH released 3.7.5 yesterday and it includes a pciehp >>> change. I'll upgrade to that, run the tests again and report back. >>> >>> One question - should I include the (acpi) pci_slot driver in the kernel >>> build or does pciehp populate the directories without pci_slot? >> >> Hi Chris, >>I am not a kernel developer but from the other threads at linux-pci I >> gathered there are in some >> scenarios problems with improper loading of the hotplug modules. Therefore, >> the patches floating >> now around are to disable hotplug module availability. Therefore, I >> suggested you to try only >> only static kernel support for hotplug. That way you don't hit the issue. >> That is for sure not >> addressed in 3.7.5, seems that it is probably in -next. >> Martin >> > In a few minutes I'll be sending out another reply to Yijing's suggestions > because I noticed a typo in the parameter I added to the kernel command line. > I'm now going back through email to remember why we were trying to get those > /sys/bus/pci... directories populated. > > Watch this space! :-) > Chris > > > . > -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
>> Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp >> modules. >> After above actions, enter /sys/bus/pci_express/devices/ directory and >> /sys/bus/pci/slots/ >> Some slots and pcie port devices should be there now. >> > Sorry, I've tried your suggestion, but the two directories are still empty. > > I verified the test environment as follows: > > [chris:~]$ uname -a > Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux > [chris:~]$ grep acpiphp /boot/System.map-3.7.4 > [chris:~]$ modinfo acpiphp > modinfo: ERROR: Module acpiphp not found. > [chris:~]$ modinfo pciehp > filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko > license:GPL > description:PCI Express Hot Plug Controller Driver > author: Dan Zink , Greg Kroah-Hartman > , Dely Sy > depends: > intree: Y > vermagic: 3.7.4 SMP preempt mod_unload CORE2 > parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto > pcie - Use PCIe based slot detection > acpi - Use ACPI for slot detection > auto(default) - Auto select mode. Use acpi option if duplicate > slot ids are found. Otherwise, use pcie option > (charp) > parm: pciehp_debug:Debugging mode enabled or not (bool) > parm: pciehp_poll_mode:Using polling mechanism for hot-plug events > or not (bool) > parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) > parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) > [chris:~]$ cat /proc/cmdline > root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 > [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 > [chris:~]$ lsmod > Module Size Used by > pciehp 19907 0 > [...] > > You will notice that the kernel I have used is 3.7.4. I hope that's a > suitable kernel for your tests. I've moved away from the 3.8 development > kernel onto one that's stable and on which Martin has identified a solution. > I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll > upgrade to that, run the tests again and report back. > > One question - should I include the (acpi) pci_slot driver in the kernel > build or does pciehp populate the directories without pci_slot? Hi Chris, pci_slot driver is not necessary, I think empty directory under /sys/bus/pci_express/devices is the main problem, Because no pcie port devices found in the system, so pciehp driver can not bind any devices when loading it. Then no slot will created under /sys/bus/pci/devices/slots. > > Thanks again. > >> /sys/bus/pci_express/devices: >> total 0 >> >> /sys/bus/pci_express/drivers: >> total 0 >> drwxr-xr-x 2 root root 0 Jan 27 13:17 pciehp/ >> >> >> On 2013/1/28 6:53, Chris Clayton wrote: >>> Thanks again, Martin. >>> >>> Firstly, maybe we should remove the linux-media list from the copy list. I >>> imagine this hotplug stuff is just noise to them. >>> >>> [snip] Do you have any other express card around to try if it works at all? Try that always after a cold boot. >>> Not at the moment, but I ordered at USB3 expresscard yesterday, so I will >>> have one soon. >>> Posting a diff result of the below procedure might help: # lspci -vvvxxx > lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx > lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx > lspci.after_1st_removal.txt -- Thanks! Yijing -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
[no one screamed, so linux-media ml dropped] Hi Martin, On 01/28/13 10:56, Martin Mokrejs wrote: Chris Clayton wrote: Hi Yijing, On 01/28/13 02:40, Yijing Wang wrote: Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. From the sysinfo you provide, there are no pcie port devices under /sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter "pcie_ports=native" and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. Sorry, I've tried your suggestion, but the two directories are still empty. I verified the test environment as follows: [chris:~]$ uname -a Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux [chris:~]$ grep acpiphp /boot/System.map-3.7.4 [chris:~]$ modinfo acpiphp modinfo: ERROR: Module acpiphp not found. [chris:~]$ modinfo pciehp filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko license:GPL description:PCI Express Hot Plug Controller Driver author: Dan Zink , Greg Kroah-Hartman , Dely Sy depends: intree: Y vermagic: 3.7.4 SMP preempt mod_unload CORE2 parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto pcie - Use PCIe based slot detection acpi - Use ACPI for slot detection auto(default) - Auto select mode. Use acpi option if duplicate slot ids are found. Otherwise, use pcie option (charp) parm: pciehp_debug:Debugging mode enabled or not (bool) parm: pciehp_poll_mode:Using polling mechanism for hot-plug events or not (bool) parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 [chris:~]$ lsmod Module Size Used by pciehp 19907 0 [...] You will notice that the kernel I have used is 3.7.4. I hope that's a suitable kernel for your tests. I've moved away from the 3.8 development kernel onto one that's stable and on which Martin has identified a solution. I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll upgrade to that, run the tests again and report back. One question - should I include the (acpi) pci_slot driver in the kernel build or does pciehp populate the directories without pci_slot? Hi Chris, I am not a kernel developer but from the other threads at linux-pci I gathered there are in some scenarios problems with improper loading of the hotplug modules. Therefore, the patches floating now around are to disable hotplug module availability. Therefore, I suggested you to try only only static kernel support for hotplug. That way you don't hit the issue. That is for sure not addressed in 3.7.5, seems that it is probably in -next. Martin In a few minutes I'll be sending out another reply to Yijing's suggestions because I noticed a typo in the parameter I added to the kernel command line. I'm now going back through email to remember why we were trying to get those /sys/bus/pci... directories populated. Watch this space! :-) Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Chris Clayton wrote: > Hi Yijing, > > On 01/28/13 02:40, Yijing Wang wrote: >> Hi Chris, >> Sorry for the delay reply. It seems like my reply last night was missed. >> >> From the sysinfo you provide, there are no pcie port devices under >> /sys/bus/pci_express/devices. >> Maybe because there are some problems with _OSC in your laptop, so pcie port >> driver won't create pcie port device >> for hotplug, aer and so on. >> >> Maybe you can add boot parameter "pcie_ports=native" and reboot your laptop. >> Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp >> modules. >> After above actions, enter /sys/bus/pci_express/devices/ directory and >> /sys/bus/pci/slots/ >> Some slots and pcie port devices should be there now. >> > Sorry, I've tried your suggestion, but the two directories are still empty. > > I verified the test environment as follows: > > [chris:~]$ uname -a > Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux > [chris:~]$ grep acpiphp /boot/System.map-3.7.4 > [chris:~]$ modinfo acpiphp > modinfo: ERROR: Module acpiphp not found. > [chris:~]$ modinfo pciehp > filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko > license:GPL > description:PCI Express Hot Plug Controller Driver > author: Dan Zink , Greg Kroah-Hartman > , Dely Sy > depends: > intree: Y > vermagic: 3.7.4 SMP preempt mod_unload CORE2 > parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto > pcie - Use PCIe based slot detection > acpi - Use ACPI for slot detection > auto(default) - Auto select mode. Use acpi option if duplicate > slot ids are found. Otherwise, use pcie option > (charp) > parm: pciehp_debug:Debugging mode enabled or not (bool) > parm: pciehp_poll_mode:Using polling mechanism for hot-plug events > or not (bool) > parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) > parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) > [chris:~]$ cat /proc/cmdline > root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 > [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 > [chris:~]$ lsmod > Module Size Used by > pciehp 19907 0 > [...] > > You will notice that the kernel I have used is 3.7.4. I hope that's a > suitable kernel for your tests. I've moved away from the 3.8 development > kernel onto one that's stable and on which Martin has identified a solution. > I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll > upgrade to that, run the tests again and report back. > > One question - should I include the (acpi) pci_slot driver in the kernel > build or does pciehp populate the directories without pci_slot? Hi Chris, I am not a kernel developer but from the other threads at linux-pci I gathered there are in some scenarios problems with improper loading of the hotplug modules. Therefore, the patches floating now around are to disable hotplug module availability. Therefore, I suggested you to try only only static kernel support for hotplug. That way you don't hit the issue. That is for sure not addressed in 3.7.5, seems that it is probably in -next. Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Yijing, On 01/28/13 02:40, Yijing Wang wrote: Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. From the sysinfo you provide, there are no pcie port devices under /sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter "pcie_ports=native" and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. Sorry, I've tried your suggestion, but the two directories are still empty. I verified the test environment as follows: [chris:~]$ uname -a Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux [chris:~]$ grep acpiphp /boot/System.map-3.7.4 [chris:~]$ modinfo acpiphp modinfo: ERROR: Module acpiphp not found. [chris:~]$ modinfo pciehp filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko license:GPL description:PCI Express Hot Plug Controller Driver author: Dan Zink , Greg Kroah-Hartman , Dely Sy depends: intree: Y vermagic: 3.7.4 SMP preempt mod_unload CORE2 parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto pcie - Use PCIe based slot detection acpi - Use ACPI for slot detection auto(default) - Auto select mode. Use acpi option if duplicate slot ids are found. Otherwise, use pcie option (charp) parm: pciehp_debug:Debugging mode enabled or not (bool) parm: pciehp_poll_mode:Using polling mechanism for hot-plug events or not (bool) parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 [chris:~]$ lsmod Module Size Used by pciehp 19907 0 [...] You will notice that the kernel I have used is 3.7.4. I hope that's a suitable kernel for your tests. I've moved away from the 3.8 development kernel onto one that's stable and on which Martin has identified a solution. I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll upgrade to that, run the tests again and report back. One question - should I include the (acpi) pci_slot driver in the kernel build or does pciehp populate the directories without pci_slot? Thanks again. /sys/bus/pci_express/devices: total 0 /sys/bus/pci_express/drivers: total 0 drwxr-xr-x 2 root root 0 Jan 27 13:17 pciehp/ On 2013/1/28 6:53, Chris Clayton wrote: Thanks again, Martin. Firstly, maybe we should remove the linux-media list from the copy list. I imagine this hotplug stuff is just noise to them. [snip] Do you have any other express card around to try if it works at all? Try that always after a cold boot. Not at the moment, but I ordered at USB3 expresscard yesterday, so I will have one soon. Posting a diff result of the below procedure might help: # lspci -vvvxxx > lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx > lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx > lspci.after_1st_removal.txt [re-plug your card into the slot] # lspci -vvvxxx > lspci.after_1st_re-insertion.txt [ unplug your card] # lspci -vvvxxx > lspci.after_2nd_removal.txt OK, I've been using kernel 3.8.0-rc kernels so far, but given that is still under development, I've switched to 3.7.4, mainly because you are having success with 3.7.x, acpiphp and pcie_aspm=off. I verified the environment as follows: [chris:~]$ cat /proc/cmdline root=/dev/sda5 pcie_aspm=off ro resume=/dev/sda6 [chris:~]$ dmesg | grep ASPM [0.00] PCIe ASPM is disabled [0.348959] pci:00: ACPI _OSC support notification failed, disabling PCIe ASPM [chris:~]$ dmesg | grep acpiphp [0.400846] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [chris:~]$ dmesg | grep pciehp [chris:~]$ uname -a Linux laptop 3.7.4 #13 SMP PREEMPT Sun Jan 27 18:39:39 GMT 2013 i686 GNU/Linux Then compare them using diff. These should have no difference: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt Correct, there were no differences. These may have only little difference, or none: diff lspci.before_insertion.txt lspci.after_1st_removal.txt 263c263 < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us --- > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us 265c265 < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- >
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Yijing, On 01/28/13 02:40, Yijing Wang wrote: Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. From the sysinfo you provide, there are no pcie port devices under /sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter pcie_ports=native and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. Sorry, I've tried your suggestion, but the two directories are still empty. I verified the test environment as follows: [chris:~]$ uname -a Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux [chris:~]$ grep acpiphp /boot/System.map-3.7.4 [chris:~]$ modinfo acpiphp modinfo: ERROR: Module acpiphp not found. [chris:~]$ modinfo pciehp filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko license:GPL description:PCI Express Hot Plug Controller Driver author: Dan Zink dan.z...@compaq.com, Greg Kroah-Hartman g...@kroah.com, Dely Sy dely.l...@intel.com depends: intree: Y vermagic: 3.7.4 SMP preempt mod_unload CORE2 parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto pcie - Use PCIe based slot detection acpi - Use ACPI for slot detection auto(default) - Auto select mode. Use acpi option if duplicate slot ids are found. Otherwise, use pcie option (charp) parm: pciehp_debug:Debugging mode enabled or not (bool) parm: pciehp_poll_mode:Using polling mechanism for hot-plug events or not (bool) parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 [chris:~]$ lsmod Module Size Used by pciehp 19907 0 [...] You will notice that the kernel I have used is 3.7.4. I hope that's a suitable kernel for your tests. I've moved away from the 3.8 development kernel onto one that's stable and on which Martin has identified a solution. I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll upgrade to that, run the tests again and report back. One question - should I include the (acpi) pci_slot driver in the kernel build or does pciehp populate the directories without pci_slot? Thanks again. /sys/bus/pci_express/devices: total 0 /sys/bus/pci_express/drivers: total 0 drwxr-xr-x 2 root root 0 Jan 27 13:17 pciehp/ On 2013/1/28 6:53, Chris Clayton wrote: Thanks again, Martin. Firstly, maybe we should remove the linux-media list from the copy list. I imagine this hotplug stuff is just noise to them. [snip] Do you have any other express card around to try if it works at all? Try that always after a cold boot. Not at the moment, but I ordered at USB3 expresscard yesterday, so I will have one soon. Posting a diff result of the below procedure might help: # lspci -vvvxxx lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_1st_removal.txt [re-plug your card into the slot] # lspci -vvvxxx lspci.after_1st_re-insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_2nd_removal.txt OK, I've been using kernel 3.8.0-rc kernels so far, but given that is still under development, I've switched to 3.7.4, mainly because you are having success with 3.7.x, acpiphp and pcie_aspm=off. I verified the environment as follows: [chris:~]$ cat /proc/cmdline root=/dev/sda5 pcie_aspm=off ro resume=/dev/sda6 [chris:~]$ dmesg | grep ASPM [0.00] PCIe ASPM is disabled [0.348959] pci:00: ACPI _OSC support notification failed, disabling PCIe ASPM [chris:~]$ dmesg | grep acpiphp [0.400846] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [chris:~]$ dmesg | grep pciehp [chris:~]$ uname -a Linux laptop 3.7.4 #13 SMP PREEMPT Sun Jan 27 18:39:39 GMT 2013 i686 GNU/Linux Then compare them using diff. These should have no difference: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt Correct, there were no differences. These may have only little difference, or none: diff lspci.before_insertion.txt lspci.after_1st_removal.txt 263c263 LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Chris Clayton wrote: Hi Yijing, On 01/28/13 02:40, Yijing Wang wrote: Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. From the sysinfo you provide, there are no pcie port devices under /sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter pcie_ports=native and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. Sorry, I've tried your suggestion, but the two directories are still empty. I verified the test environment as follows: [chris:~]$ uname -a Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux [chris:~]$ grep acpiphp /boot/System.map-3.7.4 [chris:~]$ modinfo acpiphp modinfo: ERROR: Module acpiphp not found. [chris:~]$ modinfo pciehp filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko license:GPL description:PCI Express Hot Plug Controller Driver author: Dan Zink dan.z...@compaq.com, Greg Kroah-Hartman g...@kroah.com, Dely Sy dely.l...@intel.com depends: intree: Y vermagic: 3.7.4 SMP preempt mod_unload CORE2 parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto pcie - Use PCIe based slot detection acpi - Use ACPI for slot detection auto(default) - Auto select mode. Use acpi option if duplicate slot ids are found. Otherwise, use pcie option (charp) parm: pciehp_debug:Debugging mode enabled or not (bool) parm: pciehp_poll_mode:Using polling mechanism for hot-plug events or not (bool) parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 [chris:~]$ lsmod Module Size Used by pciehp 19907 0 [...] You will notice that the kernel I have used is 3.7.4. I hope that's a suitable kernel for your tests. I've moved away from the 3.8 development kernel onto one that's stable and on which Martin has identified a solution. I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll upgrade to that, run the tests again and report back. One question - should I include the (acpi) pci_slot driver in the kernel build or does pciehp populate the directories without pci_slot? Hi Chris, I am not a kernel developer but from the other threads at linux-pci I gathered there are in some scenarios problems with improper loading of the hotplug modules. Therefore, the patches floating now around are to disable hotplug module availability. Therefore, I suggested you to try only only static kernel support for hotplug. That way you don't hit the issue. That is for sure not addressed in 3.7.5, seems that it is probably in -next. Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
[no one screamed, so linux-media ml dropped] Hi Martin, On 01/28/13 10:56, Martin Mokrejs wrote: Chris Clayton wrote: Hi Yijing, On 01/28/13 02:40, Yijing Wang wrote: Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. From the sysinfo you provide, there are no pcie port devices under /sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter pcie_ports=native and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. Sorry, I've tried your suggestion, but the two directories are still empty. I verified the test environment as follows: [chris:~]$ uname -a Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux [chris:~]$ grep acpiphp /boot/System.map-3.7.4 [chris:~]$ modinfo acpiphp modinfo: ERROR: Module acpiphp not found. [chris:~]$ modinfo pciehp filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko license:GPL description:PCI Express Hot Plug Controller Driver author: Dan Zink dan.z...@compaq.com, Greg Kroah-Hartman g...@kroah.com, Dely Sy dely.l...@intel.com depends: intree: Y vermagic: 3.7.4 SMP preempt mod_unload CORE2 parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto pcie - Use PCIe based slot detection acpi - Use ACPI for slot detection auto(default) - Auto select mode. Use acpi option if duplicate slot ids are found. Otherwise, use pcie option (charp) parm: pciehp_debug:Debugging mode enabled or not (bool) parm: pciehp_poll_mode:Using polling mechanism for hot-plug events or not (bool) parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 [chris:~]$ lsmod Module Size Used by pciehp 19907 0 [...] You will notice that the kernel I have used is 3.7.4. I hope that's a suitable kernel for your tests. I've moved away from the 3.8 development kernel onto one that's stable and on which Martin has identified a solution. I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll upgrade to that, run the tests again and report back. One question - should I include the (acpi) pci_slot driver in the kernel build or does pciehp populate the directories without pci_slot? Hi Chris, I am not a kernel developer but from the other threads at linux-pci I gathered there are in some scenarios problems with improper loading of the hotplug modules. Therefore, the patches floating now around are to disable hotplug module availability. Therefore, I suggested you to try only only static kernel support for hotplug. That way you don't hit the issue. That is for sure not addressed in 3.7.5, seems that it is probably in -next. Martin In a few minutes I'll be sending out another reply to Yijing's suggestions because I noticed a typo in the parameter I added to the kernel command line. I'm now going back through email to remember why we were trying to get those /sys/bus/pci... directories populated. Watch this space! :-) Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. Sorry, I've tried your suggestion, but the two directories are still empty. I verified the test environment as follows: [chris:~]$ uname -a Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux [chris:~]$ grep acpiphp /boot/System.map-3.7.4 [chris:~]$ modinfo acpiphp modinfo: ERROR: Module acpiphp not found. [chris:~]$ modinfo pciehp filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko license:GPL description:PCI Express Hot Plug Controller Driver author: Dan Zink dan.z...@compaq.com, Greg Kroah-Hartman g...@kroah.com, Dely Sy dely.l...@intel.com depends: intree: Y vermagic: 3.7.4 SMP preempt mod_unload CORE2 parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto pcie - Use PCIe based slot detection acpi - Use ACPI for slot detection auto(default) - Auto select mode. Use acpi option if duplicate slot ids are found. Otherwise, use pcie option (charp) parm: pciehp_debug:Debugging mode enabled or not (bool) parm: pciehp_poll_mode:Using polling mechanism for hot-plug events or not (bool) parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 [chris:~]$ lsmod Module Size Used by pciehp 19907 0 [...] You will notice that the kernel I have used is 3.7.4. I hope that's a suitable kernel for your tests. I've moved away from the 3.8 development kernel onto one that's stable and on which Martin has identified a solution. I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll upgrade to that, run the tests again and report back. One question - should I include the (acpi) pci_slot driver in the kernel build or does pciehp populate the directories without pci_slot? Hi Chris, pci_slot driver is not necessary, I think empty directory under /sys/bus/pci_express/devices is the main problem, Because no pcie port devices found in the system, so pciehp driver can not bind any devices when loading it. Then no slot will created under /sys/bus/pci/devices/slots. Thanks again. /sys/bus/pci_express/devices: total 0 /sys/bus/pci_express/drivers: total 0 drwxr-xr-x 2 root root 0 Jan 27 13:17 pciehp/ On 2013/1/28 6:53, Chris Clayton wrote: Thanks again, Martin. Firstly, maybe we should remove the linux-media list from the copy list. I imagine this hotplug stuff is just noise to them. [snip] Do you have any other express card around to try if it works at all? Try that always after a cold boot. Not at the moment, but I ordered at USB3 expresscard yesterday, so I will have one soon. Posting a diff result of the below procedure might help: # lspci -vvvxxx lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_1st_removal.txt -- Thanks! Yijing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On 2013/1/28 19:01, Chris Clayton wrote: [no one screamed, so linux-media ml dropped] Hi Martin, On 01/28/13 10:56, Martin Mokrejs wrote: Chris Clayton wrote: Hi Yijing, On 01/28/13 02:40, Yijing Wang wrote: Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. From the sysinfo you provide, there are no pcie port devices under /sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter pcie_ports=native and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. Sorry, I've tried your suggestion, but the two directories are still empty. I verified the test environment as follows: [chris:~]$ uname -a Linux laptop 3.7.4 #15 SMP PREEMPT Mon Jan 28 09:43:57 GMT 2013 i686 GNU/Linux [chris:~]$ grep acpiphp /boot/System.map-3.7.4 [chris:~]$ modinfo acpiphp modinfo: ERROR: Module acpiphp not found. [chris:~]$ modinfo pciehp filename: /lib/modules/3.7.4/kernel/drivers/pci/hotplug/pciehp.ko license:GPL description:PCI Express Hot Plug Controller Driver author: Dan Zink dan.z...@compaq.com, Greg Kroah-Hartman g...@kroah.com, Dely Sy dely.l...@intel.com depends: intree: Y vermagic: 3.7.4 SMP preempt mod_unload CORE2 parm: pciehp_detect_mode:Slot detection mode: pcie, acpi, auto pcie - Use PCIe based slot detection acpi - Use ACPI for slot detection auto(default) - Auto select mode. Use acpi option if duplicate slot ids are found. Otherwise, use pcie option (charp) parm: pciehp_debug:Debugging mode enabled or not (bool) parm: pciehp_poll_mode:Using polling mechanism for hot-plug events or not (bool) parm: pciehp_poll_time:Polling mechanism frequency, in seconds (int) parm: pciehp_force:Force pciehp, even if OSHP is missing (bool) [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 Oh, should pcie_ports=native not pciehp_ports=native. [chris:~]$ sudo modprobe pciehp pciehp_force=1 pciehp_debug=1 [chris:~]$ lsmod Module Size Used by pciehp 19907 0 [...] You will notice that the kernel I have used is 3.7.4. I hope that's a suitable kernel for your tests. I've moved away from the 3.8 development kernel onto one that's stable and on which Martin has identified a solution. I see Greg KH released 3.7.5 yesterday and it includes a pciehp change. I'll upgrade to that, run the tests again and report back. One question - should I include the (acpi) pci_slot driver in the kernel build or does pciehp populate the directories without pci_slot? Hi Chris, I am not a kernel developer but from the other threads at linux-pci I gathered there are in some scenarios problems with improper loading of the hotplug modules. Therefore, the patches floating now around are to disable hotplug module availability. Therefore, I suggested you to try only only static kernel support for hotplug. That way you don't hit the issue. That is for sure not addressed in 3.7.5, seems that it is probably in -next. Martin In a few minutes I'll be sending out another reply to Yijing's suggestions because I noticed a typo in the parameter I added to the kernel command line. I'm now going back through email to remember why we were trying to get those /sys/bus/pci... directories populated. Watch this space! :-) Chris . -- Thanks! Yijing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
[snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Chris [snip] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Chris Clayton wrote: [snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. BTW, I have with acpiphp on 3.7.4: ls -la /sys/bus/pci_express/devices total 0 drwxr-xr-x 2 root root 0 Jan 28 13:07 . drwxr-xr-x 4 root root 0 Jan 28 13:07 .. $ ls -la /sys/bus/pci/devices/slots ls: cannot access /sys/bus/pci/devices/slots: No such file or directory $ And for me hotplug also works (as far as I can tell). ;-) Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Would be fine if you could re-do the PresDet checks and confirm whether it is also broken for you under pciehp. Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On 2013/1/28 20:12, Martin Mokrejs wrote: Chris Clayton wrote: [snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. BTW, I have with acpiphp on 3.7.4: ls -la /sys/bus/pci_express/devices total 0 drwxr-xr-x 2 root root 0 Jan 28 13:07 . drwxr-xr-x 4 root root 0 Jan 28 13:07 .. $ ls -la /sys/bus/pci/devices/slots ls: cannot access /sys/bus/pci/devices/slots: No such file or directory $ And for me hotplug also works (as far as I can tell). ;-) Right, only pciehp (pcie nativa hotplug) need to bind pcie port devices. Acpiphp (acpi pci hotplug) don't need pcie port devices, it just depend the firmware in your machine, also acpiphp can support both pci hotplug and pcie hotplug. pciehp only support pcie device hotplug. Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Would be fine if you could re-do the PresDet checks and confirm whether it is also broken for you under pciehp. Martin -- Thanks! Yijing -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Martin, On 01/28/13 12:12, Martin Mokrejs wrote: Chris Clayton wrote: [snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. BTW, I have with acpiphp on 3.7.4: ls -la /sys/bus/pci_express/devices total 0 drwxr-xr-x 2 root root 0 Jan 28 13:07 . drwxr-xr-x 4 root root 0 Jan 28 13:07 .. $ ls -la /sys/bus/pci/devices/slots **typo** It should be /sys/bus/pci/slots. ls: cannot access /sys/bus/pci/devices/slots: No such file or directory $ With acpiphp, I get /sys/bus/pci_express/devices populated but /sys/bus/pci/slots is empty. And for me hotplug also works (as far as I can tell). ;-) Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Would be fine if you could re-do the PresDet checks and confirm whether it is also broken for you under pciehp. I've struggled with this a little. For some reason, the expresscard doesn't always stay properly inserted in the slot when I insert it. Now that hotplug is working, the modules are being loaded and when the card pops out again, I get an oops because, of course, the driver is running and the card disappears. Perhaps the driver can be made a bit more robust to sudden disappearance of the card. I'll report the oops later. Anyway, to run these tests I built a kernel without the dvb card's drivers, effectively simulating the situation I had before Yijing got hotplug working for me. The card popping out may also have affected these diffs a bit because, for example, the first one has the CorrErr flag changed, possibly because I had to have two or more goes at getting the card to lock in the slot. Yesterday that diff showed no changes. Anyway, here are the diffs: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt 262c262 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- --- DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- 295c295 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 --- 40: 10 80 42 01 00 80 00 00 00 00 11 00 12 3c 12 04 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt no difference = diff lspci.before_insertion.txt lspci.after_1st_removal.txt 112c112 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 08 c0 --- 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 00 c0 262,263c262,263 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt- 273c273 Changed: MRL- PresDet- LinkState- --- Changed: MRL- PresDet- LinkState+ 295,296c295,296 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 50: 03 00 01 10 60 b2 1c 00 28 00 00 00 00 00 00 00 --- 40: 10 80 42 01 00 80 00 00 00 00 11 00 12 3c 12 04 50: 40 00 11 50 60 b2 1c 00 28 00 00 01 00 00 00 00 === diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt no difference diff lspci.before_insertion.txt lspci.after_insertion.txt 112c112 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 08 c0 --- 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 00 c0 263c263 LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- 272,273c272,273 SltSta: Status: AttnBtn- PowerFlt- MRL-
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Chris Clayton wrote: Hi Martin, On 01/28/13 12:12, Martin Mokrejs wrote: Chris Clayton wrote: [snip] [chris:~]$ cat /proc/cmdline root=/dev/sda5 pciehp_ports=native ro resume=/dev/sda6 ^^ **typo** I've run the test again with pcie_ports=native and the directories now get populated. Even better though, is that when I plug in the card, hotplug **works** and the card's drivers are loaded. BTW, I have with acpiphp on 3.7.4: ls -la /sys/bus/pci_express/devices total 0 drwxr-xr-x 2 root root 0 Jan 28 13:07 . drwxr-xr-x 4 root root 0 Jan 28 13:07 .. $ ls -la /sys/bus/pci/devices/slots **typo** It should be /sys/bus/pci/slots. ls: cannot access /sys/bus/pci/devices/slots: No such file or directory $ With acpiphp, I get /sys/bus/pci_express/devices populated but /sys/bus/pci/slots is empty. OK, I haven't realized the typo, but I have here with acpiphp: # ls -laR /sys/bus/pci/slots /sys/bus/pci/slots: total 0 drwxr-xr-x 3 root root 0 Jan 27 17:14 . drwxr-xr-x 5 root root 0 Jan 25 15:56 .. drwxr-xr-x 2 root root 0 Jan 27 17:14 1 /sys/bus/pci/slots/1: total 0 drwxr-xr-x 2 root root0 Jan 27 17:14 . drwxr-xr-x 3 root root0 Jan 27 17:14 .. -r--r--r-- 1 root root 4096 Jan 28 21:31 adapter -r--r--r-- 1 root root 4096 Jan 27 17:14 address -rw-r--r-- 1 root root 4096 Jan 28 21:31 attention -r--r--r-- 1 root root 4096 Jan 28 21:31 cur_bus_speed -r--r--r-- 1 root root 4096 Jan 28 21:31 latch -r--r--r-- 1 root root 4096 Jan 28 21:31 max_bus_speed lrwxrwxrwx 1 root root0 Jan 28 21:31 module - ../../../../module/acpiphp -rw-r--r-- 1 root root 4096 Jan 28 21:31 power # And for me hotplug also works (as far as I can tell). ;-) Excellent! Thank you so much for your help (and patience) Martin and Yijing. Now to solving why running scandvb doesn't find any TV channels. Would be fine if you could re-do the PresDet checks and confirm whether it is also broken for you under pciehp. I've struggled with this a little. For some reason, the expresscard doesn't always stay properly inserted in the slot when I insert it. Now that hotplug is working, the modules are being loaded and when the card pops out again, I get an oops because, of course, the driver is running and the card disappears. Perhaps the driver can be made a bit more robust to sudden disappearance of the card. I'll report the Yes, I had or maybe still have same issues here. I used to get an Oops for sata_sil24 card weird behavior for USB3.0 NEC-based card. It was fine always for a VIA-based firewire card and serial PL2303-based one. I found out it is better if a usb device is connected to the USB card because if that slips out then the libata layer quickly realizes that. If there was no device connected, the usb waits too long before it removes the usb hub from the system. And if you plugin the card meanwhile back into the slot, weird thing happen. oops later. Anyway, to run these tests I built a kernel without the dvb card's drivers, effectively simulating the situation I had before Yijing got hotplug working for me. The card popping out may also have affected these diffs a bit because, for example, the first one has the CorrErr flag changed, possibly because I had to have two or more goes at getting the card to lock in the slot. Yesterday that diff showed no changes. Anyway, here are the diffs: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt 262c262 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- --- DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- 295c295 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 --- 40: 10 80 42 01 00 80 00 00 00 00 11 00 12 3c 12 04 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt no difference BTW, with the NEC-based card only after every second removal of the card I got into PresDet- state. So, on every other diff attempt you won't see a difference! But we are talking about acpiphp here (unlike pciehp) and with that I also have no problems. = diff lspci.before_insertion.txt lspci.after_1st_removal.txt 112c112 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 08 c0 --- 60: 20 20 ff 07 00 00 00 00 01 00 00 00 00 00 00 c0 262,263c262,263 DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- ---
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. >From the sysinfo you provide, there are no pcie port devices under >/sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter "pcie_ports=native" and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. /sys/bus/pci_express/devices: total 0 /sys/bus/pci_express/drivers: total 0 drwxr-xr-x 2 root root 0 Jan 27 13:17 pciehp/ On 2013/1/28 6:53, Chris Clayton wrote: > Thanks again, Martin. > > Firstly, maybe we should remove the linux-media list from the copy list. I > imagine this hotplug stuff is just noise to them. > > [snip] >> Do you have any other express card around to try if it works at all? Try >> that always after a cold boot. >> > Not at the moment, but I ordered at USB3 expresscard yesterday, so I will > have one soon. > >> Posting a diff result of the below procedure might help: >> >> # lspci -vvvxxx > lspci.before_insertion.txt >> >> [plug your card into the slot] >> >> # lspci -vvvxxx > lspci.after_insertion.txt >> >> [ unplug your card] >> >> # lspci -vvvxxx > lspci.after_1st_removal.txt >> >> [re-plug your card into the slot] >> >> # lspci -vvvxxx > lspci.after_1st_re-insertion.txt >> >> [ unplug your card] >> >> # lspci -vvvxxx > lspci.after_2nd_removal.txt >> > > OK, I've been using kernel 3.8.0-rc kernels so far, but given that is still > under development, I've switched to 3.7.4, mainly because you are having > success with 3.7.x, acpiphp and pcie_aspm=off. I verified the environment as > follows: > > [chris:~]$ cat /proc/cmdline > root=/dev/sda5 pcie_aspm=off ro resume=/dev/sda6 > [chris:~]$ dmesg | grep ASPM > [0.00] PCIe ASPM is disabled > [0.348959] pci:00: ACPI _OSC support notification failed, disabling > PCIe ASPM > [chris:~]$ dmesg | grep acpiphp > [0.400846] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [chris:~]$ dmesg | grep pciehp > [chris:~]$ uname -a > Linux laptop 3.7.4 #13 SMP PREEMPT Sun Jan 27 18:39:39 GMT 2013 i686 GNU/Linux > > >> Then compare them using diff. These should have no difference: >> >> diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt >> diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt >> > Correct, there were no differences. > >> >> These may have only little difference, or none: >> >> diff lspci.before_insertion.txt lspci.after_1st_removal.txt > > 263c263 > < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <1us, L1 <16us > --- > > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <512ns, L1 <16us > 265c265 > < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- > CommClk- > --- > > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- > CommClk+ > 267c267 > < LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ > DLActive- BWMgmt- ABWMgmt- > --- > > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ > DLActive- BWMgmt+ ABWMgmt- > 273c273 > < Changed: MRL- PresDet- LinkState- > --- > > Changed: MRL- PresDet- LinkState+ > 295,296c295,296 > < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 > < 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 > --- > > 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 > > 50: 40 00 11 50 60 b2 1c 00 08 00 00 01 00 00 00 00 > >> diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt >> > No difference. >> >> >> Finally, these should confirm whether the PresDet works for you (for me NOT >> with pciehp but does work with acpiphp). >> You should see PresDet- to PresDet+ changes in: >> > Yes, I do see the PresDet- to PresDet+ changes > >> diff lspci.before_insertion.txt lspci.after_insertion.txt > > 263c263 > < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <1us, L1 <16us > --- > > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <512ns, L1 <16us > 265c265 > < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- > CommClk- > --- > > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- > CommClk+ > 267c267 > < LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ > DLActive- BWMgmt- ABWMgmt- > --- > > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ > DLActive+ BWMgmt+ ABWMgmt- > 272,273c272,273 > < SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- > Interlock- > < Changed: MRL- PresDet- LinkState- > --- > > SltSta:
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Chris Clayton wrote: > Thanks again, Martin. > > Firstly, maybe we should remove the linux-media list from the copy list. I > imagine this hotplug stuff is just noise to them. > > [snip] >> Do you have any other express card around to try if it works at all? Try >> that always after a cold boot. >> > Not at the moment, but I ordered at USB3 expresscard yesterday, so I will > have one soon. > >> Posting a diff result of the below procedure might help: >> >> # lspci -vvvxxx > lspci.before_insertion.txt >> >> [plug your card into the slot] >> >> # lspci -vvvxxx > lspci.after_insertion.txt >> >> [ unplug your card] >> >> # lspci -vvvxxx > lspci.after_1st_removal.txt >> >> [re-plug your card into the slot] >> >> # lspci -vvvxxx > lspci.after_1st_re-insertion.txt >> >> [ unplug your card] >> >> # lspci -vvvxxx > lspci.after_2nd_removal.txt >> > > OK, I've been using kernel 3.8.0-rc kernels so far, but given that is still > under development, I've switched to 3.7.4, mainly because you are having > success with 3.7.x, acpiphp and pcie_aspm=off. I verified the environment as > follows: > > [chris:~]$ cat /proc/cmdline > root=/dev/sda5 pcie_aspm=off ro resume=/dev/sda6 > [chris:~]$ dmesg | grep ASPM > [0.00] PCIe ASPM is disabled > [0.348959] pci:00: ACPI _OSC support notification failed, disabling > PCIe ASPM > [chris:~]$ dmesg | grep acpiphp > [0.400846] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [chris:~]$ dmesg | grep pciehp > [chris:~]$ uname -a > Linux laptop 3.7.4 #13 SMP PREEMPT Sun Jan 27 18:39:39 GMT 2013 i686 GNU/Linux > vostro ~ # cat /proc/cmdline root=/dev/sda5 pciehp.pciehp_debug=1 slub_debug=AFPZ pcie_aspm=off vostro ~ # dmesg | grep ASPM [0.00] PCIe ASPM is disabled vostro ~ # dmesg | grep acpiphp [2.449038] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [2.453757] acpiphp: Slot [1] registered vostro ~ # uname -a Linux vostro 3.7.4-default #2 SMP Mon Jan 21 22:45:22 MET 2013 x86_64 Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GenuineIntel GNU/Linux vostro ~ # > >> Then compare them using diff. These should have no difference: >> >> diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt >> diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt >> > Correct, there were no differences. > >> >> These may have only little difference, or none: >> >> diff lspci.before_insertion.txt lspci.after_1st_removal.txt > > 263c263 > < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <1us, L1 <16us > --- > > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <512ns, L1 <16us > 265c265 > < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- > CommClk- > --- > > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- > CommClk+ > 267c267 > < LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ > DLActive- BWMgmt- ABWMgmt- > --- > > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ > DLActive- BWMgmt+ ABWMgmt- > 273c273 > < Changed: MRL- PresDet- LinkState- > --- > > Changed: MRL- PresDet- LinkState+ > 295,296c295,296 > < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 > < 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 > --- > > 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 > > 50: 40 00 11 50 60 b2 1c 00 08 00 00 01 00 00 00 00 > >> diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt >> > No difference. >> >> >> Finally, these should confirm whether the PresDet works for you (for me NOT >> with pciehp but does work with acpiphp). >> You should see PresDet- to PresDet+ changes in: >> > Yes, I do see the PresDet- to PresDet+ changes > >> diff lspci.before_insertion.txt lspci.after_insertion.txt > > 263c263 > < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <1us, L1 <16us > --- > > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency > L0 <512ns, L1 <16us > 265c265 > < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- > CommClk- > --- > > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- > CommClk+ > 267c267 > < LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ > DLActive- BWMgmt- ABWMgmt- > --- > > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ > DLActive+ BWMgmt+ ABWMgmt- > 272,273c272,273 > < SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- > Interlock- > < Changed: MRL- PresDet- LinkState- > --- > > SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ > Interlock- > > Changed: MRL- PresDet- LinkState+ > 295,296c295,296 > < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 > < 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 > --- > > 40: 10 80 42 01 00 80
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Thanks again, Martin. Firstly, maybe we should remove the linux-media list from the copy list. I imagine this hotplug stuff is just noise to them. [snip] Do you have any other express card around to try if it works at all? Try that always after a cold boot. Not at the moment, but I ordered at USB3 expresscard yesterday, so I will have one soon. Posting a diff result of the below procedure might help: # lspci -vvvxxx > lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx > lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx > lspci.after_1st_removal.txt [re-plug your card into the slot] # lspci -vvvxxx > lspci.after_1st_re-insertion.txt [ unplug your card] # lspci -vvvxxx > lspci.after_2nd_removal.txt OK, I've been using kernel 3.8.0-rc kernels so far, but given that is still under development, I've switched to 3.7.4, mainly because you are having success with 3.7.x, acpiphp and pcie_aspm=off. I verified the environment as follows: [chris:~]$ cat /proc/cmdline root=/dev/sda5 pcie_aspm=off ro resume=/dev/sda6 [chris:~]$ dmesg | grep ASPM [0.00] PCIe ASPM is disabled [0.348959] pci:00: ACPI _OSC support notification failed, disabling PCIe ASPM [chris:~]$ dmesg | grep acpiphp [0.400846] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [chris:~]$ dmesg | grep pciehp [chris:~]$ uname -a Linux laptop 3.7.4 #13 SMP PREEMPT Sun Jan 27 18:39:39 GMT 2013 i686 GNU/Linux Then compare them using diff. These should have no difference: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt Correct, there were no differences. These may have only little difference, or none: diff lspci.before_insertion.txt lspci.after_1st_removal.txt 263c263 < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us --- > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us 265c265 < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 < LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt- 273c273 < Changed: MRL- PresDet- LinkState- --- > Changed: MRL- PresDet- LinkState+ 295,296c295,296 < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 < 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 --- > 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 > 50: 40 00 11 50 60 b2 1c 00 08 00 00 01 00 00 00 00 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt No difference. Finally, these should confirm whether the PresDet works for you (for me NOT with pciehp but does work with acpiphp). You should see PresDet- to PresDet+ changes in: Yes, I do see the PresDet- to PresDet+ changes diff lspci.before_insertion.txt lspci.after_insertion.txt 263c263 < LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us --- > LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us 265c265 < LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 < LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- 272,273c272,273 < SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- < Changed: MRL- PresDet- LinkState- --- > SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- > Changed: MRL- PresDet- LinkState+ 295,296c295,296 < 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 < 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 --- > 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 > 50: 40 00 11 70 60 b2 1c 00 08 00 40 01 00 00 00 00 diff lspci.after_1st_removal.txt lspci.after_1st_re-insertion.txt 267c267 < LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt- --- > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- 272c272 < SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- --- > SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- 296c296 < 50: 40 00 11 50 60 b2 1c 00 08 00 00 01 00 00 00 00 --- > 50: 40 00 11 70 60 b2 1c 00 08 00 40 01 00 00 00 00 You should see PresDet+ to PresDet- changes in: Yes, I see those changes too. diff
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Chris Clayton wrote: > > > On 01/27/13 14:26, Martin Mokrejs wrote: >> Chris Clayton wrote: >>> >>> >>> On 01/27/13 12:18, Yijing Wang wrote: 于 2013-01-27 19:19, Chris Clayton 写道: > Hi Yijing > > On 01/27/13 02:45, Yijing Wang wrote: >> 于 2013-01-27 4:54, Chris Clayton 写道: >>> Hi Martin, >>> >>> On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether "pcie_aspm=off" in grub.conf helped. >>> >>> Thanks for the tip. I had the pciehp driver installed, but it was a >>> module and not loaded. I didn't have acpiphp enabled at all. Building >>> them both in statically, appears to have papered over the cracks of the >>> oops :-) >> >> Not loaded pciehp driver? Remove the device from this slot without >> poweroff ? >> > > That's correct. When I first encountered the oops, I did not have the > pciehp driver loaded and removing the device from the slot whilst the > laptop was powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). >>> >>> OK, thanks for the advice. >>> >>> The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. >>> >>> Those discussions are way above my level of knowledge. I guess all this >>> work will be merged into mainline in due course, so I'll watch for them >>> in 3.9 or later. Unless, of course, there is a tree I could clone and >>> help test the changes with my laptop and expresscard. >>> >>> Hotplug isn't working at all on my Fujitsu laptop, so I can only get >>> the card recognised by rebooting with the card inserted (or by writing >>> 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the >>> kernel bugzilla, so I'll look through them and see what's being done. >> >> Hi Chris, >> What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 >> pciehp_poll_time=1 ? >> >> Can you resend the dmesg log and "lspci -vvv" info after hotplug device >> from your Fujitsu laptop with above module parameters? >> > > I wasn't sure whether or not the pciehp driver should be loaded on its > own or with the acpiphp driver also loaded. So I built them both as > modules and planned to try both, pciehp only and acpiphp only. However, > I've found that acpiphp will not load (regardless of whether or not > pciehp is already loaded). What I get is: > > [chris:~]$ sudo modprobe acpiphp debug=1 > modprobe: ERROR: could not insert 'acpiphp': No such device >> >> Are you sure you had pciehp already loaded? >> > Yes, I'm sure it was. Ah, sorry, wanted to say "Are you sure you had NOT pciehp already loaded (loaded before)?". If you retry without loading it ever you might succeed with acpiphp. > Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). >>> >>> OK, thanks again for the advice. I've disabled the acpiphp driver. >> >> Pitty. For me only with acpiphp works detection of express card in the slot. >> With pciehp >> the PresDet is not updated properly upon removal/insertion and sometimes, >> probably as a result >> of the previous, PresDet on the SltSta: line of lspci is not correct. So I >> moved away from pciehp. >> I have a SandyBridge based laptop so I was hoping with your i5-based laptop >> you have also great >> chance to get rid of pciehp issues. >> > > I've just (very carefully) set this up again (i.e. no pciehp driver (module > or builtin), acpiphp driver built in and pcie_aspm=off on the kernel command > line (via grub). My card is not detected on insertion. :-( Do you have any other express card around to try if it works at all? Try that always after a cold boot. Posting a diff result of the below procedure might help: # lspci -vvvxxx > lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx > lspci.after_insertion.txt [
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On 01/27/13 14:26, Martin Mokrejs wrote: Chris Clayton wrote: On 01/27/13 12:18, Yijing Wang wrote: 于 2013-01-27 19:19, Chris Clayton 写道: Hi Yijing On 01/27/13 02:45, Yijing Wang wrote: 于 2013-01-27 4:54, Chris Clayton 写道: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether "pcie_aspm=off" in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? That's correct. When I first encountered the oops, I did not have the pciehp driver loaded and removing the device from the slot whilst the laptop was powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). OK, thanks for the advice. The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and "lspci -vvv" info after hotplug device from your Fujitsu laptop with above module parameters? I wasn't sure whether or not the pciehp driver should be loaded on its own or with the acpiphp driver also loaded. So I built them both as modules and planned to try both, pciehp only and acpiphp only. However, I've found that acpiphp will not load (regardless of whether or not pciehp is already loaded). What I get is: [chris:~]$ sudo modprobe acpiphp debug=1 modprobe: ERROR: could not insert 'acpiphp': No such device Are you sure you had pciehp already loaded? Yes, I'm sure it was. Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). OK, thanks again for the advice. I've disabled the acpiphp driver. Pitty. For me only with acpiphp works detection of express card in the slot. With pciehp the PresDet is not updated properly upon removal/insertion and sometimes, probably as a result of the previous, PresDet on the SltSta: line of lspci is not correct. So I moved away from pciehp. I have a SandyBridge based laptop so I was hoping with your i5-based laptop you have also great chance to get rid of pciehp issues. I've just (very carefully) set this up again (i.e. no pciehp driver (module or builtin), acpiphp driver built in and pcie_aspm=off on the kernel command line (via grub). My card is not detected on insertion. :-( Thanks for your suggestions, Martin. I am grateful. Chris Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Chris Clayton wrote: > > > On 01/27/13 12:18, Yijing Wang wrote: >> 于 2013-01-27 19:19, Chris Clayton 写道: >>> Hi Yijing >>> >>> On 01/27/13 02:45, Yijing Wang wrote: 于 2013-01-27 4:54, Chris Clayton 写道: > Hi Martin, > > On 01/24/13 19:21, Martin Mokrejs wrote: >> Hi Chris, >> try to include in kernel only acpiphp and omit pciehp. Don't use >> modules but include >> them statically. And try, in addition, check whether "pcie_aspm=off" in >> grub.conf helped. >> > > Thanks for the tip. I had the pciehp driver installed, but it was a > module and not loaded. I didn't have acpiphp enabled at all. Building > them both in statically, appears to have papered over the cracks of the > oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? >>> >>> That's correct. When I first encountered the oops, I did not have the >>> pciehp driver loaded and removing the device from the slot whilst the >>> laptop was powered on resulted in the oops. >> >> Hmm, that's unsafe and dangerous, because device now may be running. >> There are two ways to trigger pci hot-add or hot-remove in linux, after >> loaded pciehp or acpiphp module >> (the two modules only one can loaded into system at the same time). You can >> trigger hot-add/hot-remove by >> sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention >> button on hardware (if your laptop supports that). >> > > OK, thanks for the advice. > > >> The best would if you subscribe to linux-pci, and read my recent >> threads >> about similar issues I had with express cards with Dell Vostro 3550. >> Further, there is >> a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, >> just browse the >> archives of linux-pci and see the pacthes and the discussion. > > Those discussions are way above my level of knowledge. I guess all this > work will be merged into mainline in due course, so I'll watch for them > in 3.9 or later. Unless, of course, there is a tree I could clone and > help test the changes with my laptop and expresscard. > > Hotplug isn't working at all on my Fujitsu laptop, so I can only get the > card recognised by rebooting with the card inserted (or by writing 1 > to/sys/bus/pci/rescan). There seem to be a few reports on this in the > kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and "lspci -vvv" info after hotplug device from your Fujitsu laptop with above module parameters? >>> >>> I wasn't sure whether or not the pciehp driver should be loaded on its own >>> or with the acpiphp driver also loaded. So I built them both as modules and >>> planned to try both, pciehp only and acpiphp only. However, I've found that >>> acpiphp will not load (regardless of whether or not pciehp is already >>> loaded). What I get is: >>> >>> [chris:~]$ sudo modprobe acpiphp debug=1 >>> modprobe: ERROR: could not insert 'acpiphp': No such device Are you sure you had pciehp already loaded? >>> >> >> Currently, If your hardware support pciehp native hotplug, acpiphp driver >> will be rejected when loading it in system >> (you can force loading it by add boot parameter pcie_aspm=off as Martin >> said). >> > > OK, thanks again for the advice. I've disabled the acpiphp driver. Pitty. For me only with acpiphp works detection of express card in the slot. With pciehp the PresDet is not updated properly upon removal/insertion and sometimes, probably as a result of the previous, PresDet on the SltSta: line of lspci is not correct. So I moved away from pciehp. I have a SandyBridge based laptop so I was hoping with your i5-based laptop you have also great chance to get rid of pciehp issues. Martin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On 01/27/13 12:18, Yijing Wang wrote: 于 2013-01-27 19:19, Chris Clayton 写道: Hi Yijing On 01/27/13 02:45, Yijing Wang wrote: 于 2013-01-27 4:54, Chris Clayton 写道: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether "pcie_aspm=off" in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? That's correct. When I first encountered the oops, I did not have the pciehp driver loaded and removing the device from the slot whilst the laptop was powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). OK, thanks for the advice. The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and "lspci -vvv" info after hotplug device from your Fujitsu laptop with above module parameters? I wasn't sure whether or not the pciehp driver should be loaded on its own or with the acpiphp driver also loaded. So I built them both as modules and planned to try both, pciehp only and acpiphp only. However, I've found that acpiphp will not load (regardless of whether or not pciehp is already loaded). What I get is: [chris:~]$ sudo modprobe acpiphp debug=1 modprobe: ERROR: could not insert 'acpiphp': No such device Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). OK, thanks again for the advice. I've disabled the acpiphp driver. and at the end of the dmesg output I see: [ 68.199789] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 68.199970] acpiphp_glue: Total 0 slots The pciehp driver loads OK. I've attached pciehp-only which shows the dmesg and lscpi output that you asked for. As I said before, the only way that I can get the card detected with rebooting the laptop is to write 1 to /sys/bus/pci/rescan. In the hope that it might help (e.g. it shows details of the expresscard I'm using), I've also attached the output from dmesg and lspci after a rescan. In this case, i guess your slot maybe always power on, once you insert your pcie card, and use rescan intercace, you can find them. I checked the WinTV-HVR-1400 expressed card device's parent port device, as bellow. I found the powerctrl in slot cap is clear. So I doubt the hardware support pci hotplug. Mmm, that's odd because I dual-boot Windows 7 on this laptop and when I plug it in under Windows 7, it appears in Device Manager and works perfectly. Chris, Can you try to add and remove device by /sys/bus/pci/slots/3/power? (use #modprobe pciehp pciehp_debug=1) /sys/bus/pci/slots is empty: [chris:~]$ ls -l /sys/bus/pci/slots/ total 0 Using Google, I find that the acpi slot detection driver should populate that directory. It is configured in and built into the kernel statically, so I don't know what's happening there. By the way, there is also /sys/bus/pci_express directory: [chris:~]$ ls -Rl /sys/bus/pci_express/ /sys/bus/pci_express/: total 0 drwxr-xr-x 2 root root0 Jan 27 12:52 devices/ drwxr-xr-x 3 root root0 Jan 27 13:07 drivers/ -rw-r--r-- 1 root root 4096 Jan 27 13:07 drivers_autoprobe --w--- 1 root root 4096 Jan 27 13:07 drivers_probe --w--- 1 root root 4096 Jan 27 13:07 uevent /sys/bus/pci_express/devices:
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
于 2013-01-27 19:19, Chris Clayton 写道: > Hi Yijing > > On 01/27/13 02:45, Yijing Wang wrote: >> 于 2013-01-27 4:54, Chris Clayton 写道: >>> Hi Martin, >>> >>> On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether "pcie_aspm=off" in grub.conf helped. >>> >>> Thanks for the tip. I had the pciehp driver installed, but it was a module >>> and not loaded. I didn't have acpiphp enabled at all. Building them both in >>> statically, appears to have papered over the cracks of the oops :-) >> >> Not loaded pciehp driver? Remove the device from this slot without poweroff ? >> > > That's correct. When I first encountered the oops, I did not have the pciehp > driver loaded and removing the device from the slot whilst the laptop was > powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). >>> The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. >>> >>> Those discussions are way above my level of knowledge. I guess all this >>> work will be merged into mainline in due course, so I'll watch for them in >>> 3.9 or later. Unless, of course, there is a tree I could clone and help >>> test the changes with my laptop and expresscard. >>> >>> Hotplug isn't working at all on my Fujitsu laptop, so I can only get the >>> card recognised by rebooting with the card inserted (or by writing 1 >>> to/sys/bus/pci/rescan). There seem to be a few reports on this in the >>> kernel bugzilla, so I'll look through them and see what's being done. >> >> Hi Chris, >> What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 >> pciehp_poll_time=1 ? >> >> Can you resend the dmesg log and "lspci -vvv" info after hotplug device from >> your Fujitsu laptop with above module parameters? >> > > I wasn't sure whether or not the pciehp driver should be loaded on its own or > with the acpiphp driver also loaded. So I built them both as modules and > planned to try both, pciehp only and acpiphp only. However, I've found that > acpiphp will not load (regardless of whether or not pciehp is already > loaded). What I get is: > > [chris:~]$ sudo modprobe acpiphp debug=1 > modprobe: ERROR: could not insert 'acpiphp': No such device > Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). > and at the end of the dmesg output I see: > > [ 68.199789] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [ 68.199970] acpiphp_glue: Total 0 slots > > The pciehp driver loads OK. I've attached pciehp-only which shows the dmesg > and lscpi output that you asked for. > > As I said before, the only way that I can get the card detected with > rebooting the laptop is to write 1 to /sys/bus/pci/rescan. In the hope that > it might help (e.g. it shows details of the expresscard I'm using), I've also > attached the output from dmesg and lspci after a rescan. In this case, i guess your slot maybe always power on, once you insert your pcie card, and use rescan intercace, you can find them. I checked the WinTV-HVR-1400 expressed card device's parent port device, as bellow. I found the powerctrl in slot cap is clear. So I doubt the hardware support pci hotplug. Chris, Can you try to add and remove device by /sys/bus/pci/slots/3/power? (use #modprobe pciehp pciehp_debug=1) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5) (prog-if 00 [Normal decode]) Bus: primary=00, secondary=02, subordinate=06, sec-latency=0 Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Martin, On 01/26/13 21:14, Martin Mokrejs wrote: Hi Chris, Chris Clayton wrote: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether "pcie_aspm=off" in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. That's what I suspected. Compile in statically acpiphp, no pciehp at all (not even as a module). Then it might work for you -- at least it does for me, provided I use "pcie_aspm=off". Thanks again for the suggestion. Unfortunately, that doesn't fix the problem on my laptop. You may have seen the suggestion I've had from Yijing. I'm just building the kernel to test that out. Chris Martin Thanks again. Chris Martin Chris Clayton wrote: Hi, I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got an Oops when I removed from the expresscard slot in my laptop. I will quite understand if the response to this report is "don't do that!", but in that case, how should one remove one of these cards? I have attached three files: 1. the dmesg output from when I rebooted the machine after the oops. I have turned debugging on in the dib700p and cx23885 modules via modules options in /etc/modprobe.d/hvr1400.conf; 2. the .config file for the kernel that oopsed. 3. the text of the oops message. I've typed this up from a photograph of the screen because the laptop was locked up and there was nothing in the log files. Apologies for any typos, but I have tried to be careful. Assuming the answer isn't don't do that, let me know if I can provide any additional diagnostics, test any patches, etc. Please, however, cc me as I'm not subscribed. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Martin, On 01/26/13 21:14, Martin Mokrejs wrote: Hi Chris, Chris Clayton wrote: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. That's what I suspected. Compile in statically acpiphp, no pciehp at all (not even as a module). Then it might work for you -- at least it does for me, provided I use pcie_aspm=off. Thanks again for the suggestion. Unfortunately, that doesn't fix the problem on my laptop. You may have seen the suggestion I've had from Yijing. I'm just building the kernel to test that out. Chris Martin Thanks again. Chris Martin Chris Clayton wrote: Hi, I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got an Oops when I removed from the expresscard slot in my laptop. I will quite understand if the response to this report is don't do that!, but in that case, how should one remove one of these cards? I have attached three files: 1. the dmesg output from when I rebooted the machine after the oops. I have turned debugging on in the dib700p and cx23885 modules via modules options in /etc/modprobe.d/hvr1400.conf; 2. the .config file for the kernel that oopsed. 3. the text of the oops message. I've typed this up from a photograph of the screen because the laptop was locked up and there was nothing in the log files. Apologies for any typos, but I have tried to be careful. Assuming the answer isn't don't do that, let me know if I can provide any additional diagnostics, test any patches, etc. Please, however, cc me as I'm not subscribed. Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
于 2013-01-27 19:19, Chris Clayton 写道: Hi Yijing On 01/27/13 02:45, Yijing Wang wrote: 于 2013-01-27 4:54, Chris Clayton 写道: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? That's correct. When I first encountered the oops, I did not have the pciehp driver loaded and removing the device from the slot whilst the laptop was powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and lspci -vvv info after hotplug device from your Fujitsu laptop with above module parameters? I wasn't sure whether or not the pciehp driver should be loaded on its own or with the acpiphp driver also loaded. So I built them both as modules and planned to try both, pciehp only and acpiphp only. However, I've found that acpiphp will not load (regardless of whether or not pciehp is already loaded). What I get is: [chris:~]$ sudo modprobe acpiphp debug=1 modprobe: ERROR: could not insert 'acpiphp': No such device Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). and at the end of the dmesg output I see: [ 68.199789] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 68.199970] acpiphp_glue: Total 0 slots The pciehp driver loads OK. I've attached pciehp-only which shows the dmesg and lscpi output that you asked for. As I said before, the only way that I can get the card detected with rebooting the laptop is to write 1 to /sys/bus/pci/rescan. In the hope that it might help (e.g. it shows details of the expresscard I'm using), I've also attached the output from dmesg and lspci after a rescan. In this case, i guess your slot maybe always power on, once you insert your pcie card, and use rescan intercace, you can find them. I checked the WinTV-HVR-1400 expressed card device's parent port device, as bellow. I found the powerctrl in slot cap is clear. So I doubt the hardware support pci hotplug. Chris, Can you try to add and remove device by /sys/bus/pci/slots/3/power? (use #modprobe pciehp pciehp_debug=1) 00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b5) (prog-if 00 [Normal decode]) Bus: primary=00, secondary=02, subordinate=06, sec-latency=0 Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s 64ns, L1 1us ExtTag- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us ClockPM- Surprise- LLActRep+ BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On 01/27/13 12:18, Yijing Wang wrote: 于 2013-01-27 19:19, Chris Clayton 写道: Hi Yijing On 01/27/13 02:45, Yijing Wang wrote: 于 2013-01-27 4:54, Chris Clayton 写道: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? That's correct. When I first encountered the oops, I did not have the pciehp driver loaded and removing the device from the slot whilst the laptop was powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). OK, thanks for the advice. The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and lspci -vvv info after hotplug device from your Fujitsu laptop with above module parameters? I wasn't sure whether or not the pciehp driver should be loaded on its own or with the acpiphp driver also loaded. So I built them both as modules and planned to try both, pciehp only and acpiphp only. However, I've found that acpiphp will not load (regardless of whether or not pciehp is already loaded). What I get is: [chris:~]$ sudo modprobe acpiphp debug=1 modprobe: ERROR: could not insert 'acpiphp': No such device Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). OK, thanks again for the advice. I've disabled the acpiphp driver. and at the end of the dmesg output I see: [ 68.199789] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 68.199970] acpiphp_glue: Total 0 slots The pciehp driver loads OK. I've attached pciehp-only which shows the dmesg and lscpi output that you asked for. As I said before, the only way that I can get the card detected with rebooting the laptop is to write 1 to /sys/bus/pci/rescan. In the hope that it might help (e.g. it shows details of the expresscard I'm using), I've also attached the output from dmesg and lspci after a rescan. In this case, i guess your slot maybe always power on, once you insert your pcie card, and use rescan intercace, you can find them. I checked the WinTV-HVR-1400 expressed card device's parent port device, as bellow. I found the powerctrl in slot cap is clear. So I doubt the hardware support pci hotplug. Mmm, that's odd because I dual-boot Windows 7 on this laptop and when I plug it in under Windows 7, it appears in Device Manager and works perfectly. Chris, Can you try to add and remove device by /sys/bus/pci/slots/3/power? (use #modprobe pciehp pciehp_debug=1) /sys/bus/pci/slots is empty: [chris:~]$ ls -l /sys/bus/pci/slots/ total 0 Using Google, I find that the acpi slot detection driver should populate that directory. It is configured in and built into the kernel statically, so I don't know what's happening there. By the way, there is also /sys/bus/pci_express directory: [chris:~]$ ls -Rl /sys/bus/pci_express/ /sys/bus/pci_express/: total 0 drwxr-xr-x 2 root root0 Jan 27 12:52 devices/ drwxr-xr-x 3 root root0 Jan 27 13:07 drivers/ -rw-r--r-- 1 root root 4096 Jan 27 13:07 drivers_autoprobe --w--- 1 root root 4096 Jan 27 13:07 drivers_probe --w--- 1 root root 4096 Jan 27 13:07 uevent /sys/bus/pci_express/devices: total 0
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Chris Clayton wrote: On 01/27/13 12:18, Yijing Wang wrote: 于 2013-01-27 19:19, Chris Clayton 写道: Hi Yijing On 01/27/13 02:45, Yijing Wang wrote: 于 2013-01-27 4:54, Chris Clayton 写道: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? That's correct. When I first encountered the oops, I did not have the pciehp driver loaded and removing the device from the slot whilst the laptop was powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). OK, thanks for the advice. The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and lspci -vvv info after hotplug device from your Fujitsu laptop with above module parameters? I wasn't sure whether or not the pciehp driver should be loaded on its own or with the acpiphp driver also loaded. So I built them both as modules and planned to try both, pciehp only and acpiphp only. However, I've found that acpiphp will not load (regardless of whether or not pciehp is already loaded). What I get is: [chris:~]$ sudo modprobe acpiphp debug=1 modprobe: ERROR: could not insert 'acpiphp': No such device Are you sure you had pciehp already loaded? Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). OK, thanks again for the advice. I've disabled the acpiphp driver. Pitty. For me only with acpiphp works detection of express card in the slot. With pciehp the PresDet is not updated properly upon removal/insertion and sometimes, probably as a result of the previous, PresDet on the SltSta: line of lspci is not correct. So I moved away from pciehp. I have a SandyBridge based laptop so I was hoping with your i5-based laptop you have also great chance to get rid of pciehp issues. Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
On 01/27/13 14:26, Martin Mokrejs wrote: Chris Clayton wrote: On 01/27/13 12:18, Yijing Wang wrote: 于 2013-01-27 19:19, Chris Clayton 写道: Hi Yijing On 01/27/13 02:45, Yijing Wang wrote: 于 2013-01-27 4:54, Chris Clayton 写道: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? That's correct. When I first encountered the oops, I did not have the pciehp driver loaded and removing the device from the slot whilst the laptop was powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). OK, thanks for the advice. The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and lspci -vvv info after hotplug device from your Fujitsu laptop with above module parameters? I wasn't sure whether or not the pciehp driver should be loaded on its own or with the acpiphp driver also loaded. So I built them both as modules and planned to try both, pciehp only and acpiphp only. However, I've found that acpiphp will not load (regardless of whether or not pciehp is already loaded). What I get is: [chris:~]$ sudo modprobe acpiphp debug=1 modprobe: ERROR: could not insert 'acpiphp': No such device Are you sure you had pciehp already loaded? Yes, I'm sure it was. Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). OK, thanks again for the advice. I've disabled the acpiphp driver. Pitty. For me only with acpiphp works detection of express card in the slot. With pciehp the PresDet is not updated properly upon removal/insertion and sometimes, probably as a result of the previous, PresDet on the SltSta: line of lspci is not correct. So I moved away from pciehp. I have a SandyBridge based laptop so I was hoping with your i5-based laptop you have also great chance to get rid of pciehp issues. I've just (very carefully) set this up again (i.e. no pciehp driver (module or builtin), acpiphp driver built in and pcie_aspm=off on the kernel command line (via grub). My card is not detected on insertion. :-( Thanks for your suggestions, Martin. I am grateful. Chris Martin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Chris Clayton wrote: On 01/27/13 14:26, Martin Mokrejs wrote: Chris Clayton wrote: On 01/27/13 12:18, Yijing Wang wrote: 于 2013-01-27 19:19, Chris Clayton 写道: Hi Yijing On 01/27/13 02:45, Yijing Wang wrote: 于 2013-01-27 4:54, Chris Clayton 写道: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? That's correct. When I first encountered the oops, I did not have the pciehp driver loaded and removing the device from the slot whilst the laptop was powered on resulted in the oops. Hmm, that's unsafe and dangerous, because device now may be running. There are two ways to trigger pci hot-add or hot-remove in linux, after loaded pciehp or acpiphp module (the two modules only one can loaded into system at the same time). You can trigger hot-add/hot-remove by sysfs interface under /sys/bus/pci/slots/[slot-name]/power or attention button on hardware (if your laptop supports that). OK, thanks for the advice. The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and lspci -vvv info after hotplug device from your Fujitsu laptop with above module parameters? I wasn't sure whether or not the pciehp driver should be loaded on its own or with the acpiphp driver also loaded. So I built them both as modules and planned to try both, pciehp only and acpiphp only. However, I've found that acpiphp will not load (regardless of whether or not pciehp is already loaded). What I get is: [chris:~]$ sudo modprobe acpiphp debug=1 modprobe: ERROR: could not insert 'acpiphp': No such device Are you sure you had pciehp already loaded? Yes, I'm sure it was. Ah, sorry, wanted to say Are you sure you had NOT pciehp already loaded (loaded before)?. If you retry without loading it ever you might succeed with acpiphp. Currently, If your hardware support pciehp native hotplug, acpiphp driver will be rejected when loading it in system (you can force loading it by add boot parameter pcie_aspm=off as Martin said). OK, thanks again for the advice. I've disabled the acpiphp driver. Pitty. For me only with acpiphp works detection of express card in the slot. With pciehp the PresDet is not updated properly upon removal/insertion and sometimes, probably as a result of the previous, PresDet on the SltSta: line of lspci is not correct. So I moved away from pciehp. I have a SandyBridge based laptop so I was hoping with your i5-based laptop you have also great chance to get rid of pciehp issues. I've just (very carefully) set this up again (i.e. no pciehp driver (module or builtin), acpiphp driver built in and pcie_aspm=off on the kernel command line (via grub). My card is not detected on insertion. :-( Do you have any other express card around to try if it works at all? Try that always after a cold boot. Posting a diff result of the below procedure might help: # lspci -vvvxxx lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_1st_removal.txt [re-plug your card into the slot] # lspci -vvvxxx lspci.after_1st_re-insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_2nd_removal.txt Then compare them using diff. These should have no difference: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt These may have only little difference, or none: diff lspci.before_insertion.txt lspci.after_1st_removal.txt diff
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Thanks again, Martin. Firstly, maybe we should remove the linux-media list from the copy list. I imagine this hotplug stuff is just noise to them. [snip] Do you have any other express card around to try if it works at all? Try that always after a cold boot. Not at the moment, but I ordered at USB3 expresscard yesterday, so I will have one soon. Posting a diff result of the below procedure might help: # lspci -vvvxxx lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_1st_removal.txt [re-plug your card into the slot] # lspci -vvvxxx lspci.after_1st_re-insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_2nd_removal.txt OK, I've been using kernel 3.8.0-rc kernels so far, but given that is still under development, I've switched to 3.7.4, mainly because you are having success with 3.7.x, acpiphp and pcie_aspm=off. I verified the environment as follows: [chris:~]$ cat /proc/cmdline root=/dev/sda5 pcie_aspm=off ro resume=/dev/sda6 [chris:~]$ dmesg | grep ASPM [0.00] PCIe ASPM is disabled [0.348959] pci:00: ACPI _OSC support notification failed, disabling PCIe ASPM [chris:~]$ dmesg | grep acpiphp [0.400846] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [chris:~]$ dmesg | grep pciehp [chris:~]$ uname -a Linux laptop 3.7.4 #13 SMP PREEMPT Sun Jan 27 18:39:39 GMT 2013 i686 GNU/Linux Then compare them using diff. These should have no difference: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt Correct, there were no differences. These may have only little difference, or none: diff lspci.before_insertion.txt lspci.after_1st_removal.txt 263c263 LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt- 273c273 Changed: MRL- PresDet- LinkState- --- Changed: MRL- PresDet- LinkState+ 295,296c295,296 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 --- 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 50: 40 00 11 50 60 b2 1c 00 08 00 00 01 00 00 00 00 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt No difference. Finally, these should confirm whether the PresDet works for you (for me NOT with pciehp but does work with acpiphp). You should see PresDet- to PresDet+ changes in: Yes, I do see the PresDet- to PresDet+ changes diff lspci.before_insertion.txt lspci.after_insertion.txt 263c263 LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- 272,273c272,273 SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- Changed: MRL- PresDet- LinkState- --- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState+ 295,296c295,296 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 --- 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 50: 40 00 11 70 60 b2 1c 00 08 00 40 01 00 00 00 00 diff lspci.after_1st_removal.txt lspci.after_1st_re-insertion.txt 267c267 LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- 272c272 SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- --- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- 296c296 50: 40 00 11 50 60 b2 1c 00 08 00 00 01 00 00 00 00 --- 50: 40 00 11 70 60 b2 1c 00 08 00 40 01 00 00 00 00 You should see PresDet+ to PresDet- changes in: Yes, I see those changes too. diff lspci.after_insertion.txt lspci.after_1st_removal.txt
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Chris Clayton wrote: Thanks again, Martin. Firstly, maybe we should remove the linux-media list from the copy list. I imagine this hotplug stuff is just noise to them. [snip] Do you have any other express card around to try if it works at all? Try that always after a cold boot. Not at the moment, but I ordered at USB3 expresscard yesterday, so I will have one soon. Posting a diff result of the below procedure might help: # lspci -vvvxxx lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_1st_removal.txt [re-plug your card into the slot] # lspci -vvvxxx lspci.after_1st_re-insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_2nd_removal.txt OK, I've been using kernel 3.8.0-rc kernels so far, but given that is still under development, I've switched to 3.7.4, mainly because you are having success with 3.7.x, acpiphp and pcie_aspm=off. I verified the environment as follows: [chris:~]$ cat /proc/cmdline root=/dev/sda5 pcie_aspm=off ro resume=/dev/sda6 [chris:~]$ dmesg | grep ASPM [0.00] PCIe ASPM is disabled [0.348959] pci:00: ACPI _OSC support notification failed, disabling PCIe ASPM [chris:~]$ dmesg | grep acpiphp [0.400846] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [chris:~]$ dmesg | grep pciehp [chris:~]$ uname -a Linux laptop 3.7.4 #13 SMP PREEMPT Sun Jan 27 18:39:39 GMT 2013 i686 GNU/Linux vostro ~ # cat /proc/cmdline root=/dev/sda5 pciehp.pciehp_debug=1 slub_debug=AFPZ pcie_aspm=off vostro ~ # dmesg | grep ASPM [0.00] PCIe ASPM is disabled vostro ~ # dmesg | grep acpiphp [2.449038] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [2.453757] acpiphp: Slot [1] registered vostro ~ # uname -a Linux vostro 3.7.4-default #2 SMP Mon Jan 21 22:45:22 MET 2013 x86_64 Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz GenuineIntel GNU/Linux vostro ~ # Then compare them using diff. These should have no difference: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt Correct, there were no differences. These may have only little difference, or none: diff lspci.before_insertion.txt lspci.after_1st_removal.txt 263c263 LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt- 273c273 Changed: MRL- PresDet- LinkState- --- Changed: MRL- PresDet- LinkState+ 295,296c295,296 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 --- 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 50: 40 00 11 50 60 b2 1c 00 08 00 00 01 00 00 00 00 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt No difference. Finally, these should confirm whether the PresDet works for you (for me NOT with pciehp but does work with acpiphp). You should see PresDet- to PresDet+ changes in: Yes, I do see the PresDet- to PresDet+ changes diff lspci.before_insertion.txt lspci.after_insertion.txt 263c263 LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- 272,273c272,273 SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- Changed: MRL- PresDet- LinkState- --- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState+ 295,296c295,296 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 --- 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 50: 40 00 11 70 60 b2 1c 00 08 00 40 01 00 00 00 00 diff lspci.after_1st_removal.txt lspci.after_1st_re-insertion.txt 267c267 LnkSta: Speed 2.5GT/s, Width x1,
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Sorry for the delay reply. It seems like my reply last night was missed. From the sysinfo you provide, there are no pcie port devices under /sys/bus/pci_express/devices. Maybe because there are some problems with _OSC in your laptop, so pcie port driver won't create pcie port device for hotplug, aer and so on. Maybe you can add boot parameter pcie_ports=native and reboot your laptop. Then use #modprobe pciehp pciehp_force=1 pciehp_debug=1 to load pciehp modules. After above actions, enter /sys/bus/pci_express/devices/ directory and /sys/bus/pci/slots/ Some slots and pcie port devices should be there now. /sys/bus/pci_express/devices: total 0 /sys/bus/pci_express/drivers: total 0 drwxr-xr-x 2 root root 0 Jan 27 13:17 pciehp/ On 2013/1/28 6:53, Chris Clayton wrote: Thanks again, Martin. Firstly, maybe we should remove the linux-media list from the copy list. I imagine this hotplug stuff is just noise to them. [snip] Do you have any other express card around to try if it works at all? Try that always after a cold boot. Not at the moment, but I ordered at USB3 expresscard yesterday, so I will have one soon. Posting a diff result of the below procedure might help: # lspci -vvvxxx lspci.before_insertion.txt [plug your card into the slot] # lspci -vvvxxx lspci.after_insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_1st_removal.txt [re-plug your card into the slot] # lspci -vvvxxx lspci.after_1st_re-insertion.txt [ unplug your card] # lspci -vvvxxx lspci.after_2nd_removal.txt OK, I've been using kernel 3.8.0-rc kernels so far, but given that is still under development, I've switched to 3.7.4, mainly because you are having success with 3.7.x, acpiphp and pcie_aspm=off. I verified the environment as follows: [chris:~]$ cat /proc/cmdline root=/dev/sda5 pcie_aspm=off ro resume=/dev/sda6 [chris:~]$ dmesg | grep ASPM [0.00] PCIe ASPM is disabled [0.348959] pci:00: ACPI _OSC support notification failed, disabling PCIe ASPM [chris:~]$ dmesg | grep acpiphp [0.400846] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [chris:~]$ dmesg | grep pciehp [chris:~]$ uname -a Linux laptop 3.7.4 #13 SMP PREEMPT Sun Jan 27 18:39:39 GMT 2013 i686 GNU/Linux Then compare them using diff. These should have no difference: diff lspci.after_insertion.txt lspci.after_1st_re-insertion.txt diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt Correct, there were no differences. These may have only little difference, or none: diff lspci.before_insertion.txt lspci.after_1st_removal.txt 263c263 LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt+ ABWMgmt- 273c273 Changed: MRL- PresDet- LinkState- --- Changed: MRL- PresDet- LinkState+ 295,296c295,296 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 50: 03 00 01 10 60 b2 1c 00 08 00 00 00 00 00 00 00 --- 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 3c 12 04 50: 40 00 11 50 60 b2 1c 00 08 00 00 01 00 00 00 00 diff lspci.after_1st_removal.txt lspci.after_2nd_removal.txt No difference. Finally, these should confirm whether the PresDet works for you (for me NOT with pciehp but does work with acpiphp). You should see PresDet- to PresDet+ changes in: Yes, I do see the PresDet- to PresDet+ changes diff lspci.before_insertion.txt lspci.after_insertion.txt 263c263 LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 1us, L1 16us --- LnkCap: Port #4, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 512ns, L1 16us 265c265 LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk- --- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ 267c267 LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- --- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- 272,273c272,273 SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock- Changed: MRL- PresDet- LinkState- --- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState+ 295,296c295,296 40: 10 80 42 01 00 80 00 00 00 00 10 00 12 4c 12 04 50: 03 00 01
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
于 2013-01-27 4:54, Chris Clayton 写道: > Hi Martin, > > On 01/24/13 19:21, Martin Mokrejs wrote: >> Hi Chris, >>try to include in kernel only acpiphp and omit pciehp. Don't use modules >> but include >> them statically. And try, in addition, check whether "pcie_aspm=off" in >> grub.conf helped. >> > > Thanks for the tip. I had the pciehp driver installed, but it was a module > and not loaded. I didn't have acpiphp enabled at all. Building them both in > statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? > >>The best would if you subscribe to linux-pci, and read my recent threads >> about similar issues I had with express cards with Dell Vostro 3550. >> Further, there is >> a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, >> just browse the >> archives of linux-pci and see the pacthes and the discussion. > > Those discussions are way above my level of knowledge. I guess all this work > will be merged into mainline in due course, so I'll watch for them in 3.9 or > later. Unless, of course, there is a tree I could clone and help test the > changes with my laptop and expresscard. > > Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card > recognised by rebooting with the card inserted (or by writing 1 > to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel > bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and "lspci -vvv" info after hotplug device from your Fujitsu laptop with above module parameters? Thanks! Yijing. > Thanks again. > > Chris > >> Martin >> >> Chris Clayton wrote: >>> Hi, >>> >>> I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got >>> an Oops when I removed from the expresscard slot in my laptop. I will quite >>> understand if the response to this report is "don't do that!", but in that >>> case, how should one remove one of these cards? >>> >>> I have attached three files: >>> >>> 1. the dmesg output from when I rebooted the machine after the oops. I have >>> turned debugging on in the dib700p and cx23885 modules via modules options >>> in /etc/modprobe.d/hvr1400.conf; >>> >>> 2. the .config file for the kernel that oopsed. >>> >>> 3. the text of the oops message. I've typed this up from a photograph of >>> the screen because the laptop was locked up and there was nothing in the >>> log files. Apologies for any typos, but I have tried to be careful. >>> >>> Assuming the answer isn't don't do that, let me know if I can provide any >>> additional diagnostics, test any patches, etc. Please, however, cc me as >>> I'm not subscribed. >>> >>> Chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Chris Clayton wrote: > Hi Martin, > > On 01/24/13 19:21, Martin Mokrejs wrote: >> Hi Chris, >>try to include in kernel only acpiphp and omit pciehp. Don't use modules >> but include >> them statically. And try, in addition, check whether "pcie_aspm=off" in >> grub.conf helped. >> > > Thanks for the tip. I had the pciehp driver installed, but it was a module > and not loaded. I didn't have acpiphp enabled at all. Building them both in > statically, appears to have papered over the cracks of the oops :-) > >>The best would if you subscribe to linux-pci, and read my recent threads >> about similar issues I had with express cards with Dell Vostro 3550. >> Further, there is >> a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, >> just browse the >> archives of linux-pci and see the pacthes and the discussion. > > Those discussions are way above my level of knowledge. I guess all this work > will be merged into mainline in due course, so I'll watch for them in 3.9 or > later. Unless, of course, there is a tree I could clone and help test the > changes with my laptop and expresscard. > > Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card > recognised by rebooting with the card inserted (or by writing 1 > to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel > bugzilla, so I'll look through them and see what's being done. That's what I suspected. Compile in statically acpiphp, no pciehp at all (not even as a module). Then it might work for you -- at least it does for me, provided I use "pcie_aspm=off". Martin > > Thanks again. > > Chris > >> Martin >> >> Chris Clayton wrote: >>> Hi, >>> >>> I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got >>> an Oops when I removed from the expresscard slot in my laptop. I will quite >>> understand if the response to this report is "don't do that!", but in that >>> case, how should one remove one of these cards? >>> >>> I have attached three files: >>> >>> 1. the dmesg output from when I rebooted the machine after the oops. I have >>> turned debugging on in the dib700p and cx23885 modules via modules options >>> in /etc/modprobe.d/hvr1400.conf; >>> >>> 2. the .config file for the kernel that oopsed. >>> >>> 3. the text of the oops message. I've typed this up from a photograph of >>> the screen because the laptop was locked up and there was nothing in the >>> log files. Apologies for any typos, but I have tried to be careful. >>> >>> Assuming the answer isn't don't do that, let me know if I can provide any >>> additional diagnostics, test any patches, etc. Please, however, cc me as >>> I'm not subscribed. >>> >>> Chris > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether "pcie_aspm=off" in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Thanks again. Chris Martin Chris Clayton wrote: Hi, I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got an Oops when I removed from the expresscard slot in my laptop. I will quite understand if the response to this report is "don't do that!", but in that case, how should one remove one of these cards? I have attached three files: 1. the dmesg output from when I rebooted the machine after the oops. I have turned debugging on in the dib700p and cx23885 modules via modules options in /etc/modprobe.d/hvr1400.conf; 2. the .config file for the kernel that oopsed. 3. the text of the oops message. I've typed this up from a photograph of the screen because the laptop was locked up and there was nothing in the log files. Apologies for any typos, but I have tried to be careful. Assuming the answer isn't don't do that, let me know if I can provide any additional diagnostics, test any patches, etc. Please, however, cc me as I'm not subscribed. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Thanks again. Chris Martin Chris Clayton wrote: Hi, I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got an Oops when I removed from the expresscard slot in my laptop. I will quite understand if the response to this report is don't do that!, but in that case, how should one remove one of these cards? I have attached three files: 1. the dmesg output from when I rebooted the machine after the oops. I have turned debugging on in the dib700p and cx23885 modules via modules options in /etc/modprobe.d/hvr1400.conf; 2. the .config file for the kernel that oopsed. 3. the text of the oops message. I've typed this up from a photograph of the screen because the laptop was locked up and there was nothing in the log files. Apologies for any typos, but I have tried to be careful. Assuming the answer isn't don't do that, let me know if I can provide any additional diagnostics, test any patches, etc. Please, however, cc me as I'm not subscribed. Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, Chris Clayton wrote: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. That's what I suspected. Compile in statically acpiphp, no pciehp at all (not even as a module). Then it might work for you -- at least it does for me, provided I use pcie_aspm=off. Martin Thanks again. Chris Martin Chris Clayton wrote: Hi, I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got an Oops when I removed from the expresscard slot in my laptop. I will quite understand if the response to this report is don't do that!, but in that case, how should one remove one of these cards? I have attached three files: 1. the dmesg output from when I rebooted the machine after the oops. I have turned debugging on in the dib700p and cx23885 modules via modules options in /etc/modprobe.d/hvr1400.conf; 2. the .config file for the kernel that oopsed. 3. the text of the oops message. I've typed this up from a photograph of the screen because the laptop was locked up and there was nothing in the log files. Apologies for any typos, but I have tried to be careful. Assuming the answer isn't don't do that, let me know if I can provide any additional diagnostics, test any patches, etc. Please, however, cc me as I'm not subscribed. Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
于 2013-01-27 4:54, Chris Clayton 写道: Hi Martin, On 01/24/13 19:21, Martin Mokrejs wrote: Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. Thanks for the tip. I had the pciehp driver installed, but it was a module and not loaded. I didn't have acpiphp enabled at all. Building them both in statically, appears to have papered over the cracks of the oops :-) Not loaded pciehp driver? Remove the device from this slot without poweroff ? The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Those discussions are way above my level of knowledge. I guess all this work will be merged into mainline in due course, so I'll watch for them in 3.9 or later. Unless, of course, there is a tree I could clone and help test the changes with my laptop and expresscard. Hotplug isn't working at all on my Fujitsu laptop, so I can only get the card recognised by rebooting with the card inserted (or by writing 1 to/sys/bus/pci/rescan). There seem to be a few reports on this in the kernel bugzilla, so I'll look through them and see what's being done. Hi Chris, What about use #modprobe pciehp pciehp_debug=1 pciehp_poll_mode=1 pciehp_poll_time=1 ? Can you resend the dmesg log and lspci -vvv info after hotplug device from your Fujitsu laptop with above module parameters? Thanks! Yijing. Thanks again. Chris Martin Chris Clayton wrote: Hi, I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got an Oops when I removed from the expresscard slot in my laptop. I will quite understand if the response to this report is don't do that!, but in that case, how should one remove one of these cards? I have attached three files: 1. the dmesg output from when I rebooted the machine after the oops. I have turned debugging on in the dib700p and cx23885 modules via modules options in /etc/modprobe.d/hvr1400.conf; 2. the .config file for the kernel that oopsed. 3. the text of the oops message. I've typed this up from a photograph of the screen because the laptop was locked up and there was nothing in the log files. Apologies for any typos, but I have tried to be careful. Assuming the answer isn't don't do that, let me know if I can provide any additional diagnostics, test any patches, etc. Please, however, cc me as I'm not subscribed. Chris -- To unsubscribe from this list: send the line unsubscribe linux-pci in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether "pcie_aspm=off" in grub.conf helped. The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Martin Chris Clayton wrote: > Hi, > > I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got an > Oops when I removed from the expresscard slot in my laptop. I will quite > understand if the response to this report is "don't do that!", but in that > case, how should one remove one of these cards? > > I have attached three files: > > 1. the dmesg output from when I rebooted the machine after the oops. I have > turned debugging on in the dib700p and cx23885 modules via modules options in > /etc/modprobe.d/hvr1400.conf; > > 2. the .config file for the kernel that oopsed. > > 3. the text of the oops message. I've typed this up from a photograph of the > screen because the laptop was locked up and there was nothing in the log > files. Apologies for any typos, but I have tried to be careful. > > Assuming the answer isn't don't do that, let me know if I can provide any > additional diagnostics, test any patches, etc. Please, however, cc me as I'm > not subscribed. > > Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.8.0-rc4+ - Oops on removing WinTV-HVR-1400 expresscard TV Tuner
Hi Chris, try to include in kernel only acpiphp and omit pciehp. Don't use modules but include them statically. And try, in addition, check whether pcie_aspm=off in grub.conf helped. The best would if you subscribe to linux-pci, and read my recent threads about similar issues I had with express cards with Dell Vostro 3550. Further, there is a lot of changes to PCI hotplug done by Yingahi Liu and Rafael Wysockij, just browse the archives of linux-pci and see the pacthes and the discussion. Martin Chris Clayton wrote: Hi, I've today taken delivery of a WinTV-HVR-1400 expresscard TV Tuner and got an Oops when I removed from the expresscard slot in my laptop. I will quite understand if the response to this report is don't do that!, but in that case, how should one remove one of these cards? I have attached three files: 1. the dmesg output from when I rebooted the machine after the oops. I have turned debugging on in the dib700p and cx23885 modules via modules options in /etc/modprobe.d/hvr1400.conf; 2. the .config file for the kernel that oopsed. 3. the text of the oops message. I've typed this up from a photograph of the screen because the laptop was locked up and there was nothing in the log files. Apologies for any typos, but I have tried to be careful. Assuming the answer isn't don't do that, let me know if I can provide any additional diagnostics, test any patches, etc. Please, however, cc me as I'm not subscribed. Chris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
