Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)
Yeah, this is basically mostly copy-pasted from the sboot code, would need some cleaning up. I've been playing more a little with other bits of the hardware, writing some test fw from scratch, mostly without using the builtin rom (except for interrupts). Oleksij Rempel wrote: > Am 08.06.2017 um 00:39 schrieb Tobias Diedrich: > > Oleksij Rempel wrote: > >> Am 07.06.2017 um 02:12 schrieb Tobias Diedrich: > >>> Oleksij Rempel wrote: > >>>> Yes, this is "normal" problem. The firmware has no error handler for PCI > >>>> bus related exceptions. So if we filed to read PCI bus first time, we > >>>> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot > >>>> and provide an kernel "firmware panic!" message. > >>>> Every one who can or will to fix this, is welcome. > >>>> > >>>>> * > >>>>> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic! > >>>>> exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038. > >>> [...] > >>> > >>>> memdmp 50ae78 50ae88 > >>> > >>> 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940 l...j..@ > >>> > >>> [...copy to bin...] > >>> $ bin/objdump -b binary -m xtensa -D /tmp/memdump.bin > >>> [..] > >>>0: 6c1004 entry a1, 32 > >>>3: 126aa2 l32ra2, 0xfffdaa8c > >>>6: 0c0200 memw > >>>9: 8820l32i.n a8, a2, 0 <--Exception cause > >>> PC still points at load > >>>b: c020movi.n a2, 0 > >>>d: 081940 extui a9, a8, 1, 1 > >>> > >>> Judging from that it should be fairly simple to at least implement > >>> some sort of retry, possible after triggering a PCIe link retrain? > >> > >> I assume, yes. > >> > >>> There are some related PCIe root complex registers that may point to > >>> what exactly failed if they were dumped. > >>> > >>> The root complex registers live at 0x0004 and I think match the > >>> registers described for the root complex in the AR9344 datasheet. > >> > >> Suddenly I don't have ar7010 docs to tell.. > >> > >>> PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR: > >>> "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in > >>> the hierarchy reports any of the following errors and the associated > >>> enable bit is set in the Root Control register: ERR_COR, ERR_FATAL, > >>> ERR_NONFATAL." > >>> > >>> AFAICS link retrain can be done by setting bit3 (INIT_RST, > >>> "Application request to initiate a training reset") in > >>> PCIE_APP (0x4). > >>> > >>> See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which > >>> flips some bits in the RC to enable the PCIe bus for reading the > >>> EEPROM). > >>> > >>> The root complex pci configuration space is at 0x2 which could > >>> have further error details: > >>>> memdmp 2 20200 > >>> > >>> 02: a02a 168c 0010 0006 0001 0001 .*.. > >>> 020010: > >>> 020020: > >>> 020030: 0040 01ff ...@ > >>> 020040: 5bc3 5001 [.P. > >>> 020050: 0080 7005 ..p. > >>> 020060: > >>> 020070: 0042 0010 8701 2010 0013 4411 .BD. > >>> 020080: 3011 00c0 03c0 0... > >>> 020090: 0010 > >>> 0200a0: > >>> 0200b0: > >>> 0200c0: > >>> 0200d0: > >>> 0200e0: > >>> 0200f0: > >>> 020100: 1401 0001 0006 20
Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)
Yeah, this is basically mostly copy-pasted from the sboot code, would need some cleaning up. I've been playing more a little with other bits of the hardware, writing some test fw from scratch, mostly without using the builtin rom (except for interrupts). Oleksij Rempel wrote: > Am 08.06.2017 um 00:39 schrieb Tobias Diedrich: > > Oleksij Rempel wrote: > >> Am 07.06.2017 um 02:12 schrieb Tobias Diedrich: > >>> Oleksij Rempel wrote: > >>>> Yes, this is "normal" problem. The firmware has no error handler for PCI > >>>> bus related exceptions. So if we filed to read PCI bus first time, we > >>>> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot > >>>> and provide an kernel "firmware panic!" message. > >>>> Every one who can or will to fix this, is welcome. > >>>> > >>>>> * > >>>>> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic! > >>>>> exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038. > >>> [...] > >>> > >>>> memdmp 50ae78 50ae88 > >>> > >>> 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940 l...j..@ > >>> > >>> [...copy to bin...] > >>> $ bin/objdump -b binary -m xtensa -D /tmp/memdump.bin > >>> [..] > >>>0: 6c1004 entry a1, 32 > >>>3: 126aa2 l32ra2, 0xfffdaa8c > >>>6: 0c0200 memw > >>>9: 8820l32i.n a8, a2, 0 <--Exception cause > >>> PC still points at load > >>>b: c020movi.n a2, 0 > >>>d: 081940 extui a9, a8, 1, 1 > >>> > >>> Judging from that it should be fairly simple to at least implement > >>> some sort of retry, possible after triggering a PCIe link retrain? > >> > >> I assume, yes. > >> > >>> There are some related PCIe root complex registers that may point to > >>> what exactly failed if they were dumped. > >>> > >>> The root complex registers live at 0x0004 and I think match the > >>> registers described for the root complex in the AR9344 datasheet. > >> > >> Suddenly I don't have ar7010 docs to tell.. > >> > >>> PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR: > >>> "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in > >>> the hierarchy reports any of the following errors and the associated > >>> enable bit is set in the Root Control register: ERR_COR, ERR_FATAL, > >>> ERR_NONFATAL." > >>> > >>> AFAICS link retrain can be done by setting bit3 (INIT_RST, > >>> "Application request to initiate a training reset") in > >>> PCIE_APP (0x4). > >>> > >>> See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which > >>> flips some bits in the RC to enable the PCIe bus for reading the > >>> EEPROM). > >>> > >>> The root complex pci configuration space is at 0x2 which could > >>> have further error details: > >>>> memdmp 2 20200 > >>> > >>> 02: a02a 168c 0010 0006 0001 0001 .*.. > >>> 020010: > >>> 020020: > >>> 020030: 0040 01ff ...@ > >>> 020040: 5bc3 5001 [.P. > >>> 020050: 0080 7005 ..p. > >>> 020060: > >>> 020070: 0042 0010 8701 2010 0013 4411 .BD. > >>> 020080: 3011 00c0 03c0 0... > >>> 020090: 0010 > >>> 0200a0: > >>> 0200b0: > >>> 0200c0: > >>> 0200d0: > >>> 0200e0: > >>> 0200f0: > >>> 020100: 1401 0001 0006 20
Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)
Oleksij Rempel wrote: > Am 07.06.2017 um 02:12 schrieb Tobias Diedrich: > > Oleksij Rempel wrote: > >> Yes, this is "normal" problem. The firmware has no error handler for PCI > >> bus related exceptions. So if we filed to read PCI bus first time, we > >> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot > >> and provide an kernel "firmware panic!" message. > >> Every one who can or will to fix this, is welcome. > >> > >>> * > >>> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic! > >>> exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038. > > [...] > > > >> memdmp 50ae78 50ae88 > > > > 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940 l...j..@ > > > > [...copy to bin...] > > $ bin/objdump -b binary -m xtensa -D /tmp/memdump.bin > > [..] > >0: 6c1004 entry a1, 32 > >3: 126aa2 l32ra2, 0xfffdaa8c > >6: 0c0200 memw > >9: 8820l32i.n a8, a2, 0 <--Exception cause > > PC still points at load > >b: c020movi.n a2, 0 > >d: 081940 extui a9, a8, 1, 1 > > > > Judging from that it should be fairly simple to at least implement > > some sort of retry, possible after triggering a PCIe link retrain? > > I assume, yes. > > > There are some related PCIe root complex registers that may point to > > what exactly failed if they were dumped. > > > > The root complex registers live at 0x0004 and I think match the > > registers described for the root complex in the AR9344 datasheet. > > Suddenly I don't have ar7010 docs to tell.. > > > PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR: > > "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in > > the hierarchy reports any of the following errors and the associated > > enable bit is set in the Root Control register: ERR_COR, ERR_FATAL, > > ERR_NONFATAL." > > > > AFAICS link retrain can be done by setting bit3 (INIT_RST, > > "Application request to initiate a training reset") in > > PCIE_APP (0x4). > > > > See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which > > flips some bits in the RC to enable the PCIe bus for reading the > > EEPROM). > > > > The root complex pci configuration space is at 0x2 which could > > have further error details: > >> memdmp 2 20200 > > > > 02: a02a 168c 0010 0006 0001 0001 .*.. > > 020010: > > 020020: > > 020030: 0040 01ff ...@ > > 020040: 5bc3 5001 [.P. > > 020050: 0080 7005 ..p. > > 020060: > > 020070: 0042 0010 8701 2010 0013 4411 .BD. > > 020080: 3011 00c0 03c0 0... > > 020090: 0010 > > 0200a0: > > 0200b0: > > 0200c0: > > 0200d0: > > 0200e0: > > 0200f0: > > 020100: 1401 0001 0006 2030 ...0 > > 020110: 2000 00a0 > > 020120: > > 020130: > > 020140: 0001 0002 > > 020150: 8000 00ff > > 020160: > > 020170: > > 020180: > > 020190: > > 0201a0: > > 0201b0: > > 0201c0: > > 0
Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)
Oleksij Rempel wrote: > Am 07.06.2017 um 02:12 schrieb Tobias Diedrich: > > Oleksij Rempel wrote: > >> Yes, this is "normal" problem. The firmware has no error handler for PCI > >> bus related exceptions. So if we filed to read PCI bus first time, we > >> have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot > >> and provide an kernel "firmware panic!" message. > >> Every one who can or will to fix this, is welcome. > >> > >>> * > >>> Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic! > >>> exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038. > > [...] > > > >> memdmp 50ae78 50ae88 > > > > 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940 l...j..@ > > > > [...copy to bin...] > > $ bin/objdump -b binary -m xtensa -D /tmp/memdump.bin > > [..] > >0: 6c1004 entry a1, 32 > >3: 126aa2 l32ra2, 0xfffdaa8c > >6: 0c0200 memw > >9: 8820l32i.n a8, a2, 0 <--Exception cause > > PC still points at load > >b: c020movi.n a2, 0 > >d: 081940 extui a9, a8, 1, 1 > > > > Judging from that it should be fairly simple to at least implement > > some sort of retry, possible after triggering a PCIe link retrain? > > I assume, yes. > > > There are some related PCIe root complex registers that may point to > > what exactly failed if they were dumped. > > > > The root complex registers live at 0x0004 and I think match the > > registers described for the root complex in the AR9344 datasheet. > > Suddenly I don't have ar7010 docs to tell.. > > > PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR: > > "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in > > the hierarchy reports any of the following errors and the associated > > enable bit is set in the Root Control register: ERR_COR, ERR_FATAL, > > ERR_NONFATAL." > > > > AFAICS link retrain can be done by setting bit3 (INIT_RST, > > "Application request to initiate a training reset") in > > PCIE_APP (0x4). > > > > See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which > > flips some bits in the RC to enable the PCIe bus for reading the > > EEPROM). > > > > The root complex pci configuration space is at 0x2 which could > > have further error details: > >> memdmp 2 20200 > > > > 02: a02a 168c 0010 0006 0001 0001 .*.. > > 020010: > > 020020: > > 020030: 0040 01ff ...@ > > 020040: 5bc3 5001 [.P. > > 020050: 0080 7005 ..p. > > 020060: > > 020070: 0042 0010 8701 2010 0013 4411 .BD. > > 020080: 3011 00c0 03c0 0... > > 020090: 0010 > > 0200a0: > > 0200b0: > > 0200c0: > > 0200d0: > > 0200e0: > > 0200f0: > > 020100: 1401 0001 0006 2030 ...0 > > 020110: 2000 00a0 > > 020120: > > 020130: > > 020140: 0001 0002 > > 020150: 8000 00ff > > 020160: > > 020170: > > 020180: > > 020190: > > 0201a0: > > 0201b0: > > 0201c0: > > 0
Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)
Oleksij Rempel wrote: > Yes, this is "normal" problem. The firmware has no error handler for PCI > bus related exceptions. So if we filed to read PCI bus first time, we > have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot > and provide an kernel "firmware panic!" message. > Every one who can or will to fix this, is welcome. > > > * > > Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic! > > exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038. [...] >memdmp 50ae78 50ae88 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940 l...j..@ [...copy to bin...] $ bin/objdump -b binary -m xtensa -D /tmp/memdump.bin [..] 0: 6c1004 entry a1, 32 3: 126aa2 l32ra2, 0xfffdaa8c 6: 0c0200 memw 9: 8820l32i.n a8, a2, 0 <--Exception cause PC still points at load b: c020movi.n a2, 0 d: 081940 extui a9, a8, 1, 1 Judging from that it should be fairly simple to at least implement some sort of retry, possible after triggering a PCIe link retrain? There are some related PCIe root complex registers that may point to what exactly failed if they were dumped. The root complex registers live at 0x0004 and I think match the registers described for the root complex in the AR9344 datasheet. PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR: "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in the hierarchy reports any of the following errors and the associated enable bit is set in the Root Control register: ERR_COR, ERR_FATAL, ERR_NONFATAL." AFAICS link retrain can be done by setting bit3 (INIT_RST, "Application request to initiate a training reset") in PCIE_APP (0x4). See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which flips some bits in the RC to enable the PCIe bus for reading the EEPROM). The root complex pci configuration space is at 0x2 which could have further error details: >memdmp 2 20200 02: a02a 168c 0010 0006 0001 0001 .*.. 020010: 020020: 020030: 0040 01ff ...@ 020040: 5bc3 5001 [.P. 020050: 0080 7005 ..p. 020060: 020070: 0042 0010 8701 2010 0013 4411 .BD. 020080: 3011 00c0 03c0 0... 020090: 0010 0200a0: 0200b0: 0200c0: 0200d0: 0200e0: 0200f0: 020100: 1401 0001 0006 2030 ...0 020110: 2000 00a0 020120: 020130: 020140: 0001 0002 020150: 8000 00ff 020160: 020170: 020180: 020190: 0201a0: 0201b0: 0201c0: 0201d0: 0201e0: 0201f0: Transformed into something suitable for feeding into lspci -F: 00:00.0 Description filled in by lspci 00: 8c 16 2a a0 06 00 10 00 01 00 00 00 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00 40: 01 50 c3 5b 00 00 00 00 00 00 00 00 00 00 00 00 50: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 10 00 42 00 01 87 00 00 10 20 00 00 11 44 13 00 80: 00 00 11 30 00 00 00 00 c0 03 c0 00 00 00 00 00 90: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00
Re: ath9k_htc - Division by zero in kernel (as well as firmware panic)
Oleksij Rempel wrote: > Yes, this is "normal" problem. The firmware has no error handler for PCI > bus related exceptions. So if we filed to read PCI bus first time, we > have choice to Ooops and stall or Ooops and reboot ASAP. So we reboot > and provide an kernel "firmware panic!" message. > Every one who can or will to fix this, is welcome. > > > * > > Jun 02 14:55:30 computer kernel: usb 1-1.1: ath: firmware panic! > > exccause: 0x000d; pc: 0x0090ae81; badvaddr: 0x10ff4038. [...] >memdmp 50ae78 50ae88 50ae78: 6c10 0412 6aa2 0c02 0088 20c0 2008 1940 l...j..@ [...copy to bin...] $ bin/objdump -b binary -m xtensa -D /tmp/memdump.bin [..] 0: 6c1004 entry a1, 32 3: 126aa2 l32ra2, 0xfffdaa8c 6: 0c0200 memw 9: 8820l32i.n a8, a2, 0 <--Exception cause PC still points at load b: c020movi.n a2, 0 d: 081940 extui a9, a8, 1, 1 Judging from that it should be fairly simple to at least implement some sort of retry, possible after triggering a PCIe link retrain? There are some related PCIe root complex registers that may point to what exactly failed if they were dumped. The root complex registers live at 0x0004 and I think match the registers described for the root complex in the AR9344 datasheet. PCIE_INT_MASK would map to 0x40050 and has a bit for SYS_ERR: "A system error. The RC Core asserts CFG_SYS_ERR_RC if any device in the hierarchy reports any of the following errors and the associated enable bit is set in the Root Control register: ERR_COR, ERR_FATAL, ERR_NONFATAL." AFAICS link retrain can be done by setting bit3 (INIT_RST, "Application request to initiate a training reset") in PCIE_APP (0x4). See sboot/magpie_1_1/sboot/cmnos/eeprom/src/cmnos_eeprom.c (which flips some bits in the RC to enable the PCIe bus for reading the EEPROM). The root complex pci configuration space is at 0x2 which could have further error details: >memdmp 2 20200 02: a02a 168c 0010 0006 0001 0001 .*.. 020010: 020020: 020030: 0040 01ff ...@ 020040: 5bc3 5001 [.P. 020050: 0080 7005 ..p. 020060: 020070: 0042 0010 8701 2010 0013 4411 .BD. 020080: 3011 00c0 03c0 0... 020090: 0010 0200a0: 0200b0: 0200c0: 0200d0: 0200e0: 0200f0: 020100: 1401 0001 0006 2030 ...0 020110: 2000 00a0 020120: 020130: 020140: 0001 0002 020150: 8000 00ff 020160: 020170: 020180: 020190: 0201a0: 0201b0: 0201c0: 0201d0: 0201e0: 0201f0: Transformed into something suitable for feeding into lspci -F: 00:00.0 Description filled in by lspci 00: 8c 16 2a a0 06 00 10 00 01 00 00 00 00 00 01 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 ff 01 00 00 40: 01 50 c3 5b 00 00 00 00 00 00 00 00 00 00 00 00 50: 05 70 80 00 00 00 00 00 00 00 00 00 00 00 00 00 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 70: 10 00 42 00 01 87 00 00 10 20 00 00 11 44 13 00 80: 00 00 11 30 00 00 00 00 c0 03 c0 00 00 00 00 00 90: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00
[PATCH] gpio: Add AMD SB8XX/SB9XX/A5X/A8X driver
In principle this driver could export a pinmux interface as well, but
since setting up the pinmux settings is the BIOS/EFI responsibility
I don't think it makes sense to add it (I only read it to print
the current mux state in /sys/kernel/debug/gpio).
Signed-off-by: Tobias Diedrich
---
MAINTAINERS | 6 +
drivers/gpio/Kconfig | 8 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-sb8xx.c | 489 ++
4 files changed, 504 insertions(+)
create mode 100644 drivers/gpio/gpio-sb8xx.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d8afd29..32f7140 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -647,6 +647,12 @@ M: Borislav Petkov
S: Maintained
F: arch/x86/kernel/cpu/microcode/amd*
+AMD SB8XX/SB9xx/A5X/A8X GPIO DRIVER
+M: Tobias Diedrich
+S: Supported
+F: drivers/gpio/gpio-sb8xx.c
+F: Documentation/devicetree/bindings/gpio/gpio-sb8xx.txt
+
AMD XGBE DRIVER
M: Tom Lendacky
L: net...@vger.kernel.org
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index caefe80..a2e2dc5 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -884,6 +884,14 @@ config GPIO_BT8XX
If unsure, say N.
+config GPIO_SB8XX
+ tristate "AMD SB8XX/SB9XX/A5X/A8X GPIO driver"
+ depends on PCI
+ help
+ Say Y here to support AMD SB8XX/SB9XX/A5X/A8X south bridge GPIO.
+
+ If unsure, say N.
+
config GPIO_INTEL_MID
bool "Intel Mid GPIO support"
depends on PCI && X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f71bb97..b6d7d9d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
obj-$(CONFIG_GPIO_F7188X) += gpio-f7188x.o
obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
+obj-$(CONFIG_GPIO_SB8XX) += gpio-sb8xx.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
obj-$(CONFIG_GPIO_IOP) += gpio-iop.o
obj-$(CONFIG_GPIO_IT8761E) += gpio-it8761e.o
diff --git a/drivers/gpio/gpio-sb8xx.c b/drivers/gpio/gpio-sb8xx.c
new file mode 100644
index 000..fbfd723
--- /dev/null
+++ b/drivers/gpio/gpio-sb8xx.c
@@ -0,0 +1,489 @@
+/*
+ * GPIO driver for AMD SB8XX/SB9XX/A5X/A8X south bridges
+ *
+ * Copyright (c) 2015 Tobias Diedrich
+ *
+ * Based on the AMD 8111 GPIO driver:
+ * Copyright (c) 2012 Dmitry Eremin-Solenikov
+ *
+ * Based on the AMD RNG driver:
+ * Copyright 2005 (c) MontaVista Software, Inc.
+ * with the majority of the code coming from:
+ *
+ * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG)
+ * (c) Copyright 2003 Red Hat Inc
+ *
+ * derived from
+ *
+ * Hardware driver for the AMD 768 Random Number Generator (RNG)
+ * (c) Copyright 2001 Red Hat Inc
+ *
+ * derived from
+ *
+ * Hardware driver for Intel i810 Random Number Generator (RNG)
+ * Copyright 2000,2001 Jeff Garzik
+ * Copyright 2000,2001 Philipp Rumpf
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PM_REG_BASE0xCD6
+#define PM_REG_SIZE2
+#define PM_IDX_REG (PM_REG_BASE + 0)
+#define PM_DATA_REG(PM_REG_BASE + 1)
+#define PM_ACPI_MMIO_BAR 0x24
+
+#define GPIO_OFFSET0x100
+#define GPIO_SIZE 0x100
+#define IOMUX_OFFSET 0xd00
+#define IOMUX_SIZE 0x100
+
+#define MAX_GPIO 256
+
+#define REG_GPIO(i)(0x00 + (i))
+
+#define IOMUX_MASK 0x03
+#define IOMUX_FN0 0x00
+#define IOMUX_FN1 0x01
+#define IOMUX_FN2 0x02
+#define IOMUX_FN3 0x03
+
+#define GPIO_OWN_NONE 0x00 /* No owner */
+#define GPIO_OWN_IMC 0x01 /* OwnedByImc */
+#define GPIO_OWN_HOST 0x02 /* OwnedByHost */
+#define GPIO_OWN_MASK (GPIO_OWN_IMC | GPIO_OWN_HOST)
+#define GPIO_STICKY0x04 /* Settings sticky across reset */
+#define GPIO_PULLUP_B 0x08 /* 0 to enable pull-up */
+#define GPIO_PULLDOWN 0x10 /* 1 to enable pull-down */
+#define GPIO_PULL_MASK (GPIO_PULLUP_B | GPIO_PULLDOWN)
+#define GPIO_PULL_UP 0x00
+#define GPIO_PULL_DOWN 0x18
+#define GPIO_PULL_NONE 0x08
+#define GPIO_OUT_EN_B 0x20 /* 0 to enable output */
+#define GPIO_OUT 0x40
+#define GPIO_IN0x80
+
+static int enable_unsafe_direction_change;
+module_param(enable_unsafe_direction_change, int, 0);
+MODULE_PARM_DESC(enable_unsafe_direction_change,
+"Enable gpio direction changes. This can be unsafe!");
+
+static const struct pci_device_id pci_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_HUDSON2_SMBUS), 0 },
+ { PCI_DEVICE(PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS), 0 },
+ { 0, }, /* terminate list */
+};
+
+/*
+ * Explicitly register the supp
[PATCH] gpio: Add AMD SB8XX/SB9XX/A5X/A8X driver
In principle this driver could export a pinmux interface as well, but
since setting up the pinmux settings is the BIOS/EFI responsibility
I don't think it makes sense to add it (I only read it to print
the current mux state in /sys/kernel/debug/gpio).
Signed-off-by: Tobias Diedrich ranma+ker...@tdiedrich.de
---
MAINTAINERS | 6 +
drivers/gpio/Kconfig | 8 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-sb8xx.c | 489 ++
4 files changed, 504 insertions(+)
create mode 100644 drivers/gpio/gpio-sb8xx.c
diff --git a/MAINTAINERS b/MAINTAINERS
index d8afd29..32f7140 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -647,6 +647,12 @@ M: Borislav Petkov b...@alien8.de
S: Maintained
F: arch/x86/kernel/cpu/microcode/amd*
+AMD SB8XX/SB9xx/A5X/A8X GPIO DRIVER
+M: Tobias Diedrich ranma+ker...@tdiedrich.de
+S: Supported
+F: drivers/gpio/gpio-sb8xx.c
+F: Documentation/devicetree/bindings/gpio/gpio-sb8xx.txt
+
AMD XGBE DRIVER
M: Tom Lendacky thomas.lenda...@amd.com
L: net...@vger.kernel.org
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index caefe80..a2e2dc5 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -884,6 +884,14 @@ config GPIO_BT8XX
If unsure, say N.
+config GPIO_SB8XX
+ tristate AMD SB8XX/SB9XX/A5X/A8X GPIO driver
+ depends on PCI
+ help
+ Say Y here to support AMD SB8XX/SB9XX/A5X/A8X south bridge GPIO.
+
+ If unsure, say N.
+
config GPIO_INTEL_MID
bool Intel Mid GPIO support
depends on PCI X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f71bb97..b6d7d9d 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_GPIO_EP93XX) += gpio-ep93xx.o
obj-$(CONFIG_GPIO_F7188X) += gpio-f7188x.o
obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
+obj-$(CONFIG_GPIO_SB8XX) += gpio-sb8xx.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
obj-$(CONFIG_GPIO_IOP) += gpio-iop.o
obj-$(CONFIG_GPIO_IT8761E) += gpio-it8761e.o
diff --git a/drivers/gpio/gpio-sb8xx.c b/drivers/gpio/gpio-sb8xx.c
new file mode 100644
index 000..fbfd723
--- /dev/null
+++ b/drivers/gpio/gpio-sb8xx.c
@@ -0,0 +1,489 @@
+/*
+ * GPIO driver for AMD SB8XX/SB9XX/A5X/A8X south bridges
+ *
+ * Copyright (c) 2015 Tobias Diedrich
+ *
+ * Based on the AMD 8111 GPIO driver:
+ * Copyright (c) 2012 Dmitry Eremin-Solenikov
+ *
+ * Based on the AMD RNG driver:
+ * Copyright 2005 (c) MontaVista Software, Inc.
+ * with the majority of the code coming from:
+ *
+ * Hardware driver for the Intel/AMD/VIA Random Number Generators (RNG)
+ * (c) Copyright 2003 Red Hat Inc jgar...@redhat.com
+ *
+ * derived from
+ *
+ * Hardware driver for the AMD 768 Random Number Generator (RNG)
+ * (c) Copyright 2001 Red Hat Inc
+ *
+ * derived from
+ *
+ * Hardware driver for Intel i810 Random Number Generator (RNG)
+ * Copyright 2000,2001 Jeff Garzik jgar...@pobox.com
+ * Copyright 2000,2001 Philipp Rumpf pru...@mandrakesoft.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+#include linux/module.h
+#include linux/kernel.h
+#include linux/io.h
+#include linux/ioport.h
+#include linux/gpio.h
+#include linux/pci.h
+#include linux/spinlock.h
+#include linux/acpi.h
+#include linux/platform_device.h
+
+#define PM_REG_BASE0xCD6
+#define PM_REG_SIZE2
+#define PM_IDX_REG (PM_REG_BASE + 0)
+#define PM_DATA_REG(PM_REG_BASE + 1)
+#define PM_ACPI_MMIO_BAR 0x24
+
+#define GPIO_OFFSET0x100
+#define GPIO_SIZE 0x100
+#define IOMUX_OFFSET 0xd00
+#define IOMUX_SIZE 0x100
+
+#define MAX_GPIO 256
+
+#define REG_GPIO(i)(0x00 + (i))
+
+#define IOMUX_MASK 0x03
+#define IOMUX_FN0 0x00
+#define IOMUX_FN1 0x01
+#define IOMUX_FN2 0x02
+#define IOMUX_FN3 0x03
+
+#define GPIO_OWN_NONE 0x00 /* No owner */
+#define GPIO_OWN_IMC 0x01 /* OwnedByImc */
+#define GPIO_OWN_HOST 0x02 /* OwnedByHost */
+#define GPIO_OWN_MASK (GPIO_OWN_IMC | GPIO_OWN_HOST)
+#define GPIO_STICKY0x04 /* Settings sticky across reset */
+#define GPIO_PULLUP_B 0x08 /* 0 to enable pull-up */
+#define GPIO_PULLDOWN 0x10 /* 1 to enable pull-down */
+#define GPIO_PULL_MASK (GPIO_PULLUP_B | GPIO_PULLDOWN)
+#define GPIO_PULL_UP 0x00
+#define GPIO_PULL_DOWN 0x18
+#define GPIO_PULL_NONE 0x08
+#define GPIO_OUT_EN_B 0x20 /* 0 to enable output */
+#define GPIO_OUT 0x40
+#define GPIO_IN0x80
+
+static int enable_unsafe_direction_change;
+module_param(enable_unsafe_direction_change, int, 0);
+MODULE_PARM_DESC(enable_unsafe_direction_change,
+Enable gpio direction changes. This can be unsafe!);
+
+static const struct pci_device_id pci_tbl[] = {
+ { PCI_DEVICE
[PATCH v2] gpio / ACPI: Add label to the gpio request
In leds-gpio.c create_gpio_led only the legacy path propagates the label
by passing it into devm_gpio_request_one. Similarily gpio_keys_polled.c
also neglects to propagate the name to the gpio subsystem.
On the newer devicetree/acpi path the label is lost as far as the GPIO
subsystem goes (it is only retained as name in struct gpio_led.
Amend devm_get_gpiod_from_child to take an additonal (optional) label
argument and propagate it so it will show up in /sys/kernel/debug/gpio.
So instead of:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-475 (? ) in hi
gpio-477 (? ) out hi
gpio-478 (? ) out lo
gpio-479 (? ) out hi
we get the much nicer output:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-475 (switch1 ) in hi
gpio-477 (led1) out hi
gpio-478 (led2) out lo
gpio-479 (led3) out hi
Signed-off-by: Tobias Diedrich
---
drivers/gpio/devres.c | 6 --
drivers/gpio/gpiolib.c| 6 --
drivers/input/keyboard/gpio_keys_polled.c | 9 +
drivers/leds/leds-gpio.c | 20 +++-
include/linux/gpio/consumer.h | 6 --
5 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 07ba823..40a6089 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -127,13 +127,15 @@ EXPORT_SYMBOL(__devm_gpiod_get_index);
* @dev: GPIO consumer
* @con_id:function within the GPIO consumer
* @child: firmware node (child of @dev)
+ * @label: a literal description string of this GPIO
*
* GPIO descriptors returned from this function are automatically disposed on
* driver detach.
*/
struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
const char *con_id,
- struct fwnode_handle *child)
+ struct fwnode_handle *child,
+ const char *label)
{
static const char * const suffixes[] = { "gpios", "gpio" };
char prop_name[32]; /* 32 is max size of property name */
@@ -154,7 +156,7 @@ struct gpio_desc *devm_get_gpiod_from_child(struct device
*dev,
snprintf(prop_name, sizeof(prop_name), "%s",
suffixes[i]);
- desc = fwnode_get_named_gpiod(child, prop_name);
+ desc = fwnode_get_named_gpiod(child, prop_name, label);
if (!IS_ERR(desc) || (PTR_ERR(desc) == -EPROBE_DEFER))
break;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 6bc612b..b3f2e5c 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2017,6 +2017,7 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* fwnode_get_named_gpiod - obtain a GPIO from firmware node
* @fwnode:handle of the firmware node
* @propname: name of the firmware property representing the GPIO
+ * @label: label for the GPIO
*
* This function can be used for drivers that get their configuration
* from firmware.
@@ -2028,7 +2029,8 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* In case of error an ERR_PTR() is returned.
*/
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname)
+const char *propname,
+const char *label)
{
struct gpio_desc *desc = ERR_PTR(-ENODEV);
bool active_low = false;
@@ -2056,7 +2058,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- ret = gpiod_request(desc, NULL);
+ ret = gpiod_request(desc, label);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/input/keyboard/gpio_keys_polled.c
b/drivers/input/keyboard/gpio_keys_polled.c
index 097d721..4cf3d23 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -124,8 +124,12 @@ static struct gpio_keys_platform_data
*gpio_keys_polled_get_devtree_pdata(struct
device_for_each_child_node(dev, child) {
struct gpio_desc *desc;
+ button = >buttons[pdata->nbuttons++];
+
+ fwnode_property_read_string(child, "label", >desc);
- desc = devm_get_gpiod_from_child(dev, NULL, child);
+ desc = devm_get_gpiod_from_child(dev, NULL, child,
+button->desc);
if (IS_ERR(desc)) {
error = PTR_ERR(desc);
if (error != -EPROBE_DEFER)
@@ -1
[PATCH v2] gpio / ACPI: Add label to the gpio request
In leds-gpio.c create_gpio_led only the legacy path propagates the label
by passing it into devm_gpio_request_one. Similarily gpio_keys_polled.c
also neglects to propagate the name to the gpio subsystem.
On the newer devicetree/acpi path the label is lost as far as the GPIO
subsystem goes (it is only retained as name in struct gpio_led.
Amend devm_get_gpiod_from_child to take an additonal (optional) label
argument and propagate it so it will show up in /sys/kernel/debug/gpio.
So instead of:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-475 (? ) in hi
gpio-477 (? ) out hi
gpio-478 (? ) out lo
gpio-479 (? ) out hi
we get the much nicer output:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-475 (switch1 ) in hi
gpio-477 (led1) out hi
gpio-478 (led2) out lo
gpio-479 (led3) out hi
Signed-off-by: Tobias Diedrich ranma+ker...@tdiedrich.de
---
drivers/gpio/devres.c | 6 --
drivers/gpio/gpiolib.c| 6 --
drivers/input/keyboard/gpio_keys_polled.c | 9 +
drivers/leds/leds-gpio.c | 20 +++-
include/linux/gpio/consumer.h | 6 --
5 files changed, 28 insertions(+), 19 deletions(-)
diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 07ba823..40a6089 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -127,13 +127,15 @@ EXPORT_SYMBOL(__devm_gpiod_get_index);
* @dev: GPIO consumer
* @con_id:function within the GPIO consumer
* @child: firmware node (child of @dev)
+ * @label: a literal description string of this GPIO
*
* GPIO descriptors returned from this function are automatically disposed on
* driver detach.
*/
struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
const char *con_id,
- struct fwnode_handle *child)
+ struct fwnode_handle *child,
+ const char *label)
{
static const char * const suffixes[] = { gpios, gpio };
char prop_name[32]; /* 32 is max size of property name */
@@ -154,7 +156,7 @@ struct gpio_desc *devm_get_gpiod_from_child(struct device
*dev,
snprintf(prop_name, sizeof(prop_name), %s,
suffixes[i]);
- desc = fwnode_get_named_gpiod(child, prop_name);
+ desc = fwnode_get_named_gpiod(child, prop_name, label);
if (!IS_ERR(desc) || (PTR_ERR(desc) == -EPROBE_DEFER))
break;
}
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 6bc612b..b3f2e5c 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2017,6 +2017,7 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* fwnode_get_named_gpiod - obtain a GPIO from firmware node
* @fwnode:handle of the firmware node
* @propname: name of the firmware property representing the GPIO
+ * @label: label for the GPIO
*
* This function can be used for drivers that get their configuration
* from firmware.
@@ -2028,7 +2029,8 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* In case of error an ERR_PTR() is returned.
*/
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname)
+const char *propname,
+const char *label)
{
struct gpio_desc *desc = ERR_PTR(-ENODEV);
bool active_low = false;
@@ -2056,7 +2058,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- ret = gpiod_request(desc, NULL);
+ ret = gpiod_request(desc, label);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/input/keyboard/gpio_keys_polled.c
b/drivers/input/keyboard/gpio_keys_polled.c
index 097d721..4cf3d23 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -124,8 +124,12 @@ static struct gpio_keys_platform_data
*gpio_keys_polled_get_devtree_pdata(struct
device_for_each_child_node(dev, child) {
struct gpio_desc *desc;
+ button = pdata-buttons[pdata-nbuttons++];
+
+ fwnode_property_read_string(child, label, button-desc);
- desc = devm_get_gpiod_from_child(dev, NULL, child);
+ desc = devm_get_gpiod_from_child(dev, NULL, child,
+button-desc);
if (IS_ERR(desc)) {
error = PTR_ERR(desc);
if (error != -EPROBE_DEFER)
@@ -136,7 +140,6 @@ static struct
Re: [PATCH] gpio / ACPI: Add label to the gpio request
Mika Westerberg wrote:
> On Thu, Jun 11, 2015 at 02:08:22AM +0200, Tobias Diedrich wrote:
> > In create_gpio_led only the legacy pass propagates the label by passing it
> > into
> > devm_gpio_request_one.
> >
> > On the newer devicetree/acpi path the label is lost as far as the GPIO
> > subsystem goes (it is only retained as name in struct gpio_led.
> >
> > Amend devm_get_gpiod_from_child to also pass the label into the GPIO layer,
> > so
> > it will show up in /sys/kernel/debug/gpio, so instead of:
> >
> > GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
> > gpio-477 (? ) out hi
> > gpio-478 (? ) out lo
> > gpio-479 (? ) out hi
> >
> > we get the much nicer output:
> >
> > GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
> > gpio-477 (led1) out hi
> > gpio-478 (led2) out lo
> > gpio-479 (led3) out hi
>
> I wonder if we can just put the con_id there?
leds-gpio doesn't seem to set con_id:
led.gpiod = devm_get_gpiod_from_child(dev, NULL, child);
> > Signed-off-by: Tobias Diedrich
> > ---
> > drivers/gpio/devres.c | 6 +-
> > drivers/gpio/gpiolib.c| 6 --
> > include/linux/gpio/consumer.h | 3 ++-
> > 3 files changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
> > index 07ba823..089db97 100644
> > --- a/drivers/gpio/devres.c
> > +++ b/drivers/gpio/devres.c
> > @@ -103,13 +103,17 @@ struct gpio_desc *__must_check
> > __devm_gpiod_get_index(struct device *dev,
> > {
> > struct gpio_desc **dr;
> > struct gpio_desc *desc;
> > + const char *label = NULL;
> >
> > dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
> > GFP_KERNEL);
> > if (!dr)
> > return ERR_PTR(-ENOMEM);
> >
> > - desc = gpiod_get_index(dev, con_id, idx, flags);
> > + if (fwnode_property_present(child, "label"))
> > + fwnode_property_read_string(child, "label", );
>
> This binding needs to be documented, I suppose.
>
> But then again, does it really describe the hardware? We already have
> names like "linux,label" in the bindings but as far as I understand
> adding such things is not recommended.
Strange, this shouldn't even have compiled, botched the merge to git
HEAD. Apparently my compile test didn't end up including this file.
This was supposed to go into devm_get_gpiod_from_child.
At least gpio-keys-polled and gpio-leds both use "label" and "gpios",
but I suppose that might not be true for all users of
devm_get_gpiod_from_child.
> > +
> > + desc = gpiod_get_index(dev, con_id, idx, flags, label);
> > if (IS_ERR(desc)) {
> > devres_free(dr);
> > return desc;
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index 6bc612b..fb2be68 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -2017,6 +2017,7 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
> > * fwnode_get_named_gpiod - obtain a GPIO from firmware node
> > * @fwnode:handle of the firmware node
> > * @propname: name of the firmware property representing the GPIO
> > + * @label: optional label for the GPIO
> > *
> > * This function can be used for drivers that get their configuration
> > * from firmware.
> > @@ -2028,7 +2029,8 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
> > * In case of error an ERR_PTR() is returned.
> > */
> > struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
> > -const char *propname)
> > +const char *propname,
> > +const char *label)
> > {
> > struct gpio_desc *desc = ERR_PTR(-ENODEV);
> > bool active_low = false;
> > @@ -2056,7 +2058,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
> > fwnode_handle *fwnode,
> > if (IS_ERR(desc))
> > return desc;
> >
> > - ret = gpiod_request(desc, NULL);
> > + ret = gpiod_request(desc, label);
> > if (ret)
> > return ERR_PTR(ret);
> >
> > diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
> > index 3a7c9ff..ef7d322 100644
> > --- a/include/linux/gpio/consumer.h
> > +++ b/include/linux/gpio/consumer.h
> > @@ -134,7 +134,8 @@ int desc_to_gpi
Re: [PATCH] gpio / ACPI: Add label to the gpio request
Mika Westerberg wrote:
On Thu, Jun 11, 2015 at 02:08:22AM +0200, Tobias Diedrich wrote:
In create_gpio_led only the legacy pass propagates the label by passing it
into
devm_gpio_request_one.
On the newer devicetree/acpi path the label is lost as far as the GPIO
subsystem goes (it is only retained as name in struct gpio_led.
Amend devm_get_gpiod_from_child to also pass the label into the GPIO layer,
so
it will show up in /sys/kernel/debug/gpio, so instead of:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-477 (? ) out hi
gpio-478 (? ) out lo
gpio-479 (? ) out hi
we get the much nicer output:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-477 (led1) out hi
gpio-478 (led2) out lo
gpio-479 (led3) out hi
I wonder if we can just put the con_id there?
leds-gpio doesn't seem to set con_id:
led.gpiod = devm_get_gpiod_from_child(dev, NULL, child);
Signed-off-by: Tobias Diedrich ranma+ker...@tdiedrich.de
---
drivers/gpio/devres.c | 6 +-
drivers/gpio/gpiolib.c| 6 --
include/linux/gpio/consumer.h | 3 ++-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 07ba823..089db97 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -103,13 +103,17 @@ struct gpio_desc *__must_check
__devm_gpiod_get_index(struct device *dev,
{
struct gpio_desc **dr;
struct gpio_desc *desc;
+ const char *label = NULL;
dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
GFP_KERNEL);
if (!dr)
return ERR_PTR(-ENOMEM);
- desc = gpiod_get_index(dev, con_id, idx, flags);
+ if (fwnode_property_present(child, label))
+ fwnode_property_read_string(child, label, label);
This binding needs to be documented, I suppose.
But then again, does it really describe the hardware? We already have
names like linux,label in the bindings but as far as I understand
adding such things is not recommended.
Strange, this shouldn't even have compiled, botched the merge to git
HEAD. Apparently my compile test didn't end up including this file.
This was supposed to go into devm_get_gpiod_from_child.
At least gpio-keys-polled and gpio-leds both use label and gpios,
but I suppose that might not be true for all users of
devm_get_gpiod_from_child.
+
+ desc = gpiod_get_index(dev, con_id, idx, flags, label);
if (IS_ERR(desc)) {
devres_free(dr);
return desc;
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 6bc612b..fb2be68 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2017,6 +2017,7 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* fwnode_get_named_gpiod - obtain a GPIO from firmware node
* @fwnode:handle of the firmware node
* @propname: name of the firmware property representing the GPIO
+ * @label: optional label for the GPIO
*
* This function can be used for drivers that get their configuration
* from firmware.
@@ -2028,7 +2029,8 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* In case of error an ERR_PTR() is returned.
*/
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname)
+const char *propname,
+const char *label)
{
struct gpio_desc *desc = ERR_PTR(-ENODEV);
bool active_low = false;
@@ -2056,7 +2058,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- ret = gpiod_request(desc, NULL);
+ ret = gpiod_request(desc, label);
if (ret)
return ERR_PTR(ret);
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 3a7c9ff..ef7d322 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -134,7 +134,8 @@ int desc_to_gpio(const struct gpio_desc *desc);
struct fwnode_handle;
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname);
+const char *propname,
+const char *label);
struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
const char *con_id,
struct fwnode_handle *child);
--
2.1.4
--
Tobias PGP: http://8ef7ddba.uguu.de
--
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
Re: [PATCH] gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found
Rafael J. Wysocki wrote: > On Wednesday, June 10, 2015 04:05:05 PM Mika Westerberg wrote: > > If a driver requests a GPIO described in its _CRS but the GPIO host > > controller (gpiochip) driver providing the GPIO has not been loaded yet > > acpi_get_gpiod() returns -ENODEV which causes the calling driver to fail. > > > > If the gpiochip driver is loaded afterwards the driver requesting the GPIO > > will not notice this. > > > > Better approach is to return -EPROBE_DEFER in such case. Then when the > > gpiochip driver appears the driver requesting the GPIO will be probed > > again. This also aligns ACPI GPIO lookup code closer to DT as it does > > pretty much the same when no gpiochip driver was found. > > > > Reported-by: Tobias Diedrich > > Signed-off-by: Mika Westerberg > > Makes sense to me. > > Acked-by: Rafael J. Wysocki Signed-off-by: Tobias Diedrich -- Tobias PGP: http://8ef7ddba.uguu.de -- 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/
[PATCH] gpio / ACPI: Add label to the gpio request
In create_gpio_led only the legacy pass propagates the label by passing it into
devm_gpio_request_one.
On the newer devicetree/acpi path the label is lost as far as the GPIO
subsystem goes (it is only retained as name in struct gpio_led.
Amend devm_get_gpiod_from_child to also pass the label into the GPIO layer, so
it will show up in /sys/kernel/debug/gpio, so instead of:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-477 (? ) out hi
gpio-478 (? ) out lo
gpio-479 (? ) out hi
we get the much nicer output:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-477 (led1) out hi
gpio-478 (led2) out lo
gpio-479 (led3) out hi
Signed-off-by: Tobias Diedrich
---
drivers/gpio/devres.c | 6 +-
drivers/gpio/gpiolib.c| 6 --
include/linux/gpio/consumer.h | 3 ++-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 07ba823..089db97 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -103,13 +103,17 @@ struct gpio_desc *__must_check
__devm_gpiod_get_index(struct device *dev,
{
struct gpio_desc **dr;
struct gpio_desc *desc;
+ const char *label = NULL;
dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
GFP_KERNEL);
if (!dr)
return ERR_PTR(-ENOMEM);
- desc = gpiod_get_index(dev, con_id, idx, flags);
+ if (fwnode_property_present(child, "label"))
+ fwnode_property_read_string(child, "label", );
+
+ desc = gpiod_get_index(dev, con_id, idx, flags, label);
if (IS_ERR(desc)) {
devres_free(dr);
return desc;
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 6bc612b..fb2be68 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2017,6 +2017,7 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* fwnode_get_named_gpiod - obtain a GPIO from firmware node
* @fwnode:handle of the firmware node
* @propname: name of the firmware property representing the GPIO
+ * @label: optional label for the GPIO
*
* This function can be used for drivers that get their configuration
* from firmware.
@@ -2028,7 +2029,8 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* In case of error an ERR_PTR() is returned.
*/
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname)
+const char *propname,
+const char *label)
{
struct gpio_desc *desc = ERR_PTR(-ENODEV);
bool active_low = false;
@@ -2056,7 +2058,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- ret = gpiod_request(desc, NULL);
+ ret = gpiod_request(desc, label);
if (ret)
return ERR_PTR(ret);
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 3a7c9ff..ef7d322 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -134,7 +134,8 @@ int desc_to_gpio(const struct gpio_desc *desc);
struct fwnode_handle;
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname);
+const char *propname,
+const char *label);
struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
const char *con_id,
struct fwnode_handle *child);
--
2.1.4
--
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: [PATCH] gpio / ACPI: Return -EPROBE_DEFER if the gpiochip was not found
Rafael J. Wysocki wrote: On Wednesday, June 10, 2015 04:05:05 PM Mika Westerberg wrote: If a driver requests a GPIO described in its _CRS but the GPIO host controller (gpiochip) driver providing the GPIO has not been loaded yet acpi_get_gpiod() returns -ENODEV which causes the calling driver to fail. If the gpiochip driver is loaded afterwards the driver requesting the GPIO will not notice this. Better approach is to return -EPROBE_DEFER in such case. Then when the gpiochip driver appears the driver requesting the GPIO will be probed again. This also aligns ACPI GPIO lookup code closer to DT as it does pretty much the same when no gpiochip driver was found. Reported-by: Tobias Diedrich tobiasdiedr...@gmail.com Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com Makes sense to me. Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com Signed-off-by: Tobias Diedrich ranma+ker...@tdiedrich.de -- Tobias PGP: http://8ef7ddba.uguu.de -- 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/
[PATCH] gpio / ACPI: Add label to the gpio request
In create_gpio_led only the legacy pass propagates the label by passing it into
devm_gpio_request_one.
On the newer devicetree/acpi path the label is lost as far as the GPIO
subsystem goes (it is only retained as name in struct gpio_led.
Amend devm_get_gpiod_from_child to also pass the label into the GPIO layer, so
it will show up in /sys/kernel/debug/gpio, so instead of:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-477 (? ) out hi
gpio-478 (? ) out lo
gpio-479 (? ) out hi
we get the much nicer output:
GPIOs 288-511, platform/PRP0001:00, AMD SBX00:
gpio-477 (led1) out hi
gpio-478 (led2) out lo
gpio-479 (led3) out hi
Signed-off-by: Tobias Diedrich ranma+ker...@tdiedrich.de
---
drivers/gpio/devres.c | 6 +-
drivers/gpio/gpiolib.c| 6 --
include/linux/gpio/consumer.h | 3 ++-
3 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 07ba823..089db97 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -103,13 +103,17 @@ struct gpio_desc *__must_check
__devm_gpiod_get_index(struct device *dev,
{
struct gpio_desc **dr;
struct gpio_desc *desc;
+ const char *label = NULL;
dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
GFP_KERNEL);
if (!dr)
return ERR_PTR(-ENOMEM);
- desc = gpiod_get_index(dev, con_id, idx, flags);
+ if (fwnode_property_present(child, label))
+ fwnode_property_read_string(child, label, label);
+
+ desc = gpiod_get_index(dev, con_id, idx, flags, label);
if (IS_ERR(desc)) {
devres_free(dr);
return desc;
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 6bc612b..fb2be68 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2017,6 +2017,7 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* fwnode_get_named_gpiod - obtain a GPIO from firmware node
* @fwnode:handle of the firmware node
* @propname: name of the firmware property representing the GPIO
+ * @label: optional label for the GPIO
*
* This function can be used for drivers that get their configuration
* from firmware.
@@ -2028,7 +2029,8 @@ EXPORT_SYMBOL_GPL(__gpiod_get_index);
* In case of error an ERR_PTR() is returned.
*/
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname)
+const char *propname,
+const char *label)
{
struct gpio_desc *desc = ERR_PTR(-ENODEV);
bool active_low = false;
@@ -2056,7 +2058,7 @@ struct gpio_desc *fwnode_get_named_gpiod(struct
fwnode_handle *fwnode,
if (IS_ERR(desc))
return desc;
- ret = gpiod_request(desc, NULL);
+ ret = gpiod_request(desc, label);
if (ret)
return ERR_PTR(ret);
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 3a7c9ff..ef7d322 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -134,7 +134,8 @@ int desc_to_gpio(const struct gpio_desc *desc);
struct fwnode_handle;
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
-const char *propname);
+const char *propname,
+const char *label);
struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
const char *con_id,
struct fwnode_handle *child);
--
2.1.4
--
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: dst cache overflow
Herbert Xu wrote: > On Sat, Dec 15, 2007 at 11:08:58AM +0100, Tobias Diedrich wrote: > > > > Hmm, how do I look for that, if netstat doesn't look suspicous? > > Thanks. What does /proc/net/sockstat show? [EMAIL PROTECTED]:~$ cat /proc/net/sockstat sockets: used 143 TCP: inuse 16 orphan 0 tw 4 alloc 21 mem 1 UDP: inuse 8 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0 HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 -- 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: dst cache overflow
Herbert Xu wrote: On Sat, Dec 15, 2007 at 11:08:58AM +0100, Tobias Diedrich wrote: Hmm, how do I look for that, if netstat doesn't look suspicous? Thanks. What does /proc/net/sockstat show? [EMAIL PROTECTED]:~$ cat /proc/net/sockstat sockets: used 143 TCP: inuse 16 orphan 0 tw 4 alloc 21 mem 1 UDP: inuse 8 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0 HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 -- 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: dst cache overflow
Herbert Xu wrote: > Tobias Diedrich <[EMAIL PROTECTED]> wrote: > > > > Meanwhile I added a slab statistic rrd script. Nothing obvious to > > see on ari or yumi yet, but on oni (which after all is the most > > affected by this) I can see 'size_2048' and 'TCPv6' growing > > steadily along with the route cache size (Presumably 'ip_dst_cache', > > which is also growing larger at a more or less constant rate). > > OK that almost certainly means that we have a leak of TCPv6 > objects which would then cause a leak of dst objects. > > So you need to track down why TCPv6 isn't getting cleaned up. > First check the obvious, do you have any process(es) that are > hoarding TCPv6 sockets? Hmm, how do I look for that, if netstat doesn't look suspicous? > If not do you see a growing list of dead sockets in netstat? No, I don't think so. oni:~# netstat -an | wc -l 139 oni:~# netstat -tun Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 217.172.187.75:53668xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:40180yyy.yyy.yyy.yy:6871 TIME_WAIT tcp0 0 217.172.187.75:58480xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:49213xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:34828xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:44859xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:41863xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:38063xx.xxx.xx.x:6543ESTABLISHED tcp6 0 0 :::217.172.187.7:80 :::zz.zzz.zz.z:3729 TIME_WAIT tcp6 0 0 :::217.172.187.7:80 :::zz.zzz.zz.z:3726 TIME_WAIT tcp6 0 0 :::217.172.187.7:80 :::aa.aa.aaa.:59396 ESTABLISHED tcp6 0992 :::217.172.187.7:22 :::bb.bbb.bb.:57870 ESTABLISHED HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 -- 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: dst cache overflow
Herbert Xu wrote: Tobias Diedrich [EMAIL PROTECTED] wrote: Meanwhile I added a slab statistic rrd script. Nothing obvious to see on ari or yumi yet, but on oni (which after all is the most affected by this) I can see 'size_2048' and 'TCPv6' growing steadily along with the route cache size (Presumably 'ip_dst_cache', which is also growing larger at a more or less constant rate). OK that almost certainly means that we have a leak of TCPv6 objects which would then cause a leak of dst objects. So you need to track down why TCPv6 isn't getting cleaned up. First check the obvious, do you have any process(es) that are hoarding TCPv6 sockets? Hmm, how do I look for that, if netstat doesn't look suspicous? If not do you see a growing list of dead sockets in netstat? No, I don't think so. oni:~# netstat -an | wc -l 139 oni:~# netstat -tun Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 217.172.187.75:53668xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:40180yyy.yyy.yyy.yy:6871 TIME_WAIT tcp0 0 217.172.187.75:58480xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:49213xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:34828xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:44859xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:41863xx.xxx.xx.x:6543ESTABLISHED tcp0 0 217.172.187.75:38063xx.xxx.xx.x:6543ESTABLISHED tcp6 0 0 :::217.172.187.7:80 :::zz.zzz.zz.z:3729 TIME_WAIT tcp6 0 0 :::217.172.187.7:80 :::zz.zzz.zz.z:3726 TIME_WAIT tcp6 0 0 :::217.172.187.7:80 :::aa.aa.aaa.:59396 ESTABLISHED tcp6 0992 :::217.172.187.7:22 :::bb.bbb.bb.:57870 ESTABLISHED HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 -- 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: dst cache overflow
Eric Dumazet wrote: > On Tue, 14 Aug 2007 20:00:15 +0200 > Tobias Diedrich <[EMAIL PROTECTED]> wrote: > > > Eric Dumazet wrote: > > > > > Tobias Diedrich <[EMAIL PROTECTED]> wrote: > > > > > > > Hello, > > > > > > > > I suspect I'm seeing a slow dst cache leakage on one of my servers. > > > > The server in question (oni) regularly needs to be rebooted, because > > > > it loses network connectivity. However, netconsole and syslog shows > > > > that the > > > > machine is still running and the kernel complains about "dst cache > > > > overflow". > > > > > > > > I have since installed a monitoring script, which stores the output of > > > > both "ip route ls cache | fgrep cache | wc -l" and the 'entries' value > > > > of /proc/net/stat/rt_cache (as suggested in > > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg02107.html) > > > > and produces a nice rrd graph: > > > > > > > > http://uguu.de/~ranma/route-month-oni.png > > > > So entries is growing more or less constantly, while the number of > > > > active routes (not visible on the graph due to being too small) is > > > > relatively constant. > > > > > > > > Comparing this to another host running the exact same kernel: > > > > http://uguu.de/~ranma/route-month-ari.png > > > > Here cached_routes and entries barely differ at all. > > > > > > > > The funny thing is, both hosts are running the exact same kernel > > > > and use more or less the same iptables rules. > > > > > > > > So I'm not sure what would cause the dst cache to leak only on host > > > > oni? > > > > > > > > > > Could you send the result of these commands on oni and ari ? > > > > > > ip route ls > > > grep . /proc/sys/net/ipv4/route/* > > > > Sure. > > > > AFAICS the only visible difference is gc_thresh, which is probably > > double the size on oni since oni has double the amount of memory > > (512MB for oni vs. 256MB for ari). > > You might try to boot oni adding this to kernel commandline : > rhash_entries=2047 > so that oni has the same route cache hashtable, and see if it changes > anything. That hasn't helped I'm afraid. However I think it actually does affect all three systems running this kernel after all, the problme only manifests itself faster on oni. Meanwhile I added a slab statistic rrd script. Nothing obvious to see on ari or yumi yet, but on oni (which after all is the most affected by this) I can see 'size_2048' and 'TCPv6' growing steadily along with the route cache size (Presumably 'ip_dst_cache', which is also growing larger at a more or less constant rate). http://www.tdiedrich.de/~ranma/oni_20071214_route-week.png http://www.tdiedrich.de/~ranma/oni_20071214_slab-week.png http://www.tdiedrich.de/~ranma/oni_20071214_route-year.png http://www.tdiedrich.de/~ranma/ari_20071214_route-year.png http://www.tdiedrich.de/~ranma/yumi_20071214_route-year.png You can see that the difference on ari and yumi was also growing until they were rebooted (in the beginning of december for ari, beginning of november for yumi). Currently all three are running 2.6.23.9 and the problem is still there. HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 -- 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: dst cache overflow
Eric Dumazet wrote: On Tue, 14 Aug 2007 20:00:15 +0200 Tobias Diedrich [EMAIL PROTECTED] wrote: Eric Dumazet wrote: Tobias Diedrich [EMAIL PROTECTED] wrote: Hello, I suspect I'm seeing a slow dst cache leakage on one of my servers. The server in question (oni) regularly needs to be rebooted, because it loses network connectivity. However, netconsole and syslog shows that the machine is still running and the kernel complains about dst cache overflow. I have since installed a monitoring script, which stores the output of both ip route ls cache | fgrep cache | wc -l and the 'entries' value of /proc/net/stat/rt_cache (as suggested in http://www.mail-archive.com/[EMAIL PROTECTED]/msg02107.html) and produces a nice rrd graph: http://uguu.de/~ranma/route-month-oni.png So entries is growing more or less constantly, while the number of active routes (not visible on the graph due to being too small) is relatively constant. Comparing this to another host running the exact same kernel: http://uguu.de/~ranma/route-month-ari.png Here cached_routes and entries barely differ at all. The funny thing is, both hosts are running the exact same kernel and use more or less the same iptables rules. So I'm not sure what would cause the dst cache to leak only on host oni? Could you send the result of these commands on oni and ari ? ip route ls grep . /proc/sys/net/ipv4/route/* Sure. AFAICS the only visible difference is gc_thresh, which is probably double the size on oni since oni has double the amount of memory (512MB for oni vs. 256MB for ari). You might try to boot oni adding this to kernel commandline : rhash_entries=2047 so that oni has the same route cache hashtable, and see if it changes anything. That hasn't helped I'm afraid. However I think it actually does affect all three systems running this kernel after all, the problme only manifests itself faster on oni. Meanwhile I added a slab statistic rrd script. Nothing obvious to see on ari or yumi yet, but on oni (which after all is the most affected by this) I can see 'size_2048' and 'TCPv6' growing steadily along with the route cache size (Presumably 'ip_dst_cache', which is also growing larger at a more or less constant rate). http://www.tdiedrich.de/~ranma/oni_20071214_route-week.png http://www.tdiedrich.de/~ranma/oni_20071214_slab-week.png http://www.tdiedrich.de/~ranma/oni_20071214_route-year.png http://www.tdiedrich.de/~ranma/ari_20071214_route-year.png http://www.tdiedrich.de/~ranma/yumi_20071214_route-year.png You can see that the difference on ari and yumi was also growing until they were rebooted (in the beginning of december for ari, beginning of november for yumi). Currently all three are running 2.6.23.9 and the problem is still there. HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 -- 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: dst cache overflow
Eric Dumazet wrote: > Tobias Diedrich <[EMAIL PROTECTED]> wrote: > > > Hello, > > > > I suspect I'm seeing a slow dst cache leakage on one of my servers. > > The server in question (oni) regularly needs to be rebooted, because > > it loses network connectivity. However, netconsole and syslog shows that the > > machine is still running and the kernel complains about "dst cache > > overflow". > > > > I have since installed a monitoring script, which stores the output of > > both "ip route ls cache | fgrep cache | wc -l" and the 'entries' value > > of /proc/net/stat/rt_cache (as suggested in > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg02107.html) > > and produces a nice rrd graph: > > > > http://uguu.de/~ranma/route-month-oni.png > > So entries is growing more or less constantly, while the number of > > active routes (not visible on the graph due to being too small) is > > relatively constant. > > > > Comparing this to another host running the exact same kernel: > > http://uguu.de/~ranma/route-month-ari.png > > Here cached_routes and entries barely differ at all. > > > > The funny thing is, both hosts are running the exact same kernel > > and use more or less the same iptables rules. > > > > So I'm not sure what would cause the dst cache to leak only on host > > oni? > > > > Could you send the result of these commands on oni and ari ? > > ip route ls > grep . /proc/sys/net/ipv4/route/* Sure. AFAICS the only visible difference is gc_thresh, which is probably double the size on oni since oni has double the amount of memory (512MB for oni vs. 256MB for ari). Host oni: # ip route ls output: 217.172.187.0/24 dev eth0 proto kernel scope link src 217.172.187.75 default via 217.172.187.1 dev eth0 # grep output: /proc/sys/net/ipv4/route/error_burst:500 /proc/sys/net/ipv4/route/error_cost:100 /proc/sys/net/ipv4/route/gc_elasticity:8 /proc/sys/net/ipv4/route/gc_interval:60 /proc/sys/net/ipv4/route/gc_min_interval:0 /proc/sys/net/ipv4/route/gc_min_interval_ms:500 /proc/sys/net/ipv4/route/gc_thresh:4096 /proc/sys/net/ipv4/route/gc_timeout:300 /proc/sys/net/ipv4/route/max_delay:10 /proc/sys/net/ipv4/route/max_size:65536 /proc/sys/net/ipv4/route/min_adv_mss:256 /proc/sys/net/ipv4/route/min_delay:2 /proc/sys/net/ipv4/route/min_pmtu:552 /proc/sys/net/ipv4/route/mtu_expires:600 /proc/sys/net/ipv4/route/redirect_load:2 /proc/sys/net/ipv4/route/redirect_number:9 /proc/sys/net/ipv4/route/redirect_silence:2048 /proc/sys/net/ipv4/route/secret_interval:600 Host ari: # ip route ls output: 217.160.215.0/24 dev eth0 proto kernel scope link src 217.160.215.119 default via 217.160.215.1 dev eth0 # grep output: /proc/sys/net/ipv4/route/error_burst:500 /proc/sys/net/ipv4/route/error_cost:100 /proc/sys/net/ipv4/route/gc_elasticity:8 /proc/sys/net/ipv4/route/gc_interval:60 /proc/sys/net/ipv4/route/gc_min_interval:0 /proc/sys/net/ipv4/route/gc_min_interval_ms:500 /proc/sys/net/ipv4/route/gc_thresh:2048 /proc/sys/net/ipv4/route/gc_timeout:300 /proc/sys/net/ipv4/route/max_delay:10 /proc/sys/net/ipv4/route/max_size:32768 /proc/sys/net/ipv4/route/min_adv_mss:256 /proc/sys/net/ipv4/route/min_delay:2 /proc/sys/net/ipv4/route/min_pmtu:552 /proc/sys/net/ipv4/route/mtu_expires:600 /proc/sys/net/ipv4/route/redirect_load:2 /proc/sys/net/ipv4/route/redirect_number:9 /proc/sys/net/ipv4/route/redirect_silence:2048 /proc/sys/net/ipv4/route/secret_interval:600 -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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] fix NULL pointer dereference in __vm_enough_memory()
Andrew Morton wrote:
> erp, we have major version skew between 2.6.23-rc1-mm1 and 2.6.23-rc3 here,
> sorry.
>
> Could I ask for a redone patch against mainline?
Since I'm seeing this problem on 2.6.23-rc3, I tried adapting it.
I'm running it now and the NULL pointer messages are gone.
Index: linux-2.6.23-rc3/include/linux/mm.h
===
--- linux-2.6.23-rc3.orig/include/linux/mm.h2007-08-14 18:33:09.0
+0200
+++ linux-2.6.23-rc3/include/linux/mm.h 2007-08-14 19:31:59.0 +0200
@@ -1042,7 +1042,7 @@
}
/* mmap.c */
-extern int __vm_enough_memory(long pages, int cap_sys_admin);
+extern int __vm_enough_memory(struct mm_struct *mm, long pages, int
cap_sys_admin);
extern void vma_adjust(struct vm_area_struct *vma, unsigned long start,
unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert);
extern struct vm_area_struct *vma_merge(struct mm_struct *,
Index: linux-2.6.23-rc3/include/linux/security.h
===
--- linux-2.6.23-rc3.orig/include/linux/security.h 2007-08-14
18:33:10.0 +0200
+++ linux-2.6.23-rc3/include/linux/security.h 2007-08-14 19:38:24.0
+0200
@@ -54,7 +54,7 @@
extern int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t
old_suid, int flags);
extern void cap_task_reparent_to_init (struct task_struct *p);
extern int cap_syslog (int type);
-extern int cap_vm_enough_memory (long pages);
+extern int cap_vm_enough_memory (struct mm_struct *mm, long pages);
struct msghdr;
struct sk_buff;
@@ -1125,6 +1125,7 @@
* Return 0 if permission is granted.
* @vm_enough_memory:
* Check permissions for allocating a new virtual mapping.
+ * @mm contains the mm struct it is being added to.
* @pages contains the number of pages.
* Return 0 if permission is granted.
*
@@ -1169,7 +1170,7 @@
int (*quota_on) (struct dentry * dentry);
int (*syslog) (int type);
int (*settime) (struct timespec *ts, struct timezone *tz);
- int (*vm_enough_memory) (long pages);
+ int (*vm_enough_memory) (struct mm_struct *mm, long pages);
int (*bprm_alloc_security) (struct linux_binprm * bprm);
void (*bprm_free_security) (struct linux_binprm * bprm);
@@ -1469,10 +1470,14 @@
return security_ops->settime(ts, tz);
}
-
static inline int security_vm_enough_memory(long pages)
{
- return security_ops->vm_enough_memory(pages);
+ return security_ops->vm_enough_memory(current->mm, pages);
+}
+
+static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long
pages)
+{
+ return security_ops->vm_enough_memory(mm, pages);
}
static inline int security_bprm_alloc (struct linux_binprm *bprm)
@@ -2219,7 +2224,12 @@
static inline int security_vm_enough_memory(long pages)
{
- return cap_vm_enough_memory(pages);
+ return cap_vm_enough_memory(current->mm, pages);
+}
+
+static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long
pages)
+{
+ return cap_vm_enough_memory(mm, pages);
}
static inline int security_bprm_alloc (struct linux_binprm *bprm)
Index: linux-2.6.23-rc3/mm/mmap.c
===
--- linux-2.6.23-rc3.orig/mm/mmap.c 2007-08-14 18:33:11.0 +0200
+++ linux-2.6.23-rc3/mm/mmap.c 2007-08-14 19:31:59.0 +0200
@@ -93,7 +93,7 @@
* Note this is a helper function intended to be used by LSMs which
* wish to use this logic.
*/
-int __vm_enough_memory(long pages, int cap_sys_admin)
+int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
{
unsigned long free, allowed;
@@ -166,7 +166,7 @@
/* Don't let a single process grow too big:
leave 3% of the size of this process for other processes */
- allowed -= current->mm->total_vm / 32;
+ allowed -= mm->total_vm / 32;
/*
* cast `allowed' as a signed long because vm_committed_space
@@ -2077,7 +2077,7 @@
if (__vma && __vma->vm_start < vma->vm_end)
return -ENOMEM;
if ((vma->vm_flags & VM_ACCOUNT) &&
-security_vm_enough_memory(vma_pages(vma)))
+security_vm_enough_memory_mm(mm, vma_pages(vma)))
return -ENOMEM;
vma_link(mm, vma, prev, rb_link, rb_parent);
return 0;
Index: linux-2.6.23-rc3/mm/nommu.c
===
--- linux-2.6.23-rc3.orig/mm/nommu.c2007-08-14 18:33:12.0 +0200
+++ linux-2.6.23-rc3/mm/nommu.c 2007-08-14 19:31:59.0 +0200
@@ -1270,7 +1270,7 @@
* Note this is a helper function intended to be used by LSMs which
* wish to use this logic.
*/
-int __vm_enough_memory(long pages, int cap_sys_admin)
+int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
{
unsigned long free, allowed;
Index:
dst cache overflow
Hello, I suspect I'm seeing a slow dst cache leakage on one of my servers. The server in question (oni) regularly needs to be rebooted, because it loses network connectivity. However, netconsole and syslog shows that the machine is still running and the kernel complains about "dst cache overflow". I have since installed a monitoring script, which stores the output of both "ip route ls cache | fgrep cache | wc -l" and the 'entries' value of /proc/net/stat/rt_cache (as suggested in http://www.mail-archive.com/[EMAIL PROTECTED]/msg02107.html) and produces a nice rrd graph: http://uguu.de/~ranma/route-month-oni.png So entries is growing more or less constantly, while the number of active routes (not visible on the graph due to being too small) is relatively constant. Comparing this to another host running the exact same kernel: http://uguu.de/~ranma/route-month-ari.png Here cached_routes and entries barely differ at all. The funny thing is, both hosts are running the exact same kernel and use more or less the same iptables rules. So I'm not sure what would cause the dst cache to leak only on host oni? Kernel version: Linux oni 2.6.21.6-execshield-nokmem-tomodachi #1 Sun Jul 8 18:45:35 CEST 2007 i686 GNU/Linux With patches exec-shield-nx-2.6.19.patch (Slightly modified to make it apply on top of 2.6.21.6), patch-2.6.19-rc3-nokmem (Disables /dev/k?mem & /dev/port) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21.6 # Sun Jul 8 18:15:50 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=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_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y 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_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-execshield-nokmem-tomodachi" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # # CONFIG_MODULES is not set # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set 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_PARAVIRT 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=y # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 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_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_PREEMPT_NONE=y #
dst cache overflow
Hello, I suspect I'm seeing a slow dst cache leakage on one of my servers. The server in question (oni) regularly needs to be rebooted, because it loses network connectivity. However, netconsole and syslog shows that the machine is still running and the kernel complains about dst cache overflow. I have since installed a monitoring script, which stores the output of both ip route ls cache | fgrep cache | wc -l and the 'entries' value of /proc/net/stat/rt_cache (as suggested in http://www.mail-archive.com/[EMAIL PROTECTED]/msg02107.html) and produces a nice rrd graph: http://uguu.de/~ranma/route-month-oni.png So entries is growing more or less constantly, while the number of active routes (not visible on the graph due to being too small) is relatively constant. Comparing this to another host running the exact same kernel: http://uguu.de/~ranma/route-month-ari.png Here cached_routes and entries barely differ at all. The funny thing is, both hosts are running the exact same kernel and use more or less the same iptables rules. So I'm not sure what would cause the dst cache to leak only on host oni? Kernel version: Linux oni 2.6.21.6-execshield-nokmem-tomodachi #1 Sun Jul 8 18:45:35 CEST 2007 i686 GNU/Linux With patches exec-shield-nx-2.6.19.patch (Slightly modified to make it apply on top of 2.6.21.6), patch-2.6.19-rc3-nokmem (Disables /dev/k?mem /dev/port) # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21.6 # Sun Jul 8 18:15:50 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=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_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y 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_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-execshield-nokmem-tomodachi CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # # CONFIG_MODULES is not set # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set 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_PARAVIRT 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=y # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 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_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_CMPXCHG64=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_HPET_TIMER=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY
Re: [PATCH] fix NULL pointer dereference in __vm_enough_memory()
Andrew Morton wrote:
erp, we have major version skew between 2.6.23-rc1-mm1 and 2.6.23-rc3 here,
sorry.
Could I ask for a redone patch against mainline?
Since I'm seeing this problem on 2.6.23-rc3, I tried adapting it.
I'm running it now and the NULL pointer messages are gone.
Index: linux-2.6.23-rc3/include/linux/mm.h
===
--- linux-2.6.23-rc3.orig/include/linux/mm.h2007-08-14 18:33:09.0
+0200
+++ linux-2.6.23-rc3/include/linux/mm.h 2007-08-14 19:31:59.0 +0200
@@ -1042,7 +1042,7 @@
}
/* mmap.c */
-extern int __vm_enough_memory(long pages, int cap_sys_admin);
+extern int __vm_enough_memory(struct mm_struct *mm, long pages, int
cap_sys_admin);
extern void vma_adjust(struct vm_area_struct *vma, unsigned long start,
unsigned long end, pgoff_t pgoff, struct vm_area_struct *insert);
extern struct vm_area_struct *vma_merge(struct mm_struct *,
Index: linux-2.6.23-rc3/include/linux/security.h
===
--- linux-2.6.23-rc3.orig/include/linux/security.h 2007-08-14
18:33:10.0 +0200
+++ linux-2.6.23-rc3/include/linux/security.h 2007-08-14 19:38:24.0
+0200
@@ -54,7 +54,7 @@
extern int cap_task_post_setuid (uid_t old_ruid, uid_t old_euid, uid_t
old_suid, int flags);
extern void cap_task_reparent_to_init (struct task_struct *p);
extern int cap_syslog (int type);
-extern int cap_vm_enough_memory (long pages);
+extern int cap_vm_enough_memory (struct mm_struct *mm, long pages);
struct msghdr;
struct sk_buff;
@@ -1125,6 +1125,7 @@
* Return 0 if permission is granted.
* @vm_enough_memory:
* Check permissions for allocating a new virtual mapping.
+ * @mm contains the mm struct it is being added to.
* @pages contains the number of pages.
* Return 0 if permission is granted.
*
@@ -1169,7 +1170,7 @@
int (*quota_on) (struct dentry * dentry);
int (*syslog) (int type);
int (*settime) (struct timespec *ts, struct timezone *tz);
- int (*vm_enough_memory) (long pages);
+ int (*vm_enough_memory) (struct mm_struct *mm, long pages);
int (*bprm_alloc_security) (struct linux_binprm * bprm);
void (*bprm_free_security) (struct linux_binprm * bprm);
@@ -1469,10 +1470,14 @@
return security_ops-settime(ts, tz);
}
-
static inline int security_vm_enough_memory(long pages)
{
- return security_ops-vm_enough_memory(pages);
+ return security_ops-vm_enough_memory(current-mm, pages);
+}
+
+static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long
pages)
+{
+ return security_ops-vm_enough_memory(mm, pages);
}
static inline int security_bprm_alloc (struct linux_binprm *bprm)
@@ -2219,7 +2224,12 @@
static inline int security_vm_enough_memory(long pages)
{
- return cap_vm_enough_memory(pages);
+ return cap_vm_enough_memory(current-mm, pages);
+}
+
+static inline int security_vm_enough_memory_mm(struct mm_struct *mm, long
pages)
+{
+ return cap_vm_enough_memory(mm, pages);
}
static inline int security_bprm_alloc (struct linux_binprm *bprm)
Index: linux-2.6.23-rc3/mm/mmap.c
===
--- linux-2.6.23-rc3.orig/mm/mmap.c 2007-08-14 18:33:11.0 +0200
+++ linux-2.6.23-rc3/mm/mmap.c 2007-08-14 19:31:59.0 +0200
@@ -93,7 +93,7 @@
* Note this is a helper function intended to be used by LSMs which
* wish to use this logic.
*/
-int __vm_enough_memory(long pages, int cap_sys_admin)
+int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
{
unsigned long free, allowed;
@@ -166,7 +166,7 @@
/* Don't let a single process grow too big:
leave 3% of the size of this process for other processes */
- allowed -= current-mm-total_vm / 32;
+ allowed -= mm-total_vm / 32;
/*
* cast `allowed' as a signed long because vm_committed_space
@@ -2077,7 +2077,7 @@
if (__vma __vma-vm_start vma-vm_end)
return -ENOMEM;
if ((vma-vm_flags VM_ACCOUNT)
-security_vm_enough_memory(vma_pages(vma)))
+security_vm_enough_memory_mm(mm, vma_pages(vma)))
return -ENOMEM;
vma_link(mm, vma, prev, rb_link, rb_parent);
return 0;
Index: linux-2.6.23-rc3/mm/nommu.c
===
--- linux-2.6.23-rc3.orig/mm/nommu.c2007-08-14 18:33:12.0 +0200
+++ linux-2.6.23-rc3/mm/nommu.c 2007-08-14 19:31:59.0 +0200
@@ -1270,7 +1270,7 @@
* Note this is a helper function intended to be used by LSMs which
* wish to use this logic.
*/
-int __vm_enough_memory(long pages, int cap_sys_admin)
+int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
{
unsigned long free, allowed;
Index:
Re: dst cache overflow
Eric Dumazet wrote: Tobias Diedrich [EMAIL PROTECTED] wrote: Hello, I suspect I'm seeing a slow dst cache leakage on one of my servers. The server in question (oni) regularly needs to be rebooted, because it loses network connectivity. However, netconsole and syslog shows that the machine is still running and the kernel complains about dst cache overflow. I have since installed a monitoring script, which stores the output of both ip route ls cache | fgrep cache | wc -l and the 'entries' value of /proc/net/stat/rt_cache (as suggested in http://www.mail-archive.com/[EMAIL PROTECTED]/msg02107.html) and produces a nice rrd graph: http://uguu.de/~ranma/route-month-oni.png So entries is growing more or less constantly, while the number of active routes (not visible on the graph due to being too small) is relatively constant. Comparing this to another host running the exact same kernel: http://uguu.de/~ranma/route-month-ari.png Here cached_routes and entries barely differ at all. The funny thing is, both hosts are running the exact same kernel and use more or less the same iptables rules. So I'm not sure what would cause the dst cache to leak only on host oni? Could you send the result of these commands on oni and ari ? ip route ls grep . /proc/sys/net/ipv4/route/* Sure. AFAICS the only visible difference is gc_thresh, which is probably double the size on oni since oni has double the amount of memory (512MB for oni vs. 256MB for ari). Host oni: # ip route ls output: 217.172.187.0/24 dev eth0 proto kernel scope link src 217.172.187.75 default via 217.172.187.1 dev eth0 # grep output: /proc/sys/net/ipv4/route/error_burst:500 /proc/sys/net/ipv4/route/error_cost:100 /proc/sys/net/ipv4/route/gc_elasticity:8 /proc/sys/net/ipv4/route/gc_interval:60 /proc/sys/net/ipv4/route/gc_min_interval:0 /proc/sys/net/ipv4/route/gc_min_interval_ms:500 /proc/sys/net/ipv4/route/gc_thresh:4096 /proc/sys/net/ipv4/route/gc_timeout:300 /proc/sys/net/ipv4/route/max_delay:10 /proc/sys/net/ipv4/route/max_size:65536 /proc/sys/net/ipv4/route/min_adv_mss:256 /proc/sys/net/ipv4/route/min_delay:2 /proc/sys/net/ipv4/route/min_pmtu:552 /proc/sys/net/ipv4/route/mtu_expires:600 /proc/sys/net/ipv4/route/redirect_load:2 /proc/sys/net/ipv4/route/redirect_number:9 /proc/sys/net/ipv4/route/redirect_silence:2048 /proc/sys/net/ipv4/route/secret_interval:600 Host ari: # ip route ls output: 217.160.215.0/24 dev eth0 proto kernel scope link src 217.160.215.119 default via 217.160.215.1 dev eth0 # grep output: /proc/sys/net/ipv4/route/error_burst:500 /proc/sys/net/ipv4/route/error_cost:100 /proc/sys/net/ipv4/route/gc_elasticity:8 /proc/sys/net/ipv4/route/gc_interval:60 /proc/sys/net/ipv4/route/gc_min_interval:0 /proc/sys/net/ipv4/route/gc_min_interval_ms:500 /proc/sys/net/ipv4/route/gc_thresh:2048 /proc/sys/net/ipv4/route/gc_timeout:300 /proc/sys/net/ipv4/route/max_delay:10 /proc/sys/net/ipv4/route/max_size:32768 /proc/sys/net/ipv4/route/min_adv_mss:256 /proc/sys/net/ipv4/route/min_delay:2 /proc/sys/net/ipv4/route/min_pmtu:552 /proc/sys/net/ipv4/route/mtu_expires:600 /proc/sys/net/ipv4/route/redirect_load:2 /proc/sys/net/ipv4/route/redirect_number:9 /proc/sys/net/ipv4/route/redirect_silence:2048 /proc/sys/net/ipv4/route/secret_interval:600 -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: > > > > Rafael J. Wysocki wrote: > > > > > On Sunday, 15 April 2007 17:14, David Brownell wrote: > > > > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: > > > > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > > > I think using the 'shutdown' mode of suspend would be better. > > > > > > > There's a little > > > > > > > point in using 'platform' on desktop systems anyway. > > > > > > > > > > > > > > Frankly, I don't know what to do about it. If we move > > > > > > > platform_finish() after > > > > > > > device_resume(), some systems may be broken ... > > > > > > > > > > > > What I'm curious about is exactly why the patch matters. What ACPI > > > > > > magic is being invoked to confuse, or unconfuse, those controllers? > > > > > > > > > > I think the patch helps, because it makes the ACPI magic be done > > > > > while the > > > > > i8042's .resume() is being executed. > > > > > > > > > > Which makes me think the following patch might help: > > > > > > > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. > > > > > > Well, this means i8042 can be ruled out, so the problem probably is > > > related > > > to the ACPI resume which makes it _much_ more difficult to debug. > > > > > > Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. > > > as > > > modules, boot the kernel with init=/bin/bash and see if the problem is > > > still > > > present (please keep CONFIG_SERIO_I8042 unset just in case)? > > > > > > Rafael > > > > I first tried it with acpi+cpufreq completely disabled (works). > > Then I tried it with acpi enabled, but everything as modules and > > those not loaded (init=/bin/bash, hangs at second suspend). > > Have you tried with ACPI and without cpufreq? Yes, the second one was with ACPI enabled and cpufreq disabled (CONFIG_X86_ACPI_CPUFREQ is not set). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Sunday, 15 April 2007 17:14, David Brownell wrote: > > > > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: > > > > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: > > > > > I think using the 'shutdown' mode of suspend would be better. > > > > > There's a little > > > > > point in using 'platform' on desktop systems anyway. > > > > > > > > > > Frankly, I don't know what to do about it. If we move > > > > > platform_finish() after > > > > > device_resume(), some systems may be broken ... > > > > > > > > What I'm curious about is exactly why the patch matters. What ACPI > > > > magic is being invoked to confuse, or unconfuse, those controllers? > > > > > > I think the patch helps, because it makes the ACPI magic be done while the > > > i8042's .resume() is being executed. > > > > > > Which makes me think the following patch might help: > > > > Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. > > Well, this means i8042 can be ruled out, so the problem probably is related > to the ACPI resume which makes it _much_ more difficult to debug. > > Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as > modules, boot the kernel with init=/bin/bash and see if the problem is still > present (please keep CONFIG_SERIO_I8042 unset just in case)? > > Rafael I first tried it with acpi+cpufreq completely disabled (works). Then I tried it with acpi enabled, but everything as modules and those not loaded (init=/bin/bash, hangs at second suspend). # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7 # Sun Apr 22 09:26:07 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # 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 # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y 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" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATM
Re: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 17:14, David Brownell wrote: On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken ... What I'm curious about is exactly why the patch matters. What ACPI magic is being invoked to confuse, or unconfuse, those controllers? I think the patch helps, because it makes the ACPI magic be done while the i8042's .resume() is being executed. Which makes me think the following patch might help: Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. Well, this means i8042 can be ruled out, so the problem probably is related to the ACPI resume which makes it _much_ more difficult to debug. Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as modules, boot the kernel with init=/bin/bash and see if the problem is still present (please keep CONFIG_SERIO_I8042 unset just in case)? Rafael I first tried it with acpi+cpufreq completely disabled (works). Then I tried it with acpi enabled, but everything as modules and those not loaded (init=/bin/bash, hangs at second suspend). # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc7 # Sun Apr 22 09:26:07 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_EMBEDDED=y CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # 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 # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y 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 # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y
Re: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Wednesday, 25 April 2007 19:14, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 21:40, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Sunday, 15 April 2007 17:14, David Brownell wrote: On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote: On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote: I think using the 'shutdown' mode of suspend would be better. There's a little point in using 'platform' on desktop systems anyway. Frankly, I don't know what to do about it. If we move platform_finish() after device_resume(), some systems may be broken ... What I'm curious about is exactly why the patch matters. What ACPI magic is being invoked to confuse, or unconfuse, those controllers? I think the patch helps, because it makes the ACPI magic be done while the i8042's .resume() is being executed. Which makes me think the following patch might help: Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042. Well, this means i8042 can be ruled out, so the problem probably is related to the ACPI resume which makes it _much_ more difficult to debug. Can you compile the ACPI drivers: processor, thermal, fan, battery, etc. as modules, boot the kernel with init=/bin/bash and see if the problem is still present (please keep CONFIG_SERIO_I8042 unset just in case)? Rafael I first tried it with acpi+cpufreq completely disabled (works). Then I tried it with acpi enabled, but everything as modules and those not loaded (init=/bin/bash, hangs at second suspend). Have you tried with ACPI and without cpufreq? Yes, the second one was with ACPI enabled and cpufreq disabled (CONFIG_X86_ACPI_CPUFREQ is not set). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote:
> On Sunday, 15 April 2007 17:14, David Brownell wrote:
> > On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
> > > On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
> >
> > > > > > > Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
> > > > > > > single core CPU.
> >
> > And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
> > would be to disable the EHCI (high speed USB) support in BIOS, to make
> > for a simpler hardware configuration, and see if that makes BIOS happier.
> > (Or better, just take EHCI out of your Linux config.) Likewise, taking
> > the 8042 drivers out of Linux.
> >
> > I wouldn't be surprised if those factors didn't matter, but it'd be good
> > to rule them out.
>
> I think the disabling of i8042 support might help.
Still hangs with "# CONFIG_SERIO_I8042 is not set".
> > > Dmitry, could you please have a look?
> > >
> > > > And I can now confirm that unpatched 2.6.21-rc6 works fine as long
> > > > as USB legacy support is disabled (however without legacy support I
> > > > can't use the USB keyboard to control grub).
> > >
> > > I think using the 'shutdown' mode of suspend would be better. There's a
> > > little
> > > point in using 'platform' on desktop systems anyway.
> > >
> > > Frankly, I don't know what to do about it. If we move platform_finish()
> > > after
> > > device_resume(), some systems may be broken ...
> >
> > What I'm curious about is exactly why the patch matters. What ACPI
> > magic is being invoked to confuse, or unconfuse, those controllers?
>
> I think the patch helps, because it makes the ACPI magic be done while the
> i8042's .resume() is being executed.
>
> Which makes me think the following patch might help:
Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.
> drivers/input/serio/i8042.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
> ===
> --- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
> 12:15:19.0 +0200
> +++ linux-2.6.21-rc6/drivers/input/serio/i8042.c 2007-04-15
> 18:30:01.0 +0200
> @@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
> static int i8042_suspend(struct platform_device *dev, pm_message_t state)
> {
> if (dev->dev.power.power_state.event != state.event) {
> - if (state.event == PM_EVENT_SUSPEND)
> + if (state.event == PM_EVENT_SUSPEND
> + || state.event == PM_EVENT_PRETHAW)
> i8042_controller_reset();
>
> dev->dev.power.power_state = state;
> -
> 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/
>
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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: Linux 2.6.21-rc6
Tobias Diedrich wrote: > Rafael J. Wysocki wrote: > > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > > > Rafael J. Wysocki wrote: > > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > > > Rafael J. Wysocki wrote: > > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > > > Tobias Diedrich wrote: > > > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so > > > > > > > > > > that device_suspend() is > > > > > > > > > > called before disable_nonboot_cpus() and > > > > > > > > > > platform_finish() is called after > > > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > > > indicated by the recent > > > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit > > > > > > > > > > from -rc6. :) > > > > > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > > > > reverted from -rc1. > > > > > > > > > > > > > > > > Now, this was already reported in > > > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > > > and I even flagged that message in my local folder, but > > > > > > > > apparently forgot > > > > > > > > to follow up on it... *sigh* > > > > > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim > > > > > > > described in > > > > > > > this email are fixed for him in -rc6. > > > > > > > > > > > > > > But it's quite possible that you are running into a different > > > > > > > issue > > > > > > > exposed by this commit. > > > > > > > > > > > > Yes, it's likely. > > > > > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but > > > > > &
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > > > Rafael J. Wysocki wrote: > > > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > > > Tobias Diedrich wrote: > > > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so > > > > > > > > > that device_suspend() is > > > > > > > > > called before disable_nonboot_cpus() and > > > > > > > > > platform_finish() is called after > > > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > > > indicated by the recent > > > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from > > > > > > > > > -rc6. :) > > > > > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > > > reverted from -rc1. > > > > > > > > > > > > > > Now, this was already reported in > > > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > > > and I even flagged that message in my local folder, but > > > > > > > apparently forgot > > > > > > > to follow up on it... *sigh* > > > > > > > > > > > > Unless I misunderstood something, all of the problems Maxim > > > > > > described in > > > > > > this email are fixed for him in -rc6. > > > > > > > > > > > > But it's quite possible that you are running into a different issue > > > > > > exposed by this commit. > > > > > > > > > > Yes, it's likely. > > > > > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but my > > > > > hardware > > > > > is certainly different. Which suspend mode do you use? If that's > > > > > "platform", > > > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > > > > > Sure. > > > > shutdown/reboot works fine, only platform is broken. >
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. Thanks. Now, I suspect the problem is somehow related to the hardware, so it would help a lot if we could identify the piece of hardware (or driver) involved. AFAICT, your system is a non-SMP one, so we can rule out disable/enable_nonboot_cpus(). To confirm that the problem is related to platform_finish(), can you please apply the appended debug patch and see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) Well, I thought it would, but it also would break some other people's systems. That's the _real_ problem. Let's see if we can learn more. Can you please revert it for now, apply the appended one and try to suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 23:35, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. Thanks. Now, I suspect the problem is somehow related to the hardware, so it would help a lot if we could identify the piece of hardware (or driver) involved. AFAICT, your system is a non-SMP one, so we can rule out disable/enable_nonboot_cpus(). To confirm that the problem is related to platform_finish(), can you please apply the appended debug patch and see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. Also, would that be feasible for you to use 'shutdown' as a workaround in case the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) Well, I thought it would, but it also would break some other people's systems. That's the _real_ problem. Let's see if we can learn more. Can you please revert it for now, apply the appended one and try to suspend/resume twice in the 'platform' mode (it may or may not work)? Ok. The patch doesn't apply cleanly to 2.6.21-rc6: |patching file kernel/power/disk.c |Hunk #1 FAILED at 267. |Hunk #2 succeeded at 265 (offset -23 lines). |1 out of 2 hunks FAILED -- saving rejects to file |kernel/power/disk.c.rej wiggle helps, seems the first part of Hunk #1 is already applied in 2.6.21-rc6. With CONFIG_PM_DEBUG=y and CONFIG_DISABLE_CONSOLE_SUSPEND=y I see that the second suspend hangs at i8042 i8042: EARLY resume. This is kinda interesting because I'm normally using a USB keyboard and sure enough, if I hook up a normal keyboard and disable USB legacy support in the BIOS, then suspend to disk works multiple times. I'd still rather like to use my USB keyboard though. ;) And I can now confirm that unpatched 2.6.21-rc6 works fine as long as USB legacy support is disabled (however without legacy support I can't use the USB keyboard to control grub). -- Tobias PGP
Re: [linux-pm] Linux 2.6.21-rc6
Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 17:14, David Brownell wrote:
On Sunday 15 April 2007 4:16 am, Rafael J. Wysocki wrote:
On Sunday, 15 April 2007 10:02, Tobias Diedrich wrote:
Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
single core CPU.
And NVidia southbridge, so OHCI not UHCI (plus EHCI) ... one experiment
would be to disable the EHCI (high speed USB) support in BIOS, to make
for a simpler hardware configuration, and see if that makes BIOS happier.
(Or better, just take EHCI out of your Linux config.) Likewise, taking
the 8042 drivers out of Linux.
I wouldn't be surprised if those factors didn't matter, but it'd be good
to rule them out.
I think the disabling of i8042 support might help.
Still hangs with # CONFIG_SERIO_I8042 is not set.
Dmitry, could you please have a look?
And I can now confirm that unpatched 2.6.21-rc6 works fine as long
as USB legacy support is disabled (however without legacy support I
can't use the USB keyboard to control grub).
I think using the 'shutdown' mode of suspend would be better. There's a
little
point in using 'platform' on desktop systems anyway.
Frankly, I don't know what to do about it. If we move platform_finish()
after
device_resume(), some systems may be broken ...
What I'm curious about is exactly why the patch matters. What ACPI
magic is being invoked to confuse, or unconfuse, those controllers?
I think the patch helps, because it makes the ACPI magic be done while the
i8042's .resume() is being executed.
Which makes me think the following patch might help:
Unfortunately not, I tried this before disabling CONFIG_SERIO_I8042.
drivers/input/serio/i8042.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.21-rc6/drivers/input/serio/i8042.c
===
--- linux-2.6.21-rc6.orig/drivers/input/serio/i8042.c 2007-04-07
12:15:19.0 +0200
+++ linux-2.6.21-rc6/drivers/input/serio/i8042.c 2007-04-15
18:30:01.0 +0200
@@ -846,7 +846,8 @@ static long i8042_panic_blink(long count
static int i8042_suspend(struct platform_device *dev, pm_message_t state)
{
if (dev-dev.power.power_state.event != state.event) {
- if (state.event == PM_EVENT_SUSPEND)
+ if (state.event == PM_EVENT_SUSPEND
+ || state.event == PM_EVENT_PRETHAW)
i8042_controller_reset();
dev-dev.power.power_state = state;
-
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/
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote: > > Rafael J. Wysocki wrote: > > > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > > > Tobias Diedrich wrote: > > > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > > > > > device_suspend() is > > > > > > > called before disable_nonboot_cpus() and platform_finish() is > > > > > > > called after > > > > > > > enable_nonboot_cpus() and before device_resume(), as > > > > > > > indicated by the recent > > > > > > > discussion on Linux-PM (cf. > > > > > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from > > > > > > > -rc6. :) > > > > > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > > > reverted from -rc1. > > > > > > > > > > Now, this was already reported in > > > > > http://lkml.org/lkml/2007/3/16/126 > > > > > and I even flagged that message in my local folder, but apparently > > > > > forgot > > > > > to follow up on it... *sigh* > > > > > > > > Unless I misunderstood something, all of the problems Maxim described > > > > in > > > > this email are fixed for him in -rc6. > > > > > > > > But it's quite possible that you are running into a different issue > > > > exposed by this commit. > > > > > > Yes, it's likely. > > > > > > Tobias, I'm unable to reproduce the problem with your .config, but my > > > hardware > > > is certainly different. Which suspend mode do you use? If that's > > > "platform", > > > can you try to use "shutdown" or "reboot" and see if that helps? > > > > Sure. > > shutdown/reboot works fine, only platform is broken. > > Thanks. > > Now, I suspect the problem is somehow related to the hardware, so it would > help > a lot if we could identify the piece of hardware (or driver) involved. > > AFAICT, your system is a non-SMP one, so we can rule out > disable/enable_nonboot_cpus(). To confirm that the problem is related to > platform_finish(), can you please apply the appended debug patch and > see if the suspend in the 'platform' mode works with it? Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+ single core CPU. > Also, would that be feasible for you to use 'shutdown' as a workaround in case > the source of the problem is difficult to find and/or fix? I guess so, but the below patch fixes the problem. :) >
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: > > On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: > > > Tobias Diedrich wrote: > > > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > > > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > > > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > > > > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > > > > > > > Change the ordering of code in kernel/power/disk.c so that > > > > > device_suspend() is > > > > > called before disable_nonboot_cpus() and platform_finish() is > > > > > called after > > > > > enable_nonboot_cpus() and before device_resume(), as indicated by > > > > > the recent > > > > > discussion on Linux-PM (cf. > > > > > > > > > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > > > > > > > The changes here only affect the built-in swsusp. > > > > > > > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > > > > Cc: Greg KH <[EMAIL PROTECTED]> > > > > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > > > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > > > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > > > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > > > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > > > > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > > > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > > > > > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > > > > > > > Doesn't apply cleanly against -rc6, but fixes the problem when > > > > reverted from -rc1. > > > > > > Now, this was already reported in > > > http://lkml.org/lkml/2007/3/16/126 > > > and I even flagged that message in my local folder, but apparently forgot > > > to follow up on it... *sigh* > > > > Unless I misunderstood something, all of the problems Maxim described in > > this email are fixed for him in -rc6. > > > > But it's quite possible that you are running into a different issue > > exposed by this commit. > > Yes, it's likely. > > Tobias, I'm unable to reproduce the problem with your .config, but my hardware > is certainly different. Which suspend mode do you use? If that's "platform", > can you try to use "shutdown" or "reboot" and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. -- Tobias PGP: http://9ac7e0bc.uguu.de - 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: Linux 2.6.21-rc6
Tobias Diedrich wrote: > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > > commit ed746e3b18f4df18afa3763155972c5835f284c5 > > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Date: Sat Feb 10 01:43:32 2007 -0800 > > > > [PATCH] swsusp: Change code ordering in disk.c > > > > Change the ordering of code in kernel/power/disk.c so that > > device_suspend() is > > called before disable_nonboot_cpus() and platform_finish() is called > > after > > enable_nonboot_cpus() and before device_resume(), as indicated by the > > recent > > discussion on Linux-PM (cf. > > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > > > The changes here only affect the built-in swsusp. > > > > [EMAIL PROTECTED]: fix LED blinking during image load] > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > > Cc: Greg KH <[EMAIL PROTECTED]> > > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > > Cc: Patrick Mochel <[EMAIL PROTECTED]> > > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > > > > Now, the remaining test is to try reverting this commit from -rc6. :) > > Doesn't apply cleanly against -rc6, but fixes the problem when > reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Tobias Diedrich wrote: > Adrian Bunk wrote: > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > > Linus Torvalds wrote: > > > > > > > We should be getting close to a 2.6.21 release, so please update any > > > > regression reports you've done, > > > > > > For me, suspend to disk works only once (has been the case for all > > > .21-rcs IIRC, but I didn't get around to report it so far). > > > There are some threads about an issue like this, which is supposed > > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > > problem persists nonetheless. > > > > > > On the second suspend attempt, the last message I see is > > > "Suspending console(s)" > > > > > > If I find the time, I'll try to bisect it this weekend. > > >... > > > > Does CONFIG_HPET_TIMER=n make any difference? > > Does the latest -git work? > > bisect results: > > git-bisect start > # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 > git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 > # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 > git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba > # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of > git://ftp.linux-mips.org/pub/scm/upstream-linus > git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 > # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge > master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 > git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 > # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile > cleanups > git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 > # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support > higher rates > git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f > # good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal > with cases of ZONE_DMA meaning the first zone > git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b > # bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting > fixes > git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61 > # bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE > macro when appropriate > git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0 > # good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE > macro when appropriate > git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4 > # bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and > update_mmu_cache > git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a > # bad: [d12c610e08022a1b84d6bd4412c189214d32e713] > swsusp-change-code-ordering-in-userc-sanity > git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713 > # bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code > ordering in disk.c > git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5 > # good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering > in main.c > git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557 > > > ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit > commit ed746e3b18f4df18afa3763155972c5835f284c5 > Author: Rafael J. Wysocki <[EMAIL PROTECTED]> > Date: Sat Feb 10 01:43:32 2007 -0800 > > [PATCH] swsusp: Change code ordering in disk.c > > Change the ordering of code in kernel/power/disk.c so that > device_suspend() is > called before disable_nonboot_cpus() and platform_finish() is called after > enable_nonboot_cpus() and before device_resume(), as indicated by the > recent > discussion on Linux-PM (cf. > http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). > > The changes here only affect the built-in swsusp. > > [EMAIL PROTECTED]: fix LED blinking during image load] > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > Acked-by: Pavel Machek <[EMAIL PROTECTED]> > Cc: Greg KH <[EMAIL PROTECTED]> > Cc: Nigel Cunningham <[EMAIL PROTECTED]> > Cc: Patrick Mochel <[EMAIL PROTECTED]> > Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> > Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> > > :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 > 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel > > > Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > Linus Torvalds wrote: > > > > > We should be getting close to a 2.6.21 release, so please update any > > > regression reports you've done, > > > > For me, suspend to disk works only once (has been the case for all > > .21-rcs IIRC, but I didn't get around to report it so far). > > There are some threads about an issue like this, which is supposed > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > problem persists nonetheless. > > > > On the second suspend attempt, the last message I see is > > "Suspending console(s)" > > > > If I find the time, I'll try to bisect it this weekend. > >... > > Does CONFIG_HPET_TIMER=n make any difference? > Does the latest -git work? bisect results: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f # good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal with cases of ZONE_DMA meaning the first zone git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b # bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting fixes git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61 # bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE macro when appropriate git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0 # good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE macro when appropriate git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4 # bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and update_mmu_cache git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a # bad: [d12c610e08022a1b84d6bd4412c189214d32e713] swsusp-change-code-ordering-in-userc-sanity git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713 # bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code ordering in disk.c git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5 # good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering in main.c git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557 ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki <[EMAIL PROTECTED]> Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> Cc: Greg KH <[EMAIL PROTECTED]> Cc: Nigel Cunningham <[EMAIL PROTECTED]> Cc: Patrick Mochel <[EMAIL PROTECTED]> Cc: Alexey Starikovskiy <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: > On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote: > > Adrian Bunk wrote: > > > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > > > Linus Torvalds wrote: > > > > > > > > > We should be getting close to a 2.6.21 release, so please update any > > > > > regression reports you've done, > > > > > > > > For me, suspend to disk works only once (has been the case for all > > > > .21-rcs IIRC, but I didn't get around to report it so far). > > > > There are some threads about an issue like this, which is supposed > > > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > > > problem persists nonetheless. > > > > > > > > On the second suspend attempt, the last message I see is > > > > "Suspending console(s)" > > > > > > > > If I find the time, I'll try to bisect it this weekend. > > > >... > > > > > > Does the latest -git work? > > > > Still no luck with > > Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 > > CEST 2007 x86_64 GNU/Linux > > Can you boot with init=/bin/bash and see if the problem is present in this > configuration? Doesn't help. Maybe interesting: In the init=/bin/bash run, the first suspend try was without swap and thus bailed out. After swapon, the second try already hung, despite not having 'really' suspended at all on the first try. I tried it once more, with swap on the first try and got the same 'second try doesn't work' result. git-bisect so far: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Adrian Bunk wrote: > On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: > > Linus Torvalds wrote: > > > > > We should be getting close to a 2.6.21 release, so please update any > > > regression reports you've done, > > > > For me, suspend to disk works only once (has been the case for all > > .21-rcs IIRC, but I didn't get around to report it so far). > > There are some threads about an issue like this, which is supposed > > to be fixed by disabling CONFIG_PCI_MSI, but on my system the > > problem persists nonetheless. > > > > On the second suspend attempt, the last message I see is > > "Suspending console(s)" > > > > If I find the time, I'll try to bisect it this weekend. > >... > > Does the latest -git work? Still no luck with Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST 2007 x86_64 GNU/Linux Why -dirty? Maybe because I modified the Makefile to use ccache? > Does CONFIG_HPET_TIMER=n make any difference? Hmm, I just noticed that CONFIG_HPET_TIMER was forced back on after make oldconfig... Is that expected on amd64? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6 # Sat Apr 14 09:33:36 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # 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 # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y 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" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CO
Re: Linux 2.6.21-rc6
Adrian Bunk wrote: > Does CONFIG_HPET_TIMER=n make any difference? Unfortunately not. > Does the latest -git work? Coming up next :) -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Adrian Bunk wrote: Does CONFIG_HPET_TIMER=n make any difference? Unfortunately not. Does the latest -git work? Coming up next :) -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Adrian Bunk wrote: On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does the latest -git work? Still no luck with Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST 2007 x86_64 GNU/Linux Why -dirty? Maybe because I modified the Makefile to use ccache? Does CONFIG_HPET_TIMER=n make any difference? Hmm, I just noticed that CONFIG_HPET_TIMER was forced back on after make oldconfig... Is that expected on amd64? # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6 # Sat Apr 14 09:33:36 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # 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 # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y 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 # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y
Re: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Saturday, 14 April 2007 10:16, Tobias Diedrich wrote: Adrian Bunk wrote: On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does the latest -git work? Still no luck with Linux melchior 2.6.21-rc6-gd791d413-dirty #4 PREEMPT Sat Apr 14 09:34:21 CEST 2007 x86_64 GNU/Linux Can you boot with init=/bin/bash and see if the problem is present in this configuration? Doesn't help. Maybe interesting: In the init=/bin/bash run, the first suspend try was without swap and thus bailed out. After swapon, the second try already hung, despite not having 'really' suspended at all on the first try. I tried it once more, with swap on the first try and got the same 'second try doesn't work' result. git-bisect so far: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Adrian Bunk wrote: On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote: Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. ... Does CONFIG_HPET_TIMER=n make any difference? Does the latest -git work? bisect results: git-bisect start # good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20 git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7 # bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1 git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba # bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8 # good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6 git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1 # good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile cleanups git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9 # bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support higher rates git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f # good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal with cases of ZONE_DMA meaning the first zone git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b # bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting fixes git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61 # bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE macro when appropriate git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0 # good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE macro when appropriate git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4 # bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and update_mmu_cache git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a # bad: [d12c610e08022a1b84d6bd4412c189214d32e713] swsusp-change-code-ordering-in-userc-sanity git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713 # bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code ordering in disk.c git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5 # good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering in main.c git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557 ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Tobias Diedrich wrote:
Adrian Bunk wrote:
On Fri, Apr 13, 2007 at 11:29:55PM +0200, Tobias Diedrich wrote:
Linus Torvalds wrote:
We should be getting close to a 2.6.21 release, so please update any
regression reports you've done,
For me, suspend to disk works only once (has been the case for all
.21-rcs IIRC, but I didn't get around to report it so far).
There are some threads about an issue like this, which is supposed
to be fixed by disabling CONFIG_PCI_MSI, but on my system the
problem persists nonetheless.
On the second suspend attempt, the last message I see is
Suspending console(s)
If I find the time, I'll try to bisect it this weekend.
...
Does CONFIG_HPET_TIMER=n make any difference?
Does the latest -git work?
bisect results:
git-bisect start
# good: [fa285a3d7924a0e3782926e51f16865c5129a2f7] Linux 2.6.20
git-bisect good fa285a3d7924a0e3782926e51f16865c5129a2f7
# bad: [2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba] Linux 2.6.21-rc1
git-bisect bad 2eb1ae149a28c1b8ade687c5fbab3c37da4c0fba
# bad: [574009c1a895aeeb85eaab29c235d75852b09eb8] Merge branch 'upstream' of
git://ftp.linux-mips.org/pub/scm/upstream-linus
git-bisect bad 574009c1a895aeeb85eaab29c235d75852b09eb8
# good: [43187902cbfafe73ede0144166b741fb0f7d04e1] Merge
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-2.6
git-bisect good 43187902cbfafe73ede0144166b741fb0f7d04e1
# good: [beda9f3a13bbb22cde92a45f230a02ef2afef6a9] kbuild: more Makefile
cleanups
git-bisect good beda9f3a13bbb22cde92a45f230a02ef2afef6a9
# bad: [7edc136ab688f751037a86e8a051151d7962d33f] Char: isicom, support
higher rates
git-bisect bad 7edc136ab688f751037a86e8a051151d7962d33f
# good: [6267276f3fdda9ad0d5ca451bdcbdf42b802d64b] optional ZONE_DMA: deal
with cases of ZONE_DMA meaning the first zone
git-bisect good 6267276f3fdda9ad0d5ca451bdcbdf42b802d64b
# bad: [b4ac91a0eac36f347a509afda07e4305e931de61] uml: chan_user.h formatting
fixes
git-bisect bad b4ac91a0eac36f347a509afda07e4305e931de61
# bad: [bf0059b23fd2f0b304f647d87fad0aa626ecf0c0] M68KNOMMU: user ARRAY_SIZE
macro when appropriate
git-bisect bad bf0059b23fd2f0b304f647d87fad0aa626ecf0c0
# good: [c1725f2af89f1eda3cb9007290971b55084569a4] ARM26: Use ARRAY_SIZE
macro when appropriate
git-bisect good c1725f2af89f1eda3cb9007290971b55084569a4
# bad: [9b87ed790714bd3a8d492feb24f6c48f8bb59c3a] m32r: fix do_page_fault and
update_mmu_cache
git-bisect bad 9b87ed790714bd3a8d492feb24f6c48f8bb59c3a
# bad: [d12c610e08022a1b84d6bd4412c189214d32e713]
swsusp-change-code-ordering-in-userc-sanity
git-bisect bad d12c610e08022a1b84d6bd4412c189214d32e713
# bad: [ed746e3b18f4df18afa3763155972c5835f284c5] swsusp: Change code
ordering in disk.c
git-bisect bad ed746e3b18f4df18afa3763155972c5835f284c5
# good: [e3c7db621bed4afb8e231cb005057f2feb5db557] PM: Change code ordering
in main.c
git-bisect good e3c7db621bed4afb8e231cb005057f2feb5db557
ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
commit ed746e3b18f4df18afa3763155972c5835f284c5
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date: Sat Feb 10 01:43:32 2007 -0800
[PATCH] swsusp: Change code ordering in disk.c
Change the ordering of code in kernel/power/disk.c so that
device_suspend() is
called before disable_nonboot_cpus() and platform_finish() is called after
enable_nonboot_cpus() and before device_resume(), as indicated by the
recent
discussion on Linux-PM (cf.
http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
The changes here only affect the built-in swsusp.
[EMAIL PROTECTED]: fix LED blinking during image load]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
Cc: Nigel Cunningham [EMAIL PROTECTED]
Cc: Patrick Mochel [EMAIL PROTECTED]
Cc: Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
:04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
Now, the remaining test is to try reverting this commit from -rc6. :)
Doesn't apply cleanly against -rc6, but fixes the problem when
reverted from -rc1.
Index: linux-2.6.21-rc1/kernel/power/disk.c
===
--- linux-2.6.21-rc1.orig/kernel/power/disk.c 2007-04-14 14:16:59.0
+0200
+++ linux-2.6.21-rc1/kernel/power/disk.c2007-04-14 14:17:03.0
+0200
@@ -87,24 +87,52 @@
}
}
-static void unprepare_processes(void)
-{
- thaw_processes();
- pm_restore_console();
-}
-
static int prepare_processes(void)
{
int error = 0;
pm_prepare_console();
+
+ error = disable_nonboot_cpus();
+ if (error)
+ goto enable_cpus
Re: Linux 2.6.21-rc6
Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Linux 2.6.21-rc6
Rafael J. Wysocki wrote: On Saturday, 14 April 2007 15:00, Adrian Bunk wrote: On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote: Tobias Diedrich wrote: ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit commit ed746e3b18f4df18afa3763155972c5835f284c5 Author: Rafael J. Wysocki [EMAIL PROTECTED] Date: Sat Feb 10 01:43:32 2007 -0800 [PATCH] swsusp: Change code ordering in disk.c Change the ordering of code in kernel/power/disk.c so that device_suspend() is called before disable_nonboot_cpus() and platform_finish() is called after enable_nonboot_cpus() and before device_resume(), as indicated by the recent discussion on Linux-PM (cf. http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html). The changes here only affect the built-in swsusp. [EMAIL PROTECTED]: fix LED blinking during image load] Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Pavel Machek [EMAIL PROTECTED] Cc: Greg KH [EMAIL PROTECTED] Cc: Nigel Cunningham [EMAIL PROTECTED] Cc: Patrick Mochel [EMAIL PROTECTED] Cc: Alexey Starikovskiy [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18 8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel Now, the remaining test is to try reverting this commit from -rc6. :) Doesn't apply cleanly against -rc6, but fixes the problem when reverted from -rc1. Now, this was already reported in http://lkml.org/lkml/2007/3/16/126 and I even flagged that message in my local folder, but apparently forgot to follow up on it... *sigh* Unless I misunderstood something, all of the problems Maxim described in this email are fixed for him in -rc6. But it's quite possible that you are running into a different issue exposed by this commit. Yes, it's likely. Tobias, I'm unable to reproduce the problem with your .config, but my hardware is certainly different. Which suspend mode do you use? If that's platform, can you try to use shutdown or reboot and see if that helps? Sure. shutdown/reboot works fine, only platform is broken. -- Tobias PGP: http://9ac7e0bc.uguu.de - 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: Linux 2.6.21-rc6
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 21:56, Tobias Diedrich wrote:
Rafael J. Wysocki wrote:
On Saturday, 14 April 2007 15:00, Adrian Bunk wrote:
On Sat, Apr 14, 2007 at 02:31:54PM +0200, Tobias Diedrich wrote:
Tobias Diedrich wrote:
ed746e3b18f4df18afa3763155972c5835f284c5 is first bad commit
commit ed746e3b18f4df18afa3763155972c5835f284c5
Author: Rafael J. Wysocki [EMAIL PROTECTED]
Date: Sat Feb 10 01:43:32 2007 -0800
[PATCH] swsusp: Change code ordering in disk.c
Change the ordering of code in kernel/power/disk.c so that
device_suspend() is
called before disable_nonboot_cpus() and platform_finish() is
called after
enable_nonboot_cpus() and before device_resume(), as
indicated by the recent
discussion on Linux-PM (cf.
http://lists.osdl.org/pipermail/linux-pm/2006-November/004164.html).
The changes here only affect the built-in swsusp.
[EMAIL PROTECTED]: fix LED blinking during image load]
Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]
Acked-by: Pavel Machek [EMAIL PROTECTED]
Cc: Greg KH [EMAIL PROTECTED]
Cc: Nigel Cunningham [EMAIL PROTECTED]
Cc: Patrick Mochel [EMAIL PROTECTED]
Cc: Alexey Starikovskiy [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]
:04 04 7eca5b3a8f9606bc4f2ff41192ec8c9d4ca90d18
8313b674e1d1bdf6849350af06d28a89b3bb3054 M kernel
Now, the remaining test is to try reverting this commit from
-rc6. :)
Doesn't apply cleanly against -rc6, but fixes the problem when
reverted from -rc1.
Now, this was already reported in
http://lkml.org/lkml/2007/3/16/126
and I even flagged that message in my local folder, but apparently
forgot
to follow up on it... *sigh*
Unless I misunderstood something, all of the problems Maxim described
in
this email are fixed for him in -rc6.
But it's quite possible that you are running into a different issue
exposed by this commit.
Yes, it's likely.
Tobias, I'm unable to reproduce the problem with your .config, but my
hardware
is certainly different. Which suspend mode do you use? If that's
platform,
can you try to use shutdown or reboot and see if that helps?
Sure.
shutdown/reboot works fine, only platform is broken.
Thanks.
Now, I suspect the problem is somehow related to the hardware, so it would
help
a lot if we could identify the piece of hardware (or driver) involved.
AFAICT, your system is a non-SMP one, so we can rule out
disable/enable_nonboot_cpus(). To confirm that the problem is related to
platform_finish(), can you please apply the appended debug patch and
see if the suspend in the 'platform' mode works with it?
Yes, it's a Asus M2N-SLI-Deluxe Mainboard with a Athlon64 3200+
single core CPU.
Also, would that be feasible for you to use 'shutdown' as a workaround in case
the source of the problem is difficult to find and/or fix?
I guess so, but the below patch fixes the problem. :)
---
kernel/power/disk.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6.21-rc6/kernel/power/disk.c
===
--- linux-2.6.21-rc6.orig/kernel/power/disk.c
+++ linux-2.6.21-rc6/kernel/power/disk.c
@@ -170,8 +170,8 @@ int pm_suspend_disk(void)
if (in_suspend) {
enable_nonboot_cpus();
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
pr_debug(PM: writing image.\n);
error = swsusp_write();
@@ -189,8 +189,8 @@ int pm_suspend_disk(void)
Enable_cpus:
enable_nonboot_cpus();
Resume_devices:
- platform_finish();
device_resume();
+ platform_finish();
resume_console();
Thaw:
unprepare_processes();
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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: Linux 2.6.21-rc6
Linus Torvalds wrote: > We should be getting close to a 2.6.21 release, so please update any > regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is "Suspending console(s)" If I find the time, I'll try to bisect it this weekend. .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6 # Fri Apr 13 23:08:52 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # 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 # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y 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" # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION="" # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is
Re: Linux 2.6.21-rc6
Linus Torvalds wrote: We should be getting close to a 2.6.21 release, so please update any regression reports you've done, For me, suspend to disk works only once (has been the case for all .21-rcs IIRC, but I didn't get around to report it so far). There are some threads about an issue like this, which is supposed to be fixed by disabling CONFIG_PCI_MSI, but on my system the problem persists nonetheless. On the second suspend attempt, the last message I see is Suspending console(s) If I find the time, I'll try to bisect it this weekend. .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6 # Fri Apr 13 23:08:52 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_ZONE_DMA32=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_DMI=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # 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_EPOLL=y CONFIG_SHMEM=y CONFIG_SLAB=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_SLOB is not set # # Loadable module support # 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 # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y 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 # # Processor type and features # CONFIG_X86_PC=y # CONFIG_X86_VSMP is not set CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_INTERNODE_CACHE_BYTES=64 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_HPET_TIMER=y # CONFIG_HPET_EMULATE_RTC is not set CONFIG_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_X86_MCE_AMD=y CONFIG_KEXEC=y # CONFIG_CRASH_DUMP is not set CONFIG_PHYSICAL_START=0x20 # CONFIG_SECCOMP is not set # CONFIG_CC_STACKPROTECTOR is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 CONFIG_REORDER=y CONFIG_K8_NB=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_ISA_DMA_API=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set # CONFIG_PM_SYSFS_DEPRECATED is not set CONFIG_SOFTWARE_SUSPEND=y CONFIG_PM_STD_PARTITION= # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y CONFIG_ACPI_SLEEP_PROC_FS=y # CONFIG_ACPI_SLEEP_PROC_SLEEP is not set CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y # CONFIG_ACPI_VIDEO is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set
Re: [1/6] 2.6.21-rc4: known regressions
Adrian Bunk wrote: > This email lists some known regressions in Linus' tree compared to 2.6.20. Since I didn't see any mention of this: I'm seeing an Oops when removing the ohci1394 module: [ 16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860] GUID[c033ced6] [ 16.047287] BUG: unable to handle kernel NULL pointer dereference at virtual address 0094 [ 16.047451] printing eip: [ 16.047524] c02daf3d [ 16.047527] *pde = [ 16.047603] Oops: [#1] [ 16.047676] PREEMPT [ 16.047788] Modules linked in: backlight ohci1394 parport_pc parport [ 16.048069] CPU:0 [ 16.048071] EIP:0060:[]Not tainted VLI [ 16.048074] EFLAGS: 00010246 (2.6.21-rc4 #35) [ 16.048298] EIP is at class_device_remove_attrs+0xa/0x30 [ 16.048377] eax: dfd04338 ebx: ecx: df655988 edx: [ 16.048456] esi: edi: dfd04338 ebp: esp: df506e38 [ 16.048535] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 16.048614] Process rmmod (pid: 1455, ti=df506000 task=df6cc0b0 task.ti=df506000) [ 16.048693] Stack: dfd04338 dfd04340 c02db02f dfd04338 dfd041e4 c0331871 [ 16.049159] c02db065 dfd041b0 c0331858 c055006d 0975d589 0026 035c [ 16.049626] c033ced6 df24c000 c0331879 c02d859f df24c0bc df24c0bc [ 16.050091] Call Trace: [ 16.050233] [] class_device_del+0xcc/0xfa [ 16.050352] [] __nodemgr_remove_host_dev+0x0/0xb [ 16.050475] [] class_device_unregister+0x8/0x10 [ 16.050595] [] nodemgr_remove_ne+0x61/0x7a [ 16.050714] [] ether1394_header_cache+0x0/0x43 [ 16.050835] [] __nodemgr_remove_host_dev+0x8/0xb [ 16.050954] [] device_for_each_child+0x1a/0x3c [ 16.051073] [] nodemgr_remove_host+0x30/0x90 [ 16.051192] [] __unregister_host+0x1a/0xad [ 16.051311] [] hl_get_hostinfo+0x5b/0x76 [ 16.051430] [] highlevel_remove_host+0x21/0x42 [ 16.051549] [] hpsb_remove_host+0x37/0x56 [ 16.051668] [] ohci1394_pci_remove+0x44/0x1c7 [ohci1394] [ 16.051794] [] pci_device_remove+0x16/0x35 [ 16.053376] [] __device_release_driver+0x6e/0x8b [ 16.053496] [] driver_detach+0xa1/0xde [ 16.053613] [] bus_remove_driver+0x57/0x75 [ 16.053733] [] driver_unregister+0x8/0x13 [ 16.053850] [] pci_unregister_driver+0xc/0x6e [ 16.053969] [] sys_delete_module+0x174/0x19a [ 16.054091] [] do_page_fault+0x277/0x525 [ 16.054211] [] do_munmap+0x193/0x1ac [ 16.054331] [] syscall_call+0x7/0xb [ 16.054450] === [ 16.054523] Code: ff c3 85 c0 74 08 83 c0 08 e9 9b f8 ea ff b8 ea ff ff ff c3 85 c0 74 08 83 c0 08 e9 b9 db ea ff c3 57 89 c7 56 53 31 db 8b 70 44 <83> be 94 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 [ 16.057248] EIP: [] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:df506e38 -- Tobias PGP: http://9ac7e0bc.uguu.de - 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: [1/6] 2.6.21-rc4: known regressions
Adrian Bunk wrote: This email lists some known regressions in Linus' tree compared to 2.6.20. Since I didn't see any mention of this: I'm seeing an Oops when removing the ohci1394 module: [ 16.047275] ieee1394: Node removed: ID:BUS[158717321-38:0860] GUID[c033ced6] [ 16.047287] BUG: unable to handle kernel NULL pointer dereference at virtual address 0094 [ 16.047451] printing eip: [ 16.047524] c02daf3d [ 16.047527] *pde = [ 16.047603] Oops: [#1] [ 16.047676] PREEMPT [ 16.047788] Modules linked in: backlight ohci1394 parport_pc parport [ 16.048069] CPU:0 [ 16.048071] EIP:0060:[c02daf3d]Not tainted VLI [ 16.048074] EFLAGS: 00010246 (2.6.21-rc4 #35) [ 16.048298] EIP is at class_device_remove_attrs+0xa/0x30 [ 16.048377] eax: dfd04338 ebx: ecx: df655988 edx: [ 16.048456] esi: edi: dfd04338 ebp: esp: df506e38 [ 16.048535] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 [ 16.048614] Process rmmod (pid: 1455, ti=df506000 task=df6cc0b0 task.ti=df506000) [ 16.048693] Stack: dfd04338 dfd04340 c02db02f dfd04338 dfd041e4 c0331871 [ 16.049159] c02db065 dfd041b0 c0331858 c055006d 0975d589 0026 035c [ 16.049626] c033ced6 df24c000 c0331879 c02d859f df24c0bc df24c0bc [ 16.050091] Call Trace: [ 16.050233] [c02db02f] class_device_del+0xcc/0xfa [ 16.050352] [c0331871] __nodemgr_remove_host_dev+0x0/0xb [ 16.050475] [c02db065] class_device_unregister+0x8/0x10 [ 16.050595] [c0331858] nodemgr_remove_ne+0x61/0x7a [ 16.050714] [c033ced6] ether1394_header_cache+0x0/0x43 [ 16.050835] [c0331879] __nodemgr_remove_host_dev+0x8/0xb [ 16.050954] [c02d859f] device_for_each_child+0x1a/0x3c [ 16.051073] [c0331b98] nodemgr_remove_host+0x30/0x90 [ 16.051192] [c032f12c] __unregister_host+0x1a/0xad [ 16.051311] [c032ee17] hl_get_hostinfo+0x5b/0x76 [ 16.051430] [c032f34a] highlevel_remove_host+0x21/0x42 [ 16.051549] [c032ed9d] hpsb_remove_host+0x37/0x56 [ 16.051668] [e0869263] ohci1394_pci_remove+0x44/0x1c7 [ohci1394] [ 16.051794] [c027e5b0] pci_device_remove+0x16/0x35 [ 16.053376] [c02da6d7] __device_release_driver+0x6e/0x8b [ 16.053496] [c02dab77] driver_detach+0xa1/0xde [ 16.053613] [c02da33f] bus_remove_driver+0x57/0x75 [ 16.053733] [c02dabd4] driver_unregister+0x8/0x13 [ 16.053850] [c027e732] pci_unregister_driver+0xc/0x6e [ 16.053969] [c0134d56] sys_delete_module+0x174/0x19a [ 16.054091] [c0113cea] do_page_fault+0x277/0x525 [ 16.054211] [c0148b0d] do_munmap+0x193/0x1ac [ 16.054331] [c0103d0c] syscall_call+0x7/0xb [ 16.054450] === [ 16.054523] Code: ff c3 85 c0 74 08 83 c0 08 e9 9b f8 ea ff b8 ea ff ff ff c3 85 c0 74 08 83 c0 08 e9 b9 db ea ff c3 57 89 c7 56 53 31 db 8b 70 44 83 be 94 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 [ 16.057248] EIP: [c02daf3d] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:df506e38 -- Tobias PGP: http://9ac7e0bc.uguu.de - 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: pata_amd dropping to PIO on resume
Jeff Garzik wrote:
> Robert Hancock wrote:
> >Yes, the fact that it's going into simplex mode is the problem, it
> >wasn't in simplex to start with. It looks like pata_amd does an
> >ata_pci_clear_simplex only for certain chip models, maybe this model
> >needs it as well?
>
> Deleting the ata_pci_clear_simplex() call, then adding
> ATA_FLAG_IGN_SIMPLEX to the ata_port_info info[] array, is also worth
> trying.
I tried the latter option and it works fine.
I didn't delete the ata_pci_clear_simplex call, since it is not
called for this model.
BTW, this the nVidia MCP55 IDE controller:
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:04.0 0101: 10de:036e (rev a1)
Index: linux-2.6.20/drivers/ata/pata_amd.c
===
--- linux-2.6.20.orig/drivers/ata/pata_amd.c2007-02-17 10:27:59.0
+0100
+++ linux-2.6.20/drivers/ata/pata_amd.c 2007-02-17 10:28:14.0 +0100
@@ -611,7 +611,7 @@
},
{ /* 8: Nvidia Nforce2 and later */
.sht = _sht,
- .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST,
+ .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST |
ATA_FLAG_IGN_SIMPLEX,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
.udma_mask = 0x7f, /* UDMA 133, no swdma */
[ 1087.954496] ata5.00: disabled
[ 1087.954500] ata5.01: disabled
[ 1087.958725] Trying to free nonexistent resource
<01f0-01f7>
[ 1087.958730] Trying to free nonexistent resource
<0170-0177>
[ 1089.559228] pata_amd :00:04.0: version 0.2.7
[ 1089.559240] PCI: Setting latency timer of device :00:04.0 to 64
[ 1089.560866] ata7: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
[ 1089.561118] ata8: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
[ 1089.561133] scsi8 : pata_amd
[ 1089.717718] ata7.00: ATAPI, max UDMA/33
[ 1089.797629] ata7.01: ATAPI, max UDMA/66
[ 1089.877519] ata7.00: configured for UDMA/33
[ 1089.957429] ata7.01: configured for UDMA/33
[ 1089.957948] scsi9 : pata_amd
[ 1089.957996] ata8: port disabled. ignoring.
[ 1089.957998] ata8: reset failed, giving up
[ 1089.960193] scsi 8:0:0:0: CD-ROM_NEC DVD_RW ND-3500AG 2.1A
PQ: 0 ANSI: 5
[ 1089.962400] sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
[ 1089.962442] sr 8:0:0:0: Attached scsi CD-ROM sr0
[ 1089.962474] sr 8:0:0:0: Attached scsi generic sg1 type 5
[ 1089.963938] scsi 8:0:1:0: CD-ROMPIONEER DVD-ROM DVD-106 1.22
PQ: 0 ANSI: 5
[ 1089.966730] sr1: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
[ 1089.966769] sr 8:0:1:0: Attached scsi CD-ROM sr1
[ 1089.966802] sr 8:0:1:0: Attached scsi generic sg2 type 5
[ 1096.079852] Stopping tasks ... done.
[ 1096.126558] Shrinking memory... -\|/-done (51275 pages freed)
[ 1097.076333] Freed 205100 kbytes in 1.63 seconds (125.82 MB/s)
[ 1097.076336] Suspending console(s)
[ 1097.080211] ACPI: PCI interrupt for device :01:08.0 disabled
[ 1097.092133] ata8: port disabled. ignoring.
[ 1097.092135] ata8: reset failed, giving up
[ 1097.092153] ACPI: PCI interrupt for device :00:02.1 disabled
[ 1097.098774] ACPI: PCI interrupt for device :00:02.0 disabled
[ 1097.105558] Extended CMOS year: 20
[ 1097.105562] swsusp: critical section:
[ 1097.119909] swsusp: Need to copy 120019 pages
[ 46.569060] Extended CMOS year: 20
[ 46.586207] ACPI: Unable to turn cooling device [81003fe90890] 'on'
[ 46.599040] PCI: Enabling device :00:02.0 ( -> 0002)
[ 46.599044] ACPI: PCI Interrupt :00:02.0[A] -> Link [APCF] -> GSI 22
(level, low) -> IRQ 22
[ 46.599050] PCI: Setting latency timer of device :00:02.0 to 64
[ 46.599055] PM: Writing back config space on device :00:02.0 at offset f
(was 1030100, writing 103010a)
[ 46.599062] PM: Writing back config space on device :00:02.0 at offset 4
(was 0, writing fe02f000)
[ 46.599066] PM: Writing back config space on device :00:02.0 at offset 1
(was b6, writing b7)
[ 46.612354] ACPI: PCI Interrupt :00:02.1[B] -> Link [APCL] -> GSI 23
(level, low) -> IRQ 23
[ 46.612358] PCI: Setting latency timer of device :00:02.1 to 64
[ 46.612371] usb usb1: root hub lost power or was reset
[ 46.612378] ehci_hcd :00:02.1: debug port 1
[ 46.612380] PCI: cache line size of 64 is not supported by device
:00:02.1
[ 46.612390] PM: Writing back config space on device :00:04.0 at offset b
(was 82391043, writing 8239f043)
[ 46.612397] PCI: Setting latency timer of device :00:04.0 to 64
[ 46.612409] PCI: Setting latency timer of device :00:06.0 to 64
[ 46.612441] ata8: port disabled. ignoring.
[ 46.612443] ata8: reset failed, giving up
[ 46.626342] PCI: Setting latency timer of device :00:0a.0 to 64
[ 46.626357] PCI: Setting latency timer of device :00:0b.0
Re: pata_amd dropping to PIO on resume
Jeff Garzik wrote:
Robert Hancock wrote:
Yes, the fact that it's going into simplex mode is the problem, it
wasn't in simplex to start with. It looks like pata_amd does an
ata_pci_clear_simplex only for certain chip models, maybe this model
needs it as well?
Deleting the ata_pci_clear_simplex() call, then adding
ATA_FLAG_IGN_SIMPLEX to the ata_port_info info[] array, is also worth
trying.
I tried the latter option and it works fine.
I didn't delete the ata_pci_clear_simplex call, since it is not
called for this model.
BTW, this the nVidia MCP55 IDE controller:
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:04.0 0101: 10de:036e (rev a1)
Index: linux-2.6.20/drivers/ata/pata_amd.c
===
--- linux-2.6.20.orig/drivers/ata/pata_amd.c2007-02-17 10:27:59.0
+0100
+++ linux-2.6.20/drivers/ata/pata_amd.c 2007-02-17 10:28:14.0 +0100
@@ -611,7 +611,7 @@
},
{ /* 8: Nvidia Nforce2 and later */
.sht = amd_sht,
- .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST,
+ .flags = ATA_FLAG_SLAVE_POSS | ATA_FLAG_SRST |
ATA_FLAG_IGN_SIMPLEX,
.pio_mask = 0x1f,
.mwdma_mask = 0x07,
.udma_mask = 0x7f, /* UDMA 133, no swdma */
[ 1087.954496] ata5.00: disabled
[ 1087.954500] ata5.01: disabled
[ 1087.958725] Trying to free nonexistent resource
01f0-01f7
[ 1087.958730] Trying to free nonexistent resource
0170-0177
[ 1089.559228] pata_amd :00:04.0: version 0.2.7
[ 1089.559240] PCI: Setting latency timer of device :00:04.0 to 64
[ 1089.560866] ata7: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xF000 irq 14
[ 1089.561118] ata8: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xF008 irq 15
[ 1089.561133] scsi8 : pata_amd
[ 1089.717718] ata7.00: ATAPI, max UDMA/33
[ 1089.797629] ata7.01: ATAPI, max UDMA/66
[ 1089.877519] ata7.00: configured for UDMA/33
[ 1089.957429] ata7.01: configured for UDMA/33
[ 1089.957948] scsi9 : pata_amd
[ 1089.957996] ata8: port disabled. ignoring.
[ 1089.957998] ata8: reset failed, giving up
[ 1089.960193] scsi 8:0:0:0: CD-ROM_NEC DVD_RW ND-3500AG 2.1A
PQ: 0 ANSI: 5
[ 1089.962400] sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray
[ 1089.962442] sr 8:0:0:0: Attached scsi CD-ROM sr0
[ 1089.962474] sr 8:0:0:0: Attached scsi generic sg1 type 5
[ 1089.963938] scsi 8:0:1:0: CD-ROMPIONEER DVD-ROM DVD-106 1.22
PQ: 0 ANSI: 5
[ 1089.966730] sr1: scsi3-mmc drive: 40x/40x cd/rw xa/form2 cdda tray
[ 1089.966769] sr 8:0:1:0: Attached scsi CD-ROM sr1
[ 1089.966802] sr 8:0:1:0: Attached scsi generic sg2 type 5
[ 1096.079852] Stopping tasks ... done.
[ 1096.126558] Shrinking memory... -\|/-done (51275 pages freed)
[ 1097.076333] Freed 205100 kbytes in 1.63 seconds (125.82 MB/s)
[ 1097.076336] Suspending console(s)
[ 1097.080211] ACPI: PCI interrupt for device :01:08.0 disabled
[ 1097.092133] ata8: port disabled. ignoring.
[ 1097.092135] ata8: reset failed, giving up
[ 1097.092153] ACPI: PCI interrupt for device :00:02.1 disabled
[ 1097.098774] ACPI: PCI interrupt for device :00:02.0 disabled
[ 1097.105558] Extended CMOS year: 20
[ 1097.105562] swsusp: critical section:
[ 1097.119909] swsusp: Need to copy 120019 pages
[ 46.569060] Extended CMOS year: 20
[ 46.586207] ACPI: Unable to turn cooling device [81003fe90890] 'on'
[ 46.599040] PCI: Enabling device :00:02.0 ( - 0002)
[ 46.599044] ACPI: PCI Interrupt :00:02.0[A] - Link [APCF] - GSI 22
(level, low) - IRQ 22
[ 46.599050] PCI: Setting latency timer of device :00:02.0 to 64
[ 46.599055] PM: Writing back config space on device :00:02.0 at offset f
(was 1030100, writing 103010a)
[ 46.599062] PM: Writing back config space on device :00:02.0 at offset 4
(was 0, writing fe02f000)
[ 46.599066] PM: Writing back config space on device :00:02.0 at offset 1
(was b6, writing b7)
[ 46.612354] ACPI: PCI Interrupt :00:02.1[B] - Link [APCL] - GSI 23
(level, low) - IRQ 23
[ 46.612358] PCI: Setting latency timer of device :00:02.1 to 64
[ 46.612371] usb usb1: root hub lost power or was reset
[ 46.612378] ehci_hcd :00:02.1: debug port 1
[ 46.612380] PCI: cache line size of 64 is not supported by device
:00:02.1
[ 46.612390] PM: Writing back config space on device :00:04.0 at offset b
(was 82391043, writing 8239f043)
[ 46.612397] PCI: Setting latency timer of device :00:04.0 to 64
[ 46.612409] PCI: Setting latency timer of device :00:06.0 to 64
[ 46.612441] ata8: port disabled. ignoring.
[ 46.612443] ata8: reset failed, giving up
[ 46.626342] PCI: Setting latency timer of device :00:0a.0 to 64
[ 46.626357] PCI: Setting latency timer of device :00:0b.0 to 64
[ 46.626369]
Re: forcedeth problems on 2.6.20-rc6-mm3
Tobias Diedrich wrote: > Jeff Garzik wrote: > > Tobias Diedrich wrote: > > >Tobias Diedrich wrote: > > >>Ayaz Abdulla wrote: > > >>>For all those who are having issues, please try out the attached patch. > > >>Will try. > > > > > >Does not apply cleanly against 2.6.20, is this one fixed up right? > > > > It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3. > > > > IOW, the forcedeth changes in question are not in 2.6.20, and you need > > to apply the patch on top of the latest batch of forcedeth changes. > > Well, it hasn't blown up on me despite being applied to 2.6.20... > The problem I was seeing might even be fixed in 2.6.20 vanilla, > since the last version I saw it in was 2.6.20-rc6 and then I > reverted to 2.6.19 to make sure that one is ok (see > [EMAIL PROTECTED]). And having run vanilla 2.6.20 since my last mail, I haven't seen the problem on that one either. So I _guess_ the particular problem I was seeing was fixed somewhere between 2.6.20-rc6 and 2.6.20. But since I can't reliably trigger it, I can't say that for sure. -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: forcedeth problems on 2.6.20-rc6-mm3
Tobias Diedrich wrote: Jeff Garzik wrote: Tobias Diedrich wrote: Tobias Diedrich wrote: Ayaz Abdulla wrote: For all those who are having issues, please try out the attached patch. Will try. Does not apply cleanly against 2.6.20, is this one fixed up right? It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3. IOW, the forcedeth changes in question are not in 2.6.20, and you need to apply the patch on top of the latest batch of forcedeth changes. Well, it hasn't blown up on me despite being applied to 2.6.20... The problem I was seeing might even be fixed in 2.6.20 vanilla, since the last version I saw it in was 2.6.20-rc6 and then I reverted to 2.6.19 to make sure that one is ok (see [EMAIL PROTECTED]). And having run vanilla 2.6.20 since my last mail, I haven't seen the problem on that one either. So I _guess_ the particular problem I was seeing was fixed somewhere between 2.6.20-rc6 and 2.6.20. But since I can't reliably trigger it, I can't say that for sure. -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: forcedeth problems on 2.6.20-rc6-mm3
Jeff Garzik wrote: > Tobias Diedrich wrote: > >Tobias Diedrich wrote: > >>Ayaz Abdulla wrote: > >>>For all those who are having issues, please try out the attached patch. > >>Will try. > > > >Does not apply cleanly against 2.6.20, is this one fixed up right? > > It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3. > > IOW, the forcedeth changes in question are not in 2.6.20, and you need > to apply the patch on top of the latest batch of forcedeth changes. Well, it hasn't blown up on me despite being applied to 2.6.20... The problem I was seeing might even be fixed in 2.6.20 vanilla, since the last version I saw it in was 2.6.20-rc6 and then I reverted to 2.6.19 to make sure that one is ok (see [EMAIL PROTECTED]). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: forcedeth problems on 2.6.20-rc6-mm3
Jeff Garzik wrote: Tobias Diedrich wrote: Tobias Diedrich wrote: Ayaz Abdulla wrote: For all those who are having issues, please try out the attached patch. Will try. Does not apply cleanly against 2.6.20, is this one fixed up right? It probably needs to be top of 2.6.20-git-latest or 2.6.20-rc6-mm3. IOW, the forcedeth changes in question are not in 2.6.20, and you need to apply the patch on top of the latest batch of forcedeth changes. Well, it hasn't blown up on me despite being applied to 2.6.20... The problem I was seeing might even be fixed in 2.6.20 vanilla, since the last version I saw it in was 2.6.20-rc6 and then I reverted to 2.6.19 to make sure that one is ok (see [EMAIL PROTECTED]). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: forcedeth problems on 2.6.20-rc6-mm3
Tobias Diedrich wrote:
> Ayaz Abdulla wrote:
> > For all those who are having issues, please try out the attached patch.
>
> Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
--- linux-2.6.20/drivers/net/forcedeth.c.orig 2007-02-09 13:02:02.0
+0100
+++ linux-2.6.20/drivers/net/forcedeth.c.new2007-02-09 13:03:45.0
+0100
@@ -2603,10 +2603,16 @@
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
unsigned long flags;
+ u32 retcode;
- pkts = nv_rx_process(dev, limit);
+ if (np->desc_ver == DESC_VER_1 || np->desc_ver == DESC_VER_2) {
+ pkts = nv_rx_process(dev, limit);
+ retcode = nv_alloc_rx(dev);
+ } else {
+ retcode = nv_alloc_rx_optimized(dev);
+ }
- if (nv_alloc_rx(dev)) {
+ if (retcode) {
spin_lock_irqsave(>lock, flags);
if (!np->in_shutdown)
mod_timer(>oom_kick, jiffies + OOM_REFILL);
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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: forcedeth problems on 2.6.20-rc6-mm3
Ayaz Abdulla wrote: > For all those who are having issues, please try out the attached patch. Will try. I reverted to 2.6.19 w/o suspend/resume patch last weekend to make sure on 2.6.19 forcedeth is stable and noticed something odd: Because I didn't include the suspend/resume patch I obviously had to a down/rmmod/modprobe/up cycle after each resume and I noticed that the behaviour seems to alternate between resumes: Behaviour 1: After modprobe I get two interface 'eth0' and 'eth1' for the two ports, as expected. Behaviour 2: After modprobe I get one interface 'eth3' (which should be 'eth1') and one interface with increasing numbers (which should be 'eth0', last resume it was 'eth12' IIRC). As I said if I get behaviour 1 on one resume I get behaviour 2 on the next resume and vice versa. That seems rather odd to me. On a not quite related note, forcedeth shows a different ethtool output (compared to e100), when no cable is connected to the port: forcedeth, no cable connected: |Settings for eth1: | Supported ports: [ MII ] | Supported link modes: 10baseT/Half 10baseT/Full | 100baseT/Half 100baseT/Full | 1000baseT/Full | Supports auto-negotiation: Yes | Advertised link modes: 10baseT/Half 10baseT/Full | 100baseT/Half 100baseT/Full | 1000baseT/Full | Advertised auto-negotiation: Yes | Speed: Unknown! (65535) | Duplex: Unknown! (255) | Port: MII | PHYAD: 1 | Transceiver: external | Auto-negotiation: on | Supports Wake-on: g | Wake-on: d | Link detected: no e100, no cable connected: |Settings for eth0: |Supported ports: [ TP MII ] |Supported link modes: 10baseT/Half 10baseT/Full |100baseT/Half 100baseT/Full |Supports auto-negotiation: Yes |Advertised link modes: 10baseT/Half 10baseT/Full |100baseT/Half 100baseT/Full |Advertised auto-negotiation: Yes |Speed: 10Mb/s |Duplex: Half |Port: MII |PHYAD: 1 |Transceiver: internal |Auto-negotiation: on |Supports Wake-on: g |Wake-on: g |Current message level: 0x0007 (7) |Link detected: no Note that e100 returns the lowest possible speed if no link is detected, while forcedeth seems to return -1, which ethtool doesn't seem to recognise as a valid response (I guess, why else would it show the number after 'Unknown!'). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: forcedeth problems on 2.6.20-rc6-mm3
Ayaz Abdulla wrote: For all those who are having issues, please try out the attached patch. Will try. I reverted to 2.6.19 w/o suspend/resume patch last weekend to make sure on 2.6.19 forcedeth is stable and noticed something odd: Because I didn't include the suspend/resume patch I obviously had to a down/rmmod/modprobe/up cycle after each resume and I noticed that the behaviour seems to alternate between resumes: Behaviour 1: After modprobe I get two interface 'eth0' and 'eth1' for the two ports, as expected. Behaviour 2: After modprobe I get one interface 'eth3' (which should be 'eth1') and one interface with increasing numbers (which should be 'eth0', last resume it was 'eth12' IIRC). As I said if I get behaviour 1 on one resume I get behaviour 2 on the next resume and vice versa. That seems rather odd to me. On a not quite related note, forcedeth shows a different ethtool output (compared to e100), when no cable is connected to the port: forcedeth, no cable connected: |Settings for eth1: | Supported ports: [ MII ] | Supported link modes: 10baseT/Half 10baseT/Full | 100baseT/Half 100baseT/Full | 1000baseT/Full | Supports auto-negotiation: Yes | Advertised link modes: 10baseT/Half 10baseT/Full | 100baseT/Half 100baseT/Full | 1000baseT/Full | Advertised auto-negotiation: Yes | Speed: Unknown! (65535) | Duplex: Unknown! (255) | Port: MII | PHYAD: 1 | Transceiver: external | Auto-negotiation: on | Supports Wake-on: g | Wake-on: d | Link detected: no e100, no cable connected: |Settings for eth0: |Supported ports: [ TP MII ] |Supported link modes: 10baseT/Half 10baseT/Full |100baseT/Half 100baseT/Full |Supports auto-negotiation: Yes |Advertised link modes: 10baseT/Half 10baseT/Full |100baseT/Half 100baseT/Full |Advertised auto-negotiation: Yes |Speed: 10Mb/s |Duplex: Half |Port: MII |PHYAD: 1 |Transceiver: internal |Auto-negotiation: on |Supports Wake-on: g |Wake-on: g |Current message level: 0x0007 (7) |Link detected: no Note that e100 returns the lowest possible speed if no link is detected, while forcedeth seems to return -1, which ethtool doesn't seem to recognise as a valid response (I guess, why else would it show the number after 'Unknown!'). -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: forcedeth problems on 2.6.20-rc6-mm3
Tobias Diedrich wrote:
Ayaz Abdulla wrote:
For all those who are having issues, please try out the attached patch.
Will try.
Does not apply cleanly against 2.6.20, is this one fixed up right?
--- linux-2.6.20/drivers/net/forcedeth.c.orig 2007-02-09 13:02:02.0
+0100
+++ linux-2.6.20/drivers/net/forcedeth.c.new2007-02-09 13:03:45.0
+0100
@@ -2603,10 +2603,16 @@
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
unsigned long flags;
+ u32 retcode;
- pkts = nv_rx_process(dev, limit);
+ if (np-desc_ver == DESC_VER_1 || np-desc_ver == DESC_VER_2) {
+ pkts = nv_rx_process(dev, limit);
+ retcode = nv_alloc_rx(dev);
+ } else {
+ retcode = nv_alloc_rx_optimized(dev);
+ }
- if (nv_alloc_rx(dev)) {
+ if (retcode) {
spin_lock_irqsave(np-lock, flags);
if (!np-in_shutdown)
mod_timer(np-oom_kick, jiffies + OOM_REFILL);
--
Tobias PGP: http://9ac7e0bc.uguu.de
このメールは十割再利用されたビットで作られています。
-
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: Forcedeth issues, loss of connectivity. ASUS M2N32-SLI-D w/ AMD64
Jeroen Roodhart wrote: > > Any "me toos" out there, any suggestions? > > Big "me too" here. I use this board to run "workstation and home samba > services" > and it seems that under stress, the connection gets lost. Can't put my finger > on > the when/what/why too. I've seen some issues with forcedeth too, but only with 2.6.20-rc5 and -rc6 as far as I can say. The box stopped receiving packets, but a "ifconfig eth0 promisc" 'fixed' it. It happened rarely and I haven't been really able to reproduce it on demand so far. Looking through my syslog I think |Jan 28 22:16:44 melchior kernel: [28411.397053] Losing some ticks... checking if CPU frequency changed. |Jan 28 22:18:12 melchior kernel: [28488.534330] warning: many lost ticks. |Jan 28 22:18:12 melchior kernel: [28488.534333] Your time source seems to be instable or some driver is hogging int |Jan 28 22:18:12 melchior kernel: [28488.534350] rip nv_nic_irq_other+0x2/0x160 [forcedeth] |Jan 28 22:18:12 melchior kernel: [28488.534352] Falling back to HPET sounds suspicios. |Jan 25 18:17:20 melchior kernel: [ 2875.164597] Losing some ticks... checking if CPU frequency changed. |Jan 25 18:18:57 melchior kernel: [ 2929.230774] warning: many lost ticks. |Jan 25 18:18:57 melchior kernel: [ 2929.230777] Your time source seems to be instable or some driver is hogging interupts |Jan 25 18:18:57 melchior kernel: [ 2929.230785] rip handle_IRQ_event+0x1a/0x53 |Jan 25 18:18:57 melchior kernel: [ 2929.230787] Falling back to HPET This is on an ASUS M2N-SLI Deluxe. Right now, it again only works with eth0 promisc, but interrupts I can at least see interrupts for all three registered eth0 msi interrupt handlers: |279: 13239534 PCI-MSI-edge eth0 |280:2515250 PCI-MSI-edge eth0 |281:6268650 PCI-MSI-edge eth0 and "sleep 1" later: |279: 13239635 PCI-MSI-edge eth0 |280:2515259 PCI-MSI-edge eth0 |281:6268661 PCI-MSI-edge eth0 -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: Forcedeth issues, loss of connectivity. ASUS M2N32-SLI-D w/ AMD64
Jeroen Roodhart wrote: Any me toos out there, any suggestions? Big me too here. I use this board to run workstation and home samba services and it seems that under stress, the connection gets lost. Can't put my finger on the when/what/why too. I've seen some issues with forcedeth too, but only with 2.6.20-rc5 and -rc6 as far as I can say. The box stopped receiving packets, but a ifconfig eth0 promisc 'fixed' it. It happened rarely and I haven't been really able to reproduce it on demand so far. Looking through my syslog I think |Jan 28 22:16:44 melchior kernel: [28411.397053] Losing some ticks... checking if CPU frequency changed. |Jan 28 22:18:12 melchior kernel: [28488.534330] warning: many lost ticks. |Jan 28 22:18:12 melchior kernel: [28488.534333] Your time source seems to be instable or some driver is hogging int |Jan 28 22:18:12 melchior kernel: [28488.534350] rip nv_nic_irq_other+0x2/0x160 [forcedeth] |Jan 28 22:18:12 melchior kernel: [28488.534352] Falling back to HPET sounds suspicios. |Jan 25 18:17:20 melchior kernel: [ 2875.164597] Losing some ticks... checking if CPU frequency changed. |Jan 25 18:18:57 melchior kernel: [ 2929.230774] warning: many lost ticks. |Jan 25 18:18:57 melchior kernel: [ 2929.230777] Your time source seems to be instable or some driver is hogging interupts |Jan 25 18:18:57 melchior kernel: [ 2929.230785] rip handle_IRQ_event+0x1a/0x53 |Jan 25 18:18:57 melchior kernel: [ 2929.230787] Falling back to HPET This is on an ASUS M2N-SLI Deluxe. Right now, it again only works with eth0 promisc, but interrupts I can at least see interrupts for all three registered eth0 msi interrupt handlers: |279: 13239534 PCI-MSI-edge eth0 |280:2515250 PCI-MSI-edge eth0 |281:6268650 PCI-MSI-edge eth0 and sleep 1 later: |279: 13239635 PCI-MSI-edge eth0 |280:2515259 PCI-MSI-edge eth0 |281:6268661 PCI-MSI-edge eth0 -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.
Lu, Yinghai wrote: > -Original Message- > From: Tobias Diedrich [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 09, 2007 2:01 PM > To: Eric W. Biederman > Cc: Linus Torvalds; Lu, Yinghai; Andrew Morton; Adrian Bunk; Andi Kleen; > Linux Kernel Mailing List > Subject: Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when > check_timer fails. > > > >Works fine with BIOS 0402. > > >x86_64_io_apic_fix_eric_20060108 > > >..TIMER: vector=0x20 apic1=0 pin1=0 apic2=-1 pin2=-1 > >..TIMER trying IO-APIC=0 PIN=0<3> .. failed > >...apic 0 pin 2n use by irq 2 > >..MP-BIOS bug: 8254 timer not connected to IO-APIC > >...trying to set up timer (IRQ0) through the 8259A ... > >...ExtINT trying IO-APIC=0 PIN=0 .. success > >Using local APIC timer interrupts. > > Tobias, > > Can you post whole log for my patch? Sure: dmesg-20070108-2.6.20-rc4-bios-0402: Linux version 2.6.20-rc4-amd64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) #55 Mon Jan 8 01:41:56 CET 2007 Command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ ro BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fee (usable) BIOS-e820: 3fee - 3fee3000 (ACPI NVS) BIOS-e820: 3fee3000 - 3fef (ACPI data) BIOS-e820: 3fef - 3ff0 (reserved) BIOS-e820: f000 - f400 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 261856 On node 0 totalpages: 261759 DMA zone: 56 pages used for memmap DMA zone: 1358 pages reserved DMA zone: 2585 pages, LIFO batch:0 DMA32 zone: 3524 pages used for memmap DMA32 zone: 254236 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fd000 (fee0) mapped IOAPIC to ff5fc000 (fec0) Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000f Nosave address range: 000f - 0010 Allocating PCI resources starting at 4000 (gap: 3ff0:b010) Built 1 zonelists. Total pages: 256821 Kernel command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ ro netconsole: local port 6665 netconsole: local IP 192.168.8.241 netconsole: interface eth0 netconsole: remote port 514 netconsole: remote IP 255.255.255.255 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) trying to force-enable HPET HPET force-enabled at 0xfef0 time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer. time.c: Detected 2009.512 MHz processor. Console: colour VGA+ 80x60 Dentry cache hash table
Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.
Lu, Yinghai wrote: -Original Message- From: Tobias Diedrich [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 09, 2007 2:01 PM To: Eric W. Biederman Cc: Linus Torvalds; Lu, Yinghai; Andrew Morton; Adrian Bunk; Andi Kleen; Linux Kernel Mailing List Subject: Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails. Works fine with BIOS 0402. x86_64_io_apic_fix_eric_20060108 ..TIMER: vector=0x20 apic1=0 pin1=0 apic2=-1 pin2=-1 ..TIMER trying IO-APIC=0 PIN=03 .. failed ...apic 0 pin 2n use by irq 2 ..MP-BIOS bug: 8254 timer not connected to IO-APIC ...trying to set up timer (IRQ0) through the 8259A ... ...ExtINT trying IO-APIC=0 PIN=0 .. success Using local APIC timer interrupts. Tobias, Can you post whole log for my patch? Sure: dmesg-20070108-2.6.20-rc4-bios-0402: Linux version 2.6.20-rc4-amd64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) #55 Mon Jan 8 01:41:56 CET 2007 Command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ ro BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fee (usable) BIOS-e820: 3fee - 3fee3000 (ACPI NVS) BIOS-e820: 3fee3000 - 3fef (ACPI data) BIOS-e820: 3fef - 3ff0 (reserved) BIOS-e820: f000 - f400 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 261856 On node 0 totalpages: 261759 DMA zone: 56 pages used for memmap DMA zone: 1358 pages reserved DMA zone: 2585 pages, LIFO batch:0 DMA32 zone: 3524 pages used for memmap DMA32 zone: 254236 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fd000 (fee0) mapped IOAPIC to ff5fc000 (fec0) Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000f Nosave address range: 000f - 0010 Allocating PCI resources starting at 4000 (gap: 3ff0:b010) Built 1 zonelists. Total pages: 256821 Kernel command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ ro netconsole: local port 6665 netconsole: local IP 192.168.8.241 netconsole: interface eth0 netconsole: remote port 514 netconsole: remote IP 255.255.255.255 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) trying to force-enable HPET HPET force-enabled at 0xfef0 time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer. time.c: Detected 2009.512 MHz processor. Console: colour VGA+ 80x60 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ b2c200 size 32 MB
Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.
Eric W. Biederman wrote: > Tobias. I don't have a box with the problem yours does, and this > doesn't quite try any of the cases you have been asked to test > so could you please test this one? Works fine with BIOS 0402. patches/series: patch-2.6.20-rc4 patch-2.6.19-rc3-nokmem myconfig ccache x86_64_io_apic_fix_eric_20060108 hpet-quirk dmesg: Linux version 2.6.20-rc4-amd64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) #56 Tue Jan 9 22:40:56 CET 2007 Command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ ro BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fee (usable) BIOS-e820: 3fee - 3fee3000 (ACPI NVS) BIOS-e820: 3fee3000 - 3fef (ACPI data) BIOS-e820: 3fef - 3ff0 (reserved) BIOS-e820: f000 - f400 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 261856 On node 0 totalpages: 261759 DMA zone: 56 pages used for memmap DMA zone: 1358 pages reserved DMA zone: 2585 pages, LIFO batch:0 DMA32 zone: 3524 pages used for memmap DMA32 zone: 254236 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fd000 (fee0) mapped IOAPIC to ff5fc000 (fec0) Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000f Nosave address range: 000f - 0010 Allocating PCI resources starting at 4000 (gap: 3ff0:b010) Built 1 zonelists. Total pages: 256821 Kernel command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ ro netconsole: local port 6665 netconsole: local IP 192.168.8.241 netconsole: interface eth0 netconsole: remote port 514 netconsole: remote IP 255.255.255.255 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) trying to force-enable HPET HPET force-enabled at 0xfef0 time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer. time.c: Detected 2009.512 MHz processor. Console: colour VGA+ 80x60 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ b2c200 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 1025348k/1047424k available (3242k kernel code, 21444k reserved, 1470k data, 200k init) Calibrating delay using timer specific routine.. 4023.49 BogoMIPS (lpj=6703198) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 02 ACPI: Core revision 20060707 ACPI (tbget-0289): Table [DSDT] replaced by
Re: [PATCH 4/4] x86_64 ioapic: Improve the heuristics for when check_timer fails.
Eric W. Biederman wrote: Tobias. I don't have a box with the problem yours does, and this doesn't quite try any of the cases you have been asked to test so could you please test this one? Works fine with BIOS 0402. patches/series: patch-2.6.20-rc4 patch-2.6.19-rc3-nokmem myconfig ccache x86_64_io_apic_fix_eric_20060108 hpet-quirk dmesg: Linux version 2.6.20-rc4-amd64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) #56 Tue Jan 9 22:40:56 CET 2007 Command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ ro BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 3fee (usable) BIOS-e820: 3fee - 3fee3000 (ACPI NVS) BIOS-e820: 3fee3000 - 3fef (ACPI data) BIOS-e820: 3fef - 3ff0 (reserved) BIOS-e820: f000 - f400 (reserved) BIOS-e820: fec0 - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 261856 On node 0 totalpages: 261759 DMA zone: 56 pages used for memmap DMA zone: 1358 pages reserved DMA zone: 2585 pages, LIFO batch:0 DMA32 zone: 3524 pages used for memmap DMA32 zone: 254236 pages, LIFO batch:31 Normal zone: 0 pages used for memmap Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fd000 (fee0) mapped IOAPIC to ff5fc000 (fec0) Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000f Nosave address range: 000f - 0010 Allocating PCI resources starting at 4000 (gap: 3ff0:b010) Built 1 zonelists. Total pages: 256821 Kernel command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ ro netconsole: local port 6665 netconsole: local IP 192.168.8.241 netconsole: interface eth0 netconsole: remote port 514 netconsole: remote IP 255.255.255.255 netconsole: remote ethernet address ff:ff:ff:ff:ff:ff Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) trying to force-enable HPET HPET force-enabled at 0xfef0 time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer. time.c: Detected 2009.512 MHz processor. Console: colour VGA+ 80x60 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ b2c200 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 1025348k/1047424k available (3242k kernel code, 21444k reserved, 1470k data, 200k init) Calibrating delay using timer specific routine.. 4023.49 BogoMIPS (lpj=6703198) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: AMD Athlon(tm) 64 Processor 3200+ stepping 02 ACPI: Core revision 20060707 ACPI (tbget-0289): Table [DSDT] replaced by host OS
Re: 2.6.20-rc3: known unfixed regressions - x86_64 boot failure: "IO-APIC + timer doesn't work"
Yinghai Lu wrote: > Please check the latest version. ( 01/02/2007) Works for me, with both BIOS versions / routing variants. patches/series: patch-2.6.20-rc4 patch-2.6.19-rc3-nokmem myconfig ccache timer_01022007.diff hpet-quirk dmesg diff: --- dmesg-20070108-2.6.20-rc4-bios-0402 2007-01-08 01:51:57.0 +0100 +++ dmesg-20070108-2.6.20-rc4-bios-0609 2007-01-08 01:52:05.0 +0100 @@ -13,14 +13,15 @@ Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used end_pfn_map = 1048576 -DMI 2.3 present. -ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 -ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 -ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 -ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 -ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 -ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 -ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x +DMI 2.4 present. +ACPI: RSDP (v002 Nvidia) @ 0x000f7b70 +ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 +ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec5c0 +ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec7c0 +ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x0098) @ 0x3feec900 +ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec980 +ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec700 +ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x0300) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used Zone PFN ranges: @@ -37,8 +38,6 @@ DMA32 zone: 3524 pages used for memmap DMA32 zone: 254236 pages, LIFO batch:31 Normal zone: 0 pages used for memmap -Nvidia board detected. Ignoring ACPI timer override. -If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) @@ -48,13 +47,17 @@ ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 +ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) +ACPI: IRQ0 used by override. +ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat +ACPI: HPET id: 0x10de8201 base: 0xfefff000 Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fd000 (fee0) mapped IOAPIC to ff5fc000 (fec0) @@ -72,10 +75,8 @@ netconsole: remote ethernet address ff:ff:ff:ff:ff:ff Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) -trying to force-enable HPET -HPET force-enabled at 0xfef0 time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer. -time.c: Detected 2009.512 MHz processor. +time.c: Detected 2009.511 MHz processor. Console: colour VGA+ 80x60 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) @@ -84,7 +85,7 @@ Aperture too small (32 MB) No AGP bridge found Memory: 1025348k/1047424k available (3242k kernel code, 21444k reserved, 1470k data, 200k init) -Calibrating delay using timer specific routine.. 4023.44 BogoMIPS (lpj=6703119) +Calibrating delay using timer specific routine.. 4023.45 BogoMIPS (lpj=6703124) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) @@ -95,11 +96,10 @@ ESR value after enabling vector: , after 0004 ENABLING IO-APIC IRQs init IO_APIC IRQs - IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. -..TIMER: vector=0x20 apic1=0 pin1=0 apic2=-1 pin2=-1 -..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled<3> .. failed -..TIMER: trying IO-APIC=0 PIN=2 fallback with 8259 IRQ0 disabled<6>Using local APIC timer interrupts. -result 12559465 + IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. +..TIMER: vector=0x20 apic1=0 pin1=2 apic2=-1 pin2=-1 +..TIMER: trying IO-APIC=0 PIN=2 with 8259 IRQ0 disabled<6>Using local APIC timer interrupts. +result 12559463 Detected 12.559 MHz APIC timer. testing NMI watchdog ... OK. NET: Registered protocol family 16 @@ -168,7 +168,7 @@ usbcore:
Re: 2.6.20-rc3: known unfixed regressions - x86_64 boot failure: IO-APIC + timer doesn't work
Yinghai Lu wrote: Please check the latest version. ( 01/02/2007) Works for me, with both BIOS versions / routing variants. patches/series: patch-2.6.20-rc4 patch-2.6.19-rc3-nokmem myconfig ccache timer_01022007.diff hpet-quirk dmesg diff: --- dmesg-20070108-2.6.20-rc4-bios-0402 2007-01-08 01:51:57.0 +0100 +++ dmesg-20070108-2.6.20-rc4-bios-0609 2007-01-08 01:52:05.0 +0100 @@ -13,14 +13,15 @@ Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used end_pfn_map = 1048576 -DMI 2.3 present. -ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 -ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 -ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 -ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 -ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 -ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 -ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x +DMI 2.4 present. +ACPI: RSDP (v002 Nvidia) @ 0x000f7b70 +ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 +ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec5c0 +ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec7c0 +ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x0098) @ 0x3feec900 +ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec980 +ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec700 +ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x0300) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used Zone PFN ranges: @@ -37,8 +38,6 @@ DMA32 zone: 3524 pages used for memmap DMA32 zone: 254236 pages, LIFO batch:31 Normal zone: 0 pages used for memmap -Nvidia board detected. Ignoring ACPI timer override. -If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) @@ -48,13 +47,17 @@ ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 +ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) +ACPI: IRQ0 used by override. +ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat +ACPI: HPET id: 0x10de8201 base: 0xfefff000 Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fd000 (fee0) mapped IOAPIC to ff5fc000 (fec0) @@ -72,10 +75,8 @@ netconsole: remote ethernet address ff:ff:ff:ff:ff:ff Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) -trying to force-enable HPET -HPET force-enabled at 0xfef0 time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer. -time.c: Detected 2009.512 MHz processor. +time.c: Detected 2009.511 MHz processor. Console: colour VGA+ 80x60 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) @@ -84,7 +85,7 @@ Aperture too small (32 MB) No AGP bridge found Memory: 1025348k/1047424k available (3242k kernel code, 21444k reserved, 1470k data, 200k init) -Calibrating delay using timer specific routine.. 4023.44 BogoMIPS (lpj=6703119) +Calibrating delay using timer specific routine.. 4023.45 BogoMIPS (lpj=6703124) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) @@ -95,11 +96,10 @@ ESR value after enabling vector: , after 0004 ENABLING IO-APIC IRQs init IO_APIC IRQs - IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. -..TIMER: vector=0x20 apic1=0 pin1=0 apic2=-1 pin2=-1 -..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled3 .. failed -..TIMER: trying IO-APIC=0 PIN=2 fallback with 8259 IRQ0 disabled6Using local APIC timer interrupts. -result 12559465 + IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. +..TIMER: vector=0x20 apic1=0 pin1=2 apic2=-1 pin2=-1 +..TIMER: trying IO-APIC=0 PIN=2 with 8259 IRQ0 disabled6Using local APIC timer interrupts. +result 12559463 Detected 12.559 MHz APIC timer. testing NMI watchdog ... OK. NET: Registered protocol family 16 @@ -168,7 +168,7 @@ usbcore:
Re: IO-APIC + timer doesn't work
Yinghai Lu wrote: > On 12/19/06, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > >So the pin2 case should be tested right after the pin1 case as we do > >currently. On most new boards that will be a complete noop. > > > >But it is better than our current blind guess at using ExtINT mode. > > > >I figure after we try what the BIOS has told us about and that > >has failed we should first try the common irq 0 apic mappings, > >and then try the common ExtINT mappings. > > Please check if this one is ok. Works fine for me. FYI I'm off to my parents from Saturday onward, so after that I can't test any patches for the next one or two weeks. -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: IO-APIC + timer doesn't work
Yinghai Lu wrote: On 12/19/06, Eric W. Biederman [EMAIL PROTECTED] wrote: So the pin2 case should be tested right after the pin1 case as we do currently. On most new boards that will be a complete noop. But it is better than our current blind guess at using ExtINT mode. I figure after we try what the BIOS has told us about and that has failed we should first try the common irq 0 apic mappings, and then try the common ExtINT mappings. Please check if this one is ok. Works fine for me. FYI I'm off to my parents from Saturday onward, so after that I can't test any patches for the next one or two weeks. -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)
Tobias Diedrich wrote: > I can also report, that updating the BIOS to version 0609 (released > last week or so, also adds the long-missing HPET support) also makes > the problem go away since the first testcase then already works. > I'm currently running with the BIOS downgraded to version 0402. In case someone is interested, here is the diff between the dmesg from a boot with version 0402 and version 0609: (Changelogs for BIOS releases would be nice, all they say on the ASUS homepage is "support for new processors"...) --- dmesg-notimes-20061218-2.6.20-rc1-bios-0402 2006-12-18 16:27:36.0 +0100 +++ dmesg-notimes-20061218-2.6.20-rc1-bios-0609-works 2006-12-18 16:27:45.0 +0100 @@ -13,14 +13,15 @@ Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used end_pfn_map = 1048576 -DMI 2.3 present. -ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 -ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 -ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 -ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 -ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 -ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 -ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x +DMI 2.4 present. +ACPI: RSDP (v002 Nvidia) @ 0x000f7b70 +ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 +ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec5c0 +ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec7c0 +ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x0098) @ 0x3feec900 +ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec980 +ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec700 +ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x0300) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used Zone PFN ranges: @@ -37,8 +38,6 @@ DMA32 zone: 3524 pages used for memmap DMA32 zone: 254236 pages, LIFO batch:31 Normal zone: 0 pages used for memmap -Nvidia board detected. Ignoring ACPI timer override. -If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) @@ -48,13 +47,17 @@ ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 +ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) +ACPI: IRQ0 used by override. +ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat +ACPI: HPET id: 0x10de8201 base: 0xfefff000 Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fd000 (fee0) mapped IOAPIC to ff5fc000 (fec0) @@ -72,8 +75,8 @@ netconsole: remote ethernet address ff:ff:ff:ff:ff:ff Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) -time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. -time.c: Detected 2009.284 MHz processor. +time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer. +time.c: Detected 2009.513 MHz processor. Console: colour VGA+ 80x60 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) @@ -82,7 +85,7 @@ Aperture too small (32 MB) No AGP bridge found Memory: 1025340k/1047424k available (3252k kernel code, 21452k reserved, 1468k data, 200k init) -Calibrating delay using timer specific routine.. 4022.20 BogoMIPS (lpj=6701126) +Calibrating delay using timer specific routine.. 4023.46 BogoMIPS (lpj=6703148) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) @@ -93,12 +96,11 @@ ESR value after enabling vector: , after 0004 ENABLING IO-APIC IRQs init IO_APIC IRQs - IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. -..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled<3> (clear_IO_APIC_pin not called)<3> .. failed -..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled<3> .. works + IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. +..TIMER: trying I
Re: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)
Eric W. Biederman wrote: > Tobias Diedrich <[EMAIL PROTECTED]> writes: > > > Linus Torvalds wrote: > > > >> Your dmesg is kind of interesting: > >> > >> ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on > >> CPU0: > > 04(40) > >> .. failed > >> > >> where that APIC error on CPU0 seems to be a "Send accept error" and "Send > >> illegal vector" thing. I think we actually got the interrupt there, but > >> because we had some APIC setup bug, we didn't accept it properly, and it > >> resulted in that "APIC error" thing. Maybe. > > > > I just tried changing the code so the "8259 IRQ0 enabled" case is > > tested first and with that it boots fine. > > Could you try removing the clear_IO_APIC_pin from try_io_apic_pin. > > This isn't a complete fix but I believe for your hardware it will > fix the problem and it points at what the real fix is. > > Not properly programming the io_apic for the case we want to test. Yes, this works: |[ 27.535937] init IO_APIC IRQs |[ 27.536009] IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. |[ 27.536140] ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled<3> (clear_IO_APIC_pin not called)<3> .. failed |[ 27.569357] ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled<3> .. works |[ 27.602547] Using local APIC timer interrupts. I can also report, that updating the BIOS to version 0609 (released last week or so, also adds the long-missing HPET support) also makes the problem go away since the first testcase then already works. I'm currently running with the BIOS downgraded to version 0402. |[ 23.646371] ENABLING IO-APIC IRQs |[ 23.646477] init IO_APIC IRQs |[ 23.646479] IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. |[ 23.646674] ..TIMER: trying IO-APIC=0 PIN=2 with 8259 IRQ0 disabled<3> .. works |[ 23.679872] Using local APIC timer interrupts. Index: linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c === --- linux-2.6.20-rc1.orig/arch/x86_64/kernel/io_apic.c 2006-12-18 15:56:38.0 +0100 +++ linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c 2006-12-18 16:04:15.0 +0100 @@ -1586,9 +1586,11 @@ setup_nmi(); enable_8259A_irq(0); } + apic_printk(APIC_QUIET, KERN_ERR " .. works\n"); return 1; } - clear_IO_APIC_pin(apic, pin); + printk(KERN_ERR " (clear_IO_APIC_pin not called)"); + /* clear_IO_APIC_pin(apic, pin); */ apic_printk(APIC_QUIET, KERN_ERR " .. failed\n"); return 0; } HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)
Eric W. Biederman wrote: Tobias Diedrich [EMAIL PROTECTED] writes: Linus Torvalds wrote: Your dmesg is kind of interesting: ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0: 04(40) .. failed where that APIC error on CPU0 seems to be a Send accept error and Send illegal vector thing. I think we actually got the interrupt there, but because we had some APIC setup bug, we didn't accept it properly, and it resulted in that APIC error thing. Maybe. I just tried changing the code so the 8259 IRQ0 enabled case is tested first and with that it boots fine. Could you try removing the clear_IO_APIC_pin from try_io_apic_pin. This isn't a complete fix but I believe for your hardware it will fix the problem and it points at what the real fix is. Not properly programming the io_apic for the case we want to test. Yes, this works: |[ 27.535937] init IO_APIC IRQs |[ 27.536009] IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. |[ 27.536140] ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled3 (clear_IO_APIC_pin not called)3 .. failed |[ 27.569357] ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled3 .. works |[ 27.602547] Using local APIC timer interrupts. I can also report, that updating the BIOS to version 0609 (released last week or so, also adds the long-missing HPET support) also makes the problem go away since the first testcase then already works. I'm currently running with the BIOS downgraded to version 0402. |[ 23.646371] ENABLING IO-APIC IRQs |[ 23.646477] init IO_APIC IRQs |[ 23.646479] IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. |[ 23.646674] ..TIMER: trying IO-APIC=0 PIN=2 with 8259 IRQ0 disabled3 .. works |[ 23.679872] Using local APIC timer interrupts. Index: linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c === --- linux-2.6.20-rc1.orig/arch/x86_64/kernel/io_apic.c 2006-12-18 15:56:38.0 +0100 +++ linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c 2006-12-18 16:04:15.0 +0100 @@ -1586,9 +1586,11 @@ setup_nmi(); enable_8259A_irq(0); } + apic_printk(APIC_QUIET, KERN_ERR .. works\n); return 1; } - clear_IO_APIC_pin(apic, pin); + printk(KERN_ERR (clear_IO_APIC_pin not called)); + /* clear_IO_APIC_pin(apic, pin); */ apic_printk(APIC_QUIET, KERN_ERR .. failed\n); return 0; } HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de このメールは十割再利用されたビットで作られています。 - 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: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)
Tobias Diedrich wrote: I can also report, that updating the BIOS to version 0609 (released last week or so, also adds the long-missing HPET support) also makes the problem go away since the first testcase then already works. I'm currently running with the BIOS downgraded to version 0402. In case someone is interested, here is the diff between the dmesg from a boot with version 0402 and version 0609: (Changelogs for BIOS releases would be nice, all they say on the ASUS homepage is support for new processors...) --- dmesg-notimes-20061218-2.6.20-rc1-bios-0402 2006-12-18 16:27:36.0 +0100 +++ dmesg-notimes-20061218-2.6.20-rc1-bios-0609-works 2006-12-18 16:27:45.0 +0100 @@ -13,14 +13,15 @@ Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used end_pfn_map = 1048576 -DMI 2.3 present. -ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 -ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 -ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 -ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 -ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 -ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 -ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x +DMI 2.4 present. +ACPI: RSDP (v002 Nvidia) @ 0x000f7b70 +ACPI: XSDT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 +ACPI: FADT (v003 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec5c0 +ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec7c0 +ACPI: HPET (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x0098) @ 0x3feec900 +ACPI: MCFG (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec980 +ACPI: MADT (v001 Nvidia ASUSACPI 0x42302e31 AWRD 0x) @ 0x3feec700 +ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x0300) @ 0x Entering add_active_range(0, 0, 159) 0 entries of 256 used Entering add_active_range(0, 256, 261856) 1 entries of 256 used Zone PFN ranges: @@ -37,8 +38,6 @@ DMA32 zone: 3524 pages used for memmap DMA32 zone: 254236 pages, LIFO batch:31 Normal zone: 0 pages used for memmap -Nvidia board detected. Ignoring ACPI timer override. -If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) @@ -48,13 +47,17 @@ ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 +ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) +ACPI: IRQ0 used by override. +ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. ACPI: IRQ14 used by override. ACPI: IRQ15 used by override. Setting APIC routing to flat +ACPI: HPET id: 0x10de8201 base: 0xfefff000 Using ACPI (MADT) for SMP configuration information mapped APIC to ff5fd000 (fee0) mapped IOAPIC to ff5fc000 (fec0) @@ -72,8 +75,8 @@ netconsole: remote ethernet address ff:ff:ff:ff:ff:ff Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) -time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. -time.c: Detected 2009.284 MHz processor. +time.c: Using 25.00 MHz WALL HPET GTOD HPET/TSC timer. +time.c: Detected 2009.513 MHz processor. Console: colour VGA+ 80x60 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) @@ -82,7 +85,7 @@ Aperture too small (32 MB) No AGP bridge found Memory: 1025340k/1047424k available (3252k kernel code, 21452k reserved, 1468k data, 200k init) -Calibrating delay using timer specific routine.. 4022.20 BogoMIPS (lpj=6701126) +Calibrating delay using timer specific routine.. 4023.46 BogoMIPS (lpj=6703148) Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) @@ -93,12 +96,11 @@ ESR value after enabling vector: , after 0004 ENABLING IO-APIC IRQs init IO_APIC IRQs - IO-APIC (apicid-pin) 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. -..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 disabled3 (clear_IO_APIC_pin not called)3 .. failed -..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled3 .. works + IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23 not connected. +..TIMER: trying IO-APIC=0 PIN=2 with 8259 IRQ0 disabled3 .. works Using
Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1]
Pallipadi, Venkatesh wrote: > There are two things that can be happening when OS does not see HPET in > ACPI. > - BIOS did enable HPET in chipset and did not communicate it to OS. > - BIOS did nothing to enable HPET in chipset. > > The quirk below tries to find the HPET base address in case 1. But in > case 2 this will also fail as HPTC will be 0 below (Probably we can > still assume default base address of 0xFED0 and probe there. But I > am still checking on that). I just added couple of chipset ids that I > could test on... > > On the systems that I tested, HPTC was zero (case 2 above) and patch > below did not really help. > > I am building on this patch to enable HPET in late init stage based on > the the quirk information. Will be interesting to see what this patch > says on other ICH based systems that don't have HPET info in ACPI. In case anyone is interested, here is some information about the HPET on nVidia MCP55: With the recent update to BIOS Version 0609, ASUS has added HPET Support and a Enable/Disable BIOS option for the M2N SLI Deluxe. 00:01.0 0601: 10de:0360 (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00: de 10 60 03 0f 00 a0 00 a2 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 39 82 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 40: 43 10 39 82 00 f0 ff fe fa 3e ff 00 fa 3e ff 00 ^^^ HPET base address [0.00] ACPI: HPET id: 0x10de8201 base: 0xfefff000 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 ff 70: 10 00 ff ff c5 80 00 00 00 00 44 19 40 06 00 03 ^^ c1 => HPET disabled c5 => HPET enabled 80: 09 10 00 00 82 0d 00 00 c0 00 00 01 f0 00 00 00 90: 80 08 00 00 00 00 00 00 21 47 95 86 ef cd ab 00 a0: 01 00 30 c0 00 00 00 00 00 00 00 00 00 00 00 00 b0: 90 02 ef 02 00 08 5f 08 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de - 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: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)
Linus Torvalds wrote: > Your dmesg is kind of interesting: > > ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0: > 04(40) > .. failed > > where that APIC error on CPU0 seems to be a "Send accept error" and "Send > illegal vector" thing. I think we actually got the interrupt there, but > because we had some APIC setup bug, we didn't accept it properly, and it > resulted in that "APIC error" thing. Maybe. I just tried changing the code so the "8259 IRQ0 enabled" case is tested first and with that it boots fine. Index: linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c === --- linux-2.6.20-rc1.orig/arch/x86_64/kernel/io_apic.c 2006-12-17 00:45:57.0 +0100 +++ linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c 2006-12-17 15:39:40.0 +0100 @@ -1615,6 +1615,7 @@ */ apic_write(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_EXTINT); init_8259A(1); + enable_8259A_irq(0); pin1 = find_isa_irq_pin(0, mp_INT); apic1 = find_isa_irq_apic(0, mp_INT); [0.00] Linux version 2.6.20-rc1-amd64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) #28 Sun Dec 17 15:40:22 CET 2006 [0.00] Command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose apic=verbose ro [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fee (usable) [0.00] BIOS-e820: 3fee - 3fee3000 (ACPI NVS) [0.00] BIOS-e820: 3fee3000 - 3fef (ACPI data) [0.00] BIOS-e820: 3fef - 3ff0 (reserved) [0.00] BIOS-e820: f000 - f400 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 261856) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 [0.00] ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 [0.00] ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 [0.00] ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 [0.00] ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 [0.00] ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 [0.00] ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 261856) 1 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] DMA324096 -> 1048576 [0.00] Normal1048576 -> 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 261856 [0.00] On node 0 totalpages: 261759 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1356 pages reserved [0.00] DMA zone: 2587 pages, LIFO batch:0 [0.00] DMA32 zone: 3524 pages used for memmap [0.00] DMA32 zone: 254236 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Nvidia board detected. Ignoring ACPI timer override. [0.00] If you got timer trouble try acpi_use_timer_override [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) [0.00] ACPI: IRQ9 used by override. [0.00] ACPI: IRQ14 used by override. [0.00] ACPI: IRQ15 used by override. [0.00] Setting APIC routing to flat [0.00] Using ACPI (MADT) for SMP configuration information [
Re: IO-APIC + timer doesn't work
Linus Torvalds wrote: > On Sun, 17 Dec 2006, Tobias Diedrich wrote: > > > > No such luck, it still panics and the APIC error is also unchanged. > > Ok. I don't see anything wrong off-hand, but I'll keep the patch in the > tree in the hopes that Andi and/or Eric can see what's wrong and solve it. > > If we don't find a solution, I'll have to revert it, but let's give it a > few more days. > > Tobias, can you please make sure to remind me about this if nothing seems > to happen? Sure. BTW, I'm also wondering if this secondary Oops is supposed to happen: http://www.tdiedrich.de/~ranma/2.6.20-rc1-oops2.jpg I guess the NMI watchdog is never disabled after the test failed? |[68.908000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter |[68.908002] [~4 seconds later] |[68.908300] NMI Watchdog detected LOCKUP on CPU 0 ^ wrong timestamp? |[73.637325] CPU 0 |[73.637451] Modules linked in: |[73.637579] Pid: 1, comm: swapper Not tainted 2.6.20-rc1-amd64 #27 [...] - 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: IO-APIC + timer doesn't work
Linus Torvalds wrote: On Sun, 17 Dec 2006, Tobias Diedrich wrote: No such luck, it still panics and the APIC error is also unchanged. Ok. I don't see anything wrong off-hand, but I'll keep the patch in the tree in the hopes that Andi and/or Eric can see what's wrong and solve it. If we don't find a solution, I'll have to revert it, but let's give it a few more days. Tobias, can you please make sure to remind me about this if nothing seems to happen? Sure. BTW, I'm also wondering if this secondary Oops is supposed to happen: http://www.tdiedrich.de/~ranma/2.6.20-rc1-oops2.jpg I guess the NMI watchdog is never disabled after the test failed? |[68.908000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Try using the 'noapic' kernel parameter |[68.908002] [~4 seconds later] |[68.908300] NMI Watchdog detected LOCKUP on CPU 0 ^ wrong timestamp? |[73.637325] CPU 0 |[73.637451] Modules linked in: |[73.637579] Pid: 1, comm: swapper Not tainted 2.6.20-rc1-amd64 #27 [...] - 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: IO-APIC + timer doesn't work (was: Linux 2.6.20-rc1)
Linus Torvalds wrote: Your dmesg is kind of interesting: ..TIMER: trying IO-APIC=0 PIN=0 with 8259 IRQ0 enabled(7)APIC error on CPU0: 04(40) .. failed where that APIC error on CPU0 seems to be a Send accept error and Send illegal vector thing. I think we actually got the interrupt there, but because we had some APIC setup bug, we didn't accept it properly, and it resulted in that APIC error thing. Maybe. I just tried changing the code so the 8259 IRQ0 enabled case is tested first and with that it boots fine. Index: linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c === --- linux-2.6.20-rc1.orig/arch/x86_64/kernel/io_apic.c 2006-12-17 00:45:57.0 +0100 +++ linux-2.6.20-rc1/arch/x86_64/kernel/io_apic.c 2006-12-17 15:39:40.0 +0100 @@ -1615,6 +1615,7 @@ */ apic_write(APIC_LVT0, APIC_LVT_MASKED | APIC_DM_EXTINT); init_8259A(1); + enable_8259A_irq(0); pin1 = find_isa_irq_pin(0, mp_INT); apic1 = find_isa_irq_apic(0, mp_INT); [0.00] Linux version 2.6.20-rc1-amd64 ([EMAIL PROTECTED]) (gcc version 4.1.2 20061028 (prerelease) (Debian 4.1.1-19)) #28 Sun Dec 17 15:40:22 CET 2006 [0.00] Command line: root=/dev/sda5 resume=/dev/sda6 vga=6 apic=verbose apic=verbose ro [EMAIL PROTECTED]/,[EMAIL PROTECTED]/ [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fee (usable) [0.00] BIOS-e820: 3fee - 3fee3000 (ACPI NVS) [0.00] BIOS-e820: 3fee3000 - 3fef (ACPI data) [0.00] BIOS-e820: 3fef - 3ff0 (reserved) [0.00] BIOS-e820: f000 - f400 (reserved) [0.00] BIOS-e820: fec0 - 0001 (reserved) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 261856) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP (v000 Nvidia) @ 0x000f7ce0 [0.00] ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee3040 [0.00] ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3fee30c0 [0.00] ACPI: SSDT (v001 PTLTD POWERNOW 0x0001 LTP 0x0001) @ 0x3feec2c0 [0.00] ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec400 [0.00] ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 0x3feec200 [0.00] ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 0x [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 261856) 1 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] DMA324096 - 1048576 [0.00] Normal1048576 - 1048576 [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 - 159 [0.00] 0: 256 - 261856 [0.00] On node 0 totalpages: 261759 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1356 pages reserved [0.00] DMA zone: 2587 pages, LIFO batch:0 [0.00] DMA32 zone: 3524 pages used for memmap [0.00] DMA32 zone: 254236 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Nvidia board detected. Ignoring ACPI timer override. [0.00] If you got timer trouble try acpi_use_timer_override [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] ACPI: Local APIC address 0xfee0 [0.00] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [0.00] Processor #0 (Bootup-CPU) [0.00] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled) [0.00] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [0.00] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [0.00] ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) [0.00] IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) [0.00] ACPI: IRQ9 used by override. [0.00] ACPI: IRQ14 used by override. [0.00] ACPI: IRQ15 used by override. [0.00] Setting APIC routing to flat [0.00] Using ACPI (MADT) for SMP configuration information [0.00] mapped APIC to
Re: CONFIG_NO_HZ: missed ticks, stall (keyb IRQ required) [2.6.18-rc4-mm1]
Pallipadi, Venkatesh wrote: There are two things that can be happening when OS does not see HPET in ACPI. - BIOS did enable HPET in chipset and did not communicate it to OS. - BIOS did nothing to enable HPET in chipset. The quirk below tries to find the HPET base address in case 1. But in case 2 this will also fail as HPTC will be 0 below (Probably we can still assume default base address of 0xFED0 and probe there. But I am still checking on that). I just added couple of chipset ids that I could test on... On the systems that I tested, HPTC was zero (case 2 above) and patch below did not really help. I am building on this patch to enable HPET in late init stage based on the the quirk information. Will be interesting to see what this patch says on other ICH based systems that don't have HPET info in ACPI. In case anyone is interested, here is some information about the HPET on nVidia MCP55: With the recent update to BIOS Version 0609, ASUS has added HPET Support and a Enable/Disable BIOS option for the M2N SLI Deluxe. 00:01.0 0601: 10de:0360 (rev a2) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2) 00: de 10 60 03 0f 00 a0 00 a2 00 01 06 00 00 80 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 39 82 30: 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 40: 43 10 39 82 00 f0 ff fe fa 3e ff 00 fa 3e ff 00 ^^^ HPET base address [0.00] ACPI: HPET id: 0x10de8201 base: 0xfefff000 50: fa 3e ff 00 00 5a 62 02 00 00 00 01 00 00 ff ff 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 ff 70: 10 00 ff ff c5 80 00 00 00 00 44 19 40 06 00 03 ^^ c1 = HPET disabled c5 = HPET enabled 80: 09 10 00 00 82 0d 00 00 c0 00 00 01 f0 00 00 00 90: 80 08 00 00 00 00 00 00 21 47 95 86 ef cd ab 00 a0: 01 00 30 c0 00 00 00 00 00 00 00 00 00 00 00 00 b0: 90 02 ef 02 00 08 5f 08 00 00 00 00 00 00 00 00 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0: 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 HTH, -- Tobias PGP: http://9ac7e0bc.uguu.de - 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/
