* Re: 2.6.23-rc2-mm1 [not found] <20070809015106.cd0bfc53.akpm@linux-foundation.org> @ 2007-08-09 13:23 ` Michal Piotrowski 2007-08-09 18:37 ` 2.6.23-rc2-mm1 Andrew Morton 2007-08-09 13:51 ` 2.6.23-rc2-mm1: e1000e global symbols must be renamed Adrian Bunk 2007-08-09 23:49 ` 2.6.23-rc2-mm1: rtl8139 inconsistent lock state Mariusz Kozlowski 2 siblings, 1 reply; 13+ messages in thread From: Michal Piotrowski @ 2007-08-09 13:23 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Netdev, Jeff Garzik Andrew Morton pisze: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/ I am experiencing some problems with 8139too [ 28.847004] 8139too 0000:02:0d.0: region #0 not a PIO resource, aborting [ 28.854722] Bad IO access at port 0 () [ 28.859459] WARNING: at /home/devel/linux-mm/lib/iomap.c:44 bad_io_access() [ 28.867415] [<c040536b>] show_trace_log_lvl+0x1a/0x30 [ 28.873568] [<c0405ff3>] show_trace+0x12/0x14 [ 28.879015] [<c0406128>] dump_stack+0x16/0x18 [ 28.884451] [<c052a904>] bad_io_access+0x58/0x5a [ 28.890129] [<c052a927>] pci_iounmap+0x21/0x2b [ 28.895635] [<c05b3746>] __rtl8139_cleanup_dev+0x75/0xc6 [ 28.902037] [<c05b42c4>] rtl8139_init_one+0x59b/0xa9f [ 28.908170] [<c053e344>] pci_device_probe+0x44/0x5f [ 28.914116] [<c05a7cd0>] driver_probe_device+0xa7/0x19a [ 28.920402] [<c05a7f1a>] __driver_attach+0xa6/0xa8 [ 28.926236] [<c05a71d3>] bus_for_each_dev+0x43/0x61 [ 28.932139] [<c05a7b51>] driver_attach+0x19/0x1b [ 28.937776] [<c05a7504>] bus_add_driver+0x7e/0x1a5 [ 28.943567] [<c05a80cf>] driver_register+0x45/0x75 [ 28.949358] [<c053e4a5>] __pci_register_driver+0x56/0x84 [ 28.955678] [<c0819118>] rtl8139_init_module+0x14/0x1c [ 28.961832] [<c0800521>] kernel_init+0x132/0x306 [ 28.967451] [<c0404fb3>] kernel_thread_helper+0x7/0x14 [ 28.973588] ======================= [ 28.978151] initcall 0xc0819104: rtl8139_init_module+0x0/0x1c() returned 0. [ 28.986114] initcall 0xc0819104 ran for 161 msecs: rtl8139_init_module+0x0/0x1c() http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.23-rc2-mm1/mm-dmesg http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.23-rc2-mm1/mm-config Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.23-rc2-mm1 2007-08-09 13:23 ` 2.6.23-rc2-mm1 Michal Piotrowski @ 2007-08-09 18:37 ` Andrew Morton 2007-08-09 19:04 ` 2.6.23-rc2-mm1 Michal Piotrowski 0 siblings, 1 reply; 13+ messages in thread From: Andrew Morton @ 2007-08-09 18:37 UTC (permalink / raw) To: Michal Piotrowski; +Cc: linux-kernel, Netdev, Jeff Garzik On Thu, 09 Aug 2007 15:23:41 +0200 Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote: > Andrew Morton pisze: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/ > > I am experiencing some problems with 8139too > > [ 28.847004] 8139too 0000:02:0d.0: region #0 not a PIO resource, aborting > [ 28.854722] Bad IO access at port 0 () > [ 28.859459] WARNING: at /home/devel/linux-mm/lib/iomap.c:44 bad_io_access() > [ 28.867415] [<c040536b>] show_trace_log_lvl+0x1a/0x30 > [ 28.873568] [<c0405ff3>] show_trace+0x12/0x14 > [ 28.879015] [<c0406128>] dump_stack+0x16/0x18 > [ 28.884451] [<c052a904>] bad_io_access+0x58/0x5a > [ 28.890129] [<c052a927>] pci_iounmap+0x21/0x2b > [ 28.895635] [<c05b3746>] __rtl8139_cleanup_dev+0x75/0xc6 > [ 28.902037] [<c05b42c4>] rtl8139_init_one+0x59b/0xa9f > [ 28.908170] [<c053e344>] pci_device_probe+0x44/0x5f > [ 28.914116] [<c05a7cd0>] driver_probe_device+0xa7/0x19a > [ 28.920402] [<c05a7f1a>] __driver_attach+0xa6/0xa8 > [ 28.926236] [<c05a71d3>] bus_for_each_dev+0x43/0x61 > [ 28.932139] [<c05a7b51>] driver_attach+0x19/0x1b > [ 28.937776] [<c05a7504>] bus_add_driver+0x7e/0x1a5 > [ 28.943567] [<c05a80cf>] driver_register+0x45/0x75 > [ 28.949358] [<c053e4a5>] __pci_register_driver+0x56/0x84 > [ 28.955678] [<c0819118>] rtl8139_init_module+0x14/0x1c > [ 28.961832] [<c0800521>] kernel_init+0x132/0x306 > [ 28.967451] [<c0404fb3>] kernel_thread_helper+0x7/0x14 > [ 28.973588] ======================= > [ 28.978151] initcall 0xc0819104: rtl8139_init_module+0x0/0x1c() returned 0. > [ 28.986114] initcall 0xc0819104 ran for 161 msecs: rtl8139_init_module+0x0/0x1c() > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.23-rc2-mm1/mm-dmesg > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.23-rc2-mm1/mm-config > Please try reverting 8139too-force-media-setting-fix.patch, then applying this: From: Andrew Morton <akpm@linux-foundation.org> Revert git-netdev-all's 9ee6b32a47b9abc565466a9c3b127a5246b452e5 Cc: Michal Piotrowski <michal.k.k.piotrowski@gmail.com> Cc: Jeff Garzik <jeff@garzik.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- drivers/net/8139too.c | 50 +++++++++++++++++++++++----------------- 1 file changed, 29 insertions(+), 21 deletions(-) diff -puN drivers/net/8139too.c~revert-8139too-clean-up-i-o-remapping drivers/net/8139too.c --- a/drivers/net/8139too.c~revert-8139too-clean-up-i-o-remapping +++ a/drivers/net/8139too.c @@ -121,15 +121,8 @@ /* enable PIO instead of MMIO, if CONFIG_8139TOO_PIO is selected */ -enum rtl_bar_map_info { - rtl_pio_bar = 0, /* PCI BAR #0: PIO */ - rtl_mmio_bar = 1, /* PCI BAR #1: MMIO */ -}; - #ifdef CONFIG_8139TOO_PIO -static int use_pio = 1; -#else -static int use_pio; +#define USE_IO_OPS 1 #endif /* define to 1, 2 or 3 to enable copious debugging info */ @@ -620,17 +613,14 @@ MODULE_DESCRIPTION ("RealTek RTL-8139 Fa MODULE_LICENSE("GPL"); MODULE_VERSION(DRV_VERSION); -module_param(multicast_filter_limit, int, 0444); +module_param(multicast_filter_limit, int, 0); module_param_array(media, int, NULL, 0); module_param_array(full_duplex, int, NULL, 0); -module_param(debug, int, 0444); -module_param(use_pio, int, 0444); - +module_param(debug, int, 0); +MODULE_PARM_DESC (debug, "8139too bitmapped message enable number"); MODULE_PARM_DESC (multicast_filter_limit, "8139too maximum number of filtered multicast addresses"); MODULE_PARM_DESC (media, "8139too: Bits 4+9: force full duplex, bit 5: 100Mbps"); MODULE_PARM_DESC (full_duplex, "8139too: Force full duplex for board(s) (1)"); -MODULE_PARM_DESC (debug, "8139too bitmapped message enable number"); -MODULE_PARM_DESC (use_pio, "Non-zero to enable PIO (rather than MMIO) register mapping"); static int read_eeprom (void __iomem *ioaddr, int location, int addr_len); static int rtl8139_open (struct net_device *dev); @@ -718,7 +708,13 @@ static void __rtl8139_cleanup_dev (struc assert (tp->pci_dev != NULL); pdev = tp->pci_dev; - pci_iounmap (pdev, tp->mmio_addr); +#ifdef USE_IO_OPS + if (tp->mmio_addr) + ioport_unmap (tp->mmio_addr); +#else + if (tp->mmio_addr) + pci_iounmap (pdev, tp->mmio_addr); +#endif /* USE_IO_OPS */ /* it's ok to call this even if we have no regions to free */ pci_release_regions (pdev); @@ -794,32 +790,32 @@ static int __devinit rtl8139_init_board DPRINTK("PIO region size == 0x%02X\n", pio_len); DPRINTK("MMIO region size == 0x%02lX\n", mmio_len); +#ifdef USE_IO_OPS /* make sure PCI base addr 0 is PIO */ if (!(pio_flags & IORESOURCE_IO)) { dev_err(&pdev->dev, "region #0 not a PIO resource, aborting\n"); rc = -ENODEV; goto err_out; } - /* check for weird/broken PCI region reporting */ if (pio_len < RTL_MIN_IO_SIZE) { dev_err(&pdev->dev, "Invalid PCI I/O region size(s), aborting\n"); rc = -ENODEV; goto err_out; } - +#else /* make sure PCI base addr 1 is MMIO */ if (!(mmio_flags & IORESOURCE_MEM)) { dev_err(&pdev->dev, "region #1 not an MMIO resource, aborting\n"); rc = -ENODEV; goto err_out; } - if (mmio_len < RTL_MIN_IO_SIZE) { dev_err(&pdev->dev, "Invalid PCI mem region size(s), aborting\n"); rc = -ENODEV; goto err_out; } +#endif rc = pci_request_regions (pdev, DRV_NAME); if (rc) @@ -829,16 +825,28 @@ static int __devinit rtl8139_init_board /* enable PCI bus-mastering */ pci_set_master (pdev); - /* iomap MMIO region */ - ioaddr = pci_iomap(pdev, use_pio ? rtl_pio_bar : rtl_mmio_bar, 0); +#ifdef USE_IO_OPS + ioaddr = ioport_map(pio_start, pio_len); + if (!ioaddr) { + dev_err(&pdev->dev, "cannot map PIO, aborting\n"); + rc = -EIO; + goto err_out; + } + dev->base_addr = pio_start; + tp->mmio_addr = ioaddr; + tp->regs_len = pio_len; +#else + /* ioremap MMIO region */ + ioaddr = pci_iomap(pdev, 1, 0); if (ioaddr == NULL) { - dev_err(&pdev->dev, "cannot map I/O regions, aborting\n"); + dev_err(&pdev->dev, "cannot remap MMIO, aborting\n"); rc = -EIO; goto err_out; } dev->base_addr = (long) ioaddr; tp->mmio_addr = ioaddr; tp->regs_len = mmio_len; +#endif /* USE_IO_OPS */ /* Bring old chips out of low-power mode. */ RTL_W8 (HltClk, 'R'); _ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.23-rc2-mm1 2007-08-09 18:37 ` 2.6.23-rc2-mm1 Andrew Morton @ 2007-08-09 19:04 ` Michal Piotrowski 2007-08-09 19:10 ` 2.6.23-rc2-mm1 Andrew Morton 0 siblings, 1 reply; 13+ messages in thread From: Michal Piotrowski @ 2007-08-09 19:04 UTC (permalink / raw) To: Andrew Morton; +Cc: linux-kernel, Netdev, Jeff Garzik On 09/08/07, Andrew Morton <akpm@linux-foundation.org> wrote: > On Thu, 09 Aug 2007 15:23:41 +0200 > Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote: > > > Andrew Morton pisze: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/ > > > > I am experiencing some problems with 8139too > > > > [ 28.847004] 8139too 0000:02:0d.0: region #0 not a PIO resource, aborting > > [ 28.854722] Bad IO access at port 0 () > > [ 28.859459] WARNING: at /home/devel/linux-mm/lib/iomap.c:44 bad_io_access() > > [ 28.867415] [<c040536b>] show_trace_log_lvl+0x1a/0x30 > > [ 28.873568] [<c0405ff3>] show_trace+0x12/0x14 > > [ 28.879015] [<c0406128>] dump_stack+0x16/0x18 > > [ 28.884451] [<c052a904>] bad_io_access+0x58/0x5a > > [ 28.890129] [<c052a927>] pci_iounmap+0x21/0x2b > > [ 28.895635] [<c05b3746>] __rtl8139_cleanup_dev+0x75/0xc6 > > [ 28.902037] [<c05b42c4>] rtl8139_init_one+0x59b/0xa9f > > [ 28.908170] [<c053e344>] pci_device_probe+0x44/0x5f > > [ 28.914116] [<c05a7cd0>] driver_probe_device+0xa7/0x19a > > [ 28.920402] [<c05a7f1a>] __driver_attach+0xa6/0xa8 > > [ 28.926236] [<c05a71d3>] bus_for_each_dev+0x43/0x61 > > [ 28.932139] [<c05a7b51>] driver_attach+0x19/0x1b > > [ 28.937776] [<c05a7504>] bus_add_driver+0x7e/0x1a5 > > [ 28.943567] [<c05a80cf>] driver_register+0x45/0x75 > > [ 28.949358] [<c053e4a5>] __pci_register_driver+0x56/0x84 > > [ 28.955678] [<c0819118>] rtl8139_init_module+0x14/0x1c > > [ 28.961832] [<c0800521>] kernel_init+0x132/0x306 > > [ 28.967451] [<c0404fb3>] kernel_thread_helper+0x7/0x14 > > [ 28.973588] ======================= > > [ 28.978151] initcall 0xc0819104: rtl8139_init_module+0x0/0x1c() returned 0. > > [ 28.986114] initcall 0xc0819104 ran for 161 msecs: rtl8139_init_module+0x0/0x1c() > > > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.23-rc2-mm1/mm-dmesg > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.23-rc2-mm1/mm-config > > > > Please try reverting 8139too-force-media-setting-fix.patch, then > applying this: > > Problem fixed, thanks! Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.23-rc2-mm1 2007-08-09 19:04 ` 2.6.23-rc2-mm1 Michal Piotrowski @ 2007-08-09 19:10 ` Andrew Morton 2007-08-09 19:27 ` 2.6.23-rc2-mm1 Jeff Garzik 0 siblings, 1 reply; 13+ messages in thread From: Andrew Morton @ 2007-08-09 19:10 UTC (permalink / raw) To: Michal Piotrowski; +Cc: linux-kernel, Netdev, Jeff Garzik On Thu, 9 Aug 2007 21:04:35 +0200 "Michal Piotrowski" <michal.k.k.piotrowski@gmail.com> wrote: > On 09/08/07, Andrew Morton <akpm@linux-foundation.org> wrote: > > On Thu, 09 Aug 2007 15:23:41 +0200 > > Michal Piotrowski <michal.k.k.piotrowski@gmail.com> wrote: > > > > > Andrew Morton pisze: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/ > > > > > > I am experiencing some problems with 8139too > > > > > > [ 28.847004] 8139too 0000:02:0d.0: region #0 not a PIO resource, aborting > > > [ 28.854722] Bad IO access at port 0 () > > > [ 28.859459] WARNING: at /home/devel/linux-mm/lib/iomap.c:44 bad_io_access() > > > [ 28.867415] [<c040536b>] show_trace_log_lvl+0x1a/0x30 > > > [ 28.873568] [<c0405ff3>] show_trace+0x12/0x14 > > > [ 28.879015] [<c0406128>] dump_stack+0x16/0x18 > > > [ 28.884451] [<c052a904>] bad_io_access+0x58/0x5a > > > [ 28.890129] [<c052a927>] pci_iounmap+0x21/0x2b > > > [ 28.895635] [<c05b3746>] __rtl8139_cleanup_dev+0x75/0xc6 > > > [ 28.902037] [<c05b42c4>] rtl8139_init_one+0x59b/0xa9f > > > [ 28.908170] [<c053e344>] pci_device_probe+0x44/0x5f > > > [ 28.914116] [<c05a7cd0>] driver_probe_device+0xa7/0x19a > > > [ 28.920402] [<c05a7f1a>] __driver_attach+0xa6/0xa8 > > > [ 28.926236] [<c05a71d3>] bus_for_each_dev+0x43/0x61 > > > [ 28.932139] [<c05a7b51>] driver_attach+0x19/0x1b > > > [ 28.937776] [<c05a7504>] bus_add_driver+0x7e/0x1a5 > > > [ 28.943567] [<c05a80cf>] driver_register+0x45/0x75 > > > [ 28.949358] [<c053e4a5>] __pci_register_driver+0x56/0x84 > > > [ 28.955678] [<c0819118>] rtl8139_init_module+0x14/0x1c > > > [ 28.961832] [<c0800521>] kernel_init+0x132/0x306 > > > [ 28.967451] [<c0404fb3>] kernel_thread_helper+0x7/0x14 > > > [ 28.973588] ======================= > > > [ 28.978151] initcall 0xc0819104: rtl8139_init_module+0x0/0x1c() returned 0. > > > [ 28.986114] initcall 0xc0819104 ran for 161 msecs: rtl8139_init_module+0x0/0x1c() > > > > > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.23-rc2-mm1/mm-dmesg > > > http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.23-rc2-mm1/mm-config > > > > > > > Please try reverting 8139too-force-media-setting-fix.patch, then > > applying this: > > > > > > Problem fixed, thanks! > umm, I was hoping to find out which of those two patches was the cuplrit. Almost surely it was 9ee6b32a47b9abc565466a9c3b127a5246b452e5? ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.23-rc2-mm1 2007-08-09 19:10 ` 2.6.23-rc2-mm1 Andrew Morton @ 2007-08-09 19:27 ` Jeff Garzik 0 siblings, 0 replies; 13+ messages in thread From: Jeff Garzik @ 2007-08-09 19:27 UTC (permalink / raw) To: Andrew Morton; +Cc: Michal Piotrowski, linux-kernel, Netdev Andrew Morton wrote: > umm, I was hoping to find out which of those two patches was the cuplrit. > Almost surely it was 9ee6b32a47b9abc565466a9c3b127a5246b452e5? Highly likely it is my patch in #ALL. Jeff ^ permalink raw reply [flat|nested] 13+ messages in thread
* 2.6.23-rc2-mm1: e1000e global symbols must be renamed [not found] <20070809015106.cd0bfc53.akpm@linux-foundation.org> 2007-08-09 13:23 ` 2.6.23-rc2-mm1 Michal Piotrowski @ 2007-08-09 13:51 ` Adrian Bunk 2007-08-09 17:06 ` Kok, Auke 2007-08-09 23:49 ` 2.6.23-rc2-mm1: rtl8139 inconsistent lock state Mariusz Kozlowski 2 siblings, 1 reply; 13+ messages in thread From: Adrian Bunk @ 2007-08-09 13:51 UTC (permalink / raw) To: Andrew Morton, e1000-devel, jgarzik; +Cc: linux-kernel, netdev On Thu, Aug 09, 2007 at 01:51:06AM -0700, Andrew Morton wrote: >... > - There is a new e1000 driver in git-netdev-all, called e1000e. I'm sure > the developers would like it tested. Please cc netdev@vger.kernel.org on > any reports. >... > Changes since 2.6.23-rc2-mm1: >... > git-netdev-all.patch >... > git trees >... <-- snip --> ... LD drivers/net/built-in.o drivers/net/e1000e/built-in.o: In function `e1000_read_mac_addr': (.text+0x3470): multiple definition of `e1000_read_mac_addr' drivers/net/e1000/built-in.o:(.text+0xb6cc): first defined here drivers/net/e1000e/built-in.o: In function `e1000_set_ethtool_ops': (.text+0x594d): multiple definition of `e1000_set_ethtool_ops' drivers/net/e1000/built-in.o:(.text+0xc97a): first defined here ... make[3]: *** [drivers/net/built-in.o] Error 1 <-- snip --> cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.23-rc2-mm1: e1000e global symbols must be renamed 2007-08-09 13:51 ` 2.6.23-rc2-mm1: e1000e global symbols must be renamed Adrian Bunk @ 2007-08-09 17:06 ` Kok, Auke 0 siblings, 0 replies; 13+ messages in thread From: Kok, Auke @ 2007-08-09 17:06 UTC (permalink / raw) To: Adrian Bunk; +Cc: e1000-devel, netdev, Andrew Morton, jgarzik, linux-kernel Adrian Bunk wrote: > On Thu, Aug 09, 2007 at 01:51:06AM -0700, Andrew Morton wrote: >> ... >> - There is a new e1000 driver in git-netdev-all, called e1000e. I'm sure >> the developers would like it tested. Please cc netdev@vger.kernel.org on >> any reports. >> ... >> Changes since 2.6.23-rc2-mm1: >> ... >> git-netdev-all.patch >> ... >> git trees >> ... > > <-- snip --> > > ... > LD drivers/net/built-in.o > drivers/net/e1000e/built-in.o: In function `e1000_read_mac_addr': > (.text+0x3470): multiple definition of `e1000_read_mac_addr' > drivers/net/e1000/built-in.o:(.text+0xb6cc): first defined here > drivers/net/e1000e/built-in.o: In function `e1000_set_ethtool_ops': > (.text+0x594d): multiple definition of `e1000_set_ethtool_ops' > drivers/net/e1000/built-in.o:(.text+0xc97a): first defined here > ... > make[3]: *** [drivers/net/built-in.o] Error 1 ack, I'll step on that and make it go away :) Auke ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state [not found] <20070809015106.cd0bfc53.akpm@linux-foundation.org> 2007-08-09 13:23 ` 2.6.23-rc2-mm1 Michal Piotrowski 2007-08-09 13:51 ` 2.6.23-rc2-mm1: e1000e global symbols must be renamed Adrian Bunk @ 2007-08-09 23:49 ` Mariusz Kozlowski 2007-08-22 13:35 ` [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling " Jarek Poplawski 2007-08-23 8:44 ` [PATCH (take 2)] " Jarek Poplawski 2 siblings, 2 replies; 13+ messages in thread From: Mariusz Kozlowski @ 2007-08-09 23:49 UTC (permalink / raw) To: Andrew Morton, netdev, Jeff Garzik; +Cc: linux-kernel Hello, ================================= [ INFO: inconsistent lock state ] 2.6.23-rc2-mm1 #7 --------------------------------- inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes: (&tp->lock){+...}, at: [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] {in-hardirq-W} state was registered at: [<c0138eeb>] __lock_acquire+0x949/0x11ac [<c01397e7>] lock_acquire+0x99/0xb2 [<c0452ff3>] _spin_lock+0x35/0x42 [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] [<c0147a5d>] handle_IRQ_event+0x28/0x59 [<c01493ca>] handle_level_irq+0xad/0x10b [<c0105a13>] do_IRQ+0x93/0xd0 [<c010441e>] common_interrupt+0x2e/0x34 [<c0370d2b>] cpuidle_idle_call+0x74/0x99 [<c01023e7>] cpu_idle+0x87/0x89 [<c044fa24>] rest_init+0x60/0x62 [<c05f8ad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff irq event stamp: 1777 hardirqs last enabled at (1777): [<c0169c04>] kfree+0xee/0x105 hardirqs last disabled at (1776): [<c0169b9d>] kfree+0x87/0x105 softirqs last enabled at (1756): [<c03cb7ab>] dev_deactivate+0x86/0xa5 softirqs last disabled at (1754): [<c045300e>] _spin_lock_bh+0xe/0x47 other info that might help us debug this: 1 lock held by ifconfig/5492: #0: (rtnl_mutex){--..}, at: [<c0451778>] mutex_lock+0x1c/0x1f stack backtrace: [<c0104869>] show_trace_log_lvl+0x1a/0x30 [<c01053ad>] show_trace+0x12/0x14 [<c0105515>] dump_stack+0x15/0x17 [<c0136ed9>] print_usage_bug+0x145/0x14f [<c0137ce7>] mark_lock+0x61f/0x70c [<c0138ce0>] __lock_acquire+0x73e/0x11ac [<c01397e7>] lock_acquire+0x99/0xb2 [<c0452ff3>] _spin_lock+0x35/0x42 [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] [<c01480fd>] free_irq+0x11b/0x146 [<de871d59>] rtl8139_close+0x8a/0x14a [8139too] [<c03bde63>] dev_close+0x57/0x74 [<c03bce65>] dev_change_flags+0x8e/0x190 [<c03fd37c>] devinet_ioctl+0x4af/0x652 [<c03fdc62>] inet_ioctl+0x56/0x71 [<c03b1dba>] sock_ioctl+0xa5/0x1d4 [<c0178b42>] do_ioctl+0x22/0x71 [<c0178be6>] vfs_ioctl+0x55/0x29e [<c0178e62>] sys_ioctl+0x33/0x69 [<c01041aa>] sysenter_past_esp+0x5f/0x99 ======================= Regards, Mariusz ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state 2007-08-09 23:49 ` 2.6.23-rc2-mm1: rtl8139 inconsistent lock state Mariusz Kozlowski @ 2007-08-22 13:35 ` Jarek Poplawski 2007-08-25 9:43 ` Mariusz Kozlowski 2007-08-23 8:44 ` [PATCH (take 2)] " Jarek Poplawski 1 sibling, 1 reply; 13+ messages in thread From: Jarek Poplawski @ 2007-08-22 13:35 UTC (permalink / raw) To: Andrew Morton Cc: Mariusz Kozlowski, netdev, Jeff Garzik, David Woodhouse, Ingo Molnar, Thomas Gleixner, linux-kernel On 10-08-2007 01:49, Mariusz Kozlowski wrote: > Hello, > > ================================= > [ INFO: inconsistent lock state ] > 2.6.23-rc2-mm1 #7 > --------------------------------- > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&tp->lock){+...}, at: [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > {in-hardirq-W} state was registered at: > [<c0138eeb>] __lock_acquire+0x949/0x11ac > [<c01397e7>] lock_acquire+0x99/0xb2 > [<c0452ff3>] _spin_lock+0x35/0x42 > [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > [<c0147a5d>] handle_IRQ_event+0x28/0x59 > [<c01493ca>] handle_level_irq+0xad/0x10b > [<c0105a13>] do_IRQ+0x93/0xd0 > [<c010441e>] common_interrupt+0x2e/0x34 ... > other info that might help us debug this: > 1 lock held by ifconfig/5492: > #0: (rtnl_mutex){--..}, at: [<c0451778>] mutex_lock+0x1c/0x1f > > stack backtrace: ... > [<c0452ff3>] _spin_lock+0x35/0x42 > [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > [<c01480fd>] free_irq+0x11b/0x146 > [<de871d59>] rtl8139_close+0x8a/0x14a [8139too] > [<c03bde63>] dev_close+0x57/0x74 ... It looks like this was possible after David's fix, which really enabled running of the handler in free_irq, but before Andrew's patch disabling local irqs for this time. So, this bug should be fixed, but IMHO similar problem is possible in request_irq. And, I think, this is not only about lockdep complaining, but real lockup possibility, because any locks in such a handler are taken in another, not expected for them context, and could be vulnerable (especially with softirqs, but probably hardirqs as well). Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by: Jarek Poplawski <jarkao2@o2.pl> --- diff -Nurp 2.6.23-rc3-mm1-/kernel/irq/manage.c 2.6.23-rc3-mm1/kernel/irq/manage.c --- 2.6.23-rc3-mm1-/kernel/irq/manage.c 2007-08-22 13:58:58.000000000 +0200 +++ 2.6.23-rc3-mm1/kernel/irq/manage.c 2007-08-22 14:12:21.000000000 +0200 @@ -546,14 +546,11 @@ int request_irq(unsigned int irq, irq_ha * We do this before actually registering it, to make sure that * a 'real' IRQ doesn't run in parallel with our fake */ - if (irqflags & IRQF_DISABLED) { - unsigned long flags; + unsigned long flags; - local_irq_save(flags); - handler(irq, dev_id); - local_irq_restore(flags); - } else - handler(irq, dev_id); + local_irq_save(flags); + handler(irq, dev_id); + local_irq_restore(flags); } #endif ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state 2007-08-22 13:35 ` [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling " Jarek Poplawski @ 2007-08-25 9:43 ` Mariusz Kozlowski 2007-08-27 5:54 ` Jarek Poplawski 0 siblings, 1 reply; 13+ messages in thread From: Mariusz Kozlowski @ 2007-08-25 9:43 UTC (permalink / raw) To: Jarek Poplawski Cc: Andrew Morton, netdev, Jeff Garzik, David Woodhouse, Ingo Molnar, Thomas Gleixner, linux-kernel > > ================================= > > [ INFO: inconsistent lock state ] > > 2.6.23-rc2-mm1 #7 > > --------------------------------- > > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. > > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes: > > (&tp->lock){+...}, at: [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > > {in-hardirq-W} state was registered at: > > [<c0138eeb>] __lock_acquire+0x949/0x11ac > > [<c01397e7>] lock_acquire+0x99/0xb2 > > [<c0452ff3>] _spin_lock+0x35/0x42 > > [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > > [<c0147a5d>] handle_IRQ_event+0x28/0x59 > > [<c01493ca>] handle_level_irq+0xad/0x10b > > [<c0105a13>] do_IRQ+0x93/0xd0 > > [<c010441e>] common_interrupt+0x2e/0x34 > ... > > other info that might help us debug this: > > 1 lock held by ifconfig/5492: > > #0: (rtnl_mutex){--..}, at: [<c0451778>] mutex_lock+0x1c/0x1f > > > > stack backtrace: > ... > > [<c0452ff3>] _spin_lock+0x35/0x42 > > [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > > [<c01480fd>] free_irq+0x11b/0x146 > > [<de871d59>] rtl8139_close+0x8a/0x14a [8139too] > > [<c03bde63>] dev_close+0x57/0x74 > ... > > It looks like this was possible after David's fix, which really > enabled running of the handler in free_irq, but before Andrew's patch > disabling local irqs for this time. > > So, this bug should be fixed, but IMHO similar problem is possible in > request_irq. And, I think, this is not only about lockdep complaining, > but real lockup possibility, because any locks in such a handler are > taken in another, not expected for them context, and could be > vulnerable (especially with softirqs, but probably hardirqs as well). > > Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> > Signed-off-by: Jarek Poplawski <jarkao2@o2.pl> > > --- > > diff -Nurp 2.6.23-rc3-mm1-/kernel/irq/manage.c 2.6.23-rc3-mm1/kernel/irq/manage.c > --- 2.6.23-rc3-mm1-/kernel/irq/manage.c 2007-08-22 13:58:58.000000000 +0200 > +++ 2.6.23-rc3-mm1/kernel/irq/manage.c 2007-08-22 14:12:21.000000000 +0200 > @@ -546,14 +546,11 @@ int request_irq(unsigned int irq, irq_ha > * We do this before actually registering it, to make sure that > * a 'real' IRQ doesn't run in parallel with our fake > */ > - if (irqflags & IRQF_DISABLED) { > - unsigned long flags; > + unsigned long flags; > > - local_irq_save(flags); > - handler(irq, dev_id); > - local_irq_restore(flags); > - } else > - handler(irq, dev_id); > + local_irq_save(flags); > + handler(irq, dev_id); > + local_irq_restore(flags); > } > #endif I tested your patch and it still happens. Dmesg info from patched kernel attached. I coulnd't reproduce that on 2.6.23-rc3-mm1 - but on 2.6.23-rc2-mm2 it is easily reproducible. If you need more info, test some patches, etc. - just mail me. Pozdrawiam, Mariusz ========================================================= [ INFO: possible irq lock inversion dependency detected ] 2.6.23-rc2-mm2 #2 --------------------------------------------------------- runscript.sh/5065 just changed the state of lock: (_xmit_ETHER){-+..}, at: [<c03cb659>] dev_watchdog+0x17/0xcc but this lock took another, soft-irq-unsafe lock in the past: (&tp->lock){--..} and interrupts could create inverse lock ordering between them. other info that might help us debug this: 1 lock held by runscript.sh/5065: #0: (&mm->mmap_sem){----}, at: [<c0454569>] do_page_fault+0x159/0x6f0 the first lock's dependencies: -> (_xmit_ETHER){-+..} ops: 21 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c045281a>] _spin_lock_bh+0x3a/0x47 [<c03bc096>] dev_set_rx_mode+0x14/0x3b [<c03bc59f>] dev_change_flags+0x68/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff in-softirq-W at: [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<c03cb659>] dev_watchdog+0x17/0xcc [<c01224b7>] run_timer_softirq+0x14b/0x1a9 [<c011ecc2>] __do_softirq+0x5b/0xb2 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c014b039>] find_lock_page+0x9b/0xa5 [<c014d680>] filemap_fault+0x188/0x4d9 [<c015760d>] __do_fault+0xb7/0x444 [<c0159164>] handle_mm_fault+0x18a/0x6fc [<c0454864>] do_page_fault+0x454/0x6f0 [<c0453102>] error_code+0x6a/0x70 [<ffffffff>] 0xffffffff hardirq-on-W at: [<c01393d0>] __lock_acquire+0x73e/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c045281a>] _spin_lock_bh+0x3a/0x47 [<c03bc096>] dev_set_rx_mode+0x14/0x3b [<c03bc59f>] dev_change_flags+0x68/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff } ... key at: [<c087e9e8>] netdev_xmit_lock_key+0x8/0x1c0 -> (&tp->lock){--..} ops: 44 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<de8706e2>] rtl8139_interrupt+0x27/0x469 [8139too] [<c0148bae>] request_irq+0xd6/0xf8 [<de87152d>] rtl8139_open+0x2f/0x1e2 [8139too] [<c03be7fd>] dev_open+0x37/0x76 [<c03bc5c5>] dev_change_flags+0x8e/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff softirq-on-W at: [<c01393f9>] __lock_acquire+0x767/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<de8706e2>] rtl8139_interrupt+0x27/0x469 [8139too] [<c01487ed>] free_irq+0x11b/0x146 [<de871c90>] rtl8139_close+0x8a/0x14a [8139too] [<c03bd5c3>] dev_close+0x57/0x74 [<c03bc5c5>] dev_change_flags+0x8e/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff hardirq-on-W at: [<c01393d0>] __lock_acquire+0x73e/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<de8706e2>] rtl8139_interrupt+0x27/0x469 [8139too] [<c01487ed>] free_irq+0x11b/0x146 [<de871c90>] rtl8139_close+0x8a/0x14a [8139too] [<c03bd5c3>] dev_close+0x57/0x74 [<c03bc5c5>] dev_change_flags+0x8e/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff } ... key at: [<de875190>] __key.19796+0x0/0xffffd3c9 [8139too] ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<de870275>] rtl8139_set_rx_mode+0x1e/0x166 [8139too] [<c03bbe62>] __dev_set_rx_mode+0x24/0x85 [<c03bc0a8>] dev_set_rx_mode+0x26/0x3b [<c03be820>] dev_open+0x5a/0x76 [<c03bc5c5>] dev_change_flags+0x8e/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff -> (&priv->lock){++..} ops: 103 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04529bc>] _spin_lock_irq+0x3b/0x48 [<ded03256>] orinoco_init+0x8f5/0xbbd [orinoco] [<c03bdbce>] register_netdevice+0x13a/0x3f8 [<c03bdebe>] register_netdev+0x32/0x3f [<ded2c4bb>] orinoco_cs_probe+0x368/0x3df [orinoco_cs] [<ded378d9>] pcmcia_device_probe+0xc9/0x14c [pcmcia] [<c02f323f>] driver_probe_device+0xa6/0x198 [<c02f3482>] __driver_attach+0xa2/0xa4 [<c02f270a>] bus_for_each_dev+0x43/0x61 [<c02f30c1>] driver_attach+0x19/0x1b [<c02f2a79>] bus_add_driver+0x7e/0x1a5 [<c02f362f>] driver_register+0x45/0x75 [<ded38560>] pcmcia_register_driver+0xdb/0x12f [pcmcia] [<de87c024>] 0xde87c024 [<c0140a47>] sys_init_module+0xc4/0x1622 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff in-hardirq-W at: [<c01395db>] __lock_acquire+0x949/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<ded03bb4>] orinoco_interrupt+0x3f/0x1219 [orinoco] [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<ded06a99>] orinoco_get_wireless_stats+0xeb/0x140 [orinoco] [<c042b2aa>] get_wireless_stats+0x1a/0x21 [<c042bf59>] wireless_seq_show+0x20/0x143 [<c0187347>] seq_read+0x1af/0x2b8 [<c01a1ec2>] proc_reg_read+0x57/0x78 [<c016d771>] vfs_read+0xaa/0x147 [<c016db96>] sys_read+0x3d/0x7b [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff in-softirq-W at: [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<ded03bb4>] orinoco_interrupt+0x3f/0x1219 [orinoco] [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<ded06a99>] orinoco_get_wireless_stats+0xeb/0x140 [orinoco] [<c042b2aa>] get_wireless_stats+0x1a/0x21 [<c042bf59>] wireless_seq_show+0x20/0x143 [<c0187347>] seq_read+0x1af/0x2b8 [<c01a1ec2>] proc_reg_read+0x57/0x78 [<c016d771>] vfs_read+0xaa/0x147 [<c016db96>] sys_read+0x3d/0x7b [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff } ... key at: [<ded0a298>] __key.20430+0x0/0xffffc9cd [orinoco] -> (lweventlist_lock){+...} ops: 8 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c03c78cb>] linkwatch_add_event+0x10/0x31 [<c03c79aa>] linkwatch_fire_event+0x35/0x37 [<c03cb35a>] netif_carrier_off+0x19/0x20 [<ded023b5>] alloc_orinocodev+0x181/0x19c [orinoco] [<ded2c170>] orinoco_cs_probe+0x1d/0x3df [orinoco_cs] [<ded378d9>] pcmcia_device_probe+0xc9/0x14c [pcmcia] [<c02f323f>] driver_probe_device+0xa6/0x198 [<c02f3482>] __driver_attach+0xa2/0xa4 [<c02f270a>] bus_for_each_dev+0x43/0x61 [<c02f30c1>] driver_attach+0x19/0x1b [<c02f2a79>] bus_add_driver+0x7e/0x1a5 [<c02f362f>] driver_register+0x45/0x75 [<ded38560>] pcmcia_register_driver+0xdb/0x12f [pcmcia] [<de87c024>] 0xde87c024 [<c0140a47>] sys_init_module+0xc4/0x1622 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff in-hardirq-W at: [<c01395db>] __lock_acquire+0x949/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c03c78cb>] linkwatch_add_event+0x10/0x31 [<c03c79aa>] linkwatch_fire_event+0x35/0x37 [<c03cb38a>] netif_carrier_on+0x29/0x2b [<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco] [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c03706bb>] cpuidle_idle_call+0x74/0x99 [<c01025e4>] cpu_idle+0x87/0x89 [<c044f204>] rest_init+0x60/0x62 [<c05fcad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff } ... key at: [<c05e4990>] lweventlist_lock+0x10/0x20 ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c03c78cb>] linkwatch_add_event+0x10/0x31 [<c03c79aa>] linkwatch_fire_event+0x35/0x37 [<c03cb38a>] netif_carrier_on+0x29/0x2b [<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco] [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c03706bb>] cpuidle_idle_call+0x74/0x99 [<c01025e4>] cpu_idle+0x87/0x89 [<c044f204>] rest_init+0x60/0x62 [<c05fcad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff -> (&cwq->lock){++..} ops: 4755 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c0129002>] __queue_work+0xf/0x2d [<c012909f>] queue_work+0x57/0x90 [<c0128714>] call_usermodehelper_exec+0xce/0xe1 [<c0265375>] kobject_uevent_env+0x34d/0x449 [<c026547b>] kobject_uevent+0xa/0xf [<c0264b59>] kset_register+0x32/0x38 [<c0264b67>] subsystem_register+0x8/0xa [<c02f2c8a>] bus_register+0x65/0x1f3 [<c0611db6>] platform_bus_init+0x23/0x38 [<c0611e0c>] driver_init+0x1c/0x31 [<c05fc68d>] kernel_init+0x5d/0x26b [<c010454b>] kernel_thread_helper+0x7/0x1c [<ffffffff>] 0xffffffff in-hardirq-W at: [<c01395db>] __lock_acquire+0x949/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c0129002>] __queue_work+0xf/0x2d [<c012909f>] queue_work+0x57/0x90 [<c029238a>] acpi_os_execute+0xae/0xcb [<c02aa216>] acpi_ec_gpe_handler+0x4d/0x5e [<c0297f41>] acpi_ev_gpe_dispatch+0x4b/0x115 [<c0298243>] acpi_ev_gpe_detect+0x9a/0xe1 [<c0296979>] acpi_ev_sci_xrupt_handler+0x15/0x1d [<c0291a9e>] acpi_irq+0xe/0x18 [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c01025e4>] cpu_idle+0x87/0x89 [<c044f204>] rest_init+0x60/0x62 [<c05fcad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff in-softirq-W at: [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c0129002>] __queue_work+0xf/0x2d [<c0129044>] delayed_work_timer_fn+0x24/0x28 [<c01224b7>] run_timer_softirq+0x14b/0x1a9 [<c011ecc2>] __do_softirq+0x5b/0xb2 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c0452cac>] _spin_unlock+0x16/0x4d [<c02638ce>] _atomic_dec_and_lock+0x2e/0x50 [<c017e962>] dput+0x36/0x101 [<c0176080>] __link_path_walk+0x8de/0xe06 [<c0176603>] link_path_walk+0x5b/0xe0 [<c01766a0>] path_walk+0x18/0x1a [<c01768b2>] do_path_lookup+0x8f/0x21c [<c017757a>] __path_lookup_intent_open+0x44/0x99 [<c0177658>] path_lookup_open+0x21/0x27 [<c0171056>] open_exec+0x27/0xac [<c0172776>] do_execve+0x34/0x181 [<c0102752>] sys_execve+0x48/0x98 [<c0104256>] syscall_call+0x7/0xb [<ffffffff>] 0xffffffff } ... key at: [<c0657ae8>] __key.11148+0x0/0x8 -> (&q->lock){++..} ops: 69175 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04529bc>] _spin_lock_irq+0x3b/0x48 [<c044fce5>] wait_for_completion+0x24/0xb5 [<c012c1d1>] kthread_create+0x69/0xa8 [<c0606fcc>] cpu_callback+0x48/0xa3 [<c0607043>] spawn_ksoftirqd+0x1c/0x4e [<c05fc66c>] kernel_init+0x3c/0x26b [<c010454b>] kernel_thread_helper+0x7/0x1c [<ffffffff>] 0xffffffff in-hardirq-W at: [<c01395db>] __lock_acquire+0x949/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c0113d3b>] __wake_up+0x15/0x42 [<c02aa1ef>] acpi_ec_gpe_handler+0x26/0x5e [<c0297f41>] acpi_ev_gpe_dispatch+0x4b/0x115 [<c0298243>] acpi_ev_gpe_detect+0x9a/0xe1 [<c0296979>] acpi_ev_sci_xrupt_handler+0x15/0x1d [<c0291a9e>] acpi_irq+0xe/0x18 [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c01025e4>] cpu_idle+0x87/0x89 [<c044f204>] rest_init+0x60/0x62 [<c05fcad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff in-softirq-W at: [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c0113c7c>] complete+0x15/0x4b [<c0129ebe>] wakeme_after_rcu+0xb/0xd [<c012a013>] __rcu_process_callbacks+0x69/0x1cf [<c012a18b>] rcu_process_callbacks+0x12/0x23 [<c011eda3>] tasklet_action+0x3b/0x7b [<c011ecc2>] __do_softirq+0x5b/0xb2 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c01025e4>] cpu_idle+0x87/0x89 [<c044f204>] rest_init+0x60/0x62 [<c05fcad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff } ... key at: [<c0657f30>] __key.11466+0x0/0x8 -> (&rq->rq_lock_key){++..} ops: 212030 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c060664a>] init_idle+0x40/0x6d [<c06067e0>] sched_init+0x169/0x17c [<c05fc970>] start_kernel+0xd5/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff in-hardirq-W at: [<c01395db>] __lock_acquire+0x949/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<c01157f3>] scheduler_tick+0x20/0x192 [<c0122c31>] update_process_times+0x43/0x62 [<c0134325>] tick_periodic+0x24/0x75 [<c013438e>] tick_handle_periodic+0x18/0x7a [<c01064ae>] timer_interrupt+0xe/0x15 [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c014890a>] setup_irq+0xf2/0x20d [<c060656f>] time_init_hook+0x19/0x1b [<c05ffcc8>] hpet_time_init+0xd/0x15 [<c05fca70>] start_kernel+0x1d5/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff in-softirq-W at: [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<c01157f3>] scheduler_tick+0x20/0x192 [<c0122c31>] update_process_times+0x43/0x62 [<c0134325>] tick_periodic+0x24/0x75 [<c013438e>] tick_handle_periodic+0x18/0x7a [<c01064ae>] timer_interrupt+0xe/0x15 [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c029cf88>] acpi_ex_system_io_space_handler+0x3f/0x45 [<c0296612>] acpi_ev_address_space_dispatch+0x12f/0x170 [<c029a374>] acpi_ex_access_region+0x1a7/0x1b9 [<c029a497>] acpi_ex_field_datum_io+0x111/0x198 [<c029a812>] acpi_ex_write_with_update_rule+0xf7/0x100 [<c029aa97>] acpi_ex_insert_into_field+0x27c/0x289 [<c02991cc>] acpi_ex_write_data_to_field+0x207/0x21f [<c029d1f8>] acpi_ex_store_object_to_node+0x70/0xa5 [<c029d387>] acpi_ex_store+0xd5/0x216 [<c029b2e6>] acpi_ex_opcode_1A_1T_1R+0x3a8/0x504 [<c0293f74>] acpi_ds_exec_end_op+0xc1/0x3bd [<c02a2238>] acpi_ps_parse_loop+0x539/0x6d9 [<c02a16fa>] acpi_ps_parse_aml+0x68/0x235 [<c02a291c>] acpi_ps_execute_method+0x111/0x1b5 [<c029fd5b>] acpi_ns_evaluate+0x93/0xe8 [<c02a509c>] acpi_ut_evaluate_object+0x55/0x15f [<c02a521f>] acpi_ut_execute_STA+0x1d/0x49 [<c029f7e7>] acpi_ns_get_device_callback+0x5a/0x11c [<c02a0e74>] acpi_ns_walk_namespace+0xf0/0x10c [<c029f711>] acpi_get_devices+0x47/0x5d [<c06100a6>] pnpacpi_init+0x5e/0x8b [<c05fc6c7>] kernel_init+0x97/0x26b [<c010454b>] kernel_thread_helper+0x7/0x1c [<ffffffff>] 0xffffffff } ... key at: [<c0635d28>] per_cpu__runqueues+0x468/0x470 ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<c0114ec2>] task_rq_lock+0x28/0x40 [<c011504c>] try_to_wake_up+0x18/0x92 [<c01150d1>] default_wake_function+0xb/0xd [<c011284b>] __wake_up_common+0x39/0x59 [<c0113ca1>] complete+0x3a/0x4b [<c012c037>] kthread+0x1f/0x58 [<c010454b>] kernel_thread_helper+0x7/0x1c [<ffffffff>] 0xffffffff ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c0113d3b>] __wake_up+0x15/0x42 [<c0128c6b>] insert_work+0x60/0x75 [<c0129012>] __queue_work+0x1f/0x2d [<c012909f>] queue_work+0x57/0x90 [<c0128714>] call_usermodehelper_exec+0xce/0xe1 [<c0265375>] kobject_uevent_env+0x34d/0x449 [<c026547b>] kobject_uevent+0xa/0xf [<c0264b59>] kset_register+0x32/0x38 [<c0264b67>] subsystem_register+0x8/0xa [<c02f2c8a>] bus_register+0x65/0x1f3 [<c0611db6>] platform_bus_init+0x23/0x38 [<c0611e0c>] driver_init+0x1c/0x31 [<c05fc68d>] kernel_init+0x5d/0x26b [<c010454b>] kernel_thread_helper+0x7/0x1c [<ffffffff>] 0xffffffff ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c0129002>] __queue_work+0xf/0x2d [<c012909f>] queue_work+0x57/0x90 [<c01294af>] queue_delayed_work+0x27/0x48 [<c01294f2>] schedule_delayed_work+0x22/0x26 [<c03c792c>] linkwatch_schedule_work+0x40/0x89 [<c03c7999>] linkwatch_fire_event+0x24/0x37 [<c03cb38a>] netif_carrier_on+0x29/0x2b [<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco] [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c03706bb>] cpuidle_idle_call+0x74/0x99 [<c01025e4>] cpu_idle+0x87/0x89 [<c044f204>] rest_init+0x60/0x62 [<c05fcad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff -> (base_lock_keys + cpu){++..} ops: 85554 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c01229f6>] lock_timer_base+0x41/0x66 [<c0122ab8>] __mod_timer+0x3b/0xc5 [<c0122bea>] mod_timer+0x47/0x4b [<c0611091>] con_init+0x24b/0x27e [<c061075a>] console_init+0x20/0x2e [<c05fca30>] start_kernel+0x195/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff in-hardirq-W at: [<c01395db>] __lock_acquire+0x949/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c01229f6>] lock_timer_base+0x41/0x66 [<c0122a47>] del_timer+0x2c/0x62 [<c0302a7b>] ide_intr+0x72/0x1f0 [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c01025e4>] cpu_idle+0x87/0x89 [<c044f204>] rest_init+0x60/0x62 [<c05fcad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff in-softirq-W at: [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04529bc>] _spin_lock_irq+0x3b/0x48 [<c0122395>] run_timer_softirq+0x29/0x1a9 [<c011ecc2>] __do_softirq+0x5b/0xb2 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c014890a>] setup_irq+0xf2/0x20d [<c060656f>] time_init_hook+0x19/0x1b [<c05ffcc8>] hpet_time_init+0xd/0x15 [<c05fca70>] start_kernel+0x1d5/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff } ... key at: [<c0657a96>] base_lock_keys+0x0/0xa ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c01229f6>] lock_timer_base+0x41/0x66 [<c0122ab8>] __mod_timer+0x3b/0xc5 [<c0122bea>] mod_timer+0x47/0x4b [<c03cae57>] __netdev_watchdog_up+0x37/0x50 [<c03cb380>] netif_carrier_on+0x1f/0x2b [<ded04bdc>] orinoco_interrupt+0x1067/0x1219 [orinoco] [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c03706bb>] cpuidle_idle_call+0x74/0x99 [<c01025e4>] cpu_idle+0x87/0x89 [<c044f204>] rest_init+0x60/0x62 [<c05fcad5>] start_kernel+0x23a/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff -> (&list->lock#2){.+..} ops: 12 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c03b70ab>] skb_queue_tail+0x14/0x33 [<c042b66b>] wireless_send_event+0x348/0x369 [<c042b9a9>] ioctl_standard_call+0x1b2/0x34d [<c042be9e>] wext_handle_ioctl+0x35a/0x3e4 [<c03be755>] dev_ioctl+0x31e/0x325 [<c03b152c>] sock_ioctl+0xb7/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff in-softirq-W at: [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c03b715c>] skb_dequeue+0x12/0x50 [<c042b31d>] wireless_nlevent_process+0x2d/0x33 [<c011eda3>] tasklet_action+0x3b/0x7b [<c011ecc2>] __do_softirq+0x5b/0xb2 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<ded028e3>] orinoco_ioctl_commit+0x8e/0x10c [orinoco] [<c042b2e0>] call_commit_handler+0x2f/0x3f [<c042b9c2>] ioctl_standard_call+0x1cb/0x34d [<c042be9e>] wext_handle_ioctl+0x35a/0x3e4 [<c03be755>] dev_ioctl+0x31e/0x325 [<c03b152c>] sock_ioctl+0xb7/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff } ... key at: [<c0884a80>] __key.13323+0x0/0x20 ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c03b70ab>] skb_queue_tail+0x14/0x33 [<c042b66b>] wireless_send_event+0x348/0x369 [<ded03b69>] orinoco_send_wevents+0x9a/0xa6 [orinoco] [<c0128b28>] run_workqueue+0x110/0x1f3 [<c0129648>] worker_thread+0x9a/0xf2 [<c012c04e>] kthread+0x36/0x58 [<c010454b>] kernel_thread_helper+0x7/0x1c [<ffffffff>] 0xffffffff -> (&rq->rq_lock_key){++..} ops: 212030 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<c060664a>] init_idle+0x40/0x6d [<c06067e0>] sched_init+0x169/0x17c [<c05fc970>] start_kernel+0xd5/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff in-hardirq-W at: [<c01395db>] __lock_acquire+0x949/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<c01157f3>] scheduler_tick+0x20/0x192 [<c0122c31>] update_process_times+0x43/0x62 [<c0134325>] tick_periodic+0x24/0x75 [<c013438e>] tick_handle_periodic+0x18/0x7a [<c01064ae>] timer_interrupt+0xe/0x15 [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c014890a>] setup_irq+0xf2/0x20d [<c060656f>] time_init_hook+0x19/0x1b [<c05ffcc8>] hpet_time_init+0xd/0x15 [<c05fca70>] start_kernel+0x1d5/0x2c5 [<00000000>] 0x0 [<ffffffff>] 0xffffffff in-softirq-W at: [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<c01157f3>] scheduler_tick+0x20/0x192 [<c0122c31>] update_process_times+0x43/0x62 [<c0134325>] tick_periodic+0x24/0x75 [<c013438e>] tick_handle_periodic+0x18/0x7a [<c01064ae>] timer_interrupt+0xe/0x15 [<c014814d>] handle_IRQ_event+0x28/0x59 [<c0149a0a>] handle_level_irq+0xad/0x10b [<c01058f3>] do_IRQ+0x93/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c029cf88>] acpi_ex_system_io_space_handler+0x3f/0x45 [<c0296612>] acpi_ev_address_space_dispatch+0x12f/0x170 [<c029a374>] acpi_ex_access_region+0x1a7/0x1b9 [<c029a497>] acpi_ex_field_datum_io+0x111/0x198 [<c029a812>] acpi_ex_write_with_update_rule+0xf7/0x100 [<c029aa97>] acpi_ex_insert_into_field+0x27c/0x289 [<c02991cc>] acpi_ex_write_data_to_field+0x207/0x21f [<c029d1f8>] acpi_ex_store_object_to_node+0x70/0xa5 [<c029d387>] acpi_ex_store+0xd5/0x216 [<c029b2e6>] acpi_ex_opcode_1A_1T_1R+0x3a8/0x504 [<c0293f74>] acpi_ds_exec_end_op+0xc1/0x3bd [<c02a2238>] acpi_ps_parse_loop+0x539/0x6d9 [<c02a16fa>] acpi_ps_parse_aml+0x68/0x235 [<c02a291c>] acpi_ps_execute_method+0x111/0x1b5 [<c029fd5b>] acpi_ns_evaluate+0x93/0xe8 [<c02a509c>] acpi_ut_evaluate_object+0x55/0x15f [<c02a521f>] acpi_ut_execute_STA+0x1d/0x49 [<c029f7e7>] acpi_ns_get_device_callback+0x5a/0x11c [<c02a0e74>] acpi_ns_walk_namespace+0xf0/0x10c [<c029f711>] acpi_get_devices+0x47/0x5d [<c06100a6>] pnpacpi_init+0x5e/0x8b [<c05fc6c7>] kernel_init+0x97/0x26b [<c010454b>] kernel_thread_helper+0x7/0x1c [<ffffffff>] 0xffffffff } ... key at: [<c0635d28>] per_cpu__runqueues+0x468/0x470 ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<c0114ec2>] task_rq_lock+0x28/0x40 [<c011504c>] try_to_wake_up+0x18/0x92 [<c01150ee>] wake_up_process+0xf/0x11 [<c011f5cc>] __tasklet_schedule+0x6d/0x6f [<c042b687>] wireless_send_event+0x364/0x369 [<ded03b69>] orinoco_send_wevents+0x9a/0xa6 [orinoco] [<c0128b28>] run_workqueue+0x110/0x1f3 [<c0129648>] worker_thread+0x9a/0xf2 [<c012c04e>] kthread+0x36/0x58 [<c010454b>] kernel_thread_helper+0x7/0x1c [<ffffffff>] 0xffffffff ... acquired at: [<c0139d2d>] __lock_acquire+0x109b/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c0452a4f>] _spin_lock_irqsave+0x3e/0x4e [<ded03598>] orinoco_set_multicast_list+0x1b/0x5f [orinoco] [<c03bbe62>] __dev_set_rx_mode+0x24/0x85 [<c03bc0a8>] dev_set_rx_mode+0x26/0x3b [<c03be820>] dev_open+0x5a/0x76 [<c03bc5c5>] dev_change_flags+0x8e/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff the second lock's dependencies: -> (&tp->lock){--..} ops: 44 { initial-use at: [<c0138ea9>] __lock_acquire+0x217/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<de8706e2>] rtl8139_interrupt+0x27/0x469 [8139too] [<c0148bae>] request_irq+0xd6/0xf8 [<de87152d>] rtl8139_open+0x2f/0x1e2 [8139too] [<c03be7fd>] dev_open+0x37/0x76 [<c03bc5c5>] dev_change_flags+0x8e/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff softirq-on-W at: [<c01393f9>] __lock_acquire+0x767/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<de8706e2>] rtl8139_interrupt+0x27/0x469 [8139too] [<c01487ed>] free_irq+0x11b/0x146 [<de871c90>] rtl8139_close+0x8a/0x14a [8139too] [<c03bd5c3>] dev_close+0x57/0x74 [<c03bc5c5>] dev_change_flags+0x8e/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff hardirq-on-W at: [<c01393d0>] __lock_acquire+0x73e/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<de8706e2>] rtl8139_interrupt+0x27/0x469 [8139too] [<c01487ed>] free_irq+0x11b/0x146 [<de871c90>] rtl8139_close+0x8a/0x14a [8139too] [<c03bd5c3>] dev_close+0x57/0x74 [<c03bc5c5>] dev_change_flags+0x8e/0x190 [<c03fcb4c>] devinet_ioctl+0x4af/0x652 [<c03fd432>] inet_ioctl+0x56/0x71 [<c03b151a>] sock_ioctl+0xa5/0x1d4 [<c0178a42>] do_ioctl+0x22/0x71 [<c0178ae6>] vfs_ioctl+0x55/0x29e [<c0178d62>] sys_ioctl+0x33/0x69 [<c01041da>] sysenter_past_esp+0x5f/0x99 [<ffffffff>] 0xffffffff } ... key at: [<de875190>] __key.19796+0x0/0xffffd3c9 [8139too] stack backtrace: [<c0104899>] show_trace_log_lvl+0x1a/0x30 [<c0105296>] show_trace+0x12/0x14 [<c01053fe>] dump_stack+0x15/0x17 [<c0137462>] print_irq_inversion_bug+0x101/0x123 [<c0137db1>] check_usage_forwards+0x3e/0x45 [<c0137f67>] mark_lock+0x1af/0x70c [<c0139384>] __lock_acquire+0x6f2/0x11ac [<c0139ed7>] lock_acquire+0x99/0xb2 [<c04527d3>] _spin_lock+0x35/0x42 [<c03cb659>] dev_watchdog+0x17/0xcc [<c01224b7>] run_timer_softirq+0x14b/0x1a9 [<c011ecc2>] __do_softirq+0x5b/0xb2 [<c011ed66>] do_softirq+0x4d/0x4f [<c011f04b>] irq_exit+0x48/0x4a [<c01058f8>] do_IRQ+0x98/0xd0 [<c010444e>] common_interrupt+0x2e/0x34 [<c014b039>] find_lock_page+0x9b/0xa5 [<c014d680>] filemap_fault+0x188/0x4d9 [<c015760d>] __do_fault+0xb7/0x444 [<c0159164>] handle_mm_fault+0x18a/0x6fc [<c0454864>] do_page_fault+0x454/0x6f0 [<c0453102>] error_code+0x6a/0x70 ======================= Clocksource tsc unstable (delta = 9373021754 ns) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state 2007-08-25 9:43 ` Mariusz Kozlowski @ 2007-08-27 5:54 ` Jarek Poplawski 0 siblings, 0 replies; 13+ messages in thread From: Jarek Poplawski @ 2007-08-27 5:54 UTC (permalink / raw) To: Mariusz Kozlowski Cc: Andrew Morton, netdev, Jeff Garzik, David Woodhouse, Ingo Molnar, Thomas Gleixner, linux-kernel On Sat, Aug 25, 2007 at 11:43:08AM +0200, Mariusz Kozlowski wrote: > > > ================================= > > > [ INFO: inconsistent lock state ] > > > 2.6.23-rc2-mm1 #7 > > > --------------------------------- > > > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. > > > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes: > > > (&tp->lock){+...}, at: [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] ... > I tested your patch and it still happens. Dmesg info from patched kernel attached. > I coulnd't reproduce that on 2.6.23-rc3-mm1 - but on 2.6.23-rc2-mm2 it is easily > reproducible. > > If you need more info, test some patches, etc. - just mail me. > ... > ========================================================= > [ INFO: possible irq lock inversion dependency detected ] > 2.6.23-rc2-mm2 #2 > --------------------------------------------------------- > runscript.sh/5065 just changed the state of lock: > (_xmit_ETHER){-+..}, at: [<c03cb659>] dev_watchdog+0x17/0xcc > but this lock took another, soft-irq-unsafe lock in the past: > (&tp->lock){--..} > > and interrupts could create inverse lock ordering between them. It's OK! These're 2 different warnings. As a matter of fact, my patch wasn't supposed to fix any of them, but something similar to the first one, which was possible, but for some reason wasn't reported by lockdep. The first warning was fixed by Andrew Morton's patch to free_irq(), so it shouldn't happen in -rc3-mm. The second warning could have been fixed too, I don't know, but since it's quite long, I would prefer to think about it only if it still happens in current -mm's. Thanks, Jarek P. ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH (take 2)] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state 2007-08-09 23:49 ` 2.6.23-rc2-mm1: rtl8139 inconsistent lock state Mariusz Kozlowski 2007-08-22 13:35 ` [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling " Jarek Poplawski @ 2007-08-23 8:44 ` Jarek Poplawski 2007-08-24 5:46 ` Jarek Poplawski 1 sibling, 1 reply; 13+ messages in thread From: Jarek Poplawski @ 2007-08-23 8:44 UTC (permalink / raw) To: Andrew Morton Cc: Mariusz Kozlowski, netdev, Jeff Garzik, David Woodhouse, Ingo Molnar, Thomas Gleixner, linux-kernel Andrew Morton pointed out that my changelog was unusable. Sorry! Here is a second try with the changelog and kernel version changed. Regards, Jarek P. ------------>(take 2) Subject: request_irq() - fix DEBUG_SHIRQ handling Mariusz Kozlowski reported lockdep's warning: > ================================= > [ INFO: inconsistent lock state ] > 2.6.23-rc2-mm1 #7 > --------------------------------- > inconsistent {in-hardirq-W} -> {hardirq-on-W} usage. > ifconfig/5492 [HC0[0]:SC0[0]:HE1:SE1] takes: > (&tp->lock){+...}, at: [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > {in-hardirq-W} state was registered at: > [<c0138eeb>] __lock_acquire+0x949/0x11ac > [<c01397e7>] lock_acquire+0x99/0xb2 > [<c0452ff3>] _spin_lock+0x35/0x42 > [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > [<c0147a5d>] handle_IRQ_event+0x28/0x59 > [<c01493ca>] handle_level_irq+0xad/0x10b > [<c0105a13>] do_IRQ+0x93/0xd0 > [<c010441e>] common_interrupt+0x2e/0x34 ... > other info that might help us debug this: > 1 lock held by ifconfig/5492: > #0: (rtnl_mutex){--..}, at: [<c0451778>] mutex_lock+0x1c/0x1f > > stack backtrace: ... > [<c0452ff3>] _spin_lock+0x35/0x42 > [<de8706e0>] rtl8139_interrupt+0x27/0x46b [8139too] > [<c01480fd>] free_irq+0x11b/0x146 > [<de871d59>] rtl8139_close+0x8a/0x14a [8139too] > [<c03bde63>] dev_close+0x57/0x74 ... This shows that a driver's irq handler was running both in hard interrupt and process contexts with irqs enabled. The latter was done during free_irq() call and was possible only with CONFIG_DEBUG_SHIRQ enabled. This was fixed by another patch. But similar problem is possible with request_irq(): any locks taken from irq handler could be vulnerable - especially with soft interrupts. This patch fixes it by disabling local interrupts during handler's run. (It seems, disabling softirqs should be enough, but it needs more checking on possible races or other special cases). This patch is recommended to all stable versions since 2.6.21, too. Reported-by: Mariusz Kozlowski <m.kozlowski@tuxland.pl> Signed-off-by: Jarek Poplawski <jarkao2@o2.pl> --- diff -Nurp 2.6.23-rc3-git6-/kernel/irq/manage.c 2.6.23-rc3-git6/kernel/irq/manage.c --- 2.6.23-rc3-git6-/kernel/irq/manage.c 2007-08-23 10:11:35.000000000 +0200 +++ 2.6.23-rc3-git6/kernel/irq/manage.c 2007-08-23 10:16:29.000000000 +0200 @@ -555,14 +555,11 @@ int request_irq(unsigned int irq, irq_ha * We do this before actually registering it, to make sure that * a 'real' IRQ doesn't run in parallel with our fake */ - if (irqflags & IRQF_DISABLED) { - unsigned long flags; + unsigned long flags; - local_irq_save(flags); - handler(irq, dev_id); - local_irq_restore(flags); - } else - handler(irq, dev_id); + local_irq_save(flags); + handler(irq, dev_id); + local_irq_restore(flags); } #endif ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH (take 2)] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state 2007-08-23 8:44 ` [PATCH (take 2)] " Jarek Poplawski @ 2007-08-24 5:46 ` Jarek Poplawski 0 siblings, 0 replies; 13+ messages in thread From: Jarek Poplawski @ 2007-08-24 5:46 UTC (permalink / raw) To: Andrew Morton Cc: Mariusz Kozlowski, netdev, Jeff Garzik, David Woodhouse, Ingo Molnar, Thomas Gleixner, linux-kernel On Thu, Aug 23, 2007 at 10:44:30AM +0200, Jarek Poplawski wrote: > Andrew Morton pointed out that my changelog was unusable. Sorry! > Here is a second try with the changelog and kernel version changed. ... > ------------>(take 2) > > Subject: request_irq() - fix DEBUG_SHIRQ handling ... > Signed-off-by: Jarek Poplawski <jarkao2@o2.pl> > > --- > > diff -Nurp 2.6.23-rc3-git6-/kernel/irq/manage.c 2.6.23-rc3-git6/kernel/irq/manage.c > --- 2.6.23-rc3-git6-/kernel/irq/manage.c 2007-08-23 10:11:35.000000000 +0200 > +++ 2.6.23-rc3-git6/kernel/irq/manage.c 2007-08-23 10:16:29.000000000 +0200 So, this time I f-ed the diff part: it's not exactly against 2.6.23-rc-git6. But, it's Andrew to blame: he should've known that some old & slow chips can't do science and poetry at the same time. Sorry (for him)! Anyway, beside an offset, should be OK... Regards, Jarek P. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2007-08-27 5:53 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20070809015106.cd0bfc53.akpm@linux-foundation.org>
2007-08-09 13:23 ` 2.6.23-rc2-mm1 Michal Piotrowski
2007-08-09 18:37 ` 2.6.23-rc2-mm1 Andrew Morton
2007-08-09 19:04 ` 2.6.23-rc2-mm1 Michal Piotrowski
2007-08-09 19:10 ` 2.6.23-rc2-mm1 Andrew Morton
2007-08-09 19:27 ` 2.6.23-rc2-mm1 Jeff Garzik
2007-08-09 13:51 ` 2.6.23-rc2-mm1: e1000e global symbols must be renamed Adrian Bunk
2007-08-09 17:06 ` Kok, Auke
2007-08-09 23:49 ` 2.6.23-rc2-mm1: rtl8139 inconsistent lock state Mariusz Kozlowski
2007-08-22 13:35 ` [PATCH 2.6.23-rc3-mm1] request_irq fix DEBUG_SHIRQ handling " Jarek Poplawski
2007-08-25 9:43 ` Mariusz Kozlowski
2007-08-27 5:54 ` Jarek Poplawski
2007-08-23 8:44 ` [PATCH (take 2)] " Jarek Poplawski
2007-08-24 5:46 ` Jarek Poplawski
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).