Re: mellanox mlx4_core and SR-IOV
On Fri, Aug 10, 2012 at 12:51:53PM -0600, Chris Friesen wrote: > On 08/03/2012 02:33 AM, Lukas Hejtmanek wrote: > >I also tried OFED package from Mellanox which seems to have better SR-IOV > >support (at least mlx4_ib does not complain that SR-IOV is not supported). > >However, it does not work when SR-IOV enabled: > > Last I heard they were not officially providing support for SR-IOV. > Has anyone heard otherwise from the Mellanox folks? they speak about it for 2 years: http://www.openfabrics.org/archives/spring2010sonoma/Monday/1.30%20Liran%20Liss%20I%3FO%20Virtualization/sriov_liss.ppt these are modified OFED drivers which seem to contain SR-IOV code also for IB layer. http://www.mellanox.com/content/pages.php?pg=products_dyn_family=26_section=34#tab-three -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Fri, Aug 10, 2012 at 12:51:53PM -0600, Chris Friesen wrote: On 08/03/2012 02:33 AM, Lukas Hejtmanek wrote: I also tried OFED package from Mellanox which seems to have better SR-IOV support (at least mlx4_ib does not complain that SR-IOV is not supported). However, it does not work when SR-IOV enabled: Last I heard they were not officially providing support for SR-IOV. Has anyone heard otherwise from the Mellanox folks? they speak about it for 2 years: http://www.openfabrics.org/archives/spring2010sonoma/Monday/1.30%20Liran%20Liss%20I%3FO%20Virtualization/sriov_liss.ppt these are modified OFED drivers which seem to contain SR-IOV code also for IB layer. http://www.mellanox.com/content/pages.php?pg=products_dynproduct_family=26menu_section=34#tab-three -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Mon, Aug 06, 2012 at 10:07:06AM -0400, Konrad Rzeszutek Wilk wrote: > > good catch. I forgot to pass swiotl=force for DomU in Xen. So now, it seems > > that mlx4_core works, mlx4_en (ethernet part) works as well. Unfortunately, > > the IB part does not. IB layer complains that SR-IOV is currently > > unsupported > > (kernel 3.5.0). So no luck here so far. > > Don't use swiotlb=force. That is for the old style kernels. Use iommu=soft. OK. > > There is OFED stack directly from Mellanox, that seems to support SR-IOV > > even > > for IB layer, but they have buildable sources only for RHEL/SLES kernels > > (2.6.32) and even correcting the sources to get it compile with 3.5.0 does > > not > > make things work. The driver complains about interrupts not working in Dom0 > > or > > even without Xen hypervisor at all. > > So there is a bug that .. well, I thought I had fixed it with the > IB layer but maybe not. It was about VM_IO having to be used on the vmaps > being setup. But I can't recall the details. Perhaps the InfiniBand mailing > list might have some ... ah here it is: > http://old-list-archives.xen.org/archives/html/xen-devel/2011-01/msg00246.html not sure what do you mean. This fix is for Mellanox OFED driver to work? Or for stock kernel? Stock kernel contains explicit check for SR-IOV and refuses to load. this is exact fail of the Mellanox OFED driver. kernel: [6.568433] mlx4_core: Mellanox ConnectX core driver v1.0-mlnx_ofed1.5.3 (November 3, 2011) kernel: [6.568526] mlx4_core: Initializing :02:00.0 kernel: [7.071292] mlx4_core :02:00.0: Enabling sriov with:1 vfs kernel: [7.175587] mlx4_core :02:00.0: Running in master mode kernel: [ 18.613383] mlx4_core :02:00.0: command 0x31 timed out (go bit not cleared) kernel: [ 18.613475] mlx4_core :02:00.0: NOP command failed to generate MSI-X interrupt IRQ 94). kernel: [ 18.613564] mlx4_core :02:00.0: Trying again without MSI-X. kernel: [ 28.606086] mlx4_core :02:00.0: command 0x31 timed out (go bit not cleared) kernel: [ 30.615093] mlx4_core: probe of :02:00.0 failed with error -16 -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Mon, Aug 06, 2012 at 10:07:06AM -0400, Konrad Rzeszutek Wilk wrote: good catch. I forgot to pass swiotl=force for DomU in Xen. So now, it seems that mlx4_core works, mlx4_en (ethernet part) works as well. Unfortunately, the IB part does not. IB layer complains that SR-IOV is currently unsupported (kernel 3.5.0). So no luck here so far. Don't use swiotlb=force. That is for the old style kernels. Use iommu=soft. OK. There is OFED stack directly from Mellanox, that seems to support SR-IOV even for IB layer, but they have buildable sources only for RHEL/SLES kernels (2.6.32) and even correcting the sources to get it compile with 3.5.0 does not make things work. The driver complains about interrupts not working in Dom0 or even without Xen hypervisor at all. So there is a bug that .. well, I thought I had fixed it with the IB layer but maybe not. It was about VM_IO having to be used on the vmaps being setup. But I can't recall the details. Perhaps the InfiniBand mailing list might have some ... ah here it is: http://old-list-archives.xen.org/archives/html/xen-devel/2011-01/msg00246.html not sure what do you mean. This fix is for Mellanox OFED driver to work? Or for stock kernel? Stock kernel contains explicit check for SR-IOV and refuses to load. this is exact fail of the Mellanox OFED driver. kernel: [6.568433] mlx4_core: Mellanox ConnectX core driver v1.0-mlnx_ofed1.5.3 (November 3, 2011) kernel: [6.568526] mlx4_core: Initializing :02:00.0 kernel: [7.071292] mlx4_core :02:00.0: Enabling sriov with:1 vfs kernel: [7.175587] mlx4_core :02:00.0: Running in master mode kernel: [ 18.613383] mlx4_core :02:00.0: command 0x31 timed out (go bit not cleared) kernel: [ 18.613475] mlx4_core :02:00.0: NOP command failed to generate MSI-X interrupt IRQ 94). kernel: [ 18.613564] mlx4_core :02:00.0: Trying again without MSI-X. kernel: [ 28.606086] mlx4_core :02:00.0: command 0x31 timed out (go bit not cleared) kernel: [ 30.615093] mlx4_core: probe of :02:00.0 failed with error -16 -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
Hi, On Fri, Aug 03, 2012 at 06:49:59AM -0700, Konrad Wilk wrote: > This looks like you are using PV PCI passthrough? If so, did you > remember to use 'iommu=soft' to enable the Xen-SWIOTLB in your guest? > And are you booting with more than 4GB? Or is less than 3GB (so that you have > a nice gap in E820). good catch. I forgot to pass swiotl=force for DomU in Xen. So now, it seems that mlx4_core works, mlx4_en (ethernet part) works as well. Unfortunately, the IB part does not. IB layer complains that SR-IOV is currently unsupported (kernel 3.5.0). So no luck here so far. There is OFED stack directly from Mellanox, that seems to support SR-IOV even for IB layer, but they have buildable sources only for RHEL/SLES kernels (2.6.32) and even correcting the sources to get it compile with 3.5.0 does not make things work. The driver complains about interrupts not working in Dom0 or even without Xen hypervisor at all. The only good point is, that I managed to convice Supermicro (board manufacturer), that enabling SR-IOV in BIOS leads to BIOS lockup, they confirmed it and maybe they provide BIOS upgrade. Thanks all. -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
Hi, On Fri, Aug 03, 2012 at 06:49:59AM -0700, Konrad Wilk wrote: This looks like you are using PV PCI passthrough? If so, did you remember to use 'iommu=soft' to enable the Xen-SWIOTLB in your guest? And are you booting with more than 4GB? Or is less than 3GB (so that you have a nice gap in E820). good catch. I forgot to pass swiotl=force for DomU in Xen. So now, it seems that mlx4_core works, mlx4_en (ethernet part) works as well. Unfortunately, the IB part does not. IB layer complains that SR-IOV is currently unsupported (kernel 3.5.0). So no luck here so far. There is OFED stack directly from Mellanox, that seems to support SR-IOV even for IB layer, but they have buildable sources only for RHEL/SLES kernels (2.6.32) and even correcting the sources to get it compile with 3.5.0 does not make things work. The driver complains about interrupts not working in Dom0 or even without Xen hypervisor at all. The only good point is, that I managed to convice Supermicro (board manufacturer), that enabling SR-IOV in BIOS leads to BIOS lockup, they confirmed it and maybe they provide BIOS upgrade. Thanks all. -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 04:36:14PM -0700, Yinghai Lu wrote: > > so it seems, that pic=nocsr is a must now. > > yes. Or you have bios provide SRIOV support or 64 bit resource in _CRS. Well, I can use PCI passthrough in Xen now, however, it seems SR-IOV does not work in case of Mellanox mlx4 driver. With 3.5 stock kernel, I got this message in virtual domain: [2.23] mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011) [2.35] mlx4_core: Initializing :00:00.1 [2.666717] mlx4_core :00:00.1: enabling device ( -> 0002) [2.666975] mlx4_core :00:00.1: Xen PCI mapped GSI0 to IRQ168 [2.667040] mlx4_core :00:00.1: enabling bus mastering [2.667184] mlx4_core :00:00.1: Detected virtual function - running in slave mode [2.667214] mlx4_core :00:00.1: Sending reset [2.667319] mlx4_core :00:00.1: Sending vhcr0 [2.667886] mlx4_core :00:00.1: HCA minimum page size:1 [2.668067] mlx4_core :00:00.1: The host doesn't support eth interface [2.668074] mlx4_core :00:00.1: QUERY_FUNC_CAP command failed, aborting. [2.668079] mlx4_core :00:00.1: Failed to obtain slave caps [2.668305] mlx4_core: probe of :00:00.1 failed with error -93 not sure what does it mean. I also tried OFED package from Mellanox which seems to have better SR-IOV support (at least mlx4_ib does not complain that SR-IOV is not supported). However, it does not work when SR-IOV enabled: [13677.034266] mlx4_core :02:00.0: Running in master mode [13689.278238] mlx4_core :02:00.0: command 0x31 timed out (go bit not cleared) [13689.278324] mlx4_core :02:00.0: NOP command failed to generate MSI-X interrupt IRQ 241). [13689.278399] mlx4_core :02:00.0: Trying again without MSI-X. [13699.286473] mlx4_core :02:00.0: command 0x31 timed out (go bit not cleared) [13699.286557] mlx4_core :02:00.0: NOP command failed to generate interrupt (IRQ 237), aborting. [13699.286633] mlx4_core :02:00.0: BIOS or ACPI interrupt routing problem? [13701.406680] mlx4_core: probe of :02:00.0 failed with error -16 if I disable SR-IOV mode for this driver, it works OK. Could the interrupt problem be BIOS related? I.e., it won't work until I got BIOS which properly supports SR-IOV with Mellanox card? -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 04:36:14PM -0700, Yinghai Lu wrote: so it seems, that pic=nocsr is a must now. yes. Or you have bios provide SRIOV support or 64 bit resource in _CRS. Well, I can use PCI passthrough in Xen now, however, it seems SR-IOV does not work in case of Mellanox mlx4 driver. With 3.5 stock kernel, I got this message in virtual domain: [2.23] mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011) [2.35] mlx4_core: Initializing :00:00.1 [2.666717] mlx4_core :00:00.1: enabling device ( - 0002) [2.666975] mlx4_core :00:00.1: Xen PCI mapped GSI0 to IRQ168 [2.667040] mlx4_core :00:00.1: enabling bus mastering [2.667184] mlx4_core :00:00.1: Detected virtual function - running in slave mode [2.667214] mlx4_core :00:00.1: Sending reset [2.667319] mlx4_core :00:00.1: Sending vhcr0 [2.667886] mlx4_core :00:00.1: HCA minimum page size:1 [2.668067] mlx4_core :00:00.1: The host doesn't support eth interface [2.668074] mlx4_core :00:00.1: QUERY_FUNC_CAP command failed, aborting. [2.668079] mlx4_core :00:00.1: Failed to obtain slave caps [2.668305] mlx4_core: probe of :00:00.1 failed with error -93 not sure what does it mean. I also tried OFED package from Mellanox which seems to have better SR-IOV support (at least mlx4_ib does not complain that SR-IOV is not supported). However, it does not work when SR-IOV enabled: [13677.034266] mlx4_core :02:00.0: Running in master mode [13689.278238] mlx4_core :02:00.0: command 0x31 timed out (go bit not cleared) [13689.278324] mlx4_core :02:00.0: NOP command failed to generate MSI-X interrupt IRQ 241). [13689.278399] mlx4_core :02:00.0: Trying again without MSI-X. [13699.286473] mlx4_core :02:00.0: command 0x31 timed out (go bit not cleared) [13699.286557] mlx4_core :02:00.0: NOP command failed to generate interrupt (IRQ 237), aborting. [13699.286633] mlx4_core :02:00.0: BIOS or ACPI interrupt routing problem? [13701.406680] mlx4_core: probe of :02:00.0 failed with error -16 if I disable SR-IOV mode for this driver, it works OK. Could the interrupt problem be BIOS related? I.e., it won't work until I got BIOS which properly supports SR-IOV with Mellanox card? -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 02:32:17PM -0700, Yinghai Lu wrote: > yes, i knew that. > > one patch in my for-pci-next should address that. > > http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=patch;h=fcce563f868e296f46a2eeaa88d6959bcee26a2d this is probably only half-way. well mlx driver loads but it complains again on MMIO: [3.564844] mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011) [3.564845] mlx4_core: Initializing :02:00.0 [3.564967] mlx4_core :02:00.0: Enabling sriov with:4 vfs [3.565087] mlx4_core :02:00.0: not enough MMIO resources for SR-IOV [3.565402] mlx4_core :02:00.0: Failed to enable sriov,continuing without sriov enabled (err = -12). so it seems, that pic=nocsr is a must now. -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 02:27:34PM -0700, Yinghai Lu wrote: > you may try to boot with pci=nocrs ok, pci=nocrs i got: 02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0) 02:00.1 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2 Virtual Function] (rev b0) 02:00.2 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2 Virtual Function] (rev b0) 02:00.3 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2 Virtual Function] (rev b0) 02:00.4 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2 Virtual Function] (rev b0) so it works. Should I try your patch without pci=nocrs? -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 11:29:02AM -0700, Yinghai Lu wrote: > iov bar is not assigned by BIOS, and kernel can not find range for it too. > > Lukas, can you post whole boot log with PCI_DEBUG enabled? That will > tell exact why kernel does not assign them. > > Recent kernel from 3.4... should enable realloc when SRIOV bar is not > assigned. sorry for confusing, PCI_DEBUG does not break mlx driver, it is reallocation code that results: [3.555008] mlx4_core :02:00.0: Missing UAR, aborting. -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 11:29:02AM -0700, Yinghai Lu wrote: > On Wed, Aug 1, 2012 at 10:37 AM, Roland Dreier wrote: > > On Wed, Aug 1, 2012 at 6:38 AM, Lukas Hejtmanek > > wrote: > >> [3.558296] mlx4_core :02:00.0: not enough MMIO resources for > >> SR-IOV (nres: 0, iov->nres: 1) > > > > This comes from the core sriov_enable() function, not anything in mlx4. > > (although my kernel doesn't have the print of nres in that message) > > > > Not sure what it means. > > iov bar is not assigned by BIOS, and kernel can not find range for it too. > > Lukas, can you post whole boot log with PCI_DEBUG enabled? That will > tell exact why kernel does not assign them. > > Recent kernel from 3.4... should enable realloc when SRIOV bar is not > assigned. here is full boot log. http://www.fi.muni.cz/~xhejtman/dmesg.log weird with PCI_DEBUG it does not load mlx driver at all.. -- Lukáš Hejtmánek -- 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/
mellanox mlx4_core and SR-IOV
Hello, I tried to use SR-IOV virtualizaton for Mellanox ConnectX2 card with mlx4_core driver with kernel 3.5.0. I built firware for the IB card with sriov_en = true, lspci shows: 02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0) Subsystem: Super Micro Computer Inc Device 0048 Flags: bus master, fast devsel, latency 0, IRQ 24 Memory at fbd0 (64-bit, non-prefetchable) [size=1M] Memory at f880 (64-bit, prefetchable) [size=8M] Capabilities: [40] Power Management version 3 Capabilities: [48] Vital Product Data Capabilities: [9c] MSI-X: Enable+ Count=128 Masked- Capabilities: [60] Express Endpoint, MSI 00 Capabilities: [100] Alternative Routing-ID Interpretation (ARI) Capabilities: [148] Device Serial Number 00-25-90-ff-ff-28-09-08 Capabilities: [108] Single Root I/O Virtualization (SR-IOV) Kernel driver in use: mlx4_core however, the driver complains: [3.558221] mlx4_core :02:00.0: Enabling sriov with:4 vfs [3.558296] mlx4_core :02:00.0: not enough MMIO resources for SR-IOV (nres: 0, iov->nres: 1) [3.558299] mlx4_core :02:00.0: Failed to enable sriov,continuing without sriov enabled (err = -12). Is there any workaround for this? Or the bug is in BIOS and without a proper fix this is never gonna work? Perhaps, are there any persons more suitable for these kind of questions? -- Lukáš Hejtmánek -- 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/
mellanox mlx4_core and SR-IOV
Hello, I tried to use SR-IOV virtualizaton for Mellanox ConnectX2 card with mlx4_core driver with kernel 3.5.0. I built firware for the IB card with sriov_en = true, lspci shows: 02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0) Subsystem: Super Micro Computer Inc Device 0048 Flags: bus master, fast devsel, latency 0, IRQ 24 Memory at fbd0 (64-bit, non-prefetchable) [size=1M] Memory at f880 (64-bit, prefetchable) [size=8M] Capabilities: [40] Power Management version 3 Capabilities: [48] Vital Product Data Capabilities: [9c] MSI-X: Enable+ Count=128 Masked- Capabilities: [60] Express Endpoint, MSI 00 Capabilities: [100] Alternative Routing-ID Interpretation (ARI) Capabilities: [148] Device Serial Number 00-25-90-ff-ff-28-09-08 Capabilities: [108] Single Root I/O Virtualization (SR-IOV) Kernel driver in use: mlx4_core however, the driver complains: [3.558221] mlx4_core :02:00.0: Enabling sriov with:4 vfs [3.558296] mlx4_core :02:00.0: not enough MMIO resources for SR-IOV (nres: 0, iov-nres: 1) [3.558299] mlx4_core :02:00.0: Failed to enable sriov,continuing without sriov enabled (err = -12). Is there any workaround for this? Or the bug is in BIOS and without a proper fix this is never gonna work? Perhaps, are there any persons more suitable for these kind of questions? -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 11:29:02AM -0700, Yinghai Lu wrote: On Wed, Aug 1, 2012 at 10:37 AM, Roland Dreier rol...@kernel.org wrote: On Wed, Aug 1, 2012 at 6:38 AM, Lukas Hejtmanek xhejt...@ics.muni.cz wrote: [3.558296] mlx4_core :02:00.0: not enough MMIO resources for SR-IOV (nres: 0, iov-nres: 1) This comes from the core sriov_enable() function, not anything in mlx4. (although my kernel doesn't have the print of nres in that message) Not sure what it means. iov bar is not assigned by BIOS, and kernel can not find range for it too. Lukas, can you post whole boot log with PCI_DEBUG enabled? That will tell exact why kernel does not assign them. Recent kernel from 3.4... should enable realloc when SRIOV bar is not assigned. here is full boot log. http://www.fi.muni.cz/~xhejtman/dmesg.log weird with PCI_DEBUG it does not load mlx driver at all.. -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 11:29:02AM -0700, Yinghai Lu wrote: iov bar is not assigned by BIOS, and kernel can not find range for it too. Lukas, can you post whole boot log with PCI_DEBUG enabled? That will tell exact why kernel does not assign them. Recent kernel from 3.4... should enable realloc when SRIOV bar is not assigned. sorry for confusing, PCI_DEBUG does not break mlx driver, it is reallocation code that results: [3.555008] mlx4_core :02:00.0: Missing UAR, aborting. -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 02:27:34PM -0700, Yinghai Lu wrote: you may try to boot with pci=nocrs ok, pci=nocrs i got: 02:00.0 InfiniBand: Mellanox Technologies MT26428 [ConnectX VPI PCIe 2.0 5GT/s - IB QDR / 10GigE] (rev b0) 02:00.1 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2 Virtual Function] (rev b0) 02:00.2 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2 Virtual Function] (rev b0) 02:00.3 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2 Virtual Function] (rev b0) 02:00.4 InfiniBand: Mellanox Technologies MT25400 Family [ConnectX-2 Virtual Function] (rev b0) so it works. Should I try your patch without pci=nocrs? -- Lukáš Hejtmánek -- 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: mellanox mlx4_core and SR-IOV
On Wed, Aug 01, 2012 at 02:32:17PM -0700, Yinghai Lu wrote: yes, i knew that. one patch in my for-pci-next should address that. http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=patch;h=fcce563f868e296f46a2eeaa88d6959bcee26a2d this is probably only half-way. well mlx driver loads but it complains again on MMIO: [3.564844] mlx4_core: Mellanox ConnectX core driver v1.1 (Dec, 2011) [3.564845] mlx4_core: Initializing :02:00.0 [3.564967] mlx4_core :02:00.0: Enabling sriov with:4 vfs [3.565087] mlx4_core :02:00.0: not enough MMIO resources for SR-IOV [3.565402] mlx4_core :02:00.0: Failed to enable sriov,continuing without sriov enabled (err = -12). so it seems, that pic=nocsr is a must now. -- Lukáš Hejtmánek -- 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: 2.6.25-rc2 Regression Thinkpad acpi
On Mon, Feb 25, 2008 at 08:00:35PM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 25 Feb 2008, Lukas Hejtmanek wrote: > > volume keys work. But anything through acpid does not. Even AC/battery > > switch > > is not signalized. So the bug may be somewhere else? > > Yeah, there is an EC-related regression in 2.6.25-rc3 that bites your > thinkpad. I don't have a link to it right now, but if you look for the > messages to LKML on the last 48h, you will find it. this one fixes all my troubles with thinkpad hotkeys in rc3. http://lkml.org/lkml/2008/2/25/400 > > [ 418.816087] thinkpad_acpi: requested hot key mask 0x, but > > firmware forced it to 0x00ff > > Don't do this. Just let the driver select the default mask, unless you > *really* know better. OK, thanks. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
On Mon, Feb 25, 2008 at 08:00:35PM -0300, Henrique de Moraes Holschuh wrote: On Mon, 25 Feb 2008, Lukas Hejtmanek wrote: volume keys work. But anything through acpid does not. Even AC/battery switch is not signalized. So the bug may be somewhere else? Yeah, there is an EC-related regression in 2.6.25-rc3 that bites your thinkpad. I don't have a link to it right now, but if you look for the messages to LKML on the last 48h, you will find it. this one fixes all my troubles with thinkpad hotkeys in rc3. http://lkml.org/lkml/2008/2/25/400 [ 418.816087] thinkpad_acpi: requested hot key mask 0x, but firmware forced it to 0x00ff Don't do this. Just let the driver select the default mask, unless you *really* know better. OK, thanks. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
On Mon, Feb 25, 2008 at 06:01:13PM -0300, Henrique de Moraes Holschuh wrote: > Not even over the new netlink socket? Or the thinkpad-acpi input device? how can I check this? volume keys work. But anything through acpid does not. Even AC/battery switch is not signalized. So the bug may be somewhere else? > Please send me the debug output of thinkpad-acpi loading, just in case. [ 247.170385] thinkpad_acpi: ThinkPad ACPI Extras v0.19 [ 247.170398] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 247.170402] thinkpad_acpi: ThinkPad BIOS 7LETB0WW (2.10 ), EC 7KHT24WW-1.08 [ 247.170407] thinkpad_acpi: Lenovo ThinkPad T61 [ 247.171289] thinkpad_acpi: radio switch found; radios are enabled [ 247.184889] thinkpad_acpi: requested hot key mask 0x, but firmware forced it to 0x00ff [ 247.188509] thinkpad_acpi: detected a 16-level brightness capable ThinkPad [ 247.189027] input: ThinkPad Extra Buttons as /devices/virtual/input/input10 [ 418.790341] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \_SB.PCI0.LPC.EC for ec [ 418.793747] thinkpad_acpi: ibm_init: probing for driver [ 418.793758] thinkpad_acpi: ThinkPad ACPI Extras v0.19 [ 418.793762] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 418.793766] thinkpad_acpi: ThinkPad BIOS 7LETB0WW (2.10 ), EC 7KHT24WW-1.08 [ 418.793771] thinkpad_acpi: Lenovo ThinkPad T61 [ 418.793775] thinkpad_acpi: ibm_init: driver installed [ 418.793780] thinkpad_acpi: ibm_init: probing for hotkey [ 418.793827] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle HKEY for hkey [ 428.258389] thinkpad_acpi: radio switch found; radios are enabled [ 428.258423] thinkpad_acpi: hotkey_init: using Lenovo default hot key map [ 428.258431] thinkpad_acpi: hotkey_init: enabling hot key handling [ 428.264778] thinkpad_acpi: hotkey_init: legacy hot key reporting over procfs enabled [ 418.806536] thinkpad_acpi: register_tpacpi_subdriver: registering hotkey as an ACPI driver [ 418.808594] thinkpad_acpi: ibm_init: hotkey installed [ 418.816087] thinkpad_acpi: requested hot key mask 0x, but firmware forced it to 0x00ff [ 418.816100] thinkpad_acpi: ibm_init: probing for bluetooth [ 418.816114] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle HKEY for hkey [ 418.821862] thinkpad_acpi: ibm_init: bluetooth installed [ 418.821875] thinkpad_acpi: ibm_init: probing for wan [ 418.821890] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle HKEY for hkey [ 418.828238] thinkpad_acpi: wan_init: wan hardware not installed [ 418.828251] thinkpad_acpi: ibm_init: probing for light [ 418.828266] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \UCMS for cmos [ 418.842964] thinkpad_acpi: ibm_init: light installed [ 418.843021] thinkpad_acpi: ibm_init: probing for bay [ 418.843050] thinkpad_acpi: ibm_init: probing for cmos [ 418.843060] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \UCMS for cmos [ 418.843378] thinkpad_acpi: ibm_init: cmos installed [ 418.843385] thinkpad_acpi: ibm_init: probing for led [ 418.843402] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle LED for led [ 418.843407] thinkpad_acpi: ibm_init: led installed [ 418.843412] thinkpad_acpi: ibm_init: probing for beep [ 418.843418] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle BEEP for beep [ 418.843422] thinkpad_acpi: ibm_init: beep installed [ 418.843429] thinkpad_acpi: ibm_init: probing for thermal [ 418.849384] thinkpad_acpi: ibm_init: thermal installed [ 418.849392] thinkpad_acpi: ibm_init: probing for ecdump [ 418.849396] thinkpad_acpi: ibm_init: ecdump installed [ 418.849401] thinkpad_acpi: ibm_init: probing for brightness [ 418.849406] thinkpad_acpi: brightness_init: selected brightness_mode=2 [ 418.849424] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \_SB.PCI0.VID for vid [ 418.849464] thinkpad_acpi: detected a 16-level brightness capable ThinkPad [ 418.850526] thinkpad_acpi: ibm_init: brightness installed [ 418.850534] thinkpad_acpi: ibm_init: probing for volume [ 418.850538] thinkpad_acpi: ibm_init: volume installed [ 418.850545] thinkpad_acpi: ibm_init: probing for fan [ 418.850853] thinkpad_acpi: ibm_init: fan installed [ 418.850952] input: ThinkPad Extra Buttons as /devices/virtual/input/input11 > > I would be happy to test fixes to see whether things go well. > > Sure, try this one: not better. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
On Mon, Feb 25, 2008 at 05:03:54PM -0300, Henrique de Moraes Holschuh wrote: > This commit is indeed broken, and I have a tentative fix for it. But I'd > like to have a better description of just "how" the thinkpad keys do not > work anymore, to make sure I fix the entire breakage in one go. I will > stare at the code and the fix a bit more before sending in any patches, > though. Well, keys generate ACPI interrupt but acpid never receives any event. I would be happy to test fixes to see whether things go well. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc2 Regression Thinkpad acpi
Hello, 2.6.25-rc2-git7 has regression, thinkpad keys do not work any more. Probably this commit broke things 6c231bd5eb07ce546517019f334652b9ecfc329a -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc2 Regression Thinkpad acpi
Hello, 2.6.25-rc2-git7 has regression, thinkpad keys do not work any more. Probably this commit broke things 6c231bd5eb07ce546517019f334652b9ecfc329a -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
On Mon, Feb 25, 2008 at 05:03:54PM -0300, Henrique de Moraes Holschuh wrote: This commit is indeed broken, and I have a tentative fix for it. But I'd like to have a better description of just how the thinkpad keys do not work anymore, to make sure I fix the entire breakage in one go. I will stare at the code and the fix a bit more before sending in any patches, though. Well, keys generate ACPI interrupt but acpid never receives any event. I would be happy to test fixes to see whether things go well. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc2 Regression Thinkpad acpi
On Mon, Feb 25, 2008 at 06:01:13PM -0300, Henrique de Moraes Holschuh wrote: Not even over the new netlink socket? Or the thinkpad-acpi input device? how can I check this? volume keys work. But anything through acpid does not. Even AC/battery switch is not signalized. So the bug may be somewhere else? Please send me the debug output of thinkpad-acpi loading, just in case. [ 247.170385] thinkpad_acpi: ThinkPad ACPI Extras v0.19 [ 247.170398] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 247.170402] thinkpad_acpi: ThinkPad BIOS 7LETB0WW (2.10 ), EC 7KHT24WW-1.08 [ 247.170407] thinkpad_acpi: Lenovo ThinkPad T61 [ 247.171289] thinkpad_acpi: radio switch found; radios are enabled [ 247.184889] thinkpad_acpi: requested hot key mask 0x, but firmware forced it to 0x00ff [ 247.188509] thinkpad_acpi: detected a 16-level brightness capable ThinkPad [ 247.189027] input: ThinkPad Extra Buttons as /devices/virtual/input/input10 [ 418.790341] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \_SB.PCI0.LPC.EC for ec [ 418.793747] thinkpad_acpi: ibm_init: probing for driver [ 418.793758] thinkpad_acpi: ThinkPad ACPI Extras v0.19 [ 418.793762] thinkpad_acpi: http://ibm-acpi.sf.net/ [ 418.793766] thinkpad_acpi: ThinkPad BIOS 7LETB0WW (2.10 ), EC 7KHT24WW-1.08 [ 418.793771] thinkpad_acpi: Lenovo ThinkPad T61 [ 418.793775] thinkpad_acpi: ibm_init: driver installed [ 418.793780] thinkpad_acpi: ibm_init: probing for hotkey [ 418.793827] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle HKEY for hkey [ 428.258389] thinkpad_acpi: radio switch found; radios are enabled [ 428.258423] thinkpad_acpi: hotkey_init: using Lenovo default hot key map [ 428.258431] thinkpad_acpi: hotkey_init: enabling hot key handling [ 428.264778] thinkpad_acpi: hotkey_init: legacy hot key reporting over procfs enabled [ 418.806536] thinkpad_acpi: register_tpacpi_subdriver: registering hotkey as an ACPI driver [ 418.808594] thinkpad_acpi: ibm_init: hotkey installed [ 418.816087] thinkpad_acpi: requested hot key mask 0x, but firmware forced it to 0x00ff [ 418.816100] thinkpad_acpi: ibm_init: probing for bluetooth [ 418.816114] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle HKEY for hkey [ 418.821862] thinkpad_acpi: ibm_init: bluetooth installed [ 418.821875] thinkpad_acpi: ibm_init: probing for wan [ 418.821890] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle HKEY for hkey [ 418.828238] thinkpad_acpi: wan_init: wan hardware not installed [ 418.828251] thinkpad_acpi: ibm_init: probing for light [ 418.828266] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \UCMS for cmos [ 418.842964] thinkpad_acpi: ibm_init: light installed [ 418.843021] thinkpad_acpi: ibm_init: probing for bay [ 418.843050] thinkpad_acpi: ibm_init: probing for cmos [ 418.843060] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \UCMS for cmos [ 418.843378] thinkpad_acpi: ibm_init: cmos installed [ 418.843385] thinkpad_acpi: ibm_init: probing for led [ 418.843402] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle LED for led [ 418.843407] thinkpad_acpi: ibm_init: led installed [ 418.843412] thinkpad_acpi: ibm_init: probing for beep [ 418.843418] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle BEEP for beep [ 418.843422] thinkpad_acpi: ibm_init: beep installed [ 418.843429] thinkpad_acpi: ibm_init: probing for thermal [ 418.849384] thinkpad_acpi: ibm_init: thermal installed [ 418.849392] thinkpad_acpi: ibm_init: probing for ecdump [ 418.849396] thinkpad_acpi: ibm_init: ecdump installed [ 418.849401] thinkpad_acpi: ibm_init: probing for brightness [ 418.849406] thinkpad_acpi: brightness_init: selected brightness_mode=2 [ 418.849424] thinkpad_acpi: drv_acpi_handle_init: Found ACPI handle \_SB.PCI0.VID for vid [ 418.849464] thinkpad_acpi: detected a 16-level brightness capable ThinkPad [ 418.850526] thinkpad_acpi: ibm_init: brightness installed [ 418.850534] thinkpad_acpi: ibm_init: probing for volume [ 418.850538] thinkpad_acpi: ibm_init: volume installed [ 418.850545] thinkpad_acpi: ibm_init: probing for fan [ 418.850853] thinkpad_acpi: ibm_init: fan installed [ 418.850952] input: ThinkPad Extra Buttons as /devices/virtual/input/input11 I would be happy to test fixes to see whether things go well. Sure, try this one: not better. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Sat, Feb 16, 2008 at 05:20:49PM +, Pavel Machek wrote: > Is cat /dev/zero > file enough to reproduce this? yes. > ext3 filesystem? yes. > Will cat /etc/passwd work while machine is unresponsive? yes. while find does not work: time find / / /etc /etc/manpath.config /etc/update-manager /etc/update-manager/release-upgrades /etc/gshadow- /etc/inputrc /etc/openalrc /etc/bonobo-activation /etc/bonobo-activation/bonobo-activation-config.xml /etc/gnome-vfs-2.0 /etc/gnome-vfs-2.0/modules /etc/gnome-vfs-2.0/modules/obex-module.conf /etc/gnome-vfs-2.0/modules/extra-modules.conf /etc/gnome-vfs-2.0/modules/theme-method.conf /etc/gnome-vfs-2.0/modules/font-method.conf /etc/gnome-vfs-2.0/modules/default-modules.conf ^C real0m7.982s user0m0.003s sys 0m0.000s i.e., it took 8 seconds to list just 17 dir entries. It looks like I have this problem: http://www.linuxinsight.com/first_benchmarks_of_the_ext4_file_system.html#comment-619 (the last comment with title: Sustained writes 2 or more times the amount of memfree) -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Sat, Feb 16, 2008 at 05:20:49PM +, Pavel Machek wrote: Is cat /dev/zero file enough to reproduce this? yes. ext3 filesystem? yes. Will cat /etc/passwd work while machine is unresponsive? yes. while find does not work: time find / / /etc /etc/manpath.config /etc/update-manager /etc/update-manager/release-upgrades /etc/gshadow- /etc/inputrc /etc/openalrc /etc/bonobo-activation /etc/bonobo-activation/bonobo-activation-config.xml /etc/gnome-vfs-2.0 /etc/gnome-vfs-2.0/modules /etc/gnome-vfs-2.0/modules/obex-module.conf /etc/gnome-vfs-2.0/modules/extra-modules.conf /etc/gnome-vfs-2.0/modules/theme-method.conf /etc/gnome-vfs-2.0/modules/font-method.conf /etc/gnome-vfs-2.0/modules/default-modules.conf ^C real0m7.982s user0m0.003s sys 0m0.000s i.e., it took 8 seconds to list just 17 dir entries. It looks like I have this problem: http://www.linuxinsight.com/first_benchmarks_of_the_ext4_file_system.html#comment-619 (the last comment with title: Sustained writes 2 or more times the amount of memfree) -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent driver in linux kernel 2.6.25-rc2
On Tue, Feb 19, 2008 at 02:28:58PM -0800, Chatre, Reinette wrote: > > as of pre 2.6.25 kernels, kismet monitoring tool does not work with > > the message: # kismet > > Launching kismet_server: //usr/bin/kismet_server > > Suid priv-dropping disabled. This may not be secure. > > No specific sources given to be enabled, all will be enabled. > > Non-RFMon VAPs will be destroyed on multi-vap interfaces (ie, > > madwifi-ng) Enabling channel hopping. > > Enabling channel splitting. > > Source 0 (iwl4965): Enabling monitor mode for iwl4965 source > > interface wlan0 channel 6... > > FATAL: Failed to set channel 6 5:Input/output error > > Please load the driver with debugging enabled (debug=0x43fff) and send > us the log capturing during this kismet startup. the log is attached. -- Lukáš Hejtmánek [22269.555289] iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.2.23kds [22269.555299] iwl4965: Copyright(c) 2003-2007 Intel Corporation [22269.555430] ACPI: PCI Interrupt :03:00.0[A] -> GSI 17 (level, low) -> IRQ 17 [22269.555454] PCI: Setting latency timer of device :03:00.0 to 64 [22269.555492] iwl4965: U iwl4965_pci_probe pci_resource_len = 0x2000 [22269.555499] iwl4965: U iwl4965_pci_probe pci_resource_base = c207c000 [22269.05] iwl4965: U iwl4965_set_rxon_chain rx chain 280E [22269.09] iwl4965: Detected Intel Wireless WiFi Link 4965AGN [22269.27] iwl4965: U iwl4965_set_rxon_channel Staging channel set to 6 [2] [22269.596955] iwl4965: U iwl4965_pci_probe MAC address: 00:13:e8:d3:41:e7 [22269.596972] iwl4965: U iwl4965_init_channel_map Initializing regulatory info from EEPROM [22269.596977] iwl4965: U iwl4965_init_channel_map Parsing data for 56 channels. [22269.597007] iwl4965: U iwl4965_init_channel_map Ch. 1 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597015] iwl4965: U iwl4965_init_channel_map Ch. 2 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597023] iwl4965: U iwl4965_init_channel_map Ch. 3 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597030] iwl4965: U iwl4965_init_channel_map Ch. 4 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597038] iwl4965: U iwl4965_init_channel_map Ch. 5 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597046] iwl4965: U iwl4965_init_channel_map Ch. 6 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597053] iwl4965: U iwl4965_init_channel_map Ch. 7 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597061] iwl4965: U iwl4965_init_channel_map Ch. 8 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597069] iwl4965: U iwl4965_init_channel_map Ch. 9 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597076] iwl4965: U iwl4965_init_channel_map Ch. 10 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597084] iwl4965: U iwl4965_init_channel_map Ch. 11 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597090] iwl4965: U iwl4965_init_channel_map Ch. 12 Flags 0 [2.4GHz] - No traffic [22269.597096] iwl4965: U iwl4965_init_channel_map Ch. 13 Flags 0 [2.4GHz] - No traffic [22269.597102] iwl4965: U iwl4965_init_channel_map Ch. 14 Flags 0 [2.4GHz] - No traffic [22269.597108] iwl4965: U iwl4965_init_channel_map Ch. 183 Flags 0 [5.2GHz] - No traffic [22269.597113] iwl4965: U iwl4965_init_channel_map Ch. 184 Flags 0 [5.2GHz] - No traffic [22269.597119] iwl4965: U iwl4965_init_channel_map Ch. 185 Flags 0 [5.2GHz] - No traffic [22269.597125] iwl4965: U iwl4965_init_channel_map Ch. 187 Flags 0 [5.2GHz] - No traffic [22269.597130] iwl4965: U iwl4965_init_channel_map Ch. 188 Flags 0 [5.2GHz] - No traffic [22269.597136] iwl4965: U iwl4965_init_channel_map Ch. 189 Flags 0 [5.2GHz] - No traffic [22269.597142] iwl4965: U iwl4965_init_channel_map Ch. 192 Flags 0 [5.2GHz] - No traffic [22269.597147] iwl4965: U iwl4965_init_channel_map Ch. 196 Flags 0 [5.2GHz] - No traffic [22269.597153] iwl4965: U iwl4965_init_channel_map Ch. 7 Flags 0 [5.2GHz] - No traffic [22269.597158] iwl4965: U iwl4965_init_channel_map Ch. 8 Flags 0 [5.2GHz] - No traffic [22269.597164] iwl4965: U iwl4965_init_channel_map Ch. 11 Flags 0 [5.2GHz] - No traffic [22269.597170] iwl4965: U iwl4965_init_channel_map Ch. 12 Flags 0 [5.2GHz] - No traffic [22269.597176] iwl4965: U iwl4965_init_channel_map Ch. 16 Flags 0 [5.2GHz] - No traffic [22269.597181] iwl4965: U iwl4965_init_channel_map Ch. 34 Flags 0 [5.2GHz] - No traffic [22269.597188] iwl4965: U iwl4965_init_channel_map Ch. 36 [5.2GHz] WIDE (0x21 15dBm): Ad-Hoc not supported [22269.597194] iwl4965: U iwl4965_init_channel_map Ch. 38 Flags 0 [5.2GHz] - No traffic [22269.597201] iwl4965: U iwl4965_init_channel_map Ch. 40 [5.2GHz] WIDE (0x21 15dBm): Ad-Hoc not supported [22269.597207] iwl4965: U iwl4965_init_channel_map Ch. 42 Flags 0 [5.2GHz] - No traffic [22269.597214] iwl4965: U iwl4965_init_channel_map Ch. 44 [5.2GHz] WIDE (0x21 15dBm):
Recent driver in linux kernel 2.6.25-rc2
Hello, as of pre 2.6.25 kernels, kismet monitoring tool does not work with the message: # kismet Launching kismet_server: //usr/bin/kismet_server Suid priv-dropping disabled. This may not be secure. No specific sources given to be enabled, all will be enabled. Non-RFMon VAPs will be destroyed on multi-vap interfaces (ie, madwifi-ng) Enabling channel hopping. Enabling channel splitting. Source 0 (iwl4965): Enabling monitor mode for iwl4965 source interface wlan0 channel 6... FATAL: Failed to set channel 6 5:Input/output error Done. the same tool works in 2.6.24 kernel. I have 03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61), 8086:4230 I have ThinkPad T61 laptop. Btw, will there be support for LED with iwl4965 driver? The driver version is 1.2.23ks. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Recent driver in linux kernel 2.6.25-rc2
Hello, as of pre 2.6.25 kernels, kismet monitoring tool does not work with the message: # kismet Launching kismet_server: //usr/bin/kismet_server Suid priv-dropping disabled. This may not be secure. No specific sources given to be enabled, all will be enabled. Non-RFMon VAPs will be destroyed on multi-vap interfaces (ie, madwifi-ng) Enabling channel hopping. Enabling channel splitting. Source 0 (iwl4965): Enabling monitor mode for iwl4965 source interface wlan0 channel 6... FATAL: Failed to set channel 6 5:Input/output error Done. the same tool works in 2.6.24 kernel. I have 03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61), 8086:4230 I have ThinkPad T61 laptop. Btw, will there be support for LED with iwl4965 driver? The driver version is 1.2.23ks. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Recent driver in linux kernel 2.6.25-rc2
On Tue, Feb 19, 2008 at 02:28:58PM -0800, Chatre, Reinette wrote: as of pre 2.6.25 kernels, kismet monitoring tool does not work with the message: # kismet Launching kismet_server: //usr/bin/kismet_server Suid priv-dropping disabled. This may not be secure. No specific sources given to be enabled, all will be enabled. Non-RFMon VAPs will be destroyed on multi-vap interfaces (ie, madwifi-ng) Enabling channel hopping. Enabling channel splitting. Source 0 (iwl4965): Enabling monitor mode for iwl4965 source interface wlan0 channel 6... FATAL: Failed to set channel 6 5:Input/output error Please load the driver with debugging enabled (debug=0x43fff) and send us the log capturing during this kismet startup. the log is attached. -- Lukáš Hejtmánek [22269.555289] iwl4965: Intel(R) Wireless WiFi Link 4965AGN driver for Linux, 1.2.23kds [22269.555299] iwl4965: Copyright(c) 2003-2007 Intel Corporation [22269.555430] ACPI: PCI Interrupt :03:00.0[A] - GSI 17 (level, low) - IRQ 17 [22269.555454] PCI: Setting latency timer of device :03:00.0 to 64 [22269.555492] iwl4965: U iwl4965_pci_probe pci_resource_len = 0x2000 [22269.555499] iwl4965: U iwl4965_pci_probe pci_resource_base = c207c000 [22269.05] iwl4965: U iwl4965_set_rxon_chain rx chain 280E [22269.09] iwl4965: Detected Intel Wireless WiFi Link 4965AGN [22269.27] iwl4965: U iwl4965_set_rxon_channel Staging channel set to 6 [2] [22269.596955] iwl4965: U iwl4965_pci_probe MAC address: 00:13:e8:d3:41:e7 [22269.596972] iwl4965: U iwl4965_init_channel_map Initializing regulatory info from EEPROM [22269.596977] iwl4965: U iwl4965_init_channel_map Parsing data for 56 channels. [22269.597007] iwl4965: U iwl4965_init_channel_map Ch. 1 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597015] iwl4965: U iwl4965_init_channel_map Ch. 2 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597023] iwl4965: U iwl4965_init_channel_map Ch. 3 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597030] iwl4965: U iwl4965_init_channel_map Ch. 4 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597038] iwl4965: U iwl4965_init_channel_map Ch. 5 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597046] iwl4965: U iwl4965_init_channel_map Ch. 6 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597053] iwl4965: U iwl4965_init_channel_map Ch. 7 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597061] iwl4965: U iwl4965_init_channel_map Ch. 8 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597069] iwl4965: U iwl4965_init_channel_map Ch. 9 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597076] iwl4965: U iwl4965_init_channel_map Ch. 10 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597084] iwl4965: U iwl4965_init_channel_map Ch. 11 [2.4GHz] IBSS ACTIVE WIDE (0x2b 14dBm): Ad-Hoc supported [22269.597090] iwl4965: U iwl4965_init_channel_map Ch. 12 Flags 0 [2.4GHz] - No traffic [22269.597096] iwl4965: U iwl4965_init_channel_map Ch. 13 Flags 0 [2.4GHz] - No traffic [22269.597102] iwl4965: U iwl4965_init_channel_map Ch. 14 Flags 0 [2.4GHz] - No traffic [22269.597108] iwl4965: U iwl4965_init_channel_map Ch. 183 Flags 0 [5.2GHz] - No traffic [22269.597113] iwl4965: U iwl4965_init_channel_map Ch. 184 Flags 0 [5.2GHz] - No traffic [22269.597119] iwl4965: U iwl4965_init_channel_map Ch. 185 Flags 0 [5.2GHz] - No traffic [22269.597125] iwl4965: U iwl4965_init_channel_map Ch. 187 Flags 0 [5.2GHz] - No traffic [22269.597130] iwl4965: U iwl4965_init_channel_map Ch. 188 Flags 0 [5.2GHz] - No traffic [22269.597136] iwl4965: U iwl4965_init_channel_map Ch. 189 Flags 0 [5.2GHz] - No traffic [22269.597142] iwl4965: U iwl4965_init_channel_map Ch. 192 Flags 0 [5.2GHz] - No traffic [22269.597147] iwl4965: U iwl4965_init_channel_map Ch. 196 Flags 0 [5.2GHz] - No traffic [22269.597153] iwl4965: U iwl4965_init_channel_map Ch. 7 Flags 0 [5.2GHz] - No traffic [22269.597158] iwl4965: U iwl4965_init_channel_map Ch. 8 Flags 0 [5.2GHz] - No traffic [22269.597164] iwl4965: U iwl4965_init_channel_map Ch. 11 Flags 0 [5.2GHz] - No traffic [22269.597170] iwl4965: U iwl4965_init_channel_map Ch. 12 Flags 0 [5.2GHz] - No traffic [22269.597176] iwl4965: U iwl4965_init_channel_map Ch. 16 Flags 0 [5.2GHz] - No traffic [22269.597181] iwl4965: U iwl4965_init_channel_map Ch. 34 Flags 0 [5.2GHz] - No traffic [22269.597188] iwl4965: U iwl4965_init_channel_map Ch. 36 [5.2GHz] WIDE (0x21 15dBm): Ad-Hoc not supported [22269.597194] iwl4965: U iwl4965_init_channel_map Ch. 38 Flags 0 [5.2GHz] - No traffic [22269.597201] iwl4965: U iwl4965_init_channel_map Ch. 40 [5.2GHz] WIDE (0x21 15dBm): Ad-Hoc not supported [22269.597207] iwl4965: U iwl4965_init_channel_map Ch. 42 Flags 0 [5.2GHz] - No traffic [22269.597214] iwl4965: U iwl4965_init_channel_map Ch. 44 [5.2GHz] WIDE (0x21 15dBm): Ad-Hoc not supported
Re: 2.6.24-git4+ regression
On Thu, Feb 14, 2008 at 10:25:51PM +0530, Srivatsa Vaddagiri wrote: > The patch is against 2.6.25-rc1. I would request you to check for > difference it makes with CONFIG_FAIR_GROUP_SCHED and > CONFIG_FAIR_USER_SCHED turned on. well, I tried the patch against 2.6.25-rc2-git1. It seems to be better but without CONFIG_FAIR_GROUP_SCHED it is still even better. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Thu, Feb 14, 2008 at 10:25:51PM +0530, Srivatsa Vaddagiri wrote: The patch is against 2.6.25-rc1. I would request you to check for difference it makes with CONFIG_FAIR_GROUP_SCHED and CONFIG_FAIR_USER_SCHED turned on. well, I tried the patch against 2.6.25-rc2-git1. It seems to be better but without CONFIG_FAIR_GROUP_SCHED it is still even better. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Fri, Feb 15, 2008 at 05:24:52PM +, Paulo Marques wrote: > If you want to take advantage of all that memory to buffer disk writes, > so that the reads can proceed better, you might want to tweak your > /proc/sys/vm/dirty_ratio amd /proc/sys/vm/dirty_background_ratio to more > appropriate values. (maybe also dirty_writeback_centisecs and > dirty_expire_centisecs) I don't feel like to have my whole memory eaten by a single file which is not to be read again and thus it is pretty useless. Instead, I would like to see slowdown of scp so that other processes can also access disk. Why is this possible with kernel process scheduler and not with IO scheduler? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Fri, Feb 15, 2008 at 10:11:26AM -0700, Zan Lynx wrote: > Yes, I see this often myself. It's like the disk IO queue (I set mine > to 1024) fills up, and pdflush and friends can stuff write requests into > it much more quickly than any other programs can provide read requests. > > CFQ and ionice work very well up until iostat shows average IO queuing > above 1024 (where I set the queue number). I though that CFQ would maintain IO queues per process and pick up request in round robin from non-empty queues. Am I wrong? And if wrong, isn't it desired behavior for desktop? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Fri, Feb 15, 2008 at 05:24:52PM +, Paulo Marques wrote: If you want to take advantage of all that memory to buffer disk writes, so that the reads can proceed better, you might want to tweak your /proc/sys/vm/dirty_ratio amd /proc/sys/vm/dirty_background_ratio to more appropriate values. (maybe also dirty_writeback_centisecs and dirty_expire_centisecs) I don't feel like to have my whole memory eaten by a single file which is not to be read again and thus it is pretty useless. Instead, I would like to see slowdown of scp so that other processes can also access disk. Why is this possible with kernel process scheduler and not with IO scheduler? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Fri, Feb 15, 2008 at 10:11:26AM -0700, Zan Lynx wrote: Yes, I see this often myself. It's like the disk IO queue (I set mine to 1024) fills up, and pdflush and friends can stuff write requests into it much more quickly than any other programs can provide read requests. CFQ and ionice work very well up until iostat shows average IO queuing above 1024 (where I set the queue number). I though that CFQ would maintain IO queues per process and pick up request in round robin from non-empty queues. Am I wrong? And if wrong, isn't it desired behavior for desktop? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Fri, Feb 15, 2008 at 03:42:58PM +0100, Jan Engelhardt wrote: > Also consider > - DMA (e.g. only UDMA2 selected) > - aging disk it's not the case. hdparm reports udma5 is used, if it is reliable with libata. The disk is 3 months old, kernel does not report any errors. And it has never been different. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 regression - IBM ACPI backlight
On Fri, Feb 15, 2008 at 12:07:20PM +, Matthew Garrett wrote: > On Fri, Feb 15, 2008 at 12:02:13PM +0100, Lukas Hejtmanek wrote: > > 2.6.24 kernel has two acpi_video[01]. 2.6.25-rc1 does not, it contains only > > acpi_video0 (even in text mode in single user without X being loaded) which > > does not work at all. > > Sigh. Ok. Could you attach the output of acpidump and lspci, please? > I'll try to figure out why this is wrong. I created a bug report here including acpidump and lspci: http://bugzilla.kernel.org/show_bug.cgi?id=9995 -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 regression - IBM ACPI backlight
On Thu, Feb 14, 2008 at 10:24:52AM -0200, Henrique de Moraes Holschuh wrote: > > as of 2.6.25-rc1, there is no more /sys/class/backlight/acpi_video1 which > > controlled LVDS backlight on Lenovo ThinkPad T61. There is still > > acpi_video0 which seems to have sane values but echo N > brightness has no > > effect at all. > > > > thinkpad_acpi module reports that ACPI controlled backlight is present. > > Please report this to linux-acpi @ vger . kernel . org... > > It is likely caused by the stuff to locate and disable the unused video > device in the DSDT (apparently it got the wrong device?!). > > However, BEFORE reporting to linux-acpi, please test it in single user mode > without X *ever* being loaded on that boot. New X disables the BIOS > brightness changes that ACPI uses. 2.6.24 kernel has two acpi_video[01]. 2.6.25-rc1 does not, it contains only acpi_video0 (even in text mode in single user without X being loaded) which does not work at all. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Fri, Feb 15, 2008 at 09:02:31AM +0900, Tejun Heo wrote: > > till the scp finishes. It is not caused by low free memory, while scping > > I have 500MB of free memory (not cached or buffered). > > > > I tried cfq and anticipatory scheduler, none is different. > > > > Does deadline help? well, deadline is a little bit better. I'm trying to read from disk opening maildir with 2 mails with mutt. If I open that maildir, mutt shows progress. With cfq or anticipatory scheduler, progress is 0/2 until scp finishes. With deadline, progress is 150/2 after scp finished. So I would say, it is better but I doubt it is OK. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Fri, Feb 15, 2008 at 09:02:31AM +0900, Tejun Heo wrote: till the scp finishes. It is not caused by low free memory, while scping I have 500MB of free memory (not cached or buffered). I tried cfq and anticipatory scheduler, none is different. Does deadline help? well, deadline is a little bit better. I'm trying to read from disk opening maildir with 2 mails with mutt. If I open that maildir, mutt shows progress. With cfq or anticipatory scheduler, progress is 0/2 until scp finishes. With deadline, progress is 150/2 after scp finished. So I would say, it is better but I doubt it is OK. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 regression - IBM ACPI backlight
On Thu, Feb 14, 2008 at 10:24:52AM -0200, Henrique de Moraes Holschuh wrote: as of 2.6.25-rc1, there is no more /sys/class/backlight/acpi_video1 which controlled LVDS backlight on Lenovo ThinkPad T61. There is still acpi_video0 which seems to have sane values but echo N brightness has no effect at all. thinkpad_acpi module reports that ACPI controlled backlight is present. Please report this to linux-acpi @ vger . kernel . org... It is likely caused by the stuff to locate and disable the unused video device in the DSDT (apparently it got the wrong device?!). However, BEFORE reporting to linux-acpi, please test it in single user mode without X *ever* being loaded on that boot. New X disables the BIOS brightness changes that ACPI uses. 2.6.24 kernel has two acpi_video[01]. 2.6.25-rc1 does not, it contains only acpi_video0 (even in text mode in single user without X being loaded) which does not work at all. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 regression - IBM ACPI backlight
On Fri, Feb 15, 2008 at 12:07:20PM +, Matthew Garrett wrote: On Fri, Feb 15, 2008 at 12:02:13PM +0100, Lukas Hejtmanek wrote: 2.6.24 kernel has two acpi_video[01]. 2.6.25-rc1 does not, it contains only acpi_video0 (even in text mode in single user without X being loaded) which does not work at all. Sigh. Ok. Could you attach the output of acpidump and lspci, please? I'll try to figure out why this is wrong. I created a bug report here including acpidump and lspci: http://bugzilla.kernel.org/show_bug.cgi?id=9995 -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk schedulers
On Fri, Feb 15, 2008 at 03:42:58PM +0100, Jan Engelhardt wrote: Also consider - DMA (e.g. only UDMA2 selected) - aging disk it's not the case. hdparm reports udma5 is used, if it is reliable with libata. The disk is 3 months old, kernel does not report any errors. And it has never been different. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Disk schedulers
Hello, whom should I blame about disk schedulers? I have the following setup: 1Gb network 2GB RAM disk write speed about 20MB/s If I'm scping file (about 500MB) from the network (which is faster than the local disk), any process is totally unable to read anything from the local disk till the scp finishes. It is not caused by low free memory, while scping I have 500MB of free memory (not cached or buffered). I tried cfq and anticipatory scheduler, none is different. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1 regression - IBM ACPI backlight
Hello, as of 2.6.25-rc1, there is no more /sys/class/backlight/acpi_video1 which controlled LVDS backlight on Lenovo ThinkPad T61. There is still acpi_video0 which seems to have sane values but echo N > brightness has no effect at all. thinkpad_acpi module reports that ACPI controlled backlight is present. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1 regression - IBM ACPI backlight
Hello, as of 2.6.25-rc1, there is no more /sys/class/backlight/acpi_video1 which controlled LVDS backlight on Lenovo ThinkPad T61. There is still acpi_video0 which seems to have sane values but echo N brightness has no effect at all. thinkpad_acpi module reports that ACPI controlled backlight is present. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Disk schedulers
Hello, whom should I blame about disk schedulers? I have the following setup: 1Gb network 2GB RAM disk write speed about 20MB/s If I'm scping file (about 500MB) from the network (which is faster than the local disk), any process is totally unable to read anything from the local disk till the scp finishes. It is not caused by low free memory, while scping I have 500MB of free memory (not cached or buffered). I tried cfq and anticipatory scheduler, none is different. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 regression - ondemand governor does not work at all
On Wed, Feb 13, 2008 at 12:36:40PM -0200, Carlos R. Mafra wrote: > Lukas Hejtmanek wrote: > > Hello, > > > > as of 2.6.25-rc1, ondemand governor from cpufreq (acpi-p states driver) does > > not change frequency. Machine is still running at max frequency regardless > > of system load. > > Try the patch here: > http://lkml.org/lkml/2008/2/12/351 it seems to be fixed by this patch. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1 regression - ondemand governor does not work at all
Hello, as of 2.6.25-rc1, ondemand governor from cpufreq (acpi-p states driver) does not change frequency. Machine is still running at max frequency regardless of system load. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1 regression - ondemand governor does not work at all
Hello, as of 2.6.25-rc1, ondemand governor from cpufreq (acpi-p states driver) does not change frequency. Machine is still running at max frequency regardless of system load. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 regression - ondemand governor does not work at all
On Wed, Feb 13, 2008 at 12:36:40PM -0200, Carlos R. Mafra wrote: Lukas Hejtmanek wrote: Hello, as of 2.6.25-rc1, ondemand governor from cpufreq (acpi-p states driver) does not change frequency. Machine is still running at max frequency regardless of system load. Try the patch here: http://lkml.org/lkml/2008/2/12/351 it seems to be fixed by this patch. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 regression - suspend to ram
On Mon, Feb 11, 2008 at 03:22:13PM -0800, Venki Pallipadi wrote: > Just sent this patch to fix a regression in acpi processor_idle.c on another > thread. Can you try the patch below and check whether that helps. Yeah, it seems that it fixed suspend troubles. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.25-rc1 regression - suspend to ram
On Mon, Feb 11, 2008 at 03:22:13PM -0800, Venki Pallipadi wrote: Just sent this patch to fix a regression in acpi processor_idle.c on another thread. Can you try the patch below and check whether that helps. Yeah, it seems that it fixed suspend troubles. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1 regression - suspend to ram
Hello, 2.6.25-rc1 takes really long time till it suspends (about 30-40secs, used to be about 5 secs at all) and it is resuming about few minutes. While resuming, capslock toggles the capslock led but with few secs delay. 2.6.24-git15 was OK. 2.6.24 is OK. I have Lenovo ThinkPad T61. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.25-rc1 regression - suspend to ram
Hello, 2.6.25-rc1 takes really long time till it suspends (about 30-40secs, used to be about 5 secs at all) and it is resuming about few minutes. While resuming, capslock toggles the capslock led but with few secs delay. 2.6.24-git15 was OK. 2.6.24 is OK. I have Lenovo ThinkPad T61. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24 oops
Hello, I encountered an oops while playing a movie with mplayer. (couple of hours before, I tried this exploit: http://www.securityfocus.com/data/vulnerabilities/exploits/27704.c so the oops may be induced by the exploit.) [12695.120141] Unable to handle kernel paging request at 1000 RIP: [12695.120152] [] find_get_page+0x3b/0x80 [12695.120166] PGD 0 [12695.120172] Oops: [1] PREEMPT SMP [12695.120180] CPU 0 [12695.120184] Modules linked in: cdc_ether usbnet mii cdc_acm usb_storage des_generic cbc nfs lockd rpcsec_gss_krb5 auth_rpcgss sunrpc i915 drm rfcomm l2cap bluetooth fuse arc4 ecb blkcipher e1000 ehci_hcd uhci_hcd snd_hda_intel thinkpad_acpi intel_agp [12695.120228] Pid: 10382, comm: mplayer Not tainted 2.6.24 #2 [12695.120232] RIP: 0010:[] [] find_get_page+0x3b/0x80 [12695.120242] RSP: 0018:8100794d7ca8 EFLAGS: 00210006 [12695.120247] RAX: 1000 RBX: 1000 RCX: [12695.120252] RDX: 81000efe RSI: 0001b3c0 RDI: [12695.120257] RBP: 81007ceffeb8 R08: R09: 80270330 [12695.120262] R10: R11: 0001 R12: 0001b3c0 [12695.120267] R13: 0001 R14: 81000cf8a728 R15: 81000cf8a6c0 [12695.120273] FS: 2af6ae621610() GS:8062b000() knlGS: [12695.120278] CS: 0010 DS: ES: CR0: 8005003b [12695.120283] CR2: 1000 CR3: 512b7000 CR4: 06e0 [12695.120288] DR0: DR1: DR2: [12695.120292] DR3: DR6: 0ff0 DR7: 0400 [12695.120298] Process mplayer (pid: 10382, threadinfo 8100794d6000, task 81007c23) [12695.120303] Stack: 8100794d7ed8 81007ceffea0 0001b3c0 80270efb [12695.120313] 00037000 80270330 8100794d7d68 8100794d7e58 [12695.120322] 81000cf8a728 81007ceffd78 0001b3c1 0001b3bf [12695.120329] Call Trace: [12695.120338] [] do_generic_mapping_read+0x10b/0x400 [12695.120345] [] file_read_actor+0x0/0x1a0 [12695.120355] [] generic_file_aio_read+0xff/0x1b0 [12695.120366] [] do_sync_read+0xd9/0x120 [12695.120373] [] enqueue_hrtimer+0x6e/0x110 [12695.120383] [] autoremove_wake_function+0x0/0x30 [12695.120391] [] do_nanosleep+0x69/0x90 [12695.120397] [] hrtimer_nanosleep+0x78/0x140 [12695.120404] [] hrtimer_wakeup+0x0/0x30 [12695.120411] [] do_nanosleep+0x55/0x90 [12695.120417] [] vfs_read+0xc5/0x160 [12695.120422] [] sys_read+0x3b/0x90 [12695.120429] [] sys_read+0x53/0x90 [12695.120437] [] system_call+0x7e/0x83 [12695.120444] [12695.120446] [12695.120447] Code: 48 8b 00 48 89 da 25 00 40 02 00 48 3d 00 40 02 00 74 22 f0 [12695.120472] RIP [] find_get_page+0x3b/0x80 [12695.120480] RSP [12695.120484] CR2: 1000 [12695.120490] ---[ end trace a272000ffa9585c7 ]--- [12695.120496] note: mplayer[10382] exited with preempt_count 1 -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24 oops
Hello, I encountered an oops while playing a movie with mplayer. (couple of hours before, I tried this exploit: http://www.securityfocus.com/data/vulnerabilities/exploits/27704.c so the oops may be induced by the exploit.) [12695.120141] Unable to handle kernel paging request at 1000 RIP: [12695.120152] [802705bb] find_get_page+0x3b/0x80 [12695.120166] PGD 0 [12695.120172] Oops: [1] PREEMPT SMP [12695.120180] CPU 0 [12695.120184] Modules linked in: cdc_ether usbnet mii cdc_acm usb_storage des_generic cbc nfs lockd rpcsec_gss_krb5 auth_rpcgss sunrpc i915 drm rfcomm l2cap bluetooth fuse arc4 ecb blkcipher e1000 ehci_hcd uhci_hcd snd_hda_intel thinkpad_acpi intel_agp [12695.120228] Pid: 10382, comm: mplayer Not tainted 2.6.24 #2 [12695.120232] RIP: 0010:[802705bb] [802705bb] find_get_page+0x3b/0x80 [12695.120242] RSP: 0018:8100794d7ca8 EFLAGS: 00210006 [12695.120247] RAX: 1000 RBX: 1000 RCX: [12695.120252] RDX: 81000efe RSI: 0001b3c0 RDI: [12695.120257] RBP: 81007ceffeb8 R08: R09: 80270330 [12695.120262] R10: R11: 0001 R12: 0001b3c0 [12695.120267] R13: 0001 R14: 81000cf8a728 R15: 81000cf8a6c0 [12695.120273] FS: 2af6ae621610() GS:8062b000() knlGS: [12695.120278] CS: 0010 DS: ES: CR0: 8005003b [12695.120283] CR2: 1000 CR3: 512b7000 CR4: 06e0 [12695.120288] DR0: DR1: DR2: [12695.120292] DR3: DR6: 0ff0 DR7: 0400 [12695.120298] Process mplayer (pid: 10382, threadinfo 8100794d6000, task 81007c23) [12695.120303] Stack: 8100794d7ed8 81007ceffea0 0001b3c0 80270efb [12695.120313] 00037000 80270330 8100794d7d68 8100794d7e58 [12695.120322] 81000cf8a728 81007ceffd78 0001b3c1 0001b3bf [12695.120329] Call Trace: [12695.120338] [80270efb] do_generic_mapping_read+0x10b/0x400 [12695.120345] [80270330] file_read_actor+0x0/0x1a0 [12695.120355] [80272a8f] generic_file_aio_read+0xff/0x1b0 [12695.120366] [80298a99] do_sync_read+0xd9/0x120 [12695.120373] [802528ae] enqueue_hrtimer+0x6e/0x110 [12695.120383] [8024fed0] autoremove_wake_function+0x0/0x30 [12695.120391] [804c46f9] do_nanosleep+0x69/0x90 [12695.120397] [802533c8] hrtimer_nanosleep+0x78/0x140 [12695.120404] [80252bb0] hrtimer_wakeup+0x0/0x30 [12695.120411] [804c46e5] do_nanosleep+0x55/0x90 [12695.120417] [802993b5] vfs_read+0xc5/0x160 [12695.120422] [8029984b] sys_read+0x3b/0x90 [12695.120429] [80299863] sys_read+0x53/0x90 [12695.120437] [8020c47e] system_call+0x7e/0x83 [12695.120444] [12695.120446] [12695.120447] Code: 48 8b 00 48 89 da 25 00 40 02 00 48 3d 00 40 02 00 74 22 f0 [12695.120472] RIP [802705bb] find_get_page+0x3b/0x80 [12695.120480] RSP 8100794d7ca8 [12695.120484] CR2: 1000 [12695.120490] ---[ end trace a272000ffa9585c7 ]--- [12695.120496] note: mplayer[10382] exited with preempt_count 1 -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: T61P sound issue
Hello, I have T61 and have no problem with sound. No sound problem could arise from hw mute that is controlled via volume buttons. Volume mute does just mute (*no unmute*!), buttons volume up/down unmutes volume. There is bar "Speaker" in alsa mixer, must not be muted. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Mon, Feb 04, 2008 at 03:45:10PM +0100, Peter Zijlstra wrote: > > see my previous mail to Ingo (you were Cc.), latency top says that Xorg and > > gnome-terminal suffers 300+ms latency in scheduler: waiting for cpu. > > what happens when you turn CONFIG_FAIR_GROUP_SCHED off? If I disable CONFIG_FAIR_GROUP_SCHED, it is a lot better. I would not call it optimal, though. Xorg has 20ms latency, gnome-terminal another 20ms latency. If I just press a key (a letter for instance) to see how autorepeat fills terminal, one can see that autorepeat is not smooth and it is stopping for a little while (really extra short stops are visible but still visible). But it is really a ton better that it was with fair group sched. So, any conclusion? The case is closed or any further investigation should be done? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Mon, Feb 04, 2008 at 12:36:36PM +0100, Peter Zijlstra wrote: > I can't reproduce this with a pure cpu load. I started 10 > while :; do :; done & > instances and aside from slowing down, nothing bad happened. yes, while true; do true; does nothing wrong. But running make -j2 in kernel sources or mesa sources is catastrophic. > May I suggest you try latency top to see if there is something in your > build scenario that generates horrible latencies (some IO path or > whatnot). see my previous mail to Ingo (you were Cc.), latency top says that Xorg and gnome-terminal suffers 300+ms latency in scheduler: waiting for cpu. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Mon, Feb 04, 2008 at 01:01:32PM +0100, Ingo Molnar wrote: > > * Lukas Hejtmanek <[EMAIL PROTECTED]> wrote: > > > but in such a case, kernel 2.6.24-git13 does oops at startup in > > sched_slice. > > could you tell me more about this oops? You booted unmodified, latest > -git and it oopsed in sched_slice()? The patch below should work around > any oopses in sched_slice(). [but this is really a 'must not happen' > scenario - so a just-for-testing patch] No, I booted modified lates git to see if mentioned patch (revertin slices) solves horrible non-interactivy problem. With your fix, I can boot now but the patch did not help. Make -j2 in kernel sources significantly decreases interactivity. Any ideas? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
Ingo,
any progress here? I've tried to revert this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=67e9fb2a39a1d454218d50383094940982be138f
as it was marked as suspicious patch in this case
(http://www.uwsg.indiana.edu/hypermail/linux/kernel/0801.3/1665.html)
but in such a case, kernel 2.6.24-git13 does oops at startup in sched_slice.
I think this is really *big* regression in 2.6.24 kernel.
On Thu, Jan 31, 2008 at 11:29:19AM +0100, Ingo Molnar wrote:
>
> * Lukas Hejtmanek <[EMAIL PROTECTED]> wrote:
>
> > I noticed short thread in LKM regarding "sched: add vslice" causes
> > horrible interactivity under load.
> >
> > I can see similar behavior. If I stress both CPU cores, even typing on
> > keyboard suffers from huge latencies, I can see letters appearing with
> > delay (typing into xterm). No swap is used at all, having 1GB free
> > RAM.
> >
> > I noticed this bad behavior with 2.6.24-git[46], 2.6.24-rc8-git was
> > OK.
>
> if you apply the current sched-fixes (rollup patch below), does it get
> any better?
>
> Ingo
>
> Index: linux/kernel/sched_fair.c
> ===
> --- linux.orig/kernel/sched_fair.c
> +++ linux/kernel/sched_fair.c
> @@ -520,7 +520,7 @@ place_entity(struct cfs_rq *cfs_rq, stru
>
> if (!initial) {
> /* sleeps upto a single latency don't count. */
> - if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se))
> + if (sched_feat(NEW_FAIR_SLEEPERS))
> vruntime -= sysctl_sched_latency;
>
> /* ensure we never gain time by being placed backwards. */
> @@ -1106,7 +1106,11 @@ static void check_preempt_wakeup(struct
> }
>
> gran = sysctl_sched_wakeup_granularity;
> - if (unlikely(se->load.weight != NICE_0_LOAD))
> + /*
> + * More easily preempt - nice tasks, while not making
> + * it harder for + nice tasks.
> + */
> + if (unlikely(se->load.weight > NICE_0_LOAD))
> gran = calc_delta_fair(gran, >load);
>
> if (pse->vruntime + gran < se->vruntime)
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
Ingo,
any progress here? I've tried to revert this patch:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=67e9fb2a39a1d454218d50383094940982be138f
as it was marked as suspicious patch in this case
(http://www.uwsg.indiana.edu/hypermail/linux/kernel/0801.3/1665.html)
but in such a case, kernel 2.6.24-git13 does oops at startup in sched_slice.
I think this is really *big* regression in 2.6.24 kernel.
On Thu, Jan 31, 2008 at 11:29:19AM +0100, Ingo Molnar wrote:
* Lukas Hejtmanek [EMAIL PROTECTED] wrote:
I noticed short thread in LKM regarding sched: add vslice causes
horrible interactivity under load.
I can see similar behavior. If I stress both CPU cores, even typing on
keyboard suffers from huge latencies, I can see letters appearing with
delay (typing into xterm). No swap is used at all, having 1GB free
RAM.
I noticed this bad behavior with 2.6.24-git[46], 2.6.24-rc8-git was
OK.
if you apply the current sched-fixes (rollup patch below), does it get
any better?
Ingo
Index: linux/kernel/sched_fair.c
===
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -520,7 +520,7 @@ place_entity(struct cfs_rq *cfs_rq, stru
if (!initial) {
/* sleeps upto a single latency don't count. */
- if (sched_feat(NEW_FAIR_SLEEPERS) entity_is_task(se))
+ if (sched_feat(NEW_FAIR_SLEEPERS))
vruntime -= sysctl_sched_latency;
/* ensure we never gain time by being placed backwards. */
@@ -1106,7 +1106,11 @@ static void check_preempt_wakeup(struct
}
gran = sysctl_sched_wakeup_granularity;
- if (unlikely(se-load.weight != NICE_0_LOAD))
+ /*
+ * More easily preempt - nice tasks, while not making
+ * it harder for + nice tasks.
+ */
+ if (unlikely(se-load.weight NICE_0_LOAD))
gran = calc_delta_fair(gran, se-load);
if (pse-vruntime + gran se-vruntime)
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Mon, Feb 04, 2008 at 12:36:36PM +0100, Peter Zijlstra wrote: I can't reproduce this with a pure cpu load. I started 10 while :; do :; done instances and aside from slowing down, nothing bad happened. yes, while true; do true; does nothing wrong. But running make -j2 in kernel sources or mesa sources is catastrophic. May I suggest you try latency top to see if there is something in your build scenario that generates horrible latencies (some IO path or whatnot). see my previous mail to Ingo (you were Cc.), latency top says that Xorg and gnome-terminal suffers 300+ms latency in scheduler: waiting for cpu. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Mon, Feb 04, 2008 at 03:45:10PM +0100, Peter Zijlstra wrote: see my previous mail to Ingo (you were Cc.), latency top says that Xorg and gnome-terminal suffers 300+ms latency in scheduler: waiting for cpu. what happens when you turn CONFIG_FAIR_GROUP_SCHED off? If I disable CONFIG_FAIR_GROUP_SCHED, it is a lot better. I would not call it optimal, though. Xorg has 20ms latency, gnome-terminal another 20ms latency. If I just press a key (a letter for instance) to see how autorepeat fills terminal, one can see that autorepeat is not smooth and it is stopping for a little while (really extra short stops are visible but still visible). But it is really a ton better that it was with fair group sched. So, any conclusion? The case is closed or any further investigation should be done? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Mon, Feb 04, 2008 at 01:01:32PM +0100, Ingo Molnar wrote: * Lukas Hejtmanek [EMAIL PROTECTED] wrote: but in such a case, kernel 2.6.24-git13 does oops at startup in sched_slice. could you tell me more about this oops? You booted unmodified, latest -git and it oopsed in sched_slice()? The patch below should work around any oopses in sched_slice(). [but this is really a 'must not happen' scenario - so a just-for-testing patch] No, I booted modified lates git to see if mentioned patch (revertin slices) solves horrible non-interactivy problem. With your fix, I can boot now but the patch did not help. Make -j2 in kernel sources significantly decreases interactivity. Any ideas? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git9 ACPI oops - regression
On Fri, Feb 01, 2008 at 12:07:03PM -0500, Len Brown wrote: > this worked in 2.6.24? At least in 2.6.24-rc8 seemed to be OK, for the first time, I encountered the bug in 2.6.24-git4. 2.6.24-git6 seemed to be OK. 2.6.24-git9 is not. > You are running the "dock" driver in both cases? I use thinkpad acpi module, ACPI_DOCK is always built in. > Is this reproducible? In 2.6.24-git4, it was 100% reproducible - just pressing undock button on the dock and the oops has been generated. In 2.6.24-git9, I do not know, whether it is reproducible or not. And as I'm ill and my dock is in work, I'm not sure when I be ready to test it again. > If yes, please open a bugzilla entry here: > > http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI > Component = Config-hotplug > > and attach the output from acpidump do you need just acpidump as is or should I do acpidump when docked? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-git9 ACPI oops - regression
Hello, I encountered oops on my laptop Lenovo T61 and dock. If I press undock on the dock, I got the following oops: [79721.755165] BUG: unable to handle kernel paging request at 0034000e [79721.755165] IP: [] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755165] PGD 7203a067 PUD 0 [79721.755165] Oops: [1] SMP [79721.755165] CPU 1 [79721.755165] Modules linked in: usb_storage i915 drm rfcomm l2cap bluetooth fuse arc4 ecb crypto_blkcipher ehci_hcd uhci_hcd e1000e snd_hda_intel intel_agp thinkpad_acpi [last unloaded: cfg80211] [79721.755165] Pid: 69, comm: kacpi_notify Not tainted 2.6.24-git9 #4 [79721.755165] RIP: 0010:[] [] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755165] RSP: 0018:81007d197d28 EFLAGS: 00010246 [79721.755165] RAX: RBX: RCX: [79721.755165] RDX: 00017567 RSI: 0012c0d0 RDI: 00340006 [79721.755165] RBP: R08: 810003c0 R09: [79721.755165] R10: 0002 R11: 0001 R12: 00340006 [79721.755165] R13: R14: 81007d197d68 R15: 81007d197d70 [79721.755165] FS: () GS:81007d00e380() knlGS: [79721.755165] CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b [79721.755165] CR2: 0034000e CR3: 7200a000 CR4: 06a0 [79721.755165] DR0: DR1: DR2: [79721.755165] DR3: DR6: 0ff0 DR7: 0400 [79721.755165] Process kacpi_notify (pid: 69, threadinfo 81007d196000, task 81007d18ef20) [79721.755165] Stack: 8034e19f 8100519e8800 81007d197de0 0001 [79721.755165] 0001 80357d3d 81007d02cdc0 [79721.755165] 00340006 8058cbaa [79721.755165] Call Trace: [79721.755165] [] acpi_get_next_object+0x3b/0x99 [79721.755165] [] acpi_bus_trim+0x57/0x109 [79721.755165] [] hotplug_dock_devices+0x97/0x117 [79721.755166] [] handle_eject_request+0x4e/0xd3 [79721.755166] [] acpi_os_execute_notify+0x0/0x2c [79721.755166] [] acpi_bus_get_device+0x1d/0x2e [79721.755166] [] acpi_bus_notify+0x17/0x4c [79721.755166] [] acpi_os_execute_notify+0x0/0x2c [79721.755166] [] acpi_ev_notify_dispatch+0x57/0x60 [79721.755166] [] acpi_os_execute_notify+0x23/0x2c [79721.755166] [] run_workqueue+0xbf/0x160 [79721.755166] [] worker_thread+0x0/0x100 [79721.755166] [] worker_thread+0x0/0x100 [79721.755166] [] worker_thread+0x9f/0x100 [79721.755166] [] autoremove_wake_function+0x0/0x30 [79721.755166] [] worker_thread+0x0/0x100 [79721.755166] [] worker_thread+0x0/0x100 [79721.755166] [] kthread+0x4b/0x80 [79721.755166] [] child_rip+0xa/0x12 [79721.755166] [] kthread+0x0/0x80 [79721.755166] [] child_rip+0x0/0x12 [79721.755166] [79721.755166] [79721.755166] Code: 00 c3 49 ff c1 48 83 c6 04 41 ff c8 45 85 c0 75 a8 31 c0 c6 06 00 c3 48 8d 47 ff 48 83 f8 fd 76 08 48 8b 05 dc 49 39 00 c3 31 c0 <80> 7f 08 0f 48 0f 44 c7 c3 48 89 f8 c3 31 c0 48 85 ff 74 0d f6 [79721.755166] RIP [] acpi_ns_map_handle_to_node+0x14/0x1d [79721.755166] RSP [79721.755166] CR2: 0034000e [79721.755166] ---[ end trace 05a1f30122eb8809 ]--- -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Thu, Jan 31, 2008 at 11:29:19AM +0100, Ingo Molnar wrote: > if you apply the current sched-fixes (rollup patch below), does it get > any better? No. Another observation, running two instances of while true; do true; done (on 1 dual core cpu) does not break interactivity. running make clean; make -j2 in kernel tree breaks interactivity terribly. Looks like disk I/O activity is needed to break interactivity. While compiling, I have more than 1GB of RAM free. One friend of mine suggests that kernel is swapping out binaries which causes non-interactivity. The swaparea is clean, though. He also reports that the behavior can be seen even in 2.6.24-rc8. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-git4+ regression
On Thu, Jan 31, 2008 at 11:29:19AM +0100, Ingo Molnar wrote: if you apply the current sched-fixes (rollup patch below), does it get any better? No. Another observation, running two instances of while true; do true; done (on 1 dual core cpu) does not break interactivity. running make clean; make -j2 in kernel tree breaks interactivity terribly. Looks like disk I/O activity is needed to break interactivity. While compiling, I have more than 1GB of RAM free. One friend of mine suggests that kernel is swapping out binaries which causes non-interactivity. The swaparea is clean, though. He also reports that the behavior can be seen even in 2.6.24-rc8. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.24-git4+ regression
Hello, I noticed short thread in LKM regarding "sched: add vslice" causes horrible interactivity under load. I can see similar behavior. If I stress both CPU cores, even typing on keyboard suffers from huge latencies, I can see letters appearing with delay (typing into xterm). No swap is used at all, having 1GB free RAM. I noticed this bad behavior with 2.6.24-git[46], 2.6.24-rc8-git was OK. My config is attached. -- Lukáš Hejtmánek # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-git6 # Wed Jan 30 11:15:35 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_SUPPORTS_OPROFILE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_HT=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_BLK_DEV_BSG=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_VSMP is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set
2.6.24-git4+ regression
Hello, I noticed short thread in LKM regarding sched: add vslice causes horrible interactivity under load. I can see similar behavior. If I stress both CPU cores, even typing on keyboard suffers from huge latencies, I can see letters appearing with delay (typing into xterm). No swap is used at all, having 1GB free RAM. I noticed this bad behavior with 2.6.24-git[46], 2.6.24-rc8-git was OK. My config is attached. -- Lukáš Hejtmánek # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-git6 # Wed Jan 30 11:15:35 2008 # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y # CONFIG_QUICKLIST is not set CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ARCH_SUPPORTS_OPROFILE=y CONFIG_ZONE_DMA32=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_HT=y # CONFIG_KTIME_SCALAR is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CGROUPS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_BLK_DEV_BSG=y CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=cfq CONFIG_CLASSIC_RCU=y # CONFIG_PREEMPT_RCU is not set # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_VSMP is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_FAMILY=64 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set
Re: swapping in 2.6.24-rc5-git3
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote: > I think yes. 0 swappiness doesn't mean "no swapping at all". From the > code in shrink_active_list() it seems that it just decreases likeliness > of removing pages of mmaped files (i.e., also executables loaded in memory). So, I tried to add some prints. I have mapped ratio about 78 while scp-ing the file. Distress suddenly raises from 0 to 100. At this poing, all the processes are swapped out. I guess it happens if scp is faster than the local disk which happens if I scp-ing over GE from desktop (with fast disk - and reading) to laptop (slow disk - and writing). This is my settings. /proc/sys/vm/* block_dump:0 dirty_background_ratio:10 dirty_expire_centisecs:2999 dirty_ratio:40 dirty_writeback_centisecs:499 drop_caches:0 laptop_mode:0 legacy_va_layout:0 lowmem_reserve_ratio:256256 32 max_map_count:65536 min_free_kbytes:4006 nr_pdflush_threads:2 oom_kill_allocating_task:0 overcommit_memory:0 overcommit_ratio:50 page-cluster:3 panic_on_oom:0 percpu_pagelist_fraction:0 stat_interval:1 swappiness:0 vfs_cache_pressure:100 -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swapping in 2.6.24-rc5-git3
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote: I think yes. 0 swappiness doesn't mean no swapping at all. From the code in shrink_active_list() it seems that it just decreases likeliness of removing pages of mmaped files (i.e., also executables loaded in memory). So, I tried to add some prints. I have mapped ratio about 78 while scp-ing the file. Distress suddenly raises from 0 to 100. At this poing, all the processes are swapped out. I guess it happens if scp is faster than the local disk which happens if I scp-ing over GE from desktop (with fast disk - and reading) to laptop (slow disk - and writing). This is my settings. /proc/sys/vm/* block_dump:0 dirty_background_ratio:10 dirty_expire_centisecs:2999 dirty_ratio:40 dirty_writeback_centisecs:499 drop_caches:0 laptop_mode:0 legacy_va_layout:0 lowmem_reserve_ratio:256256 32 max_map_count:65536 min_free_kbytes:4006 nr_pdflush_threads:2 oom_kill_allocating_task:0 overcommit_memory:0 overcommit_ratio:50 page-cluster:3 panic_on_oom:0 percpu_pagelist_fraction:0 stat_interval:1 swappiness:0 vfs_cache_pressure:100 -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swapping in 2.6.24-rc5-git3
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote: > Yes, that's quite unpleasant. How much memory do you have? If you have > some time, you can try playing with the code in mm/vmscan.c to find out > what's happening in your case (putting some debugging output in > shrink_active_list() etc... I think it is a regression in recent rc versions as I use 2.6.24-xx kernels on my new laptop from the very beginnig I have the laptopt and I did not notice such behaviour before. I have 1 GB RAM and I was coping a 2GB file from the network to the laptop. After the operation, 600MB of the swap area has been consumed. At the beginning of the copy, the swap area was empty. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
swapping in 2.6.24-rc5-git3
Hello, does /proc/sys/vm/swappiness still work as expected? # /proc/sys/vm# cat swappiness 0 but scp-ing 2GB file causes many processes are swapped out due to increase of the file cache size. Why? This is totally catastrophic behaviour on the desktop. Is there a way to avoid it except turning off the swap? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
swapping in 2.6.24-rc5-git3
Hello, does /proc/sys/vm/swappiness still work as expected? # /proc/sys/vm# cat swappiness 0 but scp-ing 2GB file causes many processes are swapped out due to increase of the file cache size. Why? This is totally catastrophic behaviour on the desktop. Is there a way to avoid it except turning off the swap? -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: swapping in 2.6.24-rc5-git3
On Mon, Dec 17, 2007 at 06:15:32PM +0100, Jan Kara wrote: Yes, that's quite unpleasant. How much memory do you have? If you have some time, you can try playing with the code in mm/vmscan.c to find out what's happening in your case (putting some debugging output in shrink_active_list() etc... I think it is a regression in recent rc versions as I use 2.6.24-xx kernels on my new laptop from the very beginnig I have the laptopt and I did not notice such behaviour before. I have 1 GB RAM and I was coping a 2GB file from the network to the laptop. After the operation, 600MB of the swap area has been consumed. At the beginning of the copy, the swap area was empty. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI related Warning in 2.6.24-rc3-git2
On Thu, Dec 13, 2007 at 09:41:23PM -0500, Len Brown wrote: > I've udpated the BIOS on my T61 to 1.26 to match yours, but > running 2.6.24-rc5 I don't see the issue you reported. > > If it still fails for you, please send me your .config It has been fixed in -rc4 I guess. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI related Warning in 2.6.24-rc3-git2
On Thu, Dec 13, 2007 at 09:41:23PM -0500, Len Brown wrote: I've udpated the BIOS on my T61 to 1.26 to match yours, but running 2.6.24-rc5 I don't see the issue you reported. If it still fails for you, please send me your .config It has been fixed in -rc4 I guess. -- Lukáš Hejtmánek -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: Hitachi disk quirk
On Tue, Dec 04, 2007 at 02:48:27PM +0300, Michael Tokarev wrote:
> Which problems, exactly?
it is spurious completitions and I saw that because of that the drives are
blacklisted. Moreover, the same drive is already blacklisted but with
different firmware.
> Note that recent massive "NCQ horkage" isn't necessary due to drives fault.
> Search for "spurious completions during NCQ" for recent discussions
> (many of them).
>
> > --- a/drivers/ata/libata-core.c 2007-12-04 11:08:20.0 +0100
> > +++ b/drivers/ata/libata-core.c 2007-12-04 11:09:23.0 +0100
> > { "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
> > + { "HITACHI HTS541616J9SA00", "SB4IC7UP", ATA_HORKAGE_NONCQ, },
> > { "Hitachi HTS542525K9SA00", "BBFOC31P", ATA_HORKAGE_NONCQ, },
>
> /mjt
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
PATCH: Hitachi disk quirk
Hello,
the following patch should be applied into 2.6.24-rc3 as the mentioned Hitachi
disk has also problem with NCQ.
--
Lukáš Hejtmánek
--- a/drivers/ata/libata-core.c 2007-12-04 11:08:20.0 +0100
+++ b/drivers/ata/libata-core.c 2007-12-04 11:09:23.0 +0100
@@ -4159,6 +4159,7 @@
{ "HTS541612J9SA00", "SBDIC7JP", ATA_HORKAGE_NONCQ, },
{ "HDT722516DLA380", "V43OA96A", ATA_HORKAGE_NONCQ, },
{ "Hitachi HTS541616J9SA00", "SB4OC70P", ATA_HORKAGE_NONCQ, },
+ { "HITACHI HTS541616J9SA00", "SB4IC7UP", ATA_HORKAGE_NONCQ, },
{ "Hitachi HTS542525K9SA00", "BBFOC31P", ATA_HORKAGE_NONCQ, },
{ "WDC WD740ADFD-00NLR1", NULL, ATA_HORKAGE_NONCQ, },
{ "WDC WD3200AAJS-00RYA0", "12.01B01", ATA_HORKAGE_NONCQ, },
PATCH: Hitachi disk quirk
Hello,
the following patch should be applied into 2.6.24-rc3 as the mentioned Hitachi
disk has also problem with NCQ.
--
Lukáš Hejtmánek
--- a/drivers/ata/libata-core.c 2007-12-04 11:08:20.0 +0100
+++ b/drivers/ata/libata-core.c 2007-12-04 11:09:23.0 +0100
@@ -4159,6 +4159,7 @@
{ HTS541612J9SA00, SBDIC7JP, ATA_HORKAGE_NONCQ, },
{ HDT722516DLA380, V43OA96A, ATA_HORKAGE_NONCQ, },
{ Hitachi HTS541616J9SA00, SB4OC70P, ATA_HORKAGE_NONCQ, },
+ { HITACHI HTS541616J9SA00, SB4IC7UP, ATA_HORKAGE_NONCQ, },
{ Hitachi HTS542525K9SA00, BBFOC31P, ATA_HORKAGE_NONCQ, },
{ WDC WD740ADFD-00NLR1, NULL, ATA_HORKAGE_NONCQ, },
{ WDC WD3200AAJS-00RYA0, 12.01B01, ATA_HORKAGE_NONCQ, },
Re: PATCH: Hitachi disk quirk
On Tue, Dec 04, 2007 at 02:48:27PM +0300, Michael Tokarev wrote:
Which problems, exactly?
it is spurious completitions and I saw that because of that the drives are
blacklisted. Moreover, the same drive is already blacklisted but with
different firmware.
Note that recent massive NCQ horkage isn't necessary due to drives fault.
Search for spurious completions during NCQ for recent discussions
(many of them).
--- a/drivers/ata/libata-core.c 2007-12-04 11:08:20.0 +0100
+++ b/drivers/ata/libata-core.c 2007-12-04 11:09:23.0 +0100
{ Hitachi HTS541616J9SA00, SB4OC70P, ATA_HORKAGE_NONCQ, },
+ { HITACHI HTS541616J9SA00, SB4IC7UP, ATA_HORKAGE_NONCQ, },
{ Hitachi HTS542525K9SA00, BBFOC31P, ATA_HORKAGE_NONCQ, },
/mjt
--
Lukáš Hejtmánek
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI related Warning in 2.6.24-rc3-git2
On Thu, Nov 29, 2007 at 04:22:43PM +0800, Zhao Yakui wrote: > Subject: ACPI : Delete the IRQ operation in throttling controll via PTC > >From : Zhao Yakui <[EMAIL PROTECTED]> > > The IRQ operation(enable/disable) should be avoided when throttling is > controlled via PTC method. It is replaced by the migration of task. > > Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]> works for me. -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI related Warning in 2.6.24-rc3-git2
On Thu, Nov 29, 2007 at 04:22:43PM +0800, Zhao Yakui wrote: Subject: ACPI : Delete the IRQ operation in throttling controll via PTC From : Zhao Yakui [EMAIL PROTECTED] The IRQ operation(enable/disable) should be avoided when throttling is controlled via PTC method. It is replaced by the migration of task. Signed-off-by: Zhao Yakui [EMAIL PROTECTED] works for me. -- Lukáš Hejtmánek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI related Warning in 2.6.24-rc3-git2
On Wed, Nov 28, 2007 at 02:11:55AM -0200, Henrique de Moraes Holschuh wrote: > On Tue, 27 Nov 2007, Rafael J. Wysocki wrote: > > > in recent kernel, I got the following warnings while booting. It's ACPI > > > related. Does anybode care? Lenovo ThinkPad T61 (6465CTO). > > Could we know the BIOS version, please? 7LET56WW (1.26 ) (according to hal, 1.26 is definitely correct, can be seen in BIOS as well) -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI related Warning in 2.6.24-rc3-git2
On Wed, Nov 28, 2007 at 02:11:55AM -0200, Henrique de Moraes Holschuh wrote: On Tue, 27 Nov 2007, Rafael J. Wysocki wrote: in recent kernel, I got the following warnings while booting. It's ACPI related. Does anybode care? Lenovo ThinkPad T61 (6465CTO). Could we know the BIOS version, please? 7LET56WW (1.26 ) (according to hal, 1.26 is definitely correct, can be seen in BIOS as well) -- Lukáš Hejtmánek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: e1000 driver problems
On Tue, Nov 27, 2007 at 08:48:52AM -0800, Kok, Auke wrote: > > unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2 > > kernel due to compilation errors. > > but the in-kernel version of e1000 supports the ich8 lan device just fine > and can be builtin. also this kernel has the first release of e1000e which > supports the ich9 onboard lan device. I'm afraid, I'm missing the point as you have stated that in-kernel drivers have problem with suspicious board hang... -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI related Warning in 2.6.24-rc3-git2
On Tue, Nov 27, 2007 at 04:37:12PM +0100, Rafael J. Wysocki wrote: > > in recent kernel, I got the following warnings while booting. It's ACPI > > related. Does anybode care? Lenovo ThinkPad T61 (6465CTO). > > Appropriate Ccs added. > > Did it happen before? didn't see it in 2.6.24-rc3-git1. > > [ 13.114814] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 > > [ 13.114885] > > [ 13.114885] Call Trace: > > [ 13.115020] [] acpi_ut_update_ref_count+0x50/0x9d > > [ 13.115095] [] smp_call_function_single+0xbd/0xd0 > > [ 13.115169] [] _rdmsr_on_cpu+0x5c/0x60 > > [ 13.115241] [] > > acpi_processor_get_throttling_ptc+0xf3/0x158 > > [ 13.115323] [] > > acpi_processor_get_throttling_info+0x460/0x4af > > [ 13.115406] [] acpi_processor_start+0x54a/0x606 > > [ 13.115478] [] ifind+0x48/0xd0 > > [ 13.115550] [] acpi_start_single_object+0x24/0x46 > > [ 13.115622] [] acpi_device_probe+0x7d/0x91 > > [ 13.115694] [] driver_probe_device+0x9c/0x1b0 > > [ 13.115766] [] __driver_attach+0xc9/0xd0 > > [ 13.115840] [] __driver_attach+0x0/0xd0 > > [ 13.115924] [] bus_for_each_dev+0x4d/0x80 > > [ 13.115994] [] bus_add_driver+0xac/0x220 > > [ 13.116080] [] acpi_processor_init+0x8f/0xfc > > [ 13.116153] [] kernel_init+0x154/0x330 > > [ 13.116225] [] child_rip+0xa/0x12 > > [ 13.116295] [] kernel_init+0x0/0x330 > > [ 13.116365] [] child_rip+0x0/0x12 > > [ 13.116435] > > [ 13.116504] WARNING: at arch/x86/kernel/smp_64.c:397 > > smp_call_function_mask() > > [ 13.116577] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 > > [ 13.116648] > > [ 13.116648] Call Trace: > > [ 13.116779] [] acpi_ut_update_ref_count+0x50/0x9d > > [ 13.116851] [] smp_call_function_mask+0x8f/0xa0 > > [ 13.116923] [] _rdmsr_on_cpu+0x5c/0x60 > > [ 13.116994] [] > > acpi_processor_get_throttling_ptc+0xf3/0x158 > > [ 13.117077] [] > > acpi_processor_get_throttling_info+0x460/0x4af > > [ 13.117169] [] acpi_processor_start+0x54a/0x606 > > [ 13.117248] [] ifind+0x48/0xd0 > > [ 13.117330] [] acpi_start_single_object+0x24/0x46 > > [ 13.117402] [] acpi_device_probe+0x7d/0x91 > > [ 13.117488] [] driver_probe_device+0x9c/0x1b0 > > [ 13.117559] [] __driver_attach+0xc9/0xd0 > > [ 13.117631] [] __driver_attach+0x0/0xd0 > > [ 13.117715] [] bus_for_each_dev+0x4d/0x80 > > [ 13.117786] [] bus_add_driver+0xac/0x220 > > [ 13.117856] [] acpi_processor_init+0x8f/0xfc > > [ 13.117941] [] kernel_init+0x154/0x330 > > [ 13.118018] [] child_rip+0xa/0x12 > > [ 13.118088] [] kernel_init+0x0/0x330 > > [ 13.118158] [] child_rip+0x0/0x12 > > [ 13.118227] > > [...] > > [ 13.124714] WARNING: at arch/x86/kernel/smp_64.c:427 > > smp_call_function_single() > > [ 13.124798] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 > > [ 13.125460] > > [ 13.125461] Call Trace: > > [ 13.125592] [] acpi_ut_update_ref_count+0x50/0x9d > > [ 13.125665] [] smp_call_function_single+0xbd/0xd0 > > [ 13.125737] [] _rdmsr_on_cpu+0x5c/0x60 > > [ 13.125807] [] > > acpi_processor_get_throttling_ptc+0xf3/0x158 > > [ 13.125903] [] > > acpi_processor_get_throttling_info+0x460/0x4af > > [ 13.125999] [] acpi_processor_start+0x54a/0x606 > > [ 13.126071] [] acpi_processor_add+0x24/0x6b > > [ 13.126142] [] acpi_start_single_object+0x24/0x46 > > [ 13.126214] [] acpi_device_probe+0x7d/0x91 > > [ 13.126285] [] driver_probe_device+0x9c/0x1b0 > > [ 13.126357] [] __driver_attach+0xc9/0xd0 > > [ 13.126441] [] __driver_attach+0x0/0xd0 > > [ 13.126518] [] bus_for_each_dev+0x4d/0x80 > > [ 13.126600] [] bus_add_driver+0xac/0x220 > > [ 13.126670] [] acpi_processor_init+0x8f/0xfc > > [ 13.126755] [] kernel_init+0x154/0x330 > > [ 13.126832] [] child_rip+0xa/0x12 > > [ 13.126916] [] kernel_init+0x0/0x330 > > [ 13.126986] [] child_rip+0x0/0x12 > > [ 13.127059] > > [ 13.127124] WARNING: at arch/x86/kernel/smp_64.c:397 > > smp_call_function_mask() > > [ 13.127197] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 > > [ 13.127267] > > [ 13.127268] Call Trace: > > [ 13.127398] [] acpi_ut_update_ref_count+0x50/0x9d > > [ 13.127473] [] smp_call_function_mask+0x8f/0xa0 > > [ 13.127545] [] _rdmsr_on_cpu+0x5c/0x60 > > [ 13.127616] [] > > acpi_processor_get_throttling_ptc+0xf3/0x158 > > [ 13.127699] [] > > acpi_processor_get_throttling_info+0x460/0x4af > > [ 13.127782] [] acpi_processor_start+0x54a/0x606 > > [ 13.127861] [] acpi_processor_add+0x24/0x6b > > [ 13.127933] [] acpi_start_single_object+0x24/0x46 > > [ 13.128005] [] acpi_device_probe+0x7d/0x91 > > [ 13.128076] [] driver_probe_device+0x9c/0x1b0 > > [ 13.128147] [] __driver_attach+0xc9/0xd0 > > [ 13.128226] [] __driver_attach+0x0/0xd0 > > [ 13.128310] [] bus_for_each_dev+0x4d/0x80 > > [ 13.128381] [] bus_add_driver+0xac/0x220 > > [ 13.128452] [] acpi_processor_init+0x8f/0xfc > > [ 13.128523] [] kernel_init+0x154/0x330 > > [
Re: e1000 driver problems
On Mon, Nov 26, 2007 at 03:26:08PM -0800, Kok, Auke wrote: > The fix for this has been to grant more time for the hardware to recover > from this busy state. I'll make sure to check if the upstream drivers are OK > in this regard. > > you can try our out-of-tree e1000 driver (7.6.x or newer) which should work > OK for you with respect to this problem. Please give that a try. unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2 kernel due to compilation errors. -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI related Warning in 2.6.24-rc3-git2
Hello, in recent kernel, I got the following warnings while booting. It's ACPI related. Does anybode care? Lenovo ThinkPad T61 (6465CTO). [ 13.114814] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.114885] [ 13.114885] Call Trace: [ 13.115020] [] acpi_ut_update_ref_count+0x50/0x9d [ 13.115095] [] smp_call_function_single+0xbd/0xd0 [ 13.115169] [] _rdmsr_on_cpu+0x5c/0x60 [ 13.115241] [] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.115323] [] acpi_processor_get_throttling_info+0x460/0x4af [ 13.115406] [] acpi_processor_start+0x54a/0x606 [ 13.115478] [] ifind+0x48/0xd0 [ 13.115550] [] acpi_start_single_object+0x24/0x46 [ 13.115622] [] acpi_device_probe+0x7d/0x91 [ 13.115694] [] driver_probe_device+0x9c/0x1b0 [ 13.115766] [] __driver_attach+0xc9/0xd0 [ 13.115840] [] __driver_attach+0x0/0xd0 [ 13.115924] [] bus_for_each_dev+0x4d/0x80 [ 13.115994] [] bus_add_driver+0xac/0x220 [ 13.116080] [] acpi_processor_init+0x8f/0xfc [ 13.116153] [] kernel_init+0x154/0x330 [ 13.116225] [] child_rip+0xa/0x12 [ 13.116295] [] kernel_init+0x0/0x330 [ 13.116365] [] child_rip+0x0/0x12 [ 13.116435] [ 13.116504] WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() [ 13.116577] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.116648] [ 13.116648] Call Trace: [ 13.116779] [] acpi_ut_update_ref_count+0x50/0x9d [ 13.116851] [] smp_call_function_mask+0x8f/0xa0 [ 13.116923] [] _rdmsr_on_cpu+0x5c/0x60 [ 13.116994] [] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.117077] [] acpi_processor_get_throttling_info+0x460/0x4af [ 13.117169] [] acpi_processor_start+0x54a/0x606 [ 13.117248] [] ifind+0x48/0xd0 [ 13.117330] [] acpi_start_single_object+0x24/0x46 [ 13.117402] [] acpi_device_probe+0x7d/0x91 [ 13.117488] [] driver_probe_device+0x9c/0x1b0 [ 13.117559] [] __driver_attach+0xc9/0xd0 [ 13.117631] [] __driver_attach+0x0/0xd0 [ 13.117715] [] bus_for_each_dev+0x4d/0x80 [ 13.117786] [] bus_add_driver+0xac/0x220 [ 13.117856] [] acpi_processor_init+0x8f/0xfc [ 13.117941] [] kernel_init+0x154/0x330 [ 13.118018] [] child_rip+0xa/0x12 [ 13.118088] [] kernel_init+0x0/0x330 [ 13.118158] [] child_rip+0x0/0x12 [ 13.118227] [...] [ 13.124714] WARNING: at arch/x86/kernel/smp_64.c:427 smp_call_function_single() [ 13.124798] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.125460] [ 13.125461] Call Trace: [ 13.125592] [] acpi_ut_update_ref_count+0x50/0x9d [ 13.125665] [] smp_call_function_single+0xbd/0xd0 [ 13.125737] [] _rdmsr_on_cpu+0x5c/0x60 [ 13.125807] [] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.125903] [] acpi_processor_get_throttling_info+0x460/0x4af [ 13.125999] [] acpi_processor_start+0x54a/0x606 [ 13.126071] [] acpi_processor_add+0x24/0x6b [ 13.126142] [] acpi_start_single_object+0x24/0x46 [ 13.126214] [] acpi_device_probe+0x7d/0x91 [ 13.126285] [] driver_probe_device+0x9c/0x1b0 [ 13.126357] [] __driver_attach+0xc9/0xd0 [ 13.126441] [] __driver_attach+0x0/0xd0 [ 13.126518] [] bus_for_each_dev+0x4d/0x80 [ 13.126600] [] bus_add_driver+0xac/0x220 [ 13.126670] [] acpi_processor_init+0x8f/0xfc [ 13.126755] [] kernel_init+0x154/0x330 [ 13.126832] [] child_rip+0xa/0x12 [ 13.126916] [] kernel_init+0x0/0x330 [ 13.126986] [] child_rip+0x0/0x12 [ 13.127059] [ 13.127124] WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() [ 13.127197] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.127267] [ 13.127268] Call Trace: [ 13.127398] [] acpi_ut_update_ref_count+0x50/0x9d [ 13.127473] [] smp_call_function_mask+0x8f/0xa0 [ 13.127545] [] _rdmsr_on_cpu+0x5c/0x60 [ 13.127616] [] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.127699] [] acpi_processor_get_throttling_info+0x460/0x4af [ 13.127782] [] acpi_processor_start+0x54a/0x606 [ 13.127861] [] acpi_processor_add+0x24/0x6b [ 13.127933] [] acpi_start_single_object+0x24/0x46 [ 13.128005] [] acpi_device_probe+0x7d/0x91 [ 13.128076] [] driver_probe_device+0x9c/0x1b0 [ 13.128147] [] __driver_attach+0xc9/0xd0 [ 13.128226] [] __driver_attach+0x0/0xd0 [ 13.128310] [] bus_for_each_dev+0x4d/0x80 [ 13.128381] [] bus_add_driver+0xac/0x220 [ 13.128452] [] acpi_processor_init+0x8f/0xfc [ 13.128523] [] kernel_init+0x154/0x330 [ 13.128594] [] child_rip+0xa/0x12 [ 13.128664] [] kernel_init+0x0/0x330 [ 13.128734] [] child_rip+0x0/0x12 -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ACPI related Warning in 2.6.24-rc3-git2
Hello, in recent kernel, I got the following warnings while booting. It's ACPI related. Does anybode care? Lenovo ThinkPad T61 (6465CTO). [ 13.114814] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.114885] [ 13.114885] Call Trace: [ 13.115020] [80357ab6] acpi_ut_update_ref_count+0x50/0x9d [ 13.115095] [8021e7ad] smp_call_function_single+0xbd/0xd0 [ 13.115169] [80331dbc] _rdmsr_on_cpu+0x5c/0x60 [ 13.115241] [803631c7] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.115323] [80362f04] acpi_processor_get_throttling_info+0x460/0x4af [ 13.115406] [80362264] acpi_processor_start+0x54a/0x606 [ 13.115478] [802abc38] ifind+0x48/0xd0 [ 13.115550] [8035a31e] acpi_start_single_object+0x24/0x46 [ 13.115622] [8035b716] acpi_device_probe+0x7d/0x91 [ 13.115694] [8038effc] driver_probe_device+0x9c/0x1b0 [ 13.115766] [8038f2c9] __driver_attach+0xc9/0xd0 [ 13.115840] [8038f200] __driver_attach+0x0/0xd0 [ 13.115924] [8038e1dd] bus_for_each_dev+0x4d/0x80 [ 13.115994] [8038e64c] bus_add_driver+0xac/0x220 [ 13.116080] [8064dd7c] acpi_processor_init+0x8f/0xfc [ 13.116153] [806386f4] kernel_init+0x154/0x330 [ 13.116225] [8020d178] child_rip+0xa/0x12 [ 13.116295] [806385a0] kernel_init+0x0/0x330 [ 13.116365] [8020d16e] child_rip+0x0/0x12 [ 13.116435] [ 13.116504] WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() [ 13.116577] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.116648] [ 13.116648] Call Trace: [ 13.116779] [80357ab6] acpi_ut_update_ref_count+0x50/0x9d [ 13.116851] [8021e4af] smp_call_function_mask+0x8f/0xa0 [ 13.116923] [80331dbc] _rdmsr_on_cpu+0x5c/0x60 [ 13.116994] [803631c7] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.117077] [80362f04] acpi_processor_get_throttling_info+0x460/0x4af [ 13.117169] [80362264] acpi_processor_start+0x54a/0x606 [ 13.117248] [802abc38] ifind+0x48/0xd0 [ 13.117330] [8035a31e] acpi_start_single_object+0x24/0x46 [ 13.117402] [8035b716] acpi_device_probe+0x7d/0x91 [ 13.117488] [8038effc] driver_probe_device+0x9c/0x1b0 [ 13.117559] [8038f2c9] __driver_attach+0xc9/0xd0 [ 13.117631] [8038f200] __driver_attach+0x0/0xd0 [ 13.117715] [8038e1dd] bus_for_each_dev+0x4d/0x80 [ 13.117786] [8038e64c] bus_add_driver+0xac/0x220 [ 13.117856] [8064dd7c] acpi_processor_init+0x8f/0xfc [ 13.117941] [806386f4] kernel_init+0x154/0x330 [ 13.118018] [8020d178] child_rip+0xa/0x12 [ 13.118088] [806385a0] kernel_init+0x0/0x330 [ 13.118158] [8020d16e] child_rip+0x0/0x12 [ 13.118227] [...] [ 13.124714] WARNING: at arch/x86/kernel/smp_64.c:427 smp_call_function_single() [ 13.124798] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.125460] [ 13.125461] Call Trace: [ 13.125592] [80357ab6] acpi_ut_update_ref_count+0x50/0x9d [ 13.125665] [8021e7ad] smp_call_function_single+0xbd/0xd0 [ 13.125737] [80331dbc] _rdmsr_on_cpu+0x5c/0x60 [ 13.125807] [803631c7] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.125903] [80362f04] acpi_processor_get_throttling_info+0x460/0x4af [ 13.125999] [80362264] acpi_processor_start+0x54a/0x606 [ 13.126071] [803625ed] acpi_processor_add+0x24/0x6b [ 13.126142] [8035a31e] acpi_start_single_object+0x24/0x46 [ 13.126214] [8035b716] acpi_device_probe+0x7d/0x91 [ 13.126285] [8038effc] driver_probe_device+0x9c/0x1b0 [ 13.126357] [8038f2c9] __driver_attach+0xc9/0xd0 [ 13.126441] [8038f200] __driver_attach+0x0/0xd0 [ 13.126518] [8038e1dd] bus_for_each_dev+0x4d/0x80 [ 13.126600] [8038e64c] bus_add_driver+0xac/0x220 [ 13.126670] [8064dd7c] acpi_processor_init+0x8f/0xfc [ 13.126755] [806386f4] kernel_init+0x154/0x330 [ 13.126832] [8020d178] child_rip+0xa/0x12 [ 13.126916] [806385a0] kernel_init+0x0/0x330 [ 13.126986] [8020d16e] child_rip+0x0/0x12 [ 13.127059] [ 13.127124] WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() [ 13.127197] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.127267] [ 13.127268] Call Trace: [ 13.127398] [80357ab6] acpi_ut_update_ref_count+0x50/0x9d [ 13.127473] [8021e4af] smp_call_function_mask+0x8f/0xa0 [ 13.127545] [80331dbc] _rdmsr_on_cpu+0x5c/0x60 [ 13.127616] [803631c7] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.127699] [80362f04] acpi_processor_get_throttling_info+0x460/0x4af [ 13.127782] [80362264] acpi_processor_start+0x54a/0x606 [ 13.127861] [803625ed]
Re: e1000 driver problems
On Mon, Nov 26, 2007 at 03:26:08PM -0800, Kok, Auke wrote: The fix for this has been to grant more time for the hardware to recover from this busy state. I'll make sure to check if the upstream drivers are OK in this regard. you can try our out-of-tree e1000 driver (7.6.x or newer) which should work OK for you with respect to this problem. Please give that a try. unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2 kernel due to compilation errors. -- Lukáš Hejtmánek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI related Warning in 2.6.24-rc3-git2
On Tue, Nov 27, 2007 at 04:37:12PM +0100, Rafael J. Wysocki wrote: in recent kernel, I got the following warnings while booting. It's ACPI related. Does anybode care? Lenovo ThinkPad T61 (6465CTO). Appropriate Ccs added. Did it happen before? didn't see it in 2.6.24-rc3-git1. [ 13.114814] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.114885] [ 13.114885] Call Trace: [ 13.115020] [80357ab6] acpi_ut_update_ref_count+0x50/0x9d [ 13.115095] [8021e7ad] smp_call_function_single+0xbd/0xd0 [ 13.115169] [80331dbc] _rdmsr_on_cpu+0x5c/0x60 [ 13.115241] [803631c7] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.115323] [80362f04] acpi_processor_get_throttling_info+0x460/0x4af [ 13.115406] [80362264] acpi_processor_start+0x54a/0x606 [ 13.115478] [802abc38] ifind+0x48/0xd0 [ 13.115550] [8035a31e] acpi_start_single_object+0x24/0x46 [ 13.115622] [8035b716] acpi_device_probe+0x7d/0x91 [ 13.115694] [8038effc] driver_probe_device+0x9c/0x1b0 [ 13.115766] [8038f2c9] __driver_attach+0xc9/0xd0 [ 13.115840] [8038f200] __driver_attach+0x0/0xd0 [ 13.115924] [8038e1dd] bus_for_each_dev+0x4d/0x80 [ 13.115994] [8038e64c] bus_add_driver+0xac/0x220 [ 13.116080] [8064dd7c] acpi_processor_init+0x8f/0xfc [ 13.116153] [806386f4] kernel_init+0x154/0x330 [ 13.116225] [8020d178] child_rip+0xa/0x12 [ 13.116295] [806385a0] kernel_init+0x0/0x330 [ 13.116365] [8020d16e] child_rip+0x0/0x12 [ 13.116435] [ 13.116504] WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() [ 13.116577] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.116648] [ 13.116648] Call Trace: [ 13.116779] [80357ab6] acpi_ut_update_ref_count+0x50/0x9d [ 13.116851] [8021e4af] smp_call_function_mask+0x8f/0xa0 [ 13.116923] [80331dbc] _rdmsr_on_cpu+0x5c/0x60 [ 13.116994] [803631c7] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.117077] [80362f04] acpi_processor_get_throttling_info+0x460/0x4af [ 13.117169] [80362264] acpi_processor_start+0x54a/0x606 [ 13.117248] [802abc38] ifind+0x48/0xd0 [ 13.117330] [8035a31e] acpi_start_single_object+0x24/0x46 [ 13.117402] [8035b716] acpi_device_probe+0x7d/0x91 [ 13.117488] [8038effc] driver_probe_device+0x9c/0x1b0 [ 13.117559] [8038f2c9] __driver_attach+0xc9/0xd0 [ 13.117631] [8038f200] __driver_attach+0x0/0xd0 [ 13.117715] [8038e1dd] bus_for_each_dev+0x4d/0x80 [ 13.117786] [8038e64c] bus_add_driver+0xac/0x220 [ 13.117856] [8064dd7c] acpi_processor_init+0x8f/0xfc [ 13.117941] [806386f4] kernel_init+0x154/0x330 [ 13.118018] [8020d178] child_rip+0xa/0x12 [ 13.118088] [806385a0] kernel_init+0x0/0x330 [ 13.118158] [8020d16e] child_rip+0x0/0x12 [ 13.118227] [...] [ 13.124714] WARNING: at arch/x86/kernel/smp_64.c:427 smp_call_function_single() [ 13.124798] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.125460] [ 13.125461] Call Trace: [ 13.125592] [80357ab6] acpi_ut_update_ref_count+0x50/0x9d [ 13.125665] [8021e7ad] smp_call_function_single+0xbd/0xd0 [ 13.125737] [80331dbc] _rdmsr_on_cpu+0x5c/0x60 [ 13.125807] [803631c7] acpi_processor_get_throttling_ptc+0xf3/0x158 [ 13.125903] [80362f04] acpi_processor_get_throttling_info+0x460/0x4af [ 13.125999] [80362264] acpi_processor_start+0x54a/0x606 [ 13.126071] [803625ed] acpi_processor_add+0x24/0x6b [ 13.126142] [8035a31e] acpi_start_single_object+0x24/0x46 [ 13.126214] [8035b716] acpi_device_probe+0x7d/0x91 [ 13.126285] [8038effc] driver_probe_device+0x9c/0x1b0 [ 13.126357] [8038f2c9] __driver_attach+0xc9/0xd0 [ 13.126441] [8038f200] __driver_attach+0x0/0xd0 [ 13.126518] [8038e1dd] bus_for_each_dev+0x4d/0x80 [ 13.126600] [8038e64c] bus_add_driver+0xac/0x220 [ 13.126670] [8064dd7c] acpi_processor_init+0x8f/0xfc [ 13.126755] [806386f4] kernel_init+0x154/0x330 [ 13.126832] [8020d178] child_rip+0xa/0x12 [ 13.126916] [806385a0] kernel_init+0x0/0x330 [ 13.126986] [8020d16e] child_rip+0x0/0x12 [ 13.127059] [ 13.127124] WARNING: at arch/x86/kernel/smp_64.c:397 smp_call_function_mask() [ 13.127197] Pid: 1, comm: swapper Not tainted 2.6.24-rc3-git2 #3 [ 13.127267] [ 13.127268] Call Trace: [ 13.127398] [80357ab6] acpi_ut_update_ref_count+0x50/0x9d [ 13.127473] [8021e4af] smp_call_function_mask+0x8f/0xa0 [
Re: e1000 driver problems
On Tue, Nov 27, 2007 at 08:48:52AM -0800, Kok, Auke wrote: unfortunately, the 7.6.9 driver cannot be compiled with 2.6.24-rc3-git2 kernel due to compilation errors. but the in-kernel version of e1000 supports the ich8 lan device just fine and can be builtin. also this kernel has the first release of e1000e which supports the ich9 onboard lan device. I'm afraid, I'm missing the point as you have stated that in-kernel drivers have problem with suspicious board hang... -- Lukáš Hejtmánek - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
e1000 driver problems
Hello, I have laptop thinkpad T61 with 82566MM Gigabit Network Connection (rev 03) (8086:1049). I have kernel 2.6.24-rc3. E1000E driver does not work (the card is not detected although it is PCI-E), with E1000 driver, it works mostly OK unless I force speed to 100Mbits. (ethtool -s eth0 autoneg off speed 100) I got message about device hang: Nov 20 10:57:24 anubis kernel: [ 212.307502] e1000: eth0: e1000_watchdog: 10/100 speed: disabling TSO Nov 20 11:03:02 anubis kernel: [ 242.811474] Tx Queue <0> Nov 20 11:03:02 anubis kernel: [ 242.811476] TDH <80> Nov 20 11:03:02 anubis kernel: [ 242.811478] TDT <81> Nov 20 11:03:02 anubis kernel: [ 242.811480] next_to_use <81> Nov 20 11:03:02 anubis kernel: [ 242.811482] next_to_clean<80> Nov 20 11:03:02 anubis kernel: [ 242.811484] buffer_info[next_to_clean] Nov 20 11:03:02 anubis kernel: [ 242.811486] time_stamp <100079cdf> Nov 20 11:03:02 anubis kernel: [ 242.811488] next_to_watch<80> Nov 20 11:03:02 anubis kernel: [ 242.811489] jiffies <100079e68> Nov 20 11:03:02 anubis kernel: [ 242.811491] next_to_watch.status <0> Nov 20 11:03:04 anubis kernel: [ 243.47] Tx Queue <0> Nov 20 11:03:04 anubis kernel: [ 243.49] TDH <80> Nov 20 11:03:04 anubis kernel: [ 243.51] TDT <81> Nov 20 11:03:04 anubis kernel: [ 243.53] next_to_use <81> and so on. Is it known problem? -- Lukáš Hejtmánek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
