Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Fri, May 18, 2007 at 09:16:45PM +0200, Luca Tettamanti wrote:
>
> Output from serial console is enlightening (sort of...):
>
> Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to
> handle kernel paging request at virtual address 6b6b6ceb printing eip:
> b0141aef
> [oops]
Thanks. Turns out to be a silly bug :) It's been around for a while
though.
[CRYPTO] api: Read module pointer before freeing algorithm
The function crypto_mod_put first frees the algorithm and then drops
the reference to its module. Unfortunately we read the module pointer
which after freeing the algorithm and that pointer sits inside the
object that we just freed.
So this patch reads the module pointer out before we free the object.
Thanks to Luca Tettamanti for reporting this.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/crypto/api.c b/crypto/api.c
index 55af8bb..33734fd 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -48,8 +48,10 @@ EXPORT_SYMBOL_GPL(crypto_mod_get);
void crypto_mod_put(struct crypto_alg *alg)
{
+ struct module *module = alg->cra_module;
+
crypto_alg_put(alg);
- module_put(alg->cra_module);
+ module_put(module);
}
EXPORT_SYMBOL_GPL(crypto_mod_put);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Luca Tettamanti wrote: > Il Fri, May 18, 2007 at 11:14:55PM +1000, Herbert Xu ha scritto: >> On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote: >>> Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, >>> git agrees and I've done a full rebuild. The .config is generated >>> using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is >>> coming from there? >> Sorry, my mistake. That bug only happens if you have padlock turned on. >> >> Anyway, if possible could you post the complete dmesg when it crashes? >> I'd like to see what has happened up to the point where it crashes. > > Output from serial console is enlightening (sort of...): > > Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to > handle kernel paging request at virtual address 6b6b6ceb printing eip: > b0141aef > [oops] > module_put() is trying to decrease the refcount of a module that's already been freed, AFAICT. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Fri, May 18, 2007 at 11:14:55PM +1000, Herbert Xu ha scritto: > On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote: > > > > Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, > > git agrees and I've done a full rebuild. The .config is generated > > using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is > > coming from there? > > Sorry, my mistake. That bug only happens if you have padlock turned on. > > Anyway, if possible could you post the complete dmesg when it crashes? > I'd like to see what has happened up to the point where it crashes. Output from serial console is enlightening (sort of...): Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to handle kernel paging request at virtual address 6b6b6ceb printing eip: b0141aef [oops] Problem is that: - /etc/ipsec-tools.conf is empty (everything is commented out), it's a leftover of previous experiments. - AH and ESP are disabled in the kernel since I don't use them anymore. Removing setkey script from init.d makes the OOPS disappear though; nothing happens if I manually run setkey after the boot... This is the full log: Linux version 2.6.22-rc1-libata-g705962cc-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #63 SMP PREEMPT Thu May 17 00:22:29 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009c800 (usable) BIOS-e820: 0009c800 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ff9 (usable) BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) BIOS-e820: 3ffe - 4000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 1023MB LOWMEM available. found SMP MP-table at 000ff780 Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 262032 early_node_map[1] active PFN ranges 0:0 -> 262032 DMI 2.4 present. ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) ACPI: DSDT 3FF905C0, 8F8C (r1 A0637 A06370000 INTL 20060113) ACPI: FACS 3FF9E000, 0040 ACPI: APIC 3FF90390, 006C (r1 MSTEST OEMAPIC 12000611 MSFT 97) ACPI: MCFG 3FF90400, 003C (r1 MSTEST OEMMCFG 12000611 MSFT 97) ACPI: SLIC 3FF90440, 0176 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: OEMB 3FF9E040, 007B (r1 MSTEST AMI_OEM 12000611 MSFT 97) ACPI: HPET 3FF99550, 0038 (r1 MSTEST OEMHPET 12000611 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, 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) Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a202 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:bee0) Built 1 zonelists. Total pages: 259985 Kernel command line: BOOT_IMAGE=linux-2.6.22r1 ro video=radeonfb:[EMAIL PROTECTED] lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 console=ttyS0,57600n8 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=b042e000 soft=b042c000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2135.141 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1200 bytes | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok | A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok | A-B-B-C-C-D-D-A deadlock:
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote:
>
> Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty,
> git agrees and I've done a full rebuild. The .config is generated
> using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is
> coming from there?
Sorry, my mistake. That bug only happens if you have padlock turned on.
Anyway, if possible could you post the complete dmesg when it crashes?
I'd like to see what has happened up to the point where it crashes.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On 5/18/07, Herbert Xu <[EMAIL PROTECTED]> wrote: On Tue, May 15, 2007 at 08:52:12PM +0200, Luca Tettamanti wrote: > > CONFIG_CRYPTO_ALGAPI=m Are you sure you're actually running 2.6.22-rc1? Due to a bug in the padlock patch present in 2.6.22-rc1 it shouldn't be possible to select ALGAPI as a module. Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, git agrees and I've done a full rebuild. The .config is generated using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is coming from there? Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On 5/18/07, Herbert Xu [EMAIL PROTECTED] wrote: On Tue, May 15, 2007 at 08:52:12PM +0200, Luca Tettamanti wrote: CONFIG_CRYPTO_ALGAPI=m Are you sure you're actually running 2.6.22-rc1? Due to a bug in the padlock patch present in 2.6.22-rc1 it shouldn't be possible to select ALGAPI as a module. Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, git agrees and I've done a full rebuild. The .config is generated using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is coming from there? Luca - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote:
Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty,
git agrees and I've done a full rebuild. The .config is generated
using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is
coming from there?
Sorry, my mistake. That bug only happens if you have padlock turned on.
Anyway, if possible could you post the complete dmesg when it crashes?
I'd like to see what has happened up to the point where it crashes.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Fri, May 18, 2007 at 11:14:55PM +1000, Herbert Xu ha scritto: On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote: Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, git agrees and I've done a full rebuild. The .config is generated using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is coming from there? Sorry, my mistake. That bug only happens if you have padlock turned on. Anyway, if possible could you post the complete dmesg when it crashes? I'd like to see what has happened up to the point where it crashes. Output from serial console is enlightening (sort of...): Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to handle kernel paging request at virtual address 6b6b6ceb printing eip: b0141aef [oops] Problem is that: - /etc/ipsec-tools.conf is empty (everything is commented out), it's a leftover of previous experiments. - AH and ESP are disabled in the kernel since I don't use them anymore. Removing setkey script from init.d makes the OOPS disappear though; nothing happens if I manually run setkey after the boot... This is the full log: Linux version 2.6.22-rc1-libata-g705962cc-dirty ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #63 SMP PREEMPT Thu May 17 00:22:29 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009c800 (usable) BIOS-e820: 0009c800 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - 3ff9 (usable) BIOS-e820: 3ff9 - 3ff9e000 (ACPI data) BIOS-e820: 3ff9e000 - 3ffe (ACPI NVS) BIOS-e820: 3ffe - 4000 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) 1023MB LOWMEM available. found SMP MP-table at 000ff780 Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 262032 early_node_map[1] active PFN ranges 0:0 - 262032 DMI 2.4 present. ACPI: RSDP 000FA980, 0024 (r2 ACPIAM) ACPI: XSDT 3FF90100, 0054 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: FACP 3FF90290, 00F4 (r3 MSTEST OEMFACP 12000611 MSFT 97) ACPI: DSDT 3FF905C0, 8F8C (r1 A0637 A06370000 INTL 20060113) ACPI: FACS 3FF9E000, 0040 ACPI: APIC 3FF90390, 006C (r1 MSTEST OEMAPIC 12000611 MSFT 97) ACPI: MCFG 3FF90400, 003C (r1 MSTEST OEMMCFG 12000611 MSFT 97) ACPI: SLIC 3FF90440, 0176 (r1 KOZIRO FRONTIER 12000611 MSFT 97) ACPI: OEMB 3FF9E040, 007B (r1 MSTEST AMI_OEM 12000611 MSFT 97) ACPI: HPET 3FF99550, 0038 (r1 MSTEST OEMHPET 12000611 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:15 APIC version 20 ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled) ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, 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) Enabling APIC mode: Flat. Using 1 I/O APICs ACPI: HPET id: 0x8086a202 base: 0xfed0 Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 5000 (gap: 4000:bee0) Built 1 zonelists. Total pages: 259985 Kernel command line: BOOT_IMAGE=linux-2.6.22r1 ro video=radeonfb:[EMAIL PROTECTED] lapic apic=verbose root=/dev/mapper/mainVol-root console=tty0 console=ttyS0,57600n8 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=b042e000 soft=b042c000 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2135.141 MHz processor. Console: colour VGA+ 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES:8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS:2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1200 bytes | Locking API testsuite: | spin |wlock |rlock |mutex | wsem | rsem | -- A-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-A deadlock: ok | ok | ok | ok | ok | ok | A-B-B-C-C-A deadlock: ok | ok | ok | ok | ok | ok | A-B-C-A-B-C deadlock: ok | ok | ok | ok | ok | ok | A-B-B-C-C-D-D-A deadlock: ok | ok | ok |
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Luca Tettamanti wrote: Il Fri, May 18, 2007 at 11:14:55PM +1000, Herbert Xu ha scritto: On Fri, May 18, 2007 at 02:09:54PM +0200, Luca wrote: Well, pretty sure. The OOPS says 2.6.22-rc1-libata-g705962cc-dirty, git agrees and I've done a full rebuild. The .config is generated using 'make oldconfig' using the 2.6.21 as baseline, maybe ALGAPI is coming from there? Sorry, my mistake. That bug only happens if you have padlock turned on. Anyway, if possible could you post the complete dmesg when it crashes? I'd like to see what has happened up to the point where it crashes. Output from serial console is enlightening (sort of...): Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to handle kernel paging request at virtual address 6b6b6ceb printing eip: b0141aef [oops] module_put() is trying to decrease the refcount of a module that's already been freed, AFAICT. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Fri, May 18, 2007 at 09:16:45PM +0200, Luca Tettamanti wrote:
Output from serial console is enlightening (sort of...):
Loading IPsec SA/SP database from /etc/ipsec-tools.conf: BUG: unable to
handle kernel paging request at virtual address 6b6b6ceb printing eip:
b0141aef
[oops]
Thanks. Turns out to be a silly bug :) It's been around for a while
though.
[CRYPTO] api: Read module pointer before freeing algorithm
The function crypto_mod_put first frees the algorithm and then drops
the reference to its module. Unfortunately we read the module pointer
which after freeing the algorithm and that pointer sits inside the
object that we just freed.
So this patch reads the module pointer out before we free the object.
Thanks to Luca Tettamanti for reporting this.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/crypto/api.c b/crypto/api.c
index 55af8bb..33734fd 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -48,8 +48,10 @@ EXPORT_SYMBOL_GPL(crypto_mod_get);
void crypto_mod_put(struct crypto_alg *alg)
{
+ struct module *module = alg-cra_module;
+
crypto_alg_put(alg);
- module_put(alg-cra_module);
+ module_put(module);
}
EXPORT_SYMBOL_GPL(crypto_mod_put);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Tue, May 15, 2007 at 08:52:12PM +0200, Luca Tettamanti wrote:
>
> CONFIG_CRYPTO_ALGAPI=m
Are you sure you're actually running 2.6.22-rc1? Due to a bug
in the padlock patch present in 2.6.22-rc1 it shouldn't be
possible to select ALGAPI as a module.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On 5/17/07, Luca Tettamanti <[EMAIL PROTECTED]> wrote: Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: > On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: > > I'm running git 705962cc (which is a commit after -rc1) and I still see > > the OOPS on boot. The patch above is already applied though. Note that > > I'm using the SLAB allocator: > > > > CONFIG_SLAB=y > > # CONFIG_SLUB is not set > > # CONFIG_SLOB is not set > > > > > > Ending clean XFS mount for filesystem: dm-4 > > BUG: unable to handle kernel paging request at virtual address 6b6b6ceb > > Please send me your .config file. It seems that build system was confused... I've checked the timestamps of *.o files and make didn't rebuild anything, but rebuilding after a 'make clean' did "fix" the problem. Sorry for the noise... Ok, wait: it's still there. It's just not 100% reproducible, sometimes the system boots fine. So it either crashes on boot or it runs fine for hours. Luca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: > On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: > > I'm running git 705962cc (which is a commit after -rc1) and I still see > > the OOPS on boot. The patch above is already applied though. Note that > > I'm using the SLAB allocator: > > > > CONFIG_SLAB=y > > # CONFIG_SLUB is not set > > # CONFIG_SLOB is not set > > > > > > Ending clean XFS mount for filesystem: dm-4 > > BUG: unable to handle kernel paging request at virtual address 6b6b6ceb > > Please send me your .config file. It seems that build system was confused... I've checked the timestamps of *.o files and make didn't rebuild anything, but rebuilding after a 'make clean' did "fix" the problem. Sorry for the noise... Luca -- Mi piace avere amici rispettabili; Mi piace essere il peggiore della compagnia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: I'm running git 705962cc (which is a commit after -rc1) and I still see the OOPS on boot. The patch above is already applied though. Note that I'm using the SLAB allocator: CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set Ending clean XFS mount for filesystem: dm-4 BUG: unable to handle kernel paging request at virtual address 6b6b6ceb Please send me your .config file. It seems that build system was confused... I've checked the timestamps of *.o files and make didn't rebuild anything, but rebuilding after a 'make clean' did fix the problem. Sorry for the noise... Luca -- Mi piace avere amici rispettabili; Mi piace essere il peggiore della compagnia. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On 5/17/07, Luca Tettamanti [EMAIL PROTECTED] wrote: Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: I'm running git 705962cc (which is a commit after -rc1) and I still see the OOPS on boot. The patch above is already applied though. Note that I'm using the SLAB allocator: CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set Ending clean XFS mount for filesystem: dm-4 BUG: unable to handle kernel paging request at virtual address 6b6b6ceb Please send me your .config file. It seems that build system was confused... I've checked the timestamps of *.o files and make didn't rebuild anything, but rebuilding after a 'make clean' did fix the problem. Sorry for the noise... Ok, wait: it's still there. It's just not 100% reproducible, sometimes the system boots fine. So it either crashes on boot or it runs fine for hours. Luca - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Tue, May 15, 2007 at 08:52:12PM +0200, Luca Tettamanti wrote:
CONFIG_CRYPTO_ALGAPI=m
Are you sure you're actually running 2.6.22-rc1? Due to a bug
in the padlock patch present in 2.6.22-rc1 it shouldn't be
possible to select ALGAPI as a module.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: > On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: > > I'm running git 705962cc (which is a commit after -rc1) and I still see > > the OOPS on boot. The patch above is already applied though. Note that > > I'm using the SLAB allocator: > > > > CONFIG_SLAB=y > > # CONFIG_SLUB is not set > > # CONFIG_SLOB is not set > > > > > > Ending clean XFS mount for filesystem: dm-4 > > BUG: unable to handle kernel paging request at virtual address 6b6b6ceb > > Please send me your .config file. There it is: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc1 # Mon May 14 00:01:41 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_QUICKLIST=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_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="-libata" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # 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_LOG_BUF_SHIFT=18 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" 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=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # 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 CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # 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=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_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 is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y 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_X86_MINIMUM_CPU_MODEL=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Il Tue, May 15, 2007 at 11:43:44AM +1000, Herbert Xu ha scritto: On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote: I'm running git 705962cc (which is a commit after -rc1) and I still see the OOPS on boot. The patch above is already applied though. Note that I'm using the SLAB allocator: CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set Ending clean XFS mount for filesystem: dm-4 BUG: unable to handle kernel paging request at virtual address 6b6b6ceb Please send me your .config file. There it is: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.22-rc1 # Mon May 14 00:01:41 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_QUICKLIST=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_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION=-libata CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # 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_LOG_BUF_SHIFT=18 # CONFIG_CPUSETS is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= 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=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # 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 CONFIG_STOP_MACHINE=y # # Block layer # CONFIG_BLOCK=y CONFIG_LBD=y # 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=y # CONFIG_HIGH_RES_TIMERS is not set CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_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 is not set # CONFIG_MPENTIUMM is not set CONFIG_MCORE2=y # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set CONFIG_X86_GENERIC=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y 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_X86_MINIMUM_CPU_MODEL=4 CONFIG_HPET_TIMER=y CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y CONFIG_X86_MCE_NONFATAL=y CONFIG_X86_MCE_P4THERMAL=y CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set CONFIG_MICROCODE=m CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m # # Firmware Drivers # # CONFIG_EDD is not set #
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote:
> I'm running git 705962cc (which is a commit after -rc1) and I still see
> the OOPS on boot. The patch above is already applied though. Note that
> I'm using the SLAB allocator:
>
> CONFIG_SLAB=y
> # CONFIG_SLUB is not set
> # CONFIG_SLOB is not set
>
>
> Ending clean XFS mount for filesystem: dm-4
> BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
Please send me your .config file.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
And Dmitry Torokhov writes:
> I don't think so. Could you please try the patch below? Thanks!
The appended patch on top of yours fixes the too-early access of
psmouse->private. I don't know the expected lifetime of
psmouse->private, so I chickened out of simply assigning priv
earlier.
BTW, why do you pass psmouse down through the initializations
rather than ps2dev and private?
Jason, using git's index, dammit...
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 2aeb299..990d2a5 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -384,10 +384,9 @@ static int alps_poll(struct psmouse *psmouse)
return 0;
}
-static int alps_hw_init(struct psmouse *psmouse, int *version)
+static int alps_hw_init(struct psmouse *psmouse, struct alps_data *priv,
+ int *version)
{
- struct alps_data *priv = psmouse->private;
-
priv->i = alps_get_model(psmouse, version);
if (!priv->i)
return -1;
@@ -421,7 +420,7 @@ static int alps_reconnect(struct psmouse *psmouse)
{
psmouse_reset(psmouse);
- if (alps_hw_init(psmouse, NULL))
+ if (alps_hw_init(psmouse, (struct alps_data *)psmouse->private, NULL))
return -1;
return 0;
@@ -449,7 +448,7 @@ int alps_init(struct psmouse *psmouse)
priv->dev2 = dev2;
- if (alps_hw_init(psmouse, ))
+ if (alps_hw_init(psmouse, priv, ))
goto init_fail;
dev1->evbit[LONG(EV_KEY)] |= BIT(EV_KEY);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Kevin Winchester <[EMAIL PROTECTED]> ha scritto:
> On 5/9/07, Herbert Xu <[EMAIL PROTECTED]> wrote:
>> On Tue, May 08, 2007 at 09:58:09PM -0300, Kevin Winchester wrote:
>> >
>> > Not having any idea what I'm doing, I looked at cryptomgr_probe and
>> > cryptomgr_notify, and can't seem to see much, except for the following
>> > odd lines.
>> >
>> > From cryptomgr_schedule_probe, which is almost certainly inlined into
>> > crypto_notify:
>>
>> Thanks for reporting this. This patch should fix the problem.
>>
>> Cheers,
>> --
>> Visit Openswan at http://www.openswan.org/
>> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
>> Home Page: http://gondor.apana.org.au/~herbert/
>> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>> --
>> diff -puN crypto/cryptomgr.c~crypto-fix crypto/cryptomgr.c
>> --- a/crypto/cryptomgr.c~crypto-fix
>> +++ a/crypto/cryptomgr.c
>> @@ -24,8 +24,6 @@
>> #include "internal.h"
>>
>> struct cryptomgr_param {
>> - struct task_struct *thread;
>> -
>> struct rtattr *tb[CRYPTOA_MAX];
>>
>> struct {
>> @@ -81,6 +79,7 @@ err:
>>
>> static int cryptomgr_schedule_probe(struct crypto_larval *larval)
>> {
>> + struct task_struct *thread;
>> struct cryptomgr_param *param;
>> const char *name = larval->alg.cra_name;
>> const char *p;
>> @@ -130,8 +129,8 @@ static int cryptomgr_schedule_probe(stru
>>
>> memcpy(param->larval.name, larval->alg.cra_name,
>> CRYPTO_MAX_ALG_NAME);
>>
>> - param->thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
>> - if (IS_ERR(param->thread))
>> + thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
>> + if (IS_ERR(thread))
>> goto err_free_param;
>>
>> return NOTIFY_STOP;
>> _
>>
>
> I see that this patch made it in to mainline, and latest -git now
> works for me, so I assume this was the correct solution. I thought I
> had tried this exact change without success when I was looking at the
> problem, but I guess I did something wrong along the way.
Hum,
I'm running git 705962cc (which is a commit after -rc1) and I still see
the OOPS on boot. The patch above is already applied though. Note that
I'm using the SLAB allocator:
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
Ending clean XFS mount for filesystem: dm-4
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
b0141aef
*pde =
Oops: 0002 [#1]
PREEMPT SMP
BUG: unable to handle kernel paging request at virtual address 6b6b6d6b
printing eip:
b0141aef
*pde =
Modules linked in: sha1 md5 hmac crypto_hash cryptomgr crypto_algapi nfsd
exportfs lockd sunrpc vfat fat nls_base fuse cpufreq_ondemand acpi_cpufreq
freq_table i2c_isa ipv6 snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer ohci1394 snd e100 parport_pc parport ehci_hcd uhci_hcd atl1 intel_agp
agpgart ieee1394 usbcore soundcore mii i2c_i801 snd_page_alloc dm_snapshot
dm_mod thermal processor fan pata_ali sata_uli reiserfs xfs
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010256 (2.6.22-rc1-libata-g705962cc-dirty #62)
EIP is at module_put+0x1c/0x57
eax: ebx: 6b6b6b6b ecx: 0001 edx: ee5bb000
esi: edi: ee7b8a38 ebp: esp: ee5bbfa8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process cryptomgr (pid: 4532, ti=ee5bb000 task=ef2fc070 task.ti=ee5bb000)
Stack: ee7b8a38 ee7b8a38 f0858235 0282 ef1a0bc0 ee7b8a38
f08581b3 b0131351 007b b0131316 b0104b3b
ef1a0bb4
Call Trace:
[] cryptomgr_probe+0x82/0x99 [cryptomgr]
[] cryptomgr_probe+0x0/0x99 [cryptomgr]
[] kthread+0x3b/0x62
[] kthread+0x0/0x62
[] kernel_thread_helper+0x7/0x10
===
Code: e8 fa 70 08 00 83 c4 0c 89 d8 5b 5e 5f 5d c3 53 89 c3 83 ec 08 85 c0 74
49 b8 01 00 00 00 e8 ba a4 fd ff e8 34 70 09 00 c1 e0 07 8c 18 80 01 00 00
83 3b 02 75 0b 8b 83 88 02 00 00 e8 18 9e
EIP: [] module_put+0x1c/0x57 SS:ESP 0068:ee5bbfa8
Oops: 0002 [#2]
note: cryptomgr[4532] exited with preempt_count 1
PREEMPT SMP
Modules linked in: sha1 md5 hmac crypto_hash cryptomgr crypto_algapi nfsd
exportfs lockd sunrpc vfat fat nls_base fuse cpufreq_ondemand acpi_cpufreq
freq_table i2c_isa ipv6 snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer ohci1394 snd e100 parport_pc parport ehci_hcd uhci_hcd atl1 intel_agp
agpgart ieee1394 usbcore soundcore mii i2c_i801 snd_page_alloc dm_snapshot
dm_mod thermal processor fan pata_ali sata_uli reiserfs xfs
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 00010212 (2.6.22-rc1-libata-g705962cc-dirty #62)
EIP is at module_put+0x1c/0x57
eax: 0080 ebx: 6b6b6b6b ecx: 0001 edx: b1a0f000
esi: edi: ee20fd80 ebp: esp: b1a0ffa8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process cryptomgr (pid: 4537, ti=b1a0f000 task=eecce0b0 task.ti=b1a0f000)
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Kevin Winchester [EMAIL PROTECTED] ha scritto:
On 5/9/07, Herbert Xu [EMAIL PROTECTED] wrote:
On Tue, May 08, 2007 at 09:58:09PM -0300, Kevin Winchester wrote:
Not having any idea what I'm doing, I looked at cryptomgr_probe and
cryptomgr_notify, and can't seem to see much, except for the following
odd lines.
From cryptomgr_schedule_probe, which is almost certainly inlined into
crypto_notify:
Thanks for reporting this. This patch should fix the problem.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff -puN crypto/cryptomgr.c~crypto-fix crypto/cryptomgr.c
--- a/crypto/cryptomgr.c~crypto-fix
+++ a/crypto/cryptomgr.c
@@ -24,8 +24,6 @@
#include internal.h
struct cryptomgr_param {
- struct task_struct *thread;
-
struct rtattr *tb[CRYPTOA_MAX];
struct {
@@ -81,6 +79,7 @@ err:
static int cryptomgr_schedule_probe(struct crypto_larval *larval)
{
+ struct task_struct *thread;
struct cryptomgr_param *param;
const char *name = larval-alg.cra_name;
const char *p;
@@ -130,8 +129,8 @@ static int cryptomgr_schedule_probe(stru
memcpy(param-larval.name, larval-alg.cra_name,
CRYPTO_MAX_ALG_NAME);
- param-thread = kthread_run(cryptomgr_probe, param, cryptomgr);
- if (IS_ERR(param-thread))
+ thread = kthread_run(cryptomgr_probe, param, cryptomgr);
+ if (IS_ERR(thread))
goto err_free_param;
return NOTIFY_STOP;
_
I see that this patch made it in to mainline, and latest -git now
works for me, so I assume this was the correct solution. I thought I
had tried this exact change without success when I was looking at the
problem, but I guess I did something wrong along the way.
Hum,
I'm running git 705962cc (which is a commit after -rc1) and I still see
the OOPS on boot. The patch above is already applied though. Note that
I'm using the SLAB allocator:
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
Ending clean XFS mount for filesystem: dm-4
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
b0141aef
*pde =
Oops: 0002 [#1]
PREEMPT SMP
BUG: unable to handle kernel paging request at virtual address 6b6b6d6b
printing eip:
b0141aef
*pde =
Modules linked in: sha1 md5 hmac crypto_hash cryptomgr crypto_algapi nfsd
exportfs lockd sunrpc vfat fat nls_base fuse cpufreq_ondemand acpi_cpufreq
freq_table i2c_isa ipv6 snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer ohci1394 snd e100 parport_pc parport ehci_hcd uhci_hcd atl1 intel_agp
agpgart ieee1394 usbcore soundcore mii i2c_i801 snd_page_alloc dm_snapshot
dm_mod thermal processor fan pata_ali sata_uli reiserfs xfs
CPU:0
EIP:0060:[b0141aef]Not tainted VLI
EFLAGS: 00010256 (2.6.22-rc1-libata-g705962cc-dirty #62)
EIP is at module_put+0x1c/0x57
eax: ebx: 6b6b6b6b ecx: 0001 edx: ee5bb000
esi: edi: ee7b8a38 ebp: esp: ee5bbfa8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process cryptomgr (pid: 4532, ti=ee5bb000 task=ef2fc070 task.ti=ee5bb000)
Stack: ee7b8a38 ee7b8a38 f0858235 0282 ef1a0bc0 ee7b8a38
f08581b3 b0131351 007b b0131316 b0104b3b
ef1a0bb4
Call Trace:
[f0858235] cryptomgr_probe+0x82/0x99 [cryptomgr]
[f08581b3] cryptomgr_probe+0x0/0x99 [cryptomgr]
[b0131351] kthread+0x3b/0x62
[b0131316] kthread+0x0/0x62
[b0104b3b] kernel_thread_helper+0x7/0x10
===
Code: e8 fa 70 08 00 83 c4 0c 89 d8 5b 5e 5f 5d c3 53 89 c3 83 ec 08 85 c0 74
49 b8 01 00 00 00 e8 ba a4 fd ff e8 34 70 09 00 c1 e0 07 ff 8c 18 80 01 00 00
83 3b 02 75 0b 8b 83 88 02 00 00 e8 18 9e
EIP: [b0141aef] module_put+0x1c/0x57 SS:ESP 0068:ee5bbfa8
Oops: 0002 [#2]
note: cryptomgr[4532] exited with preempt_count 1
PREEMPT SMP
Modules linked in: sha1 md5 hmac crypto_hash cryptomgr crypto_algapi nfsd
exportfs lockd sunrpc vfat fat nls_base fuse cpufreq_ondemand acpi_cpufreq
freq_table i2c_isa ipv6 snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm
snd_timer ohci1394 snd e100 parport_pc parport ehci_hcd uhci_hcd atl1 intel_agp
agpgart ieee1394 usbcore soundcore mii i2c_i801 snd_page_alloc dm_snapshot
dm_mod thermal processor fan pata_ali sata_uli reiserfs xfs
CPU:1
EIP:0060:[b0141aef]Not tainted VLI
EFLAGS: 00010212 (2.6.22-rc1-libata-g705962cc-dirty #62)
EIP is at module_put+0x1c/0x57
eax: 0080 ebx: 6b6b6b6b ecx: 0001 edx: b1a0f000
esi: edi: ee20fd80 ebp: esp: b1a0ffa8
ds: 007b es: 007b fs: 00d8 gs: ss: 0068
Process cryptomgr (pid: 4537, ti=b1a0f000 task=eecce0b0 task.ti=b1a0f000)
Stack: ee20fd80 ee20fd80 f0858235 0282 ef1a0bc0
Re: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
And Dmitry Torokhov writes:
I don't think so. Could you please try the patch below? Thanks!
The appended patch on top of yours fixes the too-early access of
psmouse-private. I don't know the expected lifetime of
psmouse-private, so I chickened out of simply assigning priv
earlier.
BTW, why do you pass psmouse down through the initializations
rather than ps2dev and private?
Jason, using git's index, dammit...
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index 2aeb299..990d2a5 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -384,10 +384,9 @@ static int alps_poll(struct psmouse *psmouse)
return 0;
}
-static int alps_hw_init(struct psmouse *psmouse, int *version)
+static int alps_hw_init(struct psmouse *psmouse, struct alps_data *priv,
+ int *version)
{
- struct alps_data *priv = psmouse-private;
-
priv-i = alps_get_model(psmouse, version);
if (!priv-i)
return -1;
@@ -421,7 +420,7 @@ static int alps_reconnect(struct psmouse *psmouse)
{
psmouse_reset(psmouse);
- if (alps_hw_init(psmouse, NULL))
+ if (alps_hw_init(psmouse, (struct alps_data *)psmouse-private, NULL))
return -1;
return 0;
@@ -449,7 +448,7 @@ int alps_init(struct psmouse *psmouse)
priv-dev2 = dev2;
- if (alps_hw_init(psmouse, version))
+ if (alps_hw_init(psmouse, priv, version))
goto init_fail;
dev1-evbit[LONG(EV_KEY)] |= BIT(EV_KEY);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Mon, May 14, 2007 at 07:38:23PM +0200, Luca Tettamanti wrote:
I'm running git 705962cc (which is a commit after -rc1) and I still see
the OOPS on boot. The patch above is already applied though. Note that
I'm using the SLAB allocator:
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
Ending clean XFS mount for filesystem: dm-4
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
Please send me your .config file.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
On Saturday 12 May 2007 23:58, Jason Riedy wrote:
> And Dmitry Torokhov writes:
> > Have you tried any other -mm? Also, does it help if you stick
> > ps2_command(>ps2dev, NULL, PSMOUSE_CMD_SETSTREAM);
> > at the very beginning of psmouse_initialize() in
> > drivers/input/mouse/psmouse-base.c?
>
> Seems to fix it for me on a D620.
>
Ok, thanks.
> Bisecting on mainline gave commit
> f42649e84831efc69d5f621f1c36a39b4e384a99 (Input: ALPS - handle
> errors from input_register_device()) as the place where the
> trackpoint half stopped working. I don't necessarily believe it,
> unless the psmouse_reset on failure caused problems without
> logging anything.
>
I don't think so. Could you please try the patch below? Thanks!
--
Dmitry
Input: ALPS - force stream mode
ALPS appears to need SETSTREAM command after reset, otherwise it
does not produce any data. Now that we do not request stream mode
by default individual drivers need to take care of it.
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
---
drivers/input/mouse/alps.c | 55 +++--
1 files changed, 29 insertions(+), 26 deletions(-)
Index: work/drivers/input/mouse/alps.c
===
--- work.orig/drivers/input/mouse/alps.c
+++ work/drivers/input/mouse/alps.c
@@ -251,11 +251,15 @@ static const struct alps_model_info *alp
dbg("E7 report: %2.2x %2.2x %2.2x", param[0], param[1], param[2]);
- for (i = 0; i < ARRAY_SIZE(rates) && param[2] != rates[i]; i++);
- *version = (param[0] << 8) | (param[1] << 4) | i;
+ if (version) {
+ for (i = 0; i < ARRAY_SIZE(rates) && param[2] != rates[i]; i++)
+ /* empty */;
+ *version = (param[0] << 8) | (param[1] << 4) | i;
+ }
for (i = 0; i < ARRAY_SIZE(alps_model_data); i++)
- if (!memcmp(param, alps_model_data[i].signature,
sizeof(alps_model_data[i].signature)))
+ if (!memcmp(param, alps_model_data[i].signature,
+ sizeof(alps_model_data[i].signature)))
return alps_model_data + i;
return NULL;
@@ -380,32 +384,46 @@ static int alps_poll(struct psmouse *psm
return 0;
}
-static int alps_reconnect(struct psmouse *psmouse)
+static int alps_hw_init(struct psmouse *psmouse, int *version)
{
struct alps_data *priv = psmouse->private;
- int version;
-
- psmouse_reset(psmouse);
- if (!(priv->i = alps_get_model(psmouse, )))
+ priv->i = alps_get_model(psmouse, version);
+ if (!priv->i)
return -1;
if ((priv->i->flags & ALPS_PASS) && alps_passthrough_mode(psmouse, 1))
return -1;
if (alps_tap_mode(psmouse, 1)) {
- printk(KERN_WARNING "alps.c: Failed to reenable hardware
tapping\n");
+ printk(KERN_WARNING "alps.c: Failed to enable hardware
tapping\n");
return -1;
}
if (alps_absolute_mode(psmouse)) {
- printk(KERN_ERR "alps.c: Failed to reenable absolute mode\n");
+ printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
return -1;
}
if ((priv->i->flags & ALPS_PASS) && alps_passthrough_mode(psmouse, 0))
return -1;
+ /* ALPS needs stream mode, otherwise it won't report any data */
+ if (ps2_command(>ps2dev, NULL, PSMOUSE_CMD_SETSTREAM)) {
+ printk(KERN_ERR "alps.c: Failed to enable stream mode\n");
+ return -1;
+ }
+
+ return 0;
+}
+
+static int alps_reconnect(struct psmouse *psmouse)
+{
+ psmouse_reset(psmouse);
+
+ if (alps_hw_init(psmouse, NULL))
+ return -1;
+
return 0;
}
@@ -431,22 +449,7 @@ int alps_init(struct psmouse *psmouse)
priv->dev2 = dev2;
- priv->i = alps_get_model(psmouse, );
- if (!priv->i)
- goto init_fail;
-
- if ((priv->i->flags & ALPS_PASS) && alps_passthrough_mode(psmouse, 1))
- goto init_fail;
-
- if (alps_tap_mode(psmouse, 1))
- printk(KERN_WARNING "alps.c: Failed to enable hardware
tapping\n");
-
- if (alps_absolute_mode(psmouse)) {
- printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
- goto init_fail;
- }
-
- if ((priv->i->flags & ALPS_PASS) && alps_passthrough_mode(psmouse, 0))
+ if (alps_hw_init(psmouse, ))
goto init_fail;
dev1->evbit[LONG(EV_KEY)] |= BIT(EV_KEY);
-
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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
On Saturday 12 May 2007 23:58, Jason Riedy wrote:
And Dmitry Torokhov writes:
Have you tried any other -mm? Also, does it help if you stick
ps2_command(psmouse-ps2dev, NULL, PSMOUSE_CMD_SETSTREAM);
at the very beginning of psmouse_initialize() in
drivers/input/mouse/psmouse-base.c?
Seems to fix it for me on a D620.
Ok, thanks.
Bisecting on mainline gave commit
f42649e84831efc69d5f621f1c36a39b4e384a99 (Input: ALPS - handle
errors from input_register_device()) as the place where the
trackpoint half stopped working. I don't necessarily believe it,
unless the psmouse_reset on failure caused problems without
logging anything.
I don't think so. Could you please try the patch below? Thanks!
--
Dmitry
Input: ALPS - force stream mode
ALPS appears to need SETSTREAM command after reset, otherwise it
does not produce any data. Now that we do not request stream mode
by default individual drivers need to take care of it.
Signed-off-by: Dmitry Torokhov [EMAIL PROTECTED]
---
drivers/input/mouse/alps.c | 55 +++--
1 files changed, 29 insertions(+), 26 deletions(-)
Index: work/drivers/input/mouse/alps.c
===
--- work.orig/drivers/input/mouse/alps.c
+++ work/drivers/input/mouse/alps.c
@@ -251,11 +251,15 @@ static const struct alps_model_info *alp
dbg(E7 report: %2.2x %2.2x %2.2x, param[0], param[1], param[2]);
- for (i = 0; i ARRAY_SIZE(rates) param[2] != rates[i]; i++);
- *version = (param[0] 8) | (param[1] 4) | i;
+ if (version) {
+ for (i = 0; i ARRAY_SIZE(rates) param[2] != rates[i]; i++)
+ /* empty */;
+ *version = (param[0] 8) | (param[1] 4) | i;
+ }
for (i = 0; i ARRAY_SIZE(alps_model_data); i++)
- if (!memcmp(param, alps_model_data[i].signature,
sizeof(alps_model_data[i].signature)))
+ if (!memcmp(param, alps_model_data[i].signature,
+ sizeof(alps_model_data[i].signature)))
return alps_model_data + i;
return NULL;
@@ -380,32 +384,46 @@ static int alps_poll(struct psmouse *psm
return 0;
}
-static int alps_reconnect(struct psmouse *psmouse)
+static int alps_hw_init(struct psmouse *psmouse, int *version)
{
struct alps_data *priv = psmouse-private;
- int version;
-
- psmouse_reset(psmouse);
- if (!(priv-i = alps_get_model(psmouse, version)))
+ priv-i = alps_get_model(psmouse, version);
+ if (!priv-i)
return -1;
if ((priv-i-flags ALPS_PASS) alps_passthrough_mode(psmouse, 1))
return -1;
if (alps_tap_mode(psmouse, 1)) {
- printk(KERN_WARNING alps.c: Failed to reenable hardware
tapping\n);
+ printk(KERN_WARNING alps.c: Failed to enable hardware
tapping\n);
return -1;
}
if (alps_absolute_mode(psmouse)) {
- printk(KERN_ERR alps.c: Failed to reenable absolute mode\n);
+ printk(KERN_ERR alps.c: Failed to enable absolute mode\n);
return -1;
}
if ((priv-i-flags ALPS_PASS) alps_passthrough_mode(psmouse, 0))
return -1;
+ /* ALPS needs stream mode, otherwise it won't report any data */
+ if (ps2_command(psmouse-ps2dev, NULL, PSMOUSE_CMD_SETSTREAM)) {
+ printk(KERN_ERR alps.c: Failed to enable stream mode\n);
+ return -1;
+ }
+
+ return 0;
+}
+
+static int alps_reconnect(struct psmouse *psmouse)
+{
+ psmouse_reset(psmouse);
+
+ if (alps_hw_init(psmouse, NULL))
+ return -1;
+
return 0;
}
@@ -431,22 +449,7 @@ int alps_init(struct psmouse *psmouse)
priv-dev2 = dev2;
- priv-i = alps_get_model(psmouse, version);
- if (!priv-i)
- goto init_fail;
-
- if ((priv-i-flags ALPS_PASS) alps_passthrough_mode(psmouse, 1))
- goto init_fail;
-
- if (alps_tap_mode(psmouse, 1))
- printk(KERN_WARNING alps.c: Failed to enable hardware
tapping\n);
-
- if (alps_absolute_mode(psmouse)) {
- printk(KERN_ERR alps.c: Failed to enable absolute mode\n);
- goto init_fail;
- }
-
- if ((priv-i-flags ALPS_PASS) alps_passthrough_mode(psmouse, 0))
+ if (alps_hw_init(psmouse, version))
goto init_fail;
dev1-evbit[LONG(EV_KEY)] |= BIT(EV_KEY);
-
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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
And Dmitry Torokhov writes: > Have you tried any other -mm? Also, does it help if you stick > ps2_command(>ps2dev, NULL, PSMOUSE_CMD_SETSTREAM); > at the very beginning of psmouse_initialize() in > drivers/input/mouse/psmouse-base.c? Seems to fix it for me on a D620. Bisecting on mainline gave commit f42649e84831efc69d5f621f1c36a39b4e384a99 (Input: ALPS - handle errors from input_register_device()) as the place where the trackpoint half stopped working. I don't necessarily believe it, unless the psmouse_reset on failure caused problems without logging anything. Jason - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
And Dmitry Torokhov writes: Have you tried any other -mm? Also, does it help if you stick ps2_command(psmouse-ps2dev, NULL, PSMOUSE_CMD_SETSTREAM); at the very beginning of psmouse_initialize() in drivers/input/mouse/psmouse-base.c? Seems to fix it for me on a D620. Bisecting on mainline gave commit f42649e84831efc69d5f621f1c36a39b4e384a99 (Input: ALPS - handle errors from input_register_device()) as the place where the trackpoint half stopped working. I don't necessarily believe it, unless the psmouse_reset on failure caused problems without logging anything. Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- Hibernation locked up and didn't power down (had to hold power button down for five seconds)
Hi! > This is probably more log info than you need, but I am > including it in > case it helps. It is long, but useless, because it misses the critical parts. > [ 5487.322599] agpgart-intel :00:00.0: LATE freeze > [ 5487.322711] swsusp: critical section: > [ 5487.365827] swsusp: Need to copy 122651 pages > [ 5487.365831] swsusp: Normal pages needed: 114026 + > 1024 + 24, > available pages: 122386 (messages concerning powerdown missing, because they are not in usual buffers. Capture them somehow. Serial console/digicam/paper and pencil. > At this point, I had to hard power down. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
Selon Dmitry Torokhov <[EMAIL PROTECTED]>: > Hi Remi, > > On Thursday 10 May 2007 21:50, Andrew Morton wrote: > > On Thu, 10 May 2007 15:05:25 +0200 > > Remi Colinet <[EMAIL PROTECTED]> wrote: > > > > > My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. > > > No problem noticed with 2.6.21. > > > > > > The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of > 2.6.21 > > > and then removed git-input patch. It is ok since then. > > Have you tried any other -mm? Also, does it help if you stick > Tried 2.6.21-mm3. The GlidePoint is still unresponsive. > ps2_command(>ps2dev, NULL, PSMOUSE_CMD_SETSTREAM); > > at the very beginning of psmouse_initialize() in > drivers/input/mouse/psmouse-base.c? > Going to try it ... In fact, I already added the following line at the begining of each function in drivers/input/mouse/alps.c printk(KERN_ERR "start of function ...\n"); But no message is displayed when using the Glide Point. Interrupt are not raised. The alps driver is not called by the i8042 handler. Remi Colinet > -- > Dmitry > - > 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/ > - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
Selon Andrew Morton <[EMAIL PROTECTED]>: > On Thu, 10 May 2007 15:05:25 +0200 > Remi Colinet <[EMAIL PROTECTED]> wrote: > > > My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. > > No problem noticed with 2.6.21. > > > > The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of > 2.6.21 > > and then removed git-input patch. It is ok since then. > > > > >From what i can see, no interrupt is raised from the GlidePoint with > git-input > > applied. IRQ count 12 does not increase. It is when using the touchpad. > > > >CPU0 > > 0:160 IO-APIC-edge timer > > 1:935 IO-APIC-edge i8042 > > 7: 0 IO-APIC-edge parport0 > > 8: 1 IO-APIC-edge rtc > > 9: 2 IO-APIC-fasteoi acpi > > => 12:114 IO-APIC-edge i8042 <= > > 14: 3223 IO-APIC-edge libata > > 15: 5 IO-APIC-edge libata > > 16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel > ICH6 > > 17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6 > Modem > > 18: 0 IO-APIC-fasteoi uhci_hcd:usb3 > > 19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta > > NMI: 0 > > LOC: 4051 > > ERR: 0 > > MIS: 0 > > > > I have also tried to disable the ALPS driver in the .config file. IRQ 12 > are > > then raised when using the Glide Point. X refuses to start. > > > > Are you able to test 2.6.21-mm2? > > I have tried with the lastest mm broken-out snapshot, i.e 2.6.21-mm3. The GlidePoint is still unresponsive. 2.6.21-git13 works fine with the GlidePoint. So I'am bisecting 2.6.21-mm3. It works just with the origin.patch applied. Thanks, Remi Colinet - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
Selon Dmitry Torokhov [EMAIL PROTECTED]: Hi Remi, On Thursday 10 May 2007 21:50, Andrew Morton wrote: On Thu, 10 May 2007 15:05:25 +0200 Remi Colinet [EMAIL PROTECTED] wrote: My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. No problem noticed with 2.6.21. The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21 and then removed git-input patch. It is ok since then. Have you tried any other -mm? Also, does it help if you stick Tried 2.6.21-mm3. The GlidePoint is still unresponsive. ps2_command(psmouse-ps2dev, NULL, PSMOUSE_CMD_SETSTREAM); at the very beginning of psmouse_initialize() in drivers/input/mouse/psmouse-base.c? Going to try it ... In fact, I already added the following line at the begining of each function in drivers/input/mouse/alps.c printk(KERN_ERR start of function ...\n); But no message is displayed when using the Glide Point. Interrupt are not raised. The alps driver is not called by the i8042 handler. Remi Colinet -- Dmitry - 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/ - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
Selon Andrew Morton [EMAIL PROTECTED]: On Thu, 10 May 2007 15:05:25 +0200 Remi Colinet [EMAIL PROTECTED] wrote: My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. No problem noticed with 2.6.21. The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21 and then removed git-input patch. It is ok since then. From what i can see, no interrupt is raised from the GlidePoint with git-input applied. IRQ count 12 does not increase. It is when using the touchpad. CPU0 0:160 IO-APIC-edge timer 1:935 IO-APIC-edge i8042 7: 0 IO-APIC-edge parport0 8: 1 IO-APIC-edge rtc 9: 2 IO-APIC-fasteoi acpi = 12:114 IO-APIC-edge i8042 = 14: 3223 IO-APIC-edge libata 15: 5 IO-APIC-edge libata 16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel ICH6 17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6 Modem 18: 0 IO-APIC-fasteoi uhci_hcd:usb3 19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta NMI: 0 LOC: 4051 ERR: 0 MIS: 0 I have also tried to disable the ALPS driver in the .config file. IRQ 12 are then raised when using the Glide Point. X refuses to start. Are you able to test 2.6.21-mm2? I have tried with the lastest mm broken-out snapshot, i.e 2.6.21-mm3. The GlidePoint is still unresponsive. 2.6.21-git13 works fine with the GlidePoint. So I'am bisecting 2.6.21-mm3. It works just with the origin.patch applied. Thanks, Remi Colinet - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- Hibernation locked up and didn't power down (had to hold power button down for five seconds)
Hi! This is probably more log info than you need, but I am including it in case it helps. It is long, but useless, because it misses the critical parts. [ 5487.322599] agpgart-intel :00:00.0: LATE freeze [ 5487.322711] swsusp: critical section: [ 5487.365827] swsusp: Need to copy 122651 pages [ 5487.365831] swsusp: Normal pages needed: 114026 + 1024 + 24, available pages: 122386 (messages concerning powerdown missing, because they are not in usual buffers. Capture them somehow. Serial console/digicam/paper and pencil. At this point, I had to hard power down. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
Hi Remi, On Thursday 10 May 2007 21:50, Andrew Morton wrote: > On Thu, 10 May 2007 15:05:25 +0200 > Remi Colinet <[EMAIL PROTECTED]> wrote: > > > My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. > > No problem noticed with 2.6.21. > > > > The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of > > 2.6.21 > > and then removed git-input patch. It is ok since then. Have you tried any other -mm? Also, does it help if you stick ps2_command(>ps2dev, NULL, PSMOUSE_CMD_SETSTREAM); at the very beginning of psmouse_initialize() in drivers/input/mouse/psmouse-base.c? -- Dmitry - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
On Thu, 10 May 2007 15:05:25 +0200 Remi Colinet <[EMAIL PROTECTED]> wrote: > My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. > No problem noticed with 2.6.21. > > The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21 > and then removed git-input patch. It is ok since then. > > >From what i can see, no interrupt is raised from the GlidePoint with > >git-input > applied. IRQ count 12 does not increase. It is when using the touchpad. > >CPU0 > 0:160 IO-APIC-edge timer > 1:935 IO-APIC-edge i8042 > 7: 0 IO-APIC-edge parport0 > 8: 1 IO-APIC-edge rtc > 9: 2 IO-APIC-fasteoi acpi > => 12:114 IO-APIC-edge i8042 <= > 14: 3223 IO-APIC-edge libata > 15: 5 IO-APIC-edge libata > 16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel ICH6 > 17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6 Modem > 18: 0 IO-APIC-fasteoi uhci_hcd:usb3 > 19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta > NMI: 0 > LOC: 4051 > ERR: 0 > MIS: 0 > > I have also tried to disable the ALPS driver in the .config file. IRQ 12 are > then raised when using the Glide Point. X refuses to start. > Are you able to test 2.6.21-mm2? Thanks. - 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/
Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
Hello, My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. No problem noticed with 2.6.21. The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21 and then removed git-input patch. It is ok since then. >From what i can see, no interrupt is raised from the GlidePoint with git-input applied. IRQ count 12 does not increase. It is when using the touchpad. CPU0 0:160 IO-APIC-edge timer 1:935 IO-APIC-edge i8042 7: 0 IO-APIC-edge parport0 8: 1 IO-APIC-edge rtc 9: 2 IO-APIC-fasteoi acpi => 12:114 IO-APIC-edge i8042 <= 14: 3223 IO-APIC-edge libata 15: 5 IO-APIC-edge libata 16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel ICH6 17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6 Modem 18: 0 IO-APIC-fasteoi uhci_hcd:usb3 19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta NMI: 0 LOC: 4051 ERR: 0 MIS: 0 I have also tried to disable the ALPS driver in the .config file. IRQ 12 are then raised when using the Glide Point. X refuses to start. Any idea? Remi Colinet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On 5/9/07, Herbert Xu <[EMAIL PROTECTED]> wrote:
On Tue, May 08, 2007 at 09:58:09PM -0300, Kevin Winchester wrote:
>
> Not having any idea what I'm doing, I looked at cryptomgr_probe and
> cryptomgr_notify, and can't seem to see much, except for the following
> odd lines.
>
> From cryptomgr_schedule_probe, which is almost certainly inlined into
> crypto_notify:
Thanks for reporting this. This patch should fix the problem.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff -puN crypto/cryptomgr.c~crypto-fix crypto/cryptomgr.c
--- a/crypto/cryptomgr.c~crypto-fix
+++ a/crypto/cryptomgr.c
@@ -24,8 +24,6 @@
#include "internal.h"
struct cryptomgr_param {
- struct task_struct *thread;
-
struct rtattr *tb[CRYPTOA_MAX];
struct {
@@ -81,6 +79,7 @@ err:
static int cryptomgr_schedule_probe(struct crypto_larval *larval)
{
+ struct task_struct *thread;
struct cryptomgr_param *param;
const char *name = larval->alg.cra_name;
const char *p;
@@ -130,8 +129,8 @@ static int cryptomgr_schedule_probe(stru
memcpy(param->larval.name, larval->alg.cra_name, CRYPTO_MAX_ALG_NAME);
- param->thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
- if (IS_ERR(param->thread))
+ thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
+ if (IS_ERR(thread))
goto err_free_param;
return NOTIFY_STOP;
_
I see that this patch made it in to mainline, and latest -git now
works for me, so I assume this was the correct solution. I thought I
had tried this exact change without success when I was looking at the
problem, but I guess I did something wrong along the way.
Thanks for the fix,
Kevin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- x86 verify_cpu.S compile failure
Andy Whitcroft wrote: > Andi Kleen wrote: >> On Tue, May 08, 2007 at 10:46:20AM +0100, Andy Whitcroft wrote: >>> We are seeing the following compile error on older x86 installs: >>> >>> arch/i386/kernel/verify_cpu.S: Assembler messages: >>> arch/i386/kernel/verify_cpu.S:13: Error: `(%esp)' is >>> not a valid 16 bit base/index expression >>> >>> Seems to come from: >>> >>> x86_64-mm-i386-verify-cpu >>> >>> Compiler: >>> >>> gcc version 3.3.4 (Debian 1:3.3.4-3) >> Your compiler must be a brother in spirit of Andrew's vaio. >> >> Does this patch help? >> >> -Andi >> >> >> Index: linux/arch/i386/kernel/verify_cpu.S >> === >> --- linux.orig/arch/i386/kernel/verify_cpu.S >> +++ linux/arch/i386/kernel/verify_cpu.S >> @@ -10,7 +10,9 @@ verify_cpu: >> >> #if CONFIG_X86_MINIMUM_CPU_MODEL >= 4 >> pushfl >> -orl $(1<<18),(%esp) # try setting AC >> +pop %eax >> +orl $(1<<18),%eax # try setting AC >> +push%eax >> popfl >> pushfl >> popl%eax >> >> > > Yep that gets us past the compile problems. Of course she then blows up > cause SLUB does not work on x86 in that version ... but ... > > Acked-by: Andy Whitcroft <[EMAIL PROTECTED]> I note that this problem is also up in mainline, since 2.6.21-git6. Andi can you push this fix up too? -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- x86 verify_cpu.S compile failure
Andy Whitcroft wrote: Andi Kleen wrote: On Tue, May 08, 2007 at 10:46:20AM +0100, Andy Whitcroft wrote: We are seeing the following compile error on older x86 installs: arch/i386/kernel/verify_cpu.S: Assembler messages: arch/i386/kernel/verify_cpu.S:13: Error: `(%esp)' is not a valid 16 bit base/index expression Seems to come from: x86_64-mm-i386-verify-cpu Compiler: gcc version 3.3.4 (Debian 1:3.3.4-3) Your compiler must be a brother in spirit of Andrew's vaio. Does this patch help? -Andi Index: linux/arch/i386/kernel/verify_cpu.S === --- linux.orig/arch/i386/kernel/verify_cpu.S +++ linux/arch/i386/kernel/verify_cpu.S @@ -10,7 +10,9 @@ verify_cpu: #if CONFIG_X86_MINIMUM_CPU_MODEL = 4 pushfl -orl $(118),(%esp) # try setting AC +pop %eax +orl $(118),%eax # try setting AC +push%eax popfl pushfl popl%eax Yep that gets us past the compile problems. Of course she then blows up cause SLUB does not work on x86 in that version ... but ... Acked-by: Andy Whitcroft [EMAIL PROTECTED] I note that this problem is also up in mainline, since 2.6.21-git6. Andi can you push this fix up too? -apw - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On 5/9/07, Herbert Xu [EMAIL PROTECTED] wrote:
On Tue, May 08, 2007 at 09:58:09PM -0300, Kevin Winchester wrote:
Not having any idea what I'm doing, I looked at cryptomgr_probe and
cryptomgr_notify, and can't seem to see much, except for the following
odd lines.
From cryptomgr_schedule_probe, which is almost certainly inlined into
crypto_notify:
Thanks for reporting this. This patch should fix the problem.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff -puN crypto/cryptomgr.c~crypto-fix crypto/cryptomgr.c
--- a/crypto/cryptomgr.c~crypto-fix
+++ a/crypto/cryptomgr.c
@@ -24,8 +24,6 @@
#include internal.h
struct cryptomgr_param {
- struct task_struct *thread;
-
struct rtattr *tb[CRYPTOA_MAX];
struct {
@@ -81,6 +79,7 @@ err:
static int cryptomgr_schedule_probe(struct crypto_larval *larval)
{
+ struct task_struct *thread;
struct cryptomgr_param *param;
const char *name = larval-alg.cra_name;
const char *p;
@@ -130,8 +129,8 @@ static int cryptomgr_schedule_probe(stru
memcpy(param-larval.name, larval-alg.cra_name, CRYPTO_MAX_ALG_NAME);
- param-thread = kthread_run(cryptomgr_probe, param, cryptomgr);
- if (IS_ERR(param-thread))
+ thread = kthread_run(cryptomgr_probe, param, cryptomgr);
+ if (IS_ERR(thread))
goto err_free_param;
return NOTIFY_STOP;
_
I see that this patch made it in to mainline, and latest -git now
works for me, so I assume this was the correct solution. I thought I
had tried this exact change without success when I was looking at the
problem, but I guess I did something wrong along the way.
Thanks for the fix,
Kevin
-
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/
Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
Hello, My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. No problem noticed with 2.6.21. The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21 and then removed git-input patch. It is ok since then. From what i can see, no interrupt is raised from the GlidePoint with git-input applied. IRQ count 12 does not increase. It is when using the touchpad. CPU0 0:160 IO-APIC-edge timer 1:935 IO-APIC-edge i8042 7: 0 IO-APIC-edge parport0 8: 1 IO-APIC-edge rtc 9: 2 IO-APIC-fasteoi acpi = 12:114 IO-APIC-edge i8042 = 14: 3223 IO-APIC-edge libata 15: 5 IO-APIC-edge libata 16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel ICH6 17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6 Modem 18: 0 IO-APIC-fasteoi uhci_hcd:usb3 19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta NMI: 0 LOC: 4051 ERR: 0 MIS: 0 I have also tried to disable the ALPS driver in the .config file. IRQ 12 are then raised when using the Glide Point. X refuses to start. Any idea? Remi Colinet - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
On Thu, 10 May 2007 15:05:25 +0200 Remi Colinet [EMAIL PROTECTED] wrote: My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. No problem noticed with 2.6.21. The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21 and then removed git-input patch. It is ok since then. From what i can see, no interrupt is raised from the GlidePoint with git-input applied. IRQ count 12 does not increase. It is when using the touchpad. CPU0 0:160 IO-APIC-edge timer 1:935 IO-APIC-edge i8042 7: 0 IO-APIC-edge parport0 8: 1 IO-APIC-edge rtc 9: 2 IO-APIC-fasteoi acpi = 12:114 IO-APIC-edge i8042 = 14: 3223 IO-APIC-edge libata 15: 5 IO-APIC-edge libata 16: 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5, Intel ICH6 17: 1 IO-APIC-fasteoi uhci_hcd:usb2, ipw2200, Intel ICH6 Modem 18: 0 IO-APIC-fasteoi uhci_hcd:usb3 19: 1 IO-APIC-fasteoi uhci_hcd:usb4, yenta NMI: 0 LOC: 4051 ERR: 0 MIS: 0 I have also tried to disable the ALPS driver in the .config file. IRQ 12 are then raised when using the Glide Point. X refuses to start. Are you able to test 2.6.21-mm2? Thanks. - 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: Regression in 2.6.21-mm1 (git-input) on Dell D610 laptop
Hi Remi, On Thursday 10 May 2007 21:50, Andrew Morton wrote: On Thu, 10 May 2007 15:05:25 +0200 Remi Colinet [EMAIL PROTECTED] wrote: My D610 ALPS Glide Point is unresponsive with 2.6.21-mm1 patch. No problem noticed with 2.6.21. The culprit seems to be git-input. I have applied 2.6.21-mm1 on top of 2.6.21 and then removed git-input patch. It is ok since then. Have you tried any other -mm? Also, does it help if you stick ps2_command(psmouse-ps2dev, NULL, PSMOUSE_CMD_SETSTREAM); at the very beginning of psmouse_initialize() in drivers/input/mouse/psmouse-base.c? -- Dmitry - 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: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Wed, May 09, 2007 at 02:26:08PM +0200, Frederik Deweerdt wrote: > On Wed, May 09, 2007 at 11:00:46AM +0200, Andi Kleen wrote: > > On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote: > > > >I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the > > > > > > > >+ if (!pte_present(*kpte)) > > > >+ return 0; > > > > > > I the most recent version of the patch I sent to Andi this line is gone > > > (again), > > > as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its > > > respective variant was superfluous on x86-64. > > > > Yes the version of the patch that went into Linus' tree doesn't have it. > > Does the problem happen with mainline gitLATEST too? > Andi, > > Latest git is OK with qemu, I'll test it on a real machine tonight. It boots fine on a real PC too. Thanks! Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- x86 verify_cpu.S compile failure
Andi Kleen wrote: > On Tue, May 08, 2007 at 10:46:20AM +0100, Andy Whitcroft wrote: >> We are seeing the following compile error on older x86 installs: >> >> arch/i386/kernel/verify_cpu.S: Assembler messages: >> arch/i386/kernel/verify_cpu.S:13: Error: `(%esp)' is >> not a valid 16 bit base/index expression >> >> Seems to come from: >> >> x86_64-mm-i386-verify-cpu >> >> Compiler: >> >> gcc version 3.3.4 (Debian 1:3.3.4-3) > > Your compiler must be a brother in spirit of Andrew's vaio. > > Does this patch help? > > -Andi > > > Index: linux/arch/i386/kernel/verify_cpu.S > === > --- linux.orig/arch/i386/kernel/verify_cpu.S > +++ linux/arch/i386/kernel/verify_cpu.S > @@ -10,7 +10,9 @@ verify_cpu: > > #if CONFIG_X86_MINIMUM_CPU_MODEL >= 4 > pushfl > - orl $(1<<18),(%esp) # try setting AC > + pop %eax > + orl $(1<<18),%eax # try setting AC > + push%eax > popfl > pushfl > popl%eax > > Yep that gets us past the compile problems. Of course she then blows up cause SLUB does not work on x86 in that version ... but ... Acked-by: Andy Whitcroft <[EMAIL PROTECTED]> -apw - 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: kernel expection generated with 2.6.21-mm1 kernel boot up
On Wed, 9 May 2007, Srinivasa Ds wrote:
> Christoph Lameter wrote:
> > On Tue, 8 May 2007, Srinivasa Ds wrote:
> >
> >> Looks like there is a bug in SLUB implementaion for ppc64 in 2.6.21-mm1.
> >> I unmarked CONFIG_SLUB and build the kernel, its booting cleary now.
> >
> > This is a known issue for PPC with more than 4 processors. Work is in
> > progress for a general fix.
>
> That would be good. Incase if you have fix, please let us know so that
> we can test it on ppc64.
Here's Ben's & my patch, on its way from PowerPC git to Linus' git.
If you're an oldconfig user, you'll probably find you need to delete
your CONFIG_SLAB=y to get Kconfig to offer you the choice of SLUB now.
powerpc: Don't use SLAB/SLUB for PTE pages
From: Hugh Dickins <[EMAIL PROTECTED]>
The SLUB allocator relies on struct page fields first_page and slab,
overwritten by ptl when SPLIT_PTLOCK: so the SLUB allocator cannot then
be used for the lowest level of pagetable pages. This was obstructing
SLUB on PowerPC, which uses kmem_caches for its pagetables. So convert
its pte level to use normal gfp pages (whereas pmd, pud and 64k-page pgd
want partpages, so continue to use kmem_caches for pmd, pud and pgd).
Signed-off-by: Hugh Dickins <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
This version uses __GFP_ZERO instead of clear_page() and re-enables
SLUB on powerpc.
Index: linux-cell/arch/powerpc/mm/init_64.c
===
--- linux-cell.orig/arch/powerpc/mm/init_64.c 2007-05-08 16:47:48.0
+1000
+++ linux-cell/arch/powerpc/mm/init_64.c2007-05-09 12:15:22.0
+1000
@@ -146,21 +146,16 @@ static void zero_ctor(void *addr, struct
memset(addr, 0, kmem_cache_size(cache));
}
-#ifdef CONFIG_PPC_64K_PAGES
-static const unsigned int pgtable_cache_size[3] = {
- PTE_TABLE_SIZE, PMD_TABLE_SIZE, PGD_TABLE_SIZE
-};
-static const char *pgtable_cache_name[ARRAY_SIZE(pgtable_cache_size)] = {
- "pte_pmd_cache", "pmd_cache", "pgd_cache",
-};
-#else
static const unsigned int pgtable_cache_size[2] = {
- PTE_TABLE_SIZE, PMD_TABLE_SIZE
+ PGD_TABLE_SIZE, PMD_TABLE_SIZE
};
static const char *pgtable_cache_name[ARRAY_SIZE(pgtable_cache_size)] = {
- "pgd_pte_cache", "pud_pmd_cache",
-};
+#ifdef CONFIG_PPC_64K_PAGES
+ "pgd_cache", "pmd_cache",
+#else
+ "pgd_cache", "pud_pmd_cache",
#endif /* CONFIG_PPC_64K_PAGES */
+};
#ifdef CONFIG_HUGETLB_PAGE
/* Hugepages need one extra cache, initialized in hugetlbpage.c. We
Index: linux-cell/include/asm-powerpc/pgalloc.h
===
--- linux-cell.orig/include/asm-powerpc/pgalloc.h 2007-05-08
16:47:48.0 +1000
+++ linux-cell/include/asm-powerpc/pgalloc.h2007-05-09 12:17:11.0
+1000
@@ -13,18 +13,11 @@
extern struct kmem_cache *pgtable_cache[];
-#ifdef CONFIG_PPC_64K_PAGES
-#define PTE_CACHE_NUM 0
-#define PMD_CACHE_NUM 1
-#define PGD_CACHE_NUM 2
-#define HUGEPTE_CACHE_NUM 3
-#else
-#define PTE_CACHE_NUM 0
-#define PMD_CACHE_NUM 1
-#define PUD_CACHE_NUM 1
-#define PGD_CACHE_NUM 0
-#define HUGEPTE_CACHE_NUM 2
-#endif
+#define PGD_CACHE_NUM 0
+#define PUD_CACHE_NUM 1
+#define PMD_CACHE_NUM 1
+#define HUGEPTE_CACHE_NUM 2
+#define PTE_NONCACHE_NUM 3 /* from GFP rather than kmem_cache */
/*
* This program is free software; you can redistribute it and/or
@@ -97,8 +90,7 @@ static inline void pmd_free(pmd_t *pmd)
static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
unsigned long address)
{
- return kmem_cache_alloc(pgtable_cache[PTE_CACHE_NUM],
- GFP_KERNEL|__GFP_REPEAT);
+return (pte_t *)__get_free_page(GFP_KERNEL | __GFP_REPEAT |
__GFP_ZERO);
}
static inline struct page *pte_alloc_one(struct mm_struct *mm,
@@ -109,12 +101,12 @@ static inline struct page *pte_alloc_one
static inline void pte_free_kernel(pte_t *pte)
{
- kmem_cache_free(pgtable_cache[PTE_CACHE_NUM], pte);
+ free_page((unsigned long)pte);
}
static inline void pte_free(struct page *ptepage)
{
- pte_free_kernel(page_address(ptepage));
+ __free_page(ptepage);
}
#define PGF_CACHENUM_MASK 0x3
@@ -136,14 +128,17 @@ static inline void pgtable_free(pgtable_
void *p = (void *)(pgf.val & ~PGF_CACHENUM_MASK);
int cachenum = pgf.val & PGF_CACHENUM_MASK;
- kmem_cache_free(pgtable_cache[cachenum], p);
+ if (cachenum == PTE_NONCACHE_NUM)
+ free_page((unsigned long)p);
+ else
+ kmem_cache_free(pgtable_cache[cachenum], p);
}
extern void pgtable_free_tlb(struct mmu_g
Re: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Wed, May 09, 2007 at 11:00:46AM +0200, Andi Kleen wrote: > On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote: > > >I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the > > > > > >+ if (!pte_present(*kpte)) > > >+ return 0; > > > > I the most recent version of the patch I sent to Andi this line is gone > > (again), > > as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its > > respective variant was superfluous on x86-64. > > Yes the version of the patch that went into Linus' tree doesn't have it. > Does the problem happen with mainline gitLATEST too? Andi, Latest git is OK with qemu, I'll test it on a real machine tonight. Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1+hotfix -- Slab corruption -- Last user: [](cryptomgr_probe+0x6c/0x9a)
On 5/8/07, Herbert Xu <[EMAIL PROTECTED]> wrote: On Mon, May 07, 2007 at 11:57:28AM -0700, Miles Lane wrote: > [ 118.442018] ieee80211_crypt: registered algorithm 'WEP' > [ 118.514572] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready > [ 118.514664] Slab corruption: size-256 start=c6aabe98, len=256 > [ 118.514672] Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. > [ 118.514676] Last user: [](cryptomgr_probe+0x6c/0x9a) > [ 118.514692] 000: 10 55 ac c6 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > [ 118.514715] Prev obj: start=c6aabd80, len=256 > [ 118.514721] Redzone: 0xd84156c5635688c0/0xd84156c5635688c0. > [ 118.514725] Last user: [](crypto_alloc_instance+0x1d/0xc0) > [ 118.514734] 000: e0 71 39 c0 80 6e 39 c0 88 bd aa c6 88 bd aa c6 > [ 118.514753] 010: 04 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00 Oops. Does this patch fix the problem for you? Yes, that fixed it. I found the problem is also showing up in 2.6.21-git10. I tested with 2.6.21-git10. Thanks! Miles - 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: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote: > >I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the > > > >+ if (!pte_present(*kpte)) > >+ return 0; > > I the most recent version of the patch I sent to Andi this line is gone > (again), > as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its > respective variant was superfluous on x86-64. Yes the version of the patch that went into Linus' tree doesn't have it. Does the problem happen with mainline gitLATEST too? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- x86 verify_cpu.S compile failure
Andi Kleen wrote: > On Tue, May 08, 2007 at 10:46:20AM +0100, Andy Whitcroft wrote: >> We are seeing the following compile error on older x86 installs: >> >> arch/i386/kernel/verify_cpu.S: Assembler messages: >> arch/i386/kernel/verify_cpu.S:13: Error: `(%esp)' is >> not a valid 16 bit base/index expression >> >> Seems to come from: >> >> x86_64-mm-i386-verify-cpu >> >> Compiler: >> >> gcc version 3.3.4 (Debian 1:3.3.4-3) > > Your compiler must be a brother in spirit of Andrew's vaio. > > Does this patch help? Heh, it often feels like they are kin. I've submitted some tests and will let you know, but it looks plausable :). -apw - 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: kernel expection generated with 2.6.21-mm1 kernel boot up
Christoph Lameter wrote: > On Tue, 8 May 2007, Srinivasa Ds wrote: > >> Looks like there is a bug in SLUB implementaion for ppc64 in 2.6.21-mm1. >> I unmarked CONFIG_SLUB and build the kernel, its booting cleary now. >> >> Thanks >> Srinivasa DS > > This is a known issue for PPC with more than 4 processors. Work is in > progress for a general fix. That would be good. Incase if you have fix, please let us know so that we can test it on ppc64. > > You should have not been able to select SLUB at all given that you have 4 > processor configured. Hmmm... The Kconfig comparison for more than 4 cpus > does only seem to work in certain cases. > > Could I have a complete .config? Attaching it here. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21.1 # Wed May 9 12:22:16 2007 # CONFIG_PPC64=y CONFIG_64BIT=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # # Processor support # # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=64 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=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=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_EMBEDDED6xx is not set # CONFIG_APUS is not set CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y CONFIG_SCANLOG=y CONFIG_LPARCFG=y # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_CELLEB is not set # CONFIG_PPC_PS3 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_XICS=y CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set CONFIG_PPC_I8259=y CONFIG_U3_DART=y CONFIG_PPC_RTAS=y CONFIG_RTAS_ERROR_LOGGING=y CONFIG_RTAS_PROC=y CONFIG_RTAS_FLASH=y # CONFIG_MMIO_NVRAM is not set CONFIG_MPIC_U3_HT_IRQS=y CONFIG_IBMVIO=y # CONFIG_IBMEBUS is not set # CONFIG_PPC_MPC106 is not set CONFIG_PPC_970_NAP=y # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set # CONFIG_CPM2 is not set # # Kernel options # # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTA
kmem_cache_init failure (was Re: 2.6.21-mm1)
>I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the > >+ if (!pte_present(*kpte)) >+ return 0; I the most recent version of the patch I sent to Andi this line is gone (again), as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its respective variant was superfluous on x86-64. Jan - 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/
kmem_cache_init failure (was Re: 2.6.21-mm1)
I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the + if (!pte_present(*kpte)) + return 0; I the most recent version of the patch I sent to Andi this line is gone (again), as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its respective variant was superfluous on x86-64. Jan - 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: kernel expection generated with 2.6.21-mm1 kernel boot up
Christoph Lameter wrote: On Tue, 8 May 2007, Srinivasa Ds wrote: Looks like there is a bug in SLUB implementaion for ppc64 in 2.6.21-mm1. I unmarked CONFIG_SLUB and build the kernel, its booting cleary now. Thanks Srinivasa DS This is a known issue for PPC with more than 4 processors. Work is in progress for a general fix. That would be good. Incase if you have fix, please let us know so that we can test it on ppc64. You should have not been able to select SLUB at all given that you have 4 processor configured. Hmmm... The Kconfig comparison for more than 4 cpus does only seem to work in certain cases. Could I have a complete .config? Attaching it here. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21.1 # Wed May 9 12:22:16 2007 # CONFIG_PPC64=y CONFIG_64BIT=y CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_HARDIRQS=y CONFIG_IRQ_PER_CPU=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # # Processor support # # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y CONFIG_PPC_FPU=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_ALTIVEC=y CONFIG_PPC_STD_MMU=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=64 CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=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=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Platform support # CONFIG_PPC_MULTIPLATFORM=y # CONFIG_EMBEDDED6xx is not set # CONFIG_APUS is not set CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y CONFIG_SCANLOG=y CONFIG_LPARCFG=y # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_MPC52xx is not set # CONFIG_PPC_MPC5200 is not set CONFIG_PPC_PMAC=y CONFIG_PPC_PMAC64=y # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_CELLEB is not set # CONFIG_PPC_PS3 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_XICS=y CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set CONFIG_PPC_I8259=y CONFIG_U3_DART=y CONFIG_PPC_RTAS=y CONFIG_RTAS_ERROR_LOGGING=y CONFIG_RTAS_PROC=y CONFIG_RTAS_FLASH=y # CONFIG_MMIO_NVRAM is not set CONFIG_MPIC_U3_HT_IRQS=y CONFIG_IBMVIO=y # CONFIG_IBMEBUS is not set # CONFIG_PPC_MPC106 is not set CONFIG_PPC_970_NAP=y # CONFIG_PPC_INDIRECT_IO is not set # CONFIG_GENERIC_IOMAP is not set # CONFIG_CPU_FREQ is not set # CONFIG_CPM2 is not set # # Kernel options # # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_FORCE_MAX_ZONEORDER=13
Re: 2.6.21-mm1 -- x86 verify_cpu.S compile failure
Andi Kleen wrote: On Tue, May 08, 2007 at 10:46:20AM +0100, Andy Whitcroft wrote: We are seeing the following compile error on older x86 installs: arch/i386/kernel/verify_cpu.S: Assembler messages: arch/i386/kernel/verify_cpu.S:13: Error: `(%esp)' is not a valid 16 bit base/index expression Seems to come from: x86_64-mm-i386-verify-cpu Compiler: gcc version 3.3.4 (Debian 1:3.3.4-3) Your compiler must be a brother in spirit of Andrew's vaio. Does this patch help? Heh, it often feels like they are kin. I've submitted some tests and will let you know, but it looks plausable :). -apw - 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: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote: I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the + if (!pte_present(*kpte)) + return 0; I the most recent version of the patch I sent to Andi this line is gone (again), as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its respective variant was superfluous on x86-64. Yes the version of the patch that went into Linus' tree doesn't have it. Does the problem happen with mainline gitLATEST too? -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1+hotfix -- Slab corruption -- Last user: [c01b0cfa](cryptomgr_probe+0x6c/0x9a)
On 5/8/07, Herbert Xu [EMAIL PROTECTED] wrote: On Mon, May 07, 2007 at 11:57:28AM -0700, Miles Lane wrote: [ 118.442018] ieee80211_crypt: registered algorithm 'WEP' [ 118.514572] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready [ 118.514664] Slab corruption: size-256 start=c6aabe98, len=256 [ 118.514672] Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. [ 118.514676] Last user: [c01b0cfa](cryptomgr_probe+0x6c/0x9a) [ 118.514692] 000: 10 55 ac c6 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 118.514715] Prev obj: start=c6aabd80, len=256 [ 118.514721] Redzone: 0xd84156c5635688c0/0xd84156c5635688c0. [ 118.514725] Last user: [c01afd85](crypto_alloc_instance+0x1d/0xc0) [ 118.514734] 000: e0 71 39 c0 80 6e 39 c0 88 bd aa c6 88 bd aa c6 [ 118.514753] 010: 04 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00 Oops. Does this patch fix the problem for you? Yes, that fixed it. I found the problem is also showing up in 2.6.21-git10. I tested with 2.6.21-git10. Thanks! Miles - 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: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Wed, May 09, 2007 at 11:00:46AM +0200, Andi Kleen wrote: On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote: I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the + if (!pte_present(*kpte)) + return 0; I the most recent version of the patch I sent to Andi this line is gone (again), as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its respective variant was superfluous on x86-64. Yes the version of the patch that went into Linus' tree doesn't have it. Does the problem happen with mainline gitLATEST too? Andi, Latest git is OK with qemu, I'll test it on a real machine tonight. Frederik - 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: kernel expection generated with 2.6.21-mm1 kernel boot up
On Wed, 9 May 2007, Srinivasa Ds wrote:
Christoph Lameter wrote:
On Tue, 8 May 2007, Srinivasa Ds wrote:
Looks like there is a bug in SLUB implementaion for ppc64 in 2.6.21-mm1.
I unmarked CONFIG_SLUB and build the kernel, its booting cleary now.
This is a known issue for PPC with more than 4 processors. Work is in
progress for a general fix.
That would be good. Incase if you have fix, please let us know so that
we can test it on ppc64.
Here's Ben's my patch, on its way from PowerPC git to Linus' git.
If you're an oldconfig user, you'll probably find you need to delete
your CONFIG_SLAB=y to get Kconfig to offer you the choice of SLUB now.
powerpc: Don't use SLAB/SLUB for PTE pages
From: Hugh Dickins [EMAIL PROTECTED]
The SLUB allocator relies on struct page fields first_page and slab,
overwritten by ptl when SPLIT_PTLOCK: so the SLUB allocator cannot then
be used for the lowest level of pagetable pages. This was obstructing
SLUB on PowerPC, which uses kmem_caches for its pagetables. So convert
its pte level to use normal gfp pages (whereas pmd, pud and 64k-page pgd
want partpages, so continue to use kmem_caches for pmd, pud and pgd).
Signed-off-by: Hugh Dickins [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
This version uses __GFP_ZERO instead of clear_page() and re-enables
SLUB on powerpc.
Index: linux-cell/arch/powerpc/mm/init_64.c
===
--- linux-cell.orig/arch/powerpc/mm/init_64.c 2007-05-08 16:47:48.0
+1000
+++ linux-cell/arch/powerpc/mm/init_64.c2007-05-09 12:15:22.0
+1000
@@ -146,21 +146,16 @@ static void zero_ctor(void *addr, struct
memset(addr, 0, kmem_cache_size(cache));
}
-#ifdef CONFIG_PPC_64K_PAGES
-static const unsigned int pgtable_cache_size[3] = {
- PTE_TABLE_SIZE, PMD_TABLE_SIZE, PGD_TABLE_SIZE
-};
-static const char *pgtable_cache_name[ARRAY_SIZE(pgtable_cache_size)] = {
- pte_pmd_cache, pmd_cache, pgd_cache,
-};
-#else
static const unsigned int pgtable_cache_size[2] = {
- PTE_TABLE_SIZE, PMD_TABLE_SIZE
+ PGD_TABLE_SIZE, PMD_TABLE_SIZE
};
static const char *pgtable_cache_name[ARRAY_SIZE(pgtable_cache_size)] = {
- pgd_pte_cache, pud_pmd_cache,
-};
+#ifdef CONFIG_PPC_64K_PAGES
+ pgd_cache, pmd_cache,
+#else
+ pgd_cache, pud_pmd_cache,
#endif /* CONFIG_PPC_64K_PAGES */
+};
#ifdef CONFIG_HUGETLB_PAGE
/* Hugepages need one extra cache, initialized in hugetlbpage.c. We
Index: linux-cell/include/asm-powerpc/pgalloc.h
===
--- linux-cell.orig/include/asm-powerpc/pgalloc.h 2007-05-08
16:47:48.0 +1000
+++ linux-cell/include/asm-powerpc/pgalloc.h2007-05-09 12:17:11.0
+1000
@@ -13,18 +13,11 @@
extern struct kmem_cache *pgtable_cache[];
-#ifdef CONFIG_PPC_64K_PAGES
-#define PTE_CACHE_NUM 0
-#define PMD_CACHE_NUM 1
-#define PGD_CACHE_NUM 2
-#define HUGEPTE_CACHE_NUM 3
-#else
-#define PTE_CACHE_NUM 0
-#define PMD_CACHE_NUM 1
-#define PUD_CACHE_NUM 1
-#define PGD_CACHE_NUM 0
-#define HUGEPTE_CACHE_NUM 2
-#endif
+#define PGD_CACHE_NUM 0
+#define PUD_CACHE_NUM 1
+#define PMD_CACHE_NUM 1
+#define HUGEPTE_CACHE_NUM 2
+#define PTE_NONCACHE_NUM 3 /* from GFP rather than kmem_cache */
/*
* This program is free software; you can redistribute it and/or
@@ -97,8 +90,7 @@ static inline void pmd_free(pmd_t *pmd)
static inline pte_t *pte_alloc_one_kernel(struct mm_struct *mm,
unsigned long address)
{
- return kmem_cache_alloc(pgtable_cache[PTE_CACHE_NUM],
- GFP_KERNEL|__GFP_REPEAT);
+return (pte_t *)__get_free_page(GFP_KERNEL | __GFP_REPEAT |
__GFP_ZERO);
}
static inline struct page *pte_alloc_one(struct mm_struct *mm,
@@ -109,12 +101,12 @@ static inline struct page *pte_alloc_one
static inline void pte_free_kernel(pte_t *pte)
{
- kmem_cache_free(pgtable_cache[PTE_CACHE_NUM], pte);
+ free_page((unsigned long)pte);
}
static inline void pte_free(struct page *ptepage)
{
- pte_free_kernel(page_address(ptepage));
+ __free_page(ptepage);
}
#define PGF_CACHENUM_MASK 0x3
@@ -136,14 +128,17 @@ static inline void pgtable_free(pgtable_
void *p = (void *)(pgf.val ~PGF_CACHENUM_MASK);
int cachenum = pgf.val PGF_CACHENUM_MASK;
- kmem_cache_free(pgtable_cache[cachenum], p);
+ if (cachenum == PTE_NONCACHE_NUM)
+ free_page((unsigned long)p);
+ else
+ kmem_cache_free(pgtable_cache[cachenum], p);
}
extern void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf);
#define __pte_free_tlb(tlb, ptepage) \
pgtable_free_tlb(tlb, pgtable_free_cache(page_address(ptepage), \
- PTE_CACHE_NUM, PTE_TABLE_SIZE-1
Re: 2.6.21-mm1 -- x86 verify_cpu.S compile failure
Andi Kleen wrote: On Tue, May 08, 2007 at 10:46:20AM +0100, Andy Whitcroft wrote: We are seeing the following compile error on older x86 installs: arch/i386/kernel/verify_cpu.S: Assembler messages: arch/i386/kernel/verify_cpu.S:13: Error: `(%esp)' is not a valid 16 bit base/index expression Seems to come from: x86_64-mm-i386-verify-cpu Compiler: gcc version 3.3.4 (Debian 1:3.3.4-3) Your compiler must be a brother in spirit of Andrew's vaio. Does this patch help? -Andi Index: linux/arch/i386/kernel/verify_cpu.S === --- linux.orig/arch/i386/kernel/verify_cpu.S +++ linux/arch/i386/kernel/verify_cpu.S @@ -10,7 +10,9 @@ verify_cpu: #if CONFIG_X86_MINIMUM_CPU_MODEL = 4 pushfl - orl $(118),(%esp) # try setting AC + pop %eax + orl $(118),%eax # try setting AC + push%eax popfl pushfl popl%eax Yep that gets us past the compile problems. Of course she then blows up cause SLUB does not work on x86 in that version ... but ... Acked-by: Andy Whitcroft [EMAIL PROTECTED] -apw - 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: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Wed, May 09, 2007 at 02:26:08PM +0200, Frederik Deweerdt wrote: On Wed, May 09, 2007 at 11:00:46AM +0200, Andi Kleen wrote: On Wed, May 09, 2007 at 09:40:24AM +0200, Jan Beulich wrote: I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the + if (!pte_present(*kpte)) + return 0; I the most recent version of the patch I sent to Andi this line is gone (again), as I realized it was wrong on i386 (namely for DEBUG_PAGEALLOC) and its respective variant was superfluous on x86-64. Yes the version of the patch that went into Linus' tree doesn't have it. Does the problem happen with mainline gitLATEST too? Andi, Latest git is OK with qemu, I'll test it on a real machine tonight. It boots fine on a real PC too. Thanks! Frederik - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
On Tue, May 08, 2007 at 09:58:09PM -0300, Kevin Winchester wrote:
>
> Not having any idea what I'm doing, I looked at cryptomgr_probe and
> cryptomgr_notify, and can't seem to see much, except for the following
> odd lines.
>
> From cryptomgr_schedule_probe, which is almost certainly inlined into
> crypto_notify:
Thanks for reporting this. This patch should fix the problem.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff -puN crypto/cryptomgr.c~crypto-fix crypto/cryptomgr.c
--- a/crypto/cryptomgr.c~crypto-fix
+++ a/crypto/cryptomgr.c
@@ -24,8 +24,6 @@
#include "internal.h"
struct cryptomgr_param {
- struct task_struct *thread;
-
struct rtattr *tb[CRYPTOA_MAX];
struct {
@@ -81,6 +79,7 @@ err:
static int cryptomgr_schedule_probe(struct crypto_larval *larval)
{
+ struct task_struct *thread;
struct cryptomgr_param *param;
const char *name = larval->alg.cra_name;
const char *p;
@@ -130,8 +129,8 @@ static int cryptomgr_schedule_probe(stru
memcpy(param->larval.name, larval->alg.cra_name, CRYPTO_MAX_ALG_NAME);
- param->thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
- if (IS_ERR(param->thread))
+ thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
+ if (IS_ERR(thread))
goto err_free_param;
return NOTIFY_STOP;
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot - crypto?
Christoph Lameter wrote: On Tue, 8 May 2007, Kevin Winchester wrote: Here's the dmesg of the slub_debug run, I'll try the patch next: Ok someone wrote to an object after it was freed. Not slubs problem. [1.367129] Object 0x810001bdecd0: 80 b7 b1 01 00 81 ff ff 6b 6b 6b 6b 6b 6b 6b 6b .·±... The first 8 bytes of the freed object were overwritten. [1.374455] Last alloc: cryptomgr_notify+0x28/0x190 jiffies_ago=0 cpu=0 pid=1 [1.374611] Last free : cryptomgr_probe+0x85/0xb0 jiffies_ago=0 cpu=0 pid=405 Here are some potential candidates that have recently handled the object. That was less than a jiffy ago. So very recent. Not having any idea what I'm doing, I looked at cryptomgr_probe and cryptomgr_notify, and can't seem to see much, except for the following odd lines. From cryptomgr_schedule_probe, which is almost certainly inlined into crypto_notify: - param = kzalloc(sizeof(*param), GFP_KERNEL); ... param->thread = kthread_run(cryptomgr_probe, param, "cryptomgr"); if (IS_ERR(param->thread)) goto err_free_param; return NOTIFY_STOP; err_free_param: kfree(param); err_put_module: module_put(THIS_MODULE); err: return NOTIFY_OK; - while cryptomgr_probe does (with a local variable param that points to the same data): - ... if (err) goto err; out: kfree(param); module_put_and_exit(0); - Now perhaps I am wrong, but would it be possible for the kthread_run() call to cause cryptomgr_probe to run before the return result is stored into param->thread? That would mean that param would be accessed after freeing. method...compile...test...still fails> I guess that's not it. Any thoughts on what might be the cause of this (I've added Herbert Xu to the CC list since he seems to be the crypto maintainer)? I'll try to add some printk's in there to see if that enlightens me. Kevin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot
On Tue, 8 May 2007, Kevin Winchester wrote: > [1.376783] [] kernel_init+0xc4/0x2a0 > [1.376857] [] __switch_to+0x2a/0x2d0 > [1.376932] [] child_rip+0xa/0x12 > [1.377006] [] kernel_init+0x0/0x2a0 > [1.377080] [] child_rip+0x0/0x12 > [1.377151] > [1.377221] @@@ SLUB kmalloc-256: Restoring Poison (0x6b) from > 0x810001bdecd0-0x810001bdedce > [1.377326] @@@ SLUB kmalloc-256: Restoring Poison (0xa5) from > 0x810001bdedcf-0x810001bdedcf > [1.377430] @@@ SLUB: kmalloc-256 slab 0x810001061890. Marking all > objects used. There is more... The above describes the repair actions that were taken by SLUB. Poison was restored and then the slab was taken out of circulation since pointers may still exist that may damage additional objects if used to store more data. - 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: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Wed, May 09, 2007 at 12:12:29AM +0200, Andi Kleen wrote: > On Tue, May 08, 2007 at 07:22:33PM +0200, Frederik Deweerdt wrote: > > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > > > > > Hi all, > > > > My computer fails early at boot with a stack along the lines of: > > Do you have a full oops (.jpg or serial)? Yup, I've uploaded the .jpg at http://fdeweerdt.free.fr/kmem_prob/ The faulty address is missing from the shot, but it's %edi+0xc Thanks, Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot
On Tue, 8 May 2007, Kevin Winchester wrote: > Here's the dmesg of the slub_debug run, I'll try the patch next: Ok someone wrote to an object after it was freed. Not slubs problem. > [1.367129] Object 0x810001bdecd0: 80 b7 b1 01 00 81 ff ff 6b 6b > 6b 6b 6b 6b 6b 6b .·±... The first 8 bytes of the freed object were overwritten. > [1.374455] Last alloc: cryptomgr_notify+0x28/0x190 jiffies_ago=0 cpu=0 > pid=1 > [1.374611] Last free : cryptomgr_probe+0x85/0xb0 jiffies_ago=0 cpu=0 > pid=405 Here are some potential candidates that have recently handled the object. That was less than a jiffy ago. So very recent.
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot
Christoph Lameter wrote: On Tue, 8 May 2007, Kevin Winchester wrote: x86_64 UP Athlon64 I get a crash on boot using SLUB. Switching to SLAB makes it go away. I don't have a serial console, so the best I have is a digital photo of as many lines as my VGA console was able to get (60 or so). Is there a better way to capture the oops output so that the full trace canbe seen? http://picasaweb.google.com/kjwinchester/Linux/photo#5061982383505227842 It fails to create a slab. There should be some of message above what I can see that would indicate what went wrong. Please try to reboot and specify "slub_debug" as a kernel parameter. If it boots then send us the kernel log output. Must have something to do with how the scsi slab is created in scsi_setup_command_freelist. Here's the dmesg of the slub_debug run, I'll try the patch next: [0.00] Linux version 2.6.21-mm1 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2)) #2 PREEMPT Tue May 8 20:13:55 ADT 2007 [0.00] Command line: root=/dev/sda3 slub_debug [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 - 1fef (usable) [0.00] BIOS-e820: 1fef - 1fef3000 (ACPI NVS) [0.00] BIOS-e820: 1fef3000 - 1ff0 (ACPI data) [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, 130800) 1 entries of 256 used [0.00] end_pfn_map = 1048576 [0.00] DMI 2.3 present. [0.00] ACPI: RSDP 000F77D0, 0014 (r0 VIAK8T) [0.00] ACPI: RSDT 1FEF3040, 0034 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: FACP 1FEF30C0, 0074 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: DSDT 1FEF3180, 4F8A (r1 VIAK8T AWRDACPI 1000 MSFT 10E) [0.00] ACPI: FACS 1FEF, 0040 [0.00] ACPI: BOOT 1FEF8180, 0028 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] ACPI: SSDT 1FEF82C0, 00B5 (r1 PTLTD POWERNOW1 LTP1) [0.00] ACPI: APIC 1FEF8200, 0068 (r1 VIAK8T AWRDACPI 42302E31 AWRD0) [0.00] Entering add_active_range(0, 0, 159) 0 entries of 256 used [0.00] Entering add_active_range(0, 256, 130800) 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] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN ranges [0.00] 0:0 -> 159 [0.00] 0: 256 -> 130800 [0.00] On node 0 totalpages: 130703 [0.00] DMA zone: 56 pages used for memmap [0.00] DMA zone: 1380 pages reserved [0.00] DMA zone: 2563 pages, LIFO batch:0 [0.00] DMA32 zone: 1732 pages used for memmap [0.00] DMA32 zone: 124972 pages, LIFO batch:31 [0.00] Normal zone: 0 pages used for memmap [0.00] Movable zone: 0 pages used for memmap [0.00] ACPI: PM-Timer IO Port: 0x4008 [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 0 global_irq 2 dfl dfl) [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. [0.00] ACPI: IRQ9 used by override. [0.00] Setting APIC routing to flat [0.00] Using ACPI (MADT) for SMP configuration information [0.00] Allocating PCI resources starting at 2000 (gap: 1ff0:ded0) [0.00] Built 1 zonelists, mobility grouping on. Total pages: 127535 [0.00] Kernel command line: root=/dev/sda3 slub_debug [0.00] Initializing CPU#0 [0.00] PID hash table entries: 2048 (order: 11, 16384 bytes) [0.00] time.c: Detected 1838.876 MHz processor. [0.002000] Console: colour VGA+ 80x25 [0.003000] Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) [0.004000] Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) [0.004000] Checking aperture... [0.004000] CPU 0: ape
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot
It seems that a uevent notification fails.
Does this patch fix it?
---
mm/slub.c |1 -
1 file changed, 1 deletion(-)
Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c2007-05-08 16:06:54.0 -0700
+++ linux-2.6/mm/slub.c 2007-05-08 16:07:11.0 -0700
@@ -3438,7 +3438,6 @@ static int sysfs_slab_add(struct kmem_ca
err = sysfs_create_group(>kobj, _attr_group);
if (err)
return err;
- kobject_uevent(>kobj, KOBJ_ADD);
if (!unmergeable) {
/* Setup first alias */
sysfs_slab_alias(s, s->name);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 and now 2.6.21-git: SLUB Crashes on boot
On Tue, 8 May 2007, Kevin Winchester wrote: > x86_64 UP Athlon64 I get a crash on boot using SLUB. Switching to SLAB makes > it go away. I don't have a serial console, so the best I have is a digital > photo of as many lines as my VGA console was able to get (60 or so). Is there > a better way to capture the oops output so that the full trace canbe seen? > > http://picasaweb.google.com/kjwinchester/Linux/photo#5061982383505227842 It fails to create a slab. There should be some of message above what I can see that would indicate what went wrong. Please try to reboot and specify "slub_debug" as a kernel parameter. If it boots then send us the kernel log output. Must have something to do with how the scsi slab is created in scsi_setup_command_freelist. - 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: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Tue, May 08, 2007 at 07:22:33PM +0200, Frederik Deweerdt wrote: > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > > > Hi all, > > My computer fails early at boot with a stack along the lines of: Do you have a full oops (.jpg or serial)? -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- Hibernation locked up and didn't power down (had to hold power button down for five seconds)
On Tuesday, 8 May 2007 01:37, Miles Lane wrote: > This is probably more log info than you need, but I am including it in > case it helps. > This log shows another manifestation of the time confusion on wakeup. > This is the portion beginning with the hibernation initiation: Can we please debug this in one thread at a time? > [ 5482.518162] PM: Removing info for No Bus:eth0 > [ 5482.581594] ACPI: PCI interrupt for device :01:00.0 disabled > [ 5482.664582] PM: Removing info for No Bus:eth1 > [ 5482.740270] ACPI: PCI interrupt for device :01:06.0 disabled > [ 5483.947270] [ACPI Debug] String: [0x1C] "Temperature increasing: _Q80" > [ 5485.142037] PM: suspend-to-disk mode set to 'shutdown' > [ 5485.142618] swsusp: Basic memory bitmaps created > [ 5485.153011] Stopping tasks ... done. > [ 5485.783751] Shrinking memory... -[ACPI Debug] String: [0x1C] > "Temperature increasing: _Q80" > [ 5485.974969]done (101216 pages freed) > [ 5487.254038] Freed 404864 kbytes in 1.47 seconds (275.41 MB/s) > [ 5487.254042] Suspending console(s) > [ 5487.254050] Suspending device event4 > [ 5487.254056] Suspending device input13 > [ 5487.254059] Suspending device event3 > [ 5487.254062] Suspending device input12 > [ 5487.254065] Suspending device event2 > [ 5487.254068] Suspending device input11 > [ 5487.254071] Suspending device bluetooth > [ 5487.254074] platform bluetooth: freeze > [ 5487.254078] Suspending device apm_bios > [ 5487.254081] Suspending device vcsa7 > [ 5487.254084] Suspending device vcs7 > [ 5487.254087] Suspending device vcsa2 > [ 5487.254090] Suspending device vcs2 > [ 5487.254093] Suspending device vcsa6 > [ 5487.254096] Suspending device vcs6 > [ 5487.254099] Suspending device vcsa1 > [ 5487.254101] Suspending device vcs1 > [ 5487.254104] Suspending device vcsa3 > [ 5487.254107] Suspending device vcs3 > [ 5487.254110] Suspending device vcsa5 > [ 5487.254113] Suspending device vcs5 > [ 5487.254116] Suspending device vcsa4 > [ 5487.254119] Suspending device vcs4 > [ 5487.254122] Suspending device fuse > [ 5487.254125] Suspending device mixer > [ 5487.254128] Suspending device controlC0 > [ 5487.254131] Suspending device 0-0:unknown codec > [ 5487.254134] ac97 0-0:unknown codec: freeze > [ 5487.254137] Suspending device audio > [ 5487.254140] Suspending device dsp > [ 5487.254143] Suspending device pcmC0D0c > [ 5487.254145] Suspending device pcmC0D0p > [ 5487.254148] Suspending device adsp > [ 5487.254151] Suspending device pcmC0D1c > [ 5487.254154] Suspending device pcmC0D2c > [ 5487.254157] Suspending device pcmC0D3c > [ 5487.254160] Suspending device pcmC0D4p > [ 5487.254163] Suspending device card0 > [ 5487.254166] Suspending device sequencer2 > [ 5487.254169] Suspending device sequencer > [ 5487.254172] Suspending device mmc2 > [ 5487.254175] Suspending device mmc1 > [ 5487.254178] Suspending device mmc0 > [ 5487.254181] Suspending device pcmcia_socket0 > [ 5487.254184] Suspending device seq > [ 5487.254187] Suspending device timer > [ 5487.254190] Suspending device event1 > [ 5487.254193] Suspending device mouse0 > [ 5487.254196] Suspending device input1 > [ 5487.254199] Suspending device rtc > [ 5487.254202] Suspending device watchdog > [ 5487.254205] Suspending device iTCO_wdt > [ 5487.254207] iTCO_wdt iTCO_wdt: freeze > [ 5487.254210] Suspending device agpgart > [ 5487.254213] Suspending device 00c09f4fec18 > [ 5487.254217] Suspending device fw-host0 > [ 5487.254220] Suspending device 1:0:0:0 > [ 5487.254223] sr 1:0:0:0: freeze > [ 5487.254277] Suspending device target1:0:0 > [ 5487.254280] Suspending device 0:0:0:0 > [ 5487.254282] sd 0:0:0:0: freeze > [ 5487.254289] sd 0:0:0:0: [sda] Synchronizing SCSI cache > [ 5487.254773] Suspending device target0:0:0 > [ 5487.254776] Suspending device host1 > [ 5487.254779] Suspending device host0 > [ 5487.254782] Suspending device usbdev4.1_ep81 > [ 5487.254786] usb_endpoint usbdev4.1_ep81: PM: suspend 0->1, parent > 4-0:1.0 already 2 > [ 5487.254789] Suspending device 4-0:1.0 > [ 5487.254792] hub 4-0:1.0: PM: suspend 2-->1 > [ 5487.254794] hub 4-0:1.0: PM: suspend 2->1, parent usb4 already 2 > [ 5487.254797] Suspending device usbdev4.1_ep00 > [ 5487.254800] usb_endpoint usbdev4.1_ep00: PM: suspend 0->1, parent > usb4 already 2 > [ 5487.254803] Suspending device usb4 > [ 5487.254806] usb usb4: PM: suspend 2-->1 > [ 5487.254809] Suspending device usbdev3.1_ep81 > [ 5487.254812] usb_endpoint usbdev3.1_ep81: PM: suspend 0->1, parent > 3-0:1.0 already 2 > [ 5487.254815] Suspending device 3-0:1.0 > [ 5487.254817] hub 3-0:1.0: PM: suspend 2-->1 > [ 5487.254819] hub 3-0:1.0: PM: suspend 2->1, parent usb3 already 2 > [ 5487.254822] Suspending device usbdev3.1_ep00 > [ 5487.254825] usb_endpoint usbdev3.1_ep00: PM: suspend 0->1, parent > usb3 already 2 > [ 5487.254828] Suspending device usb3 > [ 5487.254830] usb usb3: PM: suspend 2-->1 > [ 5487.254833] Suspending device usbdev2.1_ep81 > [ 5487.254836] usb_endpoint usbdev2.1_ep81: PM: suspend 0->1, parent
Re: [PATCH] drivers/macintosh: remove default y from Kconfig (was: Re: 2.6.21-mm1)
On Tue, May 08, 2007 at 10:33:22AM +0200, Jan Engelhardt wrote: > > On May 7 2007 12:35, Borislav Petkov wrote: > > > >I don't think I need macintosh drivers for my x86 arch selected in by > >default, > > do I? > > For new config variables that were introduced, I set them to 'default y' > so when upgrading from an older .config, it does not deselect the drivers > _inside_ the new menuconfig. People who have CONFIG_MAC_EMUMOUSEBTN=y > will magically get it set to =n because MACINTOSH_DRIVERS is not y. I had a similar suspicion that something else requires the default=y things ... > Whether you need macintosh on i386... oh well, ask someone who knows. > Fact is, that at least SUSE has CONFIG_MAC_EMUMOUSEBTN=y but I > wonder wtf for. Well, this is clearly wrong since it is only for a mac, single-button, mouse, IMHO. Look for CONFIG_MAC_EMUMOUSEBTN in drivers/char/keyboard.c > >Index: trees/linux-mm/drivers/macintosh/Kconfig > >=== > >--- linux-mm.orig/drivers/macintosh/Kconfig > >+++ linux-mm/drivers/macintosh/Kconfig > >@@ -2,7 +2,6 @@ > > menuconfig MACINTOSH_DRIVERS > > bool "Macintosh device drivers" > > depends on PPC || MAC || X86 > >-default y > > How about > default y if PPC || MAC > then? sounds good, here we go: - From: Borislav Petkov <[EMAIL PROTECTED]> Do not select macintosh drivers by default. Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> -- Index: linux-mm/drivers/macintosh/Kconfig === --- linux-mm/drivers/macintosh/Kconfig.orig +++ linux-mm/drivers/macintosh/Kconfig @@ -2,7 +2,7 @@ menuconfig MACINTOSH_DRIVERS bool "Macintosh device drivers" depends on PPC || MAC || X86 - default y + default y if PPC || MAC if MACINTOSH_DRIVERS -- Regards/Gruß, Boris. - 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: kmem_cache_init failure (was Re: 2.6.21-mm1)
On Tue, 8 May 2007 19:22:33 +0200 Frederik Deweerdt <[EMAIL PROTECTED]> wrote: > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > > > Hi all, > > My computer fails early at boot with a stack along the lines of: > > kmem_cache_zalloc > kmem_cache_create > kmem_cache_init > start_kernel > > eip is at cache_calloc_refill+0x3e1 which is the > slabp->colouroff = colouroff; in alloc_slabmgmt() > > I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the > > + if (!pte_present(*kpte)) > + return 0; > > part in particular. Dotconfig and cpuinfo are available at > http://fdeweerdt.free.fr/kmem_prob/. Any ideas? Thanks for working that out - it helps heaps. x86_64-mm-cpa-kerneltext.patch seems to have been dropped from Andi's tree. It might come back, so please let's keep an eye out for that. - 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: kernel expection generated with 2.6.21-mm1 kernel boot up
On Tue, 8 May 2007, Srinivasa Ds wrote: > Looks like there is a bug in SLUB implementaion for ppc64 in 2.6.21-mm1. > I unmarked CONFIG_SLUB and build the kernel, its booting cleary now. > > Thanks > Srinivasa DS This is a known issue for PPC with more than 4 processors. Work is in progress for a general fix. You should have not been able to select SLUB at all given that you have 4 processor configured. Hmmm... The Kconfig comparison for more than 4 cpus does only seem to work in certain cases. Could I have a complete .config? - 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/
kmem_cache_init failure (was Re: 2.6.21-mm1)
On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > Hi all, My computer fails early at boot with a stack along the lines of: kmem_cache_zalloc kmem_cache_create kmem_cache_init start_kernel eip is at cache_calloc_refill+0x3e1 which is the slabp->colouroff = colouroff; in alloc_slabmgmt() I've bisected it down to the x86_64-mm-cpa-kerneltext.patch and the + if (!pte_present(*kpte)) + return 0; part in particular. Dotconfig and cpuinfo are available at http://fdeweerdt.free.fr/kmem_prob/. Any ideas? Regards, Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1
On Tue, 8 May 2007, Andy Whitcroft wrote: > The SLUB code introduces the config segment below to stop SLUB being > used on powerpc: > > config ARCH_USES_SLAB_PAGE_STRUCT >bool >default y >depends on SPLIT_PTLOCK_CPUS <= NR_CPUS > > However as far as I can kconfig has no support for operators other than > ==, !=, &&, and ||. Who can say why we do not get an error. > > Cirtainly in my testing this simply never triggers and bad kernels result. > > Thoughts? Get rid of the whole patch as soon as possible? It seems that PPC work is in progress to make SLUB work in all configurations. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- x86 verify_cpu.S compile failure
On Tue, May 08, 2007 at 10:46:20AM +0100, Andy Whitcroft wrote: > We are seeing the following compile error on older x86 installs: > > arch/i386/kernel/verify_cpu.S: Assembler messages: > arch/i386/kernel/verify_cpu.S:13: Error: `(%esp)' is >not a valid 16 bit base/index expression > > Seems to come from: > > x86_64-mm-i386-verify-cpu > > Compiler: > > gcc version 3.3.4 (Debian 1:3.3.4-3) Your compiler must be a brother in spirit of Andrew's vaio. Does this patch help? -Andi Index: linux/arch/i386/kernel/verify_cpu.S === --- linux.orig/arch/i386/kernel/verify_cpu.S +++ linux/arch/i386/kernel/verify_cpu.S @@ -10,7 +10,9 @@ verify_cpu: #if CONFIG_X86_MINIMUM_CPU_MODEL >= 4 pushfl - orl $(1<<18),(%esp) # try setting AC + pop %eax + orl $(1<<18),%eax # try setting AC + push%eax popfl pushfl popl%eax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
On 05/08, Oleg Nesterov wrote:
>
> On 05/08, Jiri Slaby wrote:
> >
> > vmstat_update+0x0/0x2b
>
> Thanks a lot.
>
> Right now,
>
> > +static void vmstat_update(struct work_struct *w)
> > +{
> > + refresh_cpu_vm_stats(smp_processor_id());
> > + schedule_delayed_work(&__get_cpu_var(vmstat_work),
> > + sysctl_stat_interval);
> > +}
>
> This is not precisely correct. We cam schedule the wrong vmstat_work
> if this timer/work migrates to another CPU. I'd suggest
>
> schedule_delayed_work(container_of(w, struct delayed_work, work))
>
> This should not happen because we are doing cancel_rearming_delayed_work()
> below, however:
>
> > + case CPU_DOWN_PREPARE:
> > + case CPU_DOWN_PREPARE_FROZEN:
> > + cancel_rearming_delayed_work(_cpu(vmstat_work, cpu));
> > + per_cpu(vmstat_work, cpu).work.func = NULL;
> > + case CPU_DOWN_FAILED:
> > + case CPU_DOWN_FAILED_FROZEN:
> > + start_cpu_timer(cpu);
>
> we need a "break;" before "case CPU_DOWN_FAILED", otherwise we re-start
> vmstat_update() immediately.
>
> This is a bug, but I am not sure is this the only problem.
In case I was not clear, this _can_ explain the problem. Because an extra
start_cpu_timer() (due to missed "break;") re-initializes dwork, and clears
_PENDING.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
On 05/08, Jiri Slaby wrote:
>
> > Oleg Nesterov napsal(a):
> >>>
> >>>> kernel BUG at /home/l/latest/xxx/kernel/workqueue.c:106!
> >>>> invalid opcode: [#1]
> >>>> SMP
> >>>> Modules linked in: ipv6 floppy ohci1394 ieee1394 parport_pc parport
> >>>> usbhid
> >>>> ehci_hcd pata_acpi ff_memless sr_mod cdrom
> >>>> CPU:1
> >>>> EIP:0060:[]Not tainted VLI
> >>>> EFLAGS: 00010046 (2.6.21-mm1 #272)
> >>>> EIP is at insert_work+0x6d/0x71
> [...]
> >> --- OLD/kernel/workqueue.c~2007-05-06 00:01:06.0 +0400
> >> +++ OLD/kernel/workqueue.c 2007-05-08 14:50:39.0 +0400
> >> @@ -103,7 +103,10 @@ static inline void set_wq_data(struct wo
> >> {
> >>unsigned long new;
> >>
> >> - BUG_ON(!work_pending(work));
> >> + if (!work_pending(work)) {
> >> + printk(KERN_ERR "BUG: set_wq_data ");
> >> + print_symbol("%s\n", (unsigned long) work->func);
> >> + }
> >>
> >>new = (unsigned long) cwq | (1UL << WORK_STRUCT_PENDING);
> >>new |= WORK_STRUCT_FLAG_MASK & *work_data_bits(work);
>
> vmstat_update+0x0/0x2b
Thanks a lot.
I know nothing about hwsusp, to the point I don't even know what it does.
I'll try to do some reading tomorrow.
Right now,
> +static void vmstat_update(struct work_struct *w)
> +{
> + refresh_cpu_vm_stats(smp_processor_id());
> + schedule_delayed_work(&__get_cpu_var(vmstat_work),
> + sysctl_stat_interval);
> +}
This is not precisely correct. We cam schedule the wrong vmstat_work
if this timer/work migrates to another CPU. I'd suggest
schedule_delayed_work(container_of(w, struct delayed_work, work))
This should not happen because we are doing cancel_rearming_delayed_work()
below, however:
> + case CPU_DOWN_PREPARE:
> + case CPU_DOWN_PREPARE_FROZEN:
> + cancel_rearming_delayed_work(_cpu(vmstat_work, cpu));
> + per_cpu(vmstat_work, cpu).work.func = NULL;
> + case CPU_DOWN_FAILED:
> + case CPU_DOWN_FAILED_FROZEN:
> + start_cpu_timer(cpu);
we need a "break;" before "case CPU_DOWN_FAILED", otherwise we re-start
vmstat_update() immediately.
This is a bug, but I am not sure is this the only problem.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1
The SLUB code introduces the config segment below to stop SLUB being used on powerpc: config ARCH_USES_SLAB_PAGE_STRUCT bool default y depends on SPLIT_PTLOCK_CPUS <= NR_CPUS However as far as I can kconfig has no support for operators other than ==, !=, &&, and ||. Who can say why we do not get an error. Cirtainly in my testing this simply never triggers and bad kernels result. Thoughts? -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
On 05/08, Jarek Poplawski wrote: > > On 08-05-2007 12:55, Oleg Nesterov wrote: > > On 05/08, Andrew Morton wrote: > >> On Tue, 08 May 2007 10:57:35 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote: > >> > >>> this occured in dmesg during resuming from hwsusp in 2.6.21-mm1 (captured > >>> through netconsole). Perfectly reproducible, it simply happens each time I > >>> try it. > >> Let's cc Oleg. > >> > >>> usb_endpoint usbdev5.1_ep00: PM: resume from 0, parent usb5 still 2 > >>> [ cut here ] > >>> kernel BUG at /home/l/latest/xxx/kernel/workqueue.c:106! > >>> invalid opcode: [#1] > >>> SMP > >>> Modules linked in: ipv6 floppy ohci1394 ieee1394 parport_pc parport usbhid > >>> ehci_hcd pata_acpi ff_memless sr_mod cdrom > ... > > queue_delayed_work(). > > > > Probably, cancel_delayed_work(_work->work) was called with the > > ->timer > > pending. This is wrong, cancel_delayed_work() clears _PENDING > > unconditionally, > > Maybe I miss your point, but clearing is conditional: on timer delete... > > I think more suspicious is calling cancel_work_sync() for a delayed work > (with timer pending). Or maybe some race profits from _PENDING cleared > without locking? Yes, of course, I meant cancel_work_sync(), sorry for the confusion. Thanks! So, once again, cancel_work_sync(>work) is wrong unless the timer was stopped. Before make-cancel_rearming_delayed_work-reliable.patch it requires that the @work can't be re-queued. After works, but waits for the timer expiration in a busy-wait loop. Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
Jiri Slaby napsal(a):
> Oleg Nesterov napsal(a):
>> On 05/08, Andrew Morton wrote:
>>> On Tue, 08 May 2007 10:57:35 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote:
>>>
>>>> this occured in dmesg during resuming from hwsusp in 2.6.21-mm1 (captured
>>>> through netconsole). Perfectly reproducible, it simply happens each time I
>>>> try it.
>>> Let's cc Oleg.
>>>
>>>> usb_endpoint usbdev5.1_ep00: PM: resume from 0, parent usb5 still 2
>>>> [ cut here ]
>>>> kernel BUG at /home/l/latest/xxx/kernel/workqueue.c:106!
>>>> invalid opcode: [#1]
>>>> SMP
>>>> Modules linked in: ipv6 floppy ohci1394 ieee1394 parport_pc parport usbhid
>>>> ehci_hcd pata_acpi ff_memless sr_mod cdrom
>>>> CPU:1
>>>> EIP:0060:[]Not tainted VLI
>>>> EFLAGS: 00010046 (2.6.21-mm1 #272)
>>>> EIP is at insert_work+0x6d/0x71
>>>> eax: c1c3b3c0 ebx: c1814aa0 ecx: 0001 edx: c1814aa0
>>>> esi: c1c3b340 edi: 0282 ebp: c04d2f68 esp: c04d2f50
>>>> ds: 007b es: 007b fs: 00d8 gs: ss: 0068
>>>> Process swapper (pid: 0, ti=c04d2000 task=c1c26030 task.ti=c1c2)
>>>> Stack: c4685f54 c18148ac c04d2f98 c013816f c1c3b340 c1814aa0 c04d2f88
>>>> c013256c
>>>>0066 c1814880 c1c5e000 c04d2fc4 c01325a1
>>>> c1c5e000 0100 c012ba35 c04d2fb8 c01333f4 Call Trace:
>>>> [] [] show_stack_log_lvl+0xa5/0xca
>>>> show_registers+0x1e2/0x2da
>>>> [] [] do_trap+0x84/0xaa
>>>> do_invalid_op+0x88/0x92
>>>> [] [] __queue_work+0x22/0x33
>>>> delayed_work_timer_fn+0x24/0x2a
>>>> [] [] __do_softirq+0x75/0xe6
>>>> do_softirq+0x63/0xac
>>>> [] [] smp_apic_timer_interrupt+0x5c/0x88
>>>> apic_timer_interrupt+0x28/0x30
[...]
>> queue_delayed_work().
>>
>> Probably, cancel_delayed_work(_work->work) was called with the
>> ->timer
>> pending. This is wrong, cancel_delayed_work() clears _PENDING
>> unconditionally,
>> that is why the comment says
>>
>> it is expected that, prior to calling cancel_work_sync(), the caller has
>> arranged for the work to not be requeued.
>>
>> (Just in case, after make-cancel_rearming_delayed_work-reliable.patch this
>> is still
>> wrong (as documented) to do cancel_delayed_work() before
>> cancel_delayed_timer(),
>> but should work correctly).
[...]
>> --- OLD/kernel/workqueue.c~ 2007-05-06 00:01:06.0 +0400
>> +++ OLD/kernel/workqueue.c 2007-05-08 14:50:39.0 +0400
>> @@ -103,7 +103,10 @@ static inline void set_wq_data(struct wo
>> {
>> unsigned long new;
>>
>> -BUG_ON(!work_pending(work));
>> +if (!work_pending(work)) {
>> +printk(KERN_ERR "BUG: set_wq_data ");
>> +print_symbol("%s\n", (unsigned long) work->func);
>> +}
>>
>> new = (unsigned long) cwq | (1UL << WORK_STRUCT_PENDING);
>> new |= WORK_STRUCT_FLAG_MASK & *work_data_bits(work);
vmstat_update+0x0/0x2b
Ccing Christoph.
regards,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
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: kernel expection generated with 2.6.21-mm1 kernel boot up
Kamalesh Babulal wrote: > Hi, > > I tried compiling and booting up with 2.6.21-mm1 kernel > on the following machine > > Architecture :PPC64 > CPU Type :POWER5 (gr) > Machine Type:CHRP IBM,9117-570 > Base OS :Fedora Core 5 > > > Faulting instruction address: 0xc00cc5e4 > > cpu 0x1: Vector: 300 (Data Access) at [c5373320] > > pc: c00cc5e4: .slab_free+0x6c/0x424 > > lr: c002fa70: .pgtable_free_tlb+0xd0/0x140 > > sp: c53735a0 > > msr: 80009032 > Looks like there is a bug in SLUB implementaion for ppc64 in 2.6.21-mm1. I unmarked CONFIG_SLUB and build the kernel, its booting cleary now. Thanks Srinivasa DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
On 08-05-2007 12:55, Oleg Nesterov wrote: > On 05/08, Andrew Morton wrote: >> On Tue, 08 May 2007 10:57:35 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote: >> >>> this occured in dmesg during resuming from hwsusp in 2.6.21-mm1 (captured >>> through netconsole). Perfectly reproducible, it simply happens each time I >>> try it. >> Let's cc Oleg. >> >>> usb_endpoint usbdev5.1_ep00: PM: resume from 0, parent usb5 still 2 >>> [ cut here ] >>> kernel BUG at /home/l/latest/xxx/kernel/workqueue.c:106! >>> invalid opcode: [#1] >>> SMP >>> Modules linked in: ipv6 floppy ohci1394 ieee1394 parport_pc parport usbhid >>> ehci_hcd pata_acpi ff_memless sr_mod cdrom ... > queue_delayed_work(). > > Probably, cancel_delayed_work(_work->work) was called with the ->timer > pending. This is wrong, cancel_delayed_work() clears _PENDING unconditionally, Maybe I miss your point, but clearing is conditional: on timer delete... I think more suspicious is calling cancel_work_sync() for a delayed work (with timer pending). Or maybe some race profits from _PENDING cleared without locking? BTW, it seems some debugging is needed to show, whose work is doing the mess. Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
Oleg Nesterov napsal(a):
> On 05/08, Andrew Morton wrote:
>> On Tue, 08 May 2007 10:57:35 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote:
>>
>>> this occured in dmesg during resuming from hwsusp in 2.6.21-mm1 (captured
>>> through netconsole). Perfectly reproducible, it simply happens each time I
>>> try it.
>> Let's cc Oleg.
>>
>>> usb_endpoint usbdev5.1_ep00: PM: resume from 0, parent usb5 still 2
>>> [ cut here ]
>>> kernel BUG at /home/l/latest/xxx/kernel/workqueue.c:106!
>>> invalid opcode: [#1]
>>> SMP
>>> Modules linked in: ipv6 floppy ohci1394 ieee1394 parport_pc parport usbhid
>>> ehci_hcd pata_acpi ff_memless sr_mod cdrom
>>> CPU:1
>>> EIP:0060:[]Not tainted VLI
>>> EFLAGS: 00010046 (2.6.21-mm1 #272)
>>> EIP is at insert_work+0x6d/0x71
>>> eax: c1c3b3c0 ebx: c1814aa0 ecx: 0001 edx: c1814aa0
>>> esi: c1c3b340 edi: 0282 ebp: c04d2f68 esp: c04d2f50
>>> ds: 007b es: 007b fs: 00d8 gs: ss: 0068
>>> Process swapper (pid: 0, ti=c04d2000 task=c1c26030 task.ti=c1c2)
>>> Stack: c4685f54 c18148ac c04d2f98 c013816f c1c3b340 c1814aa0 c04d2f88
>>> c013256c
>>>0066 c1814880 c1c5e000 c04d2fc4 c01325a1
>>> c1c5e000 0100 c012ba35 c04d2fb8 c01333f4 Call Trace:
>>> [] [] show_stack_log_lvl+0xa5/0xca
>>> show_registers+0x1e2/0x2da
>>> [] [] do_trap+0x84/0xaa
>>> do_invalid_op+0x88/0x92
>>> [] [] __queue_work+0x22/0x33
>>> delayed_work_timer_fn+0x24/0x2a
>>> [] [] __do_softirq+0x75/0xe6
>>> do_softirq+0x63/0xac
>>> [] [] smp_apic_timer_interrupt+0x5c/0x88
>>> apic_timer_interrupt+0x28/0x30
>> hm, how come it's so messy?
I have no idea, this is how it appeared in the `nc -ul' output...
> queue_delayed_work().
>
> Probably, cancel_delayed_work(_work->work) was called with the ->timer
> pending. This is wrong, cancel_delayed_work() clears _PENDING unconditionally,
> that is why the comment says
>
> it is expected that, prior to calling cancel_work_sync(), the caller has
> arranged for the work to not be requeued.
>
> (Just in case, after make-cancel_rearming_delayed_work-reliable.patch this is
> still
> wrong (as documented) to do cancel_delayed_work() before
> cancel_delayed_timer(),
> but should work correctly).
>
> ata_port_flush_task() and ata_port_detach() do this, I sent the patch to fix
> this
> twice. The last one is
>
> [PATCH -mm] libata-core: convert to use cancel_rearming_delayed_work()
> http://marc.info/?l=linux-kernel=117840349108505
>
>
> Jiri, any chance you can re-test with the patch below?
Yes. In the meantime I investigated, that the regression is between
broken-out-2007-04-28-05-06
and
special -js edition:
I guess it's time to end the staircase experiment in -mm.
http://userweb.kernel.org/~akpm/js.bz2 is my current rollup (against
2.6.21) minus staircase and related things.
I don't know if it's possible to dig out the patch list from it, otherwise,
2.6.21-mm1 list may be used...
> --- OLD/kernel/workqueue.c~ 2007-05-06 00:01:06.0 +0400
> +++ OLD/kernel/workqueue.c2007-05-08 14:50:39.0 +0400
> @@ -103,7 +103,10 @@ static inline void set_wq_data(struct wo
> {
> unsigned long new;
>
> - BUG_ON(!work_pending(work));
> + if (!work_pending(work)) {
> + printk(KERN_ERR "BUG: set_wq_data ");
> + print_symbol("%s\n", (unsigned long) work->func);
> + }
>
> new = (unsigned long) cwq | (1UL << WORK_STRUCT_PENDING);
> new |= WORK_STRUCT_FLAG_MASK & *work_data_bits(work);
building and will report,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
On 05/08, Andrew Morton wrote:
>
> On Tue, 08 May 2007 10:57:35 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote:
>
> >
> > this occured in dmesg during resuming from hwsusp in 2.6.21-mm1 (captured
> > through netconsole). Perfectly reproducible, it simply happens each time I
> > try it.
>
> Let's cc Oleg.
>
> > usb_endpoint usbdev5.1_ep00: PM: resume from 0, parent usb5 still 2
> > [ cut here ]
> > kernel BUG at /home/l/latest/xxx/kernel/workqueue.c:106!
> > invalid opcode: [#1]
> > SMP
> > Modules linked in: ipv6 floppy ohci1394 ieee1394 parport_pc parport usbhid
> > ehci_hcd pata_acpi ff_memless sr_mod cdrom
> > CPU:1
> > EIP:0060:[]Not tainted VLI
> > EFLAGS: 00010046 (2.6.21-mm1 #272)
> > EIP is at insert_work+0x6d/0x71
> > eax: c1c3b3c0 ebx: c1814aa0 ecx: 0001 edx: c1814aa0
> > esi: c1c3b340 edi: 0282 ebp: c04d2f68 esp: c04d2f50
> > ds: 007b es: 007b fs: 00d8 gs: ss: 0068
> > Process swapper (pid: 0, ti=c04d2000 task=c1c26030 task.ti=c1c2)
> > Stack: c4685f54 c18148ac c04d2f98 c013816f c1c3b340 c1814aa0 c04d2f88
> > c013256c
> >0066 c1814880 c1c5e000 c04d2fc4 c01325a1
> > c1c5e000 0100 c012ba35 c04d2fb8 c01333f4 Call Trace:
> > [] [] show_stack_log_lvl+0xa5/0xca
> > show_registers+0x1e2/0x2da
> > [] [] do_trap+0x84/0xaa
> > do_invalid_op+0x88/0x92
> > [] [] __queue_work+0x22/0x33
> > delayed_work_timer_fn+0x24/0x2a
> > [] [] __do_softirq+0x75/0xe6
> > do_softirq+0x63/0xac
> > [] [] smp_apic_timer_interrupt+0x5c/0x88
> > apic_timer_interrupt+0x28/0x30
queue_delayed_work().
Probably, cancel_delayed_work(_work->work) was called with the ->timer
pending. This is wrong, cancel_delayed_work() clears _PENDING unconditionally,
that is why the comment says
it is expected that, prior to calling cancel_work_sync(), the caller has
arranged for the work to not be requeued.
(Just in case, after make-cancel_rearming_delayed_work-reliable.patch this is
still
wrong (as documented) to do cancel_delayed_work() before
cancel_delayed_timer(),
but should work correctly).
ata_port_flush_task() and ata_port_detach() do this, I sent the patch to fix
this
twice. The last one is
[PATCH -mm] libata-core: convert to use cancel_rearming_delayed_work()
http://marc.info/?l=linux-kernel=117840349108505
Jiri, any chance you can re-test with the patch below?
--- OLD/kernel/workqueue.c~ 2007-05-06 00:01:06.0 +0400
+++ OLD/kernel/workqueue.c 2007-05-08 14:50:39.0 +0400
@@ -103,7 +103,10 @@ static inline void set_wq_data(struct wo
{
unsigned long new;
- BUG_ON(!work_pending(work));
+ if (!work_pending(work)) {
+ printk(KERN_ERR "BUG: set_wq_data ");
+ print_symbol("%s\n", (unsigned long) work->func);
+ }
new = (unsigned long) cwq | (1UL << WORK_STRUCT_PENDING);
new |= WORK_STRUCT_FLAG_MASK & *work_data_bits(work);
-
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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:31:32PM -0700, William Lee Irwin III wrote:
>> I think Andi's handling the mergework on those patches, but I'll check
>> in to see if I should rediff vs. -mm or what if you want them.
>> Andi, what's the verdict on those stack patches?
On Tue, May 08, 2007 at 10:59:50AM +0200, Andi Kleen wrote:
> I planned to merge them partially. Add the separate 4/8/irqstack options,
> add the vmalloc support, but not support the > 8K stacks. Haven't yet.
I respun things to incorporate some of hch's suggestions and to fix
an issue Jeremy Fitzhardinge had with CPU hotplug, and some suggestion
from someone else, too.
Basically what changed was:
( 1) drop the large stack config option patch entirely
( 2) fold the __pa() check into the vmalloc stack patch under #ifdef
( 3) rename CONFIG_VMALLOC_STACK to CONFIG_DEBUG_STACK
( 4) fold guarding CPU 0's IRQ stack into the vmalloc stack patch
( 5) make IRQ stacks unconditional instead of independently configurable
( 6) check slab_is_available() for CPU 0's bootmem vs. get_free_pages()
( 7) mark various things __cpuinit that needed to be
( 8) handle and propagate allocation errors up to __cpu_up()
( 9) redo CPU 0's IRQ stack allocation to normalize it for hotplug
(10) use a struct for IRQ stack state instead of 3 per_cpu vars
The current patch series needs the two fixup patches at the end folded
back into the patches it fixes up, but follows in its entirety as a
series of MIME attachments. I've no idea what it applies against.
-- wli
Subject: dynamically allocate IRQ stacks
Dynamically allocate IRQ stacks in order to conserve memory when using
IRQ stacks. cpu_possible_map is not now initialized in such a manner as
to provide a meaningful indication of how many CPU's might be in the
system, and features to appear in the sequel also require indirection,
so they themselves are not allocatable as per_cpu variables, but rather
only pointers to them.
Signed-off-by: William Irwin <[EMAIL PROTECTED]>
Index: stack-paranoia/arch/i386/kernel/irq.c
===
--- stack-paranoia.orig/arch/i386/kernel/irq.c 2007-04-30 14:18:25.645682879 -0700
+++ stack-paranoia/arch/i386/kernel/irq.c 2007-05-01 10:19:38.028853928 -0700
@@ -17,9 +17,11 @@
#include
#include
#include
+#include
#include
#include
+#include
DEFINE_PER_CPU(irq_cpustat_t, irq_stat) cacheline_internodealigned_in_smp;
EXPORT_PER_CPU_SYMBOL(irq_stat);
@@ -56,8 +58,8 @@
u32 stack[THREAD_SIZE/sizeof(u32)];
};
-static union irq_ctx *hardirq_ctx[NR_CPUS] __read_mostly;
-static union irq_ctx *softirq_ctx[NR_CPUS] __read_mostly;
+static DEFINE_PER_CPU(union irq_ctx *, hardirq_ctx);
+static DEFINE_PER_CPU(union irq_ctx *, softirq_ctx);
#endif
/*
@@ -102,7 +104,7 @@
#ifdef CONFIG_4KSTACKS
curctx = (union irq_ctx *) current_thread_info();
- irqctx = hardirq_ctx[smp_processor_id()];
+ irqctx = per_cpu(hardirq_ctx, smp_processor_id());
/*
* this is where we switch to the IRQ stack. However, if we are
@@ -150,11 +152,24 @@
* These should really be __section__(".bss.page_aligned") as well, but
* gcc's 3.0 and earlier don't handle that correctly.
*/
-static char softirq_stack[NR_CPUS * THREAD_SIZE]
- __attribute__((__aligned__(THREAD_SIZE)));
+static DEFINE_PER_CPU(char *, softirq_stack);
+static DEFINE_PER_CPU(char *, hardirq_stack);
-static char hardirq_stack[NR_CPUS * THREAD_SIZE]
- __attribute__((__aligned__(THREAD_SIZE)));
+static void * __init __alloc_irqstack(int cpu)
+{
+ if (!slab_is_available())
+ return __alloc_bootmem(THREAD_SIZE, THREAD_SIZE,
+ __pa(MAX_DMA_ADDRESS));
+
+ return (void *)__get_free_pages(GFP_KERNEL,
+ ilog2(THREAD_SIZE/PAGE_SIZE));
+}
+
+static void __init alloc_irqstacks(int cpu)
+{
+ per_cpu(softirq_stack, cpu) = __alloc_irqstack(cpu);
+ per_cpu(hardirq_stack, cpu) = __alloc_irqstack(cpu);
+}
/*
* allocate per-cpu stacks for hardirq and for softirq processing
@@ -163,34 +178,36 @@
{
union irq_ctx *irqctx;
- if (hardirq_ctx[cpu])
+ if (per_cpu(hardirq_ctx, cpu))
return;
- irqctx = (union irq_ctx*) _stack[cpu*THREAD_SIZE];
+ alloc_irqstacks(cpu);
+
+ irqctx = (union irq_ctx*)per_cpu(hardirq_stack, cpu);
irqctx->tinfo.task = NULL;
irqctx->tinfo.exec_domain = NULL;
irqctx->tinfo.cpu = cpu;
irqctx->tinfo.preempt_count = HARDIRQ_OFFSET;
irqctx->tinfo.addr_limit= MAKE_MM_SEG(0);
- hardirq_ctx[cpu] = irqctx;
+ per_cpu(hardirq_ctx, cpu) = irqctx;
- irqctx = (union irq_ctx*) _stack[cpu*THREAD_SIZE];
+ irqctx = (union irq_ctx*)per_cpu(softirq_stack, cpu);
irqctx->tinfo.task = NULL;
irqctx->tinfo.exec_domain = NULL;
irqctx->tinfo.cpu = cpu;
irqctx->tinfo.preempt_count = 0;
irqctx->tinfo.addr_limit= MAKE_MM_SEG(0);
- softirq_ctx[cpu] = irqctx;
+ per_cpu(softirq_ctx, cpu) = irqctx;
printk("CPU %u irqstacks, hard=%p soft=%p\n",
-
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
On 08-05-2007 10:57, Jiri Slaby wrote: ... > [...] Perfectly reproducible, it simply happens each time I > try it. ...so, maybe, only subjectively reproducible? Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1+hotfix -- Slab corruption -- Last user: [](cryptomgr_probe+0x6c/0x9a)
On Mon, May 07, 2007 at 11:57:28AM -0700, Miles Lane wrote:
> [ 118.442018] ieee80211_crypt: registered algorithm 'WEP'
> [ 118.514572] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> [ 118.514664] Slab corruption: size-256 start=c6aabe98, len=256
> [ 118.514672] Redzone: 0x9f911029d74e35b/0x9f911029d74e35b.
> [ 118.514676] Last user: [](cryptomgr_probe+0x6c/0x9a)
> [ 118.514692] 000: 10 55 ac c6 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
> [ 118.514715] Prev obj: start=c6aabd80, len=256
> [ 118.514721] Redzone: 0xd84156c5635688c0/0xd84156c5635688c0.
> [ 118.514725] Last user: [](crypto_alloc_instance+0x1d/0xc0)
> [ 118.514734] 000: e0 71 39 c0 80 6e 39 c0 88 bd aa c6 88 bd aa c6
> [ 118.514753] 010: 04 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00
Oops. Does this patch fix the problem for you?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/crypto/cryptomgr.c b/crypto/cryptomgr.c
index 6958ea8..e5fb7cc 100644
--- a/crypto/cryptomgr.c
+++ b/crypto/cryptomgr.c
@@ -24,8 +24,6 @@
#include "internal.h"
struct cryptomgr_param {
- struct task_struct *thread;
-
struct rtattr *tb[CRYPTOA_MAX];
struct {
@@ -81,6 +79,7 @@ err:
static int cryptomgr_schedule_probe(struct crypto_larval *larval)
{
+ struct task_struct *thread;
struct cryptomgr_param *param;
const char *name = larval->alg.cra_name;
const char *p;
@@ -130,8 +129,8 @@ static int cryptomgr_schedule_probe(struct crypto_larval
*larval)
memcpy(param->larval.name, larval->alg.cra_name, CRYPTO_MAX_ALG_NAME);
- param->thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
- if (IS_ERR(param->thread))
+ thread = kthread_run(cryptomgr_probe, param, "cryptomgr");
+ if (IS_ERR(thread))
goto err_free_param;
return NOTIFY_STOP;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 -- x86 verify_cpu.S compile failure
We are seeing the following compile error on older x86 installs: arch/i386/kernel/verify_cpu.S: Assembler messages: arch/i386/kernel/verify_cpu.S:13: Error: `(%esp)' is not a valid 16 bit base/index expression Seems to come from: x86_64-mm-i386-verify-cpu Compiler: gcc version 3.3.4 (Debian 1:3.3.4-3) -apw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-mm1 hwsusp: BUG at workqueue.c:106
On Tue, 08 May 2007 10:57:35 +0200 Jiri Slaby <[EMAIL PROTECTED]> wrote: > > this occured in dmesg during resuming from hwsusp in 2.6.21-mm1 (captured > through netconsole). Perfectly reproducible, it simply happens each time I > try it. Let's cc Oleg. > usb_endpoint usbdev5.1_ep00: PM: resume from 0, parent usb5 still 2 > [ cut here ] > kernel BUG at /home/l/latest/xxx/kernel/workqueue.c:106! > invalid opcode: [#1] > SMP > Modules linked in: ipv6 floppy ohci1394 ieee1394 parport_pc parport usbhid > ehci_hcd pata_acpi ff_memless sr_mod cdrom > CPU:1 > EIP:0060:[] Not tainted VLI > EFLAGS: 00010046 (2.6.21-mm1 #272) > EIP is at insert_work+0x6d/0x71 > eax: c1c3b3c0 ebx: c1814aa0 ecx: 0001 edx: c1814aa0 > esi: c1c3b340 edi: 0282 ebp: c04d2f68 esp: c04d2f50 > ds: 007b es: 007b fs: 00d8 gs: ss: 0068 > Process swapper (pid: 0, ti=c04d2000 task=c1c26030 task.ti=c1c2) > Stack: c4685f54 c18148ac c04d2f98 c013816f c1c3b340 c1814aa0 c04d2f88 c013256c >0066 c1814880 c1c5e000 c04d2fc4 c01325a1 > c1c5e000 0100 c012ba35 c04d2fb8 c01333f4 Call Trace: > [] [] show_stack_log_lvl+0xa5/0xca > show_registers+0x1e2/0x2da > [] [] do_trap+0x84/0xaa > do_invalid_op+0x88/0x92 > [] [] __queue_work+0x22/0x33 > delayed_work_timer_fn+0x24/0x2a > [] [] __do_softirq+0x75/0xe6 > do_softirq+0x63/0xac > [] [] smp_apic_timer_interrupt+0x5c/0x88 > apic_timer_interrupt+0x28/0x30 > [] [] start_secondary+0x25e/0x37a > 0x0 > === > 00 00 ba 03 00 00 40 a3 ff 83 10 5b 5d c3 4e 04 56 04 43 04 42 04 53 04 48 > 04 46 04 c9 <0f> eb fe 89 e5 ec 0c > hm, how come it's so messy? - 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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:31:32PM -0700, William Lee Irwin III wrote: > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> > wrote: > >> I'm using wli's 8k > >> stack + irq stack patches with good success though. > > On Mon, May 07, 2007 at 10:24:09PM -0700, Andrew Morton wrote: > > wlis are handy. > > I think Andi's handling the mergework on those patches, but I'll check > in to see if I should rediff vs. -mm or what if you want them. > > Andi, what's the verdict on those stack patches? I planned to merge them partially. Add the separate 4/8/irqstack options, add the vmalloc support, but not support the > 8K stacks. Haven't yet. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.21-mm1 hwsusp: BUG at workqueue.c:106
Hi, this occured in dmesg during resuming from hwsusp in 2.6.21-mm1 (captured through netconsole). Perfectly reproducible, it simply happens each time I try it. usb_endpoint usbdev5.1_ep00: PM: resume from 0, parent usb5 still 2 [ cut here ] kernel BUG at /home/l/latest/xxx/kernel/workqueue.c:106! invalid opcode: [#1] SMP Modules linked in: ipv6 floppy ohci1394 ieee1394 parport_pc parport usbhid ehci_hcd pata_acpi ff_memless sr_mod cdrom CPU:1 EIP:0060:[]Not tainted VLI EFLAGS: 00010046 (2.6.21-mm1 #272) EIP is at insert_work+0x6d/0x71 eax: c1c3b3c0 ebx: c1814aa0 ecx: 0001 edx: c1814aa0 esi: c1c3b340 edi: 0282 ebp: c04d2f68 esp: c04d2f50 ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process swapper (pid: 0, ti=c04d2000 task=c1c26030 task.ti=c1c2) Stack: c4685f54 c18148ac c04d2f98 c013816f c1c3b340 c1814aa0 c04d2f88 c013256c 0066 c1814880 c1c5e000 c04d2fc4 c01325a1 c1c5e000 0100 c012ba35 c04d2fb8 c01333f4 Call Trace: [] [] show_stack_log_lvl+0xa5/0xca show_registers+0x1e2/0x2da [] [] do_trap+0x84/0xaa do_invalid_op+0x88/0x92 [] [] __queue_work+0x22/0x33 delayed_work_timer_fn+0x24/0x2a [] [] __do_softirq+0x75/0xe6 do_softirq+0x63/0xac [] [] smp_apic_timer_interrupt+0x5c/0x88 apic_timer_interrupt+0x28/0x30 [] [] start_secondary+0x25e/0x37a 0x0 === 00 00 ba 03 00 00 40 a3 ff 83 10 5b 5d c3 4e 04 56 04 43 04 42 04 53 04 48 04 46 04 c9 <0f> eb fe 89 e5 ec 0c regards, -- http://www.fi.muni.cz/~xslaby/Jiri Slaby faculty of informatics, masaryk university, brno, cz e-mail: jirislaby gmail com, gpg pubkey fingerprint: B674 9967 0407 CE62 ACC8 22A0 32CC 55C3 39D4 7A7E - 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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On May 8 2007 16:18, David Chinner wrote: > >On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote: >> Andrew Morton wrote: >> > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> >> > wrote: >> > >> >> I've found that XFS+lvm+4k stacks is completely unusable with current >> >> kernels. I get hangs/oopes after ~10mins of work. >> > >> > Sounds like this is new behaviour? >> > I wonder why. Same compiler version? >> >> I've only recently started using xfs, so I couldn't say if its new >> behaviour. I did notice that it took a week or so for problems to set >> in; my theory is that as the filesystem got a bit aged, its >> datastructures got a bit more complex, and cause the kernel code to use >> more stack. But that's just a guess. FWIW, I run dm-crypt+xfs on one machine, of course with 8k since that's suse default. No issues. dm-crypt and lvm got something in common, don't they? Jan -- - 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] drivers/macintosh: remove default y from Kconfig (was: Re: 2.6.21-mm1)
On May 7 2007 12:35, Borislav Petkov wrote: > >I don't think I need macintosh drivers for my x86 arch selected in by default, > do I? For new config variables that were introduced, I set them to 'default y' so when upgrading from an older .config, it does not deselect the drivers _inside_ the new menuconfig. People who have CONFIG_MAC_EMUMOUSEBTN=y will magically get it set to =n because MACINTOSH_DRIVERS is not y. Whether you need macintosh on i386... oh well, ask someone who knows. Fact is, that at least SUSE has CONFIG_MAC_EMUMOUSEBTN=y but I wonder wtf for. >Index: trees/linux-mm/drivers/macintosh/Kconfig >=== >--- linux-mm.orig/drivers/macintosh/Kconfig >+++ linux-mm/drivers/macintosh/Kconfig >@@ -2,7 +2,6 @@ > menuconfig MACINTOSH_DRIVERS > bool "Macintosh device drivers" > depends on PPC || MAC || X86 >- default y How about default y if PPC || MAC then? Jan -- - 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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote: > Andrew Morton wrote: > > On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]> > > wrote: > > > >> I've found that XFS+lvm+4k stacks is completely unusable with current > >> kernels. I get hangs/oopes after ~10mins of work. > >> > > > > Sounds like this is new behaviour? > > > > I wonder why. Same compiler version? > > I've only recently started using xfs, so I couldn't say if its new > behaviour. I did notice that it took a week or so for problems to set > in; my theory is that as the filesystem got a bit aged, its > datastructures got a bit more complex, and cause the kernel code to use > more stack. But that's just a guess. The worst case stack usage through XFS occurs when it has to read metadata blocks in the writeback path when doing an allocation transaction. This happens when walking the freespace btrees looking for an extent matching the allocation requirements. As the fileystem fills up, these btrees will grow and you are more likely not to have a block inthe btree cached in memory. So yes, this is a possible reason you hadn't seen any problems early on. FWIW, there's also been recent reports of both ext3 and reiser on LVM blowing 4k stacks, so if you use LVM it probably advisable to go back to 8k stacks Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> I think Andi's handling the mergework on those patches, but I'll check >> in to see if I should rediff vs. -mm or what if you want them. >> Andi, what's the verdict on those stack patches? On Mon, May 07, 2007 at 10:37:38PM -0700, Andrew Morton wrote: > Whoa. The verdict is usually "don't use so much stack". > Do we know what has gone wrong here? > Last week Jens said he was picking up the ancient > md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't > seem to have done so yet. > XFS is frequently implicated. Well, the culmination of those patches is a patch to use vmallocspace to establish guard pages for stacks so overflows are immediately trapped and the potential for silent corruption greatly reduced. That would be where I suspect it's most relevant, as that's the focal point of the series. The bit about unconditional IRQ stacks arose as part of review. It started life as a set of patches intended to help with debugging stack overflows, which is how the only tangentially-related unconditional IRQ stacks came about: originally they were optional as a debug option for differential diagnosis of interrupt-time overflows. For mainline, hch suggested that they should rather be made unconditional. The third part of the series that survived review was dynamic boot-time allocation of IRQ stacks, which was originally motivated by the need for indirection when remapping IRQ stacks into vmallocspace, but also served the purpose of mitigating space overhead when using IRQ stacks because cpu_possible_map is not set up as it should be to avoid the allocation via per_cpu array variables' dynamic boot-time allocation on i386 and (AFAIK) x86-64. -- wli - 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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, 7 May 2007 22:31:32 -0700 William Lee Irwin III [EMAIL PROTECTED] wrote: I think Andi's handling the mergework on those patches, but I'll check in to see if I should rediff vs. -mm or what if you want them. Andi, what's the verdict on those stack patches? On Mon, May 07, 2007 at 10:37:38PM -0700, Andrew Morton wrote: Whoa. The verdict is usually don't use so much stack. Do we know what has gone wrong here? Last week Jens said he was picking up the ancient md-dm-reduce-stack-usage-with-stacked-block-devices.patch, but he doesn't seem to have done so yet. XFS is frequently implicated. Well, the culmination of those patches is a patch to use vmallocspace to establish guard pages for stacks so overflows are immediately trapped and the potential for silent corruption greatly reduced. That would be where I suspect it's most relevant, as that's the focal point of the series. The bit about unconditional IRQ stacks arose as part of review. It started life as a set of patches intended to help with debugging stack overflows, which is how the only tangentially-related unconditional IRQ stacks came about: originally they were optional as a debug option for differential diagnosis of interrupt-time overflows. For mainline, hch suggested that they should rather be made unconditional. The third part of the series that survived review was dynamic boot-time allocation of IRQ stacks, which was originally motivated by the need for indirection when remapping IRQ stacks into vmallocspace, but also served the purpose of mitigating space overhead when using IRQ stacks because cpu_possible_map is not set up as it should be to avoid the allocation via per_cpu array variables' dynamic boot-time allocation on i386 and (AFAIK) x86-64. -- wli - 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: sleeping function called from invalid context at block/cfq-iosched.c (Was: Re: 2.6.21-mm1)
On Mon, May 07, 2007 at 10:38:24PM -0700, Jeremy Fitzhardinge wrote: Andrew Morton wrote: On Mon, 07 May 2007 21:31:06 -0700 Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: I've found that XFS+lvm+4k stacks is completely unusable with current kernels. I get hangs/oopes after ~10mins of work. Sounds like this is new behaviour? I wonder why. Same compiler version? I've only recently started using xfs, so I couldn't say if its new behaviour. I did notice that it took a week or so for problems to set in; my theory is that as the filesystem got a bit aged, its datastructures got a bit more complex, and cause the kernel code to use more stack. But that's just a guess. The worst case stack usage through XFS occurs when it has to read metadata blocks in the writeback path when doing an allocation transaction. This happens when walking the freespace btrees looking for an extent matching the allocation requirements. As the fileystem fills up, these btrees will grow and you are more likely not to have a block inthe btree cached in memory. So yes, this is a possible reason you hadn't seen any problems early on. FWIW, there's also been recent reports of both ext3 and reiser on LVM blowing 4k stacks, so if you use LVM it probably advisable to go back to 8k stacks Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - 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/
