AW: More E820 brokenness
Hello all, I won't be able to test anything before next Tuesday, but I'm with Jordan on this one. Have a look at the dmsg output I sent you some time ago (http://article.gmane.org/gmane.linux.kernel/584681). This was as plain from Linus' tree as you get it (git bisect, make defconfig, make) and I see: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1e7b (usable) BIOS-e820: 1e7b - 1e7bffc0 (ACPI data) BIOS-e820: 1e7bffc0 - 1e7c (ACPI NVS) BIOS-e820: 4040 - 40440004 (reserved) BIOS-e820: f000 - 0001 (reserved) -- Kind regards Joerg - Ursprüngliche Mail Von: Jordan Crouse <[EMAIL PROTECTED]> An: H. Peter Anvin <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED]; Joerg Pommnitz <[EMAIL PROTECTED]>; Chuck Ebbert <[EMAIL PROTECTED]>; Linux Kernel Mailing List ; Andi Kleen <[EMAIL PROTECTED]> Gesendet: Freitag, den 28. September 2007, 01:15:52 Uhr Betreff: Re: More E820 brokenness On 27/09/07 15:47 -0700, H. Peter Anvin wrote: > Jordan Crouse wrote: > > > > Breaks on the Geode - original behavior. > > > > I think that having boot_prams.e820_entries != 0 makes the kernel > > assume the e820 data is correct. > > > > Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode, > because this, to the best of my reading, mimics the 2.6.22 behavior > exactly. DID IT REALLY, and/or did you make any kind of configuration > changes? I copied in a 2.6.22 kernel to see that it really did work, and it did. But here's the crazy part - I did a dmesg, and it looks like it *is* using e820 data, and it looks complete (I see the entire map - including the ACPI and reserved blocks way up high). So apparently it was the 2.6.22 code that was buggy, but reading it, I don't immediately see how. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. __ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever - 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/
AW: More E820 brokenness
Hello all, I won't be able to test anything before next Tuesday, but I'm with Jordan on this one. Have a look at the dmsg output I sent you some time ago (http://article.gmane.org/gmane.linux.kernel/584681). This was as plain from Linus' tree as you get it (git bisect, make defconfig, make) and I see: BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1e7b (usable) BIOS-e820: 1e7b - 1e7bffc0 (ACPI data) BIOS-e820: 1e7bffc0 - 1e7c (ACPI NVS) BIOS-e820: 4040 - 40440004 (reserved) BIOS-e820: f000 - 0001 (reserved) -- Kind regards Joerg - Ursprüngliche Mail Von: Jordan Crouse [EMAIL PROTECTED] An: H. Peter Anvin [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; Joerg Pommnitz [EMAIL PROTECTED]; Chuck Ebbert [EMAIL PROTECTED]; Linux Kernel Mailing List linux-kernel@vger.kernel.org; Andi Kleen [EMAIL PROTECTED] Gesendet: Freitag, den 28. September 2007, 01:15:52 Uhr Betreff: Re: More E820 brokenness On 27/09/07 15:47 -0700, H. Peter Anvin wrote: Jordan Crouse wrote: Breaks on the Geode - original behavior. I think that having boot_prams.e820_entries != 0 makes the kernel assume the e820 data is correct. Okay, now I'm utterly baffled how 2.6.22 ever worked on this Geode, because this, to the best of my reading, mimics the 2.6.22 behavior exactly. DID IT REALLY, and/or did you make any kind of configuration changes? I copied in a 2.6.22 kernel to see that it really did work, and it did. But here's the crazy part - I did a dmesg, and it looks like it *is* using e820 data, and it looks complete (I see the entire map - including the ACPI and reserved blocks way up high). So apparently it was the 2.6.22 code that was buggy, but reading it, I don't immediately see how. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. __ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever - 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: [GIT PULL] Workaround for broken Geode E820 BIOS
I just tried 2.6.23-rc8 with the patch applied. Works fine here, so my very
first
Acked-by: Joerg Pommnitz <[EMAIL PROTECTED]>
for whatever it's worth, since it is already in Linus' tree.
Thanks to Peter and Jordan for taking the interest and time to track
this one down and fix it.
--
Regards
Joerg
- Ursprüngliche Mail
Von: H. Peter Anvin <[EMAIL PROTECTED]>
An: Linus Torvalds <[EMAIL PROTECTED]>
CC: Linux Kernel Mailing List ; Jordan Crouse
<[EMAIL PROTECTED]>; Joerg Pommnitz <[EMAIL PROTECTED]>
Gesendet: Donnerstag, den 27. September 2007, 00:27:20 Uhr
Betreff: [GIT PULL] Workaround for broken Geode E820 BIOS
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (1):
[x86 setup] Handle case of improperly terminated E820 chain
arch/i386/boot/memory.c | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
[Log messages and full diffs follow]
commit 2efa33f81ef56e7700c09a3d8a881c96692149e5
Author: H. Peter Anvin <[EMAIL PROTECTED]>
Date: Wed Sep 26 14:11:43 2007 -0700
[x86 setup] Handle case of improperly terminated E820 chain
At least one system (a Geode system with a Digital Logic BIOS) has
been found which suddenly stops reporting the SMAP signature when
reading the E820 memory chain. We can't know what, exactly, broke in
the BIOS, so if we detect this situation, declare the E820 data
unusable and fall back to E801.
Also, revert to original behavior of always probing all memory
methods; that way all the memory information is available to the
kernel.
Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]>
Cc: Jordan Crouse <[EMAIL PROTECTED]>
Cc: Joerg Pommnitz <[EMAIL PROTECTED]>
diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index 1a2e62d..bccaa1c 100644
--- a/arch/i386/boot/memory.c
+++ b/arch/i386/boot/memory.c
@@ -20,6 +20,7 @@
static int detect_memory_e820(void)
{
+int count = 0;
u32 next = 0;
u32 size, id;
u8 err;
@@ -33,14 +34,24 @@ static int detect_memory_e820(void)
"=m" (*desc)
: "D" (desc), "a" (0xe820));
-if (err || id != SMAP)
+/* Some BIOSes stop returning SMAP in the middle of
+ the search loop. We don't know exactly how the BIOS
+ screwed up the map at that point, we might have a
+ partial map, the full map, or complete garbage, so
+ just return failure. */
+if (id != SMAP) {
+count = 0;
break;
+}
-boot_params.e820_entries++;
+if (err)
+break;
+
+count++;
desc++;
-} while (next && boot_params.e820_entries < E820MAX);
+} while (next && count < E820MAX);
-return boot_params.e820_entries;
+return boot_params.e820_entries = count;
}
static int detect_memory_e801(void)
@@ -89,11 +100,16 @@ static int detect_memory_88(void)
int detect_memory(void)
{
+int err = -1;
+
if (detect_memory_e820() > 0)
-return 0;
+err = 0;
if (!detect_memory_e801())
-return 0;
+err = 0;
+
+if (!detect_memory_88())
+err = 0;
-return detect_memory_88();
+return err;
}
Die etwas anderen Infos rund um das Thema Reisen. BE A BETTER
WELTENBUMMLER! www.yahoo.de/clever
-
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: [GIT PULL] Workaround for broken Geode E820 BIOS
I just tried 2.6.23-rc8 with the patch applied. Works fine here, so my very
first
Acked-by: Joerg Pommnitz [EMAIL PROTECTED]
for whatever it's worth, since it is already in Linus' tree.
Thanks to Peter and Jordan for taking the interest and time to track
this one down and fix it.
--
Regards
Joerg
- Ursprüngliche Mail
Von: H. Peter Anvin [EMAIL PROTECTED]
An: Linus Torvalds [EMAIL PROTECTED]
CC: Linux Kernel Mailing List linux-kernel@vger.kernel.org; Jordan Crouse
[EMAIL PROTECTED]; Joerg Pommnitz [EMAIL PROTECTED]
Gesendet: Donnerstag, den 27. September 2007, 00:27:20 Uhr
Betreff: [GIT PULL] Workaround for broken Geode E820 BIOS
Hi Linus,
Please pull:
git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
for-linus
H. Peter Anvin (1):
[x86 setup] Handle case of improperly terminated E820 chain
arch/i386/boot/memory.c | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
[Log messages and full diffs follow]
commit 2efa33f81ef56e7700c09a3d8a881c96692149e5
Author: H. Peter Anvin [EMAIL PROTECTED]
Date: Wed Sep 26 14:11:43 2007 -0700
[x86 setup] Handle case of improperly terminated E820 chain
At least one system (a Geode system with a Digital Logic BIOS) has
been found which suddenly stops reporting the SMAP signature when
reading the E820 memory chain. We can't know what, exactly, broke in
the BIOS, so if we detect this situation, declare the E820 data
unusable and fall back to E801.
Also, revert to original behavior of always probing all memory
methods; that way all the memory information is available to the
kernel.
Signed-off-by: H. Peter Anvin [EMAIL PROTECTED]
Cc: Jordan Crouse [EMAIL PROTECTED]
Cc: Joerg Pommnitz [EMAIL PROTECTED]
diff --git a/arch/i386/boot/memory.c b/arch/i386/boot/memory.c
index 1a2e62d..bccaa1c 100644
--- a/arch/i386/boot/memory.c
+++ b/arch/i386/boot/memory.c
@@ -20,6 +20,7 @@
static int detect_memory_e820(void)
{
+int count = 0;
u32 next = 0;
u32 size, id;
u8 err;
@@ -33,14 +34,24 @@ static int detect_memory_e820(void)
=m (*desc)
: D (desc), a (0xe820));
-if (err || id != SMAP)
+/* Some BIOSes stop returning SMAP in the middle of
+ the search loop. We don't know exactly how the BIOS
+ screwed up the map at that point, we might have a
+ partial map, the full map, or complete garbage, so
+ just return failure. */
+if (id != SMAP) {
+count = 0;
break;
+}
-boot_params.e820_entries++;
+if (err)
+break;
+
+count++;
desc++;
-} while (next boot_params.e820_entries E820MAX);
+} while (next count E820MAX);
-return boot_params.e820_entries;
+return boot_params.e820_entries = count;
}
static int detect_memory_e801(void)
@@ -89,11 +100,16 @@ static int detect_memory_88(void)
int detect_memory(void)
{
+int err = -1;
+
if (detect_memory_e820() 0)
-return 0;
+err = 0;
if (!detect_memory_e801())
-return 0;
+err = 0;
+
+if (!detect_memory_88())
+err = 0;
-return detect_memory_88();
+return err;
}
Die etwas anderen Infos rund um das Thema Reisen. BE A BETTER
WELTENBUMMLER! www.yahoo.de/clever
-
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.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800
> There is something very fishy.
>
> The only documentation you've given us so far is a screen shot which
> contained a message ("BIOS data check successful") which doesn't occur
> in the kernel.
>
> The loader string doesn't look all that familiar either; it looks like
> an extremely old version of SYSLINUX, but that doesn't contain that
> message either.
The boot loader is LILO from Ubuntu 7.04, so it should be fairly recent.
> INT 6 is #UD, the undefined instruction exception. This is consistent with:
>
> > Its hitting a bug - specifically (from bootmem.c:125):
> > BUG_ON(PFN_DOWN(addr) >= bdata->node_low_pfn);
>
> However, all that tells us is that reserve_bootmem_core() was either
> called with a bad address or bdata->node_low_pfn is garbage. In
> particular, without knowing how it got there it's hard to know for sure.
>
> Could you send me the boot messages from a working kernel boot?
Attached is a boot log I get where the last patch is
f2d98ae63dc64dedb00499289e13a50677f771f9, e.g. "Linker script for the
new x86 setup code".
The kernel is directly from "git bisect, make defconfig, make", no local
changes or strange patches applied. Build environment is plain Ubuntu-7.04.
--
Kind regards
Joerg
__
Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN!
www.yahoo.de/cleverLinux version 2.6.22-gf2d98ae6 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu
4.1.2-0ubuntu4)) #12 SMP Wed Sep 26 12:45:21 CEST 2007
BIOS-provided physical RAM map:
BIOS-e820: - 0009fc00 (usable)
BIOS-e820: 0009fc00 - 000a (reserved)
BIOS-e820: 000e - 0010 (reserved)
BIOS-e820: 0010 - 1e7b (usable)
BIOS-e820: 1e7b - 1e7bffc0 (ACPI data)
BIOS-e820: 1e7bffc0 - 1e7c (ACPI NVS)
BIOS-e820: 4040 - 40440004 (reserved)
BIOS-e820: f000 - 0001 (reserved)
0MB HIGHMEM available.
487MB LOWMEM available.
Entering add_active_range(0, 0, 124848) 0 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 124848
HighMem124848 -> 124848
early_node_map[1] active PFN ranges
0:0 -> 124848
On node 0 totalpages: 124848
DMA zone: 32 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4064 pages, LIFO batch:0
Normal zone: 943 pages used for memmap
Normal zone: 119809 pages, LIFO batch:31
HighMem zone: 0 pages used for memmap
DMI not present or invalid.
Using APIC driver default
ACPI: RSDP 000E9010, 0014 (r0 OID_00)
ACPI: RSDT 1E7B2AE0, 0030 (r1 AMDRSDT_000 31303030 AMD 31303030)
ACPI: FACP 1E7B29E0, 0084 (r1 AMDFACP_000 31303030 AMD 31303030)
ACPI: DSDT 1E7B, 29D6 (r1 INSYDE CS553x 1007 INTL 20030122)
ACPI: FACS 1E7BFFC0, 0040
ACPI: BOOT 1E7B2A70, 0028 (r1 AMDBOOT_000 31303030 AMD 31303030)
ACPI: DBGP 1E7B2AA0, 0034 (r1 AMDDBGP_000 31303030 AMD 31303030)
ACPI: no DMI BIOS year, acpi=force is required to enable ACPI
ACPI: Disabling ACPI support
Allocating PCI resources starting at 5000 (gap: 40440004:afbbfffc)
Built 1 zonelists. Total pages: 123873
Kernel command line: BOOT_IMAGE=Linux2623 ro root=341
No local APIC present or hardware disabled
mapped APIC to d000 (013dc000)
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 498.434 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 488944k/499392k available (3041k kernel code, 9872k reserved, 1517k
data, 292k init, 0k highmem)
virtual kernel memory layout:
fixmap : 0xffe16000 - 0xf000 (1956 kB)
pkmap : 0xff80 - 0xffc0 (4096 kB)
vmalloc : 0xdf00 - 0xff7fe000 ( 519 MB)
lowmem : 0xc000 - 0xde7b ( 487 MB)
.init : 0xc057b000 - 0xc05c4000 ( 292 kB)
.data : 0xc03f86e0 - 0xc0573ecc (1517 kB)
.text : 0xc010 - 0xc03f86e0 (3041 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 998.38 BogoMIPS (lpj=1996769)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0088a93d c0c0a13d
CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line)
CPU: L2 Cache: 128K (32 bytes/line)
CPU: After all inits, caps: 0088a93d c0c0a13d
Compat vDSO mapped to e000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 18k freed
CPU0: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
Brought up 1 CPUs
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10
Regression in 2.6.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800
Hello all, this is what git bisect told me about the problem: [EMAIL PROTECTED]:~/linux-2.6$ git bisect good 4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit commit 4fd06960f120e02e9abc802a09f9511c400042a5 Author: H. Peter Anvin <[EMAIL PROTECTED]> Date: Wed Jul 11 12:18:56 2007 -0700 Use the new x86 setup code for i386 This patch hooks the new x86 setup code into the Makefile machinery. It also adapts boot/tools/build.c to a two-file (as opposed to three-file) universe, and simplifies it substantially. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> :04 04 6560eb5b7e40d93813276544bced8c478f9067f5 fe5f90d9ca08e526559815789175602ba2c51743 M arch -- Regards Joerg - Ursprüngliche Mail Von: Jordan Crouse <[EMAIL PROTECTED]> An: Joerg Pommnitz <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Gesendet: Dienstag, den 25. September 2007, 17:04:52 Uhr Betreff: Re: Problems with 2.6.23-rc6 on AMD Geode LX800 On 25/09/07 01:38 -0700, Joerg Pommnitz wrote: > Chuck, Jordan, > thanks for taking an interest in this problem. As suggested by Jordan I tried > a new > BIOS revision from > http://www.digitallogic.ch/index.php?id=256=/MSEP800%20-%20SM800PCX%20%20-%20MPC20%20-%20MPC21=23 > > Unfortunately the kernel still fails to boot in the same way. You'll have to contact Digital Logic and have them check with the BIOS vendor to see if the fix was made in that version or not. I don't have that particular board, so I can't try out the fixes here. I'm still trying to track down the particulars of the fix from the BIOS vendor. I'll let you know. > Do you still need the disassembled reserve_bootmem_core? Sure - you might as well - just to make sure its the same problem. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. __ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever - 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.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800
Hello all, this is what git bisect told me about the problem: [EMAIL PROTECTED]:~/linux-2.6$ git bisect good 4fd06960f120e02e9abc802a09f9511c400042a5 is first bad commit commit 4fd06960f120e02e9abc802a09f9511c400042a5 Author: H. Peter Anvin [EMAIL PROTECTED] Date: Wed Jul 11 12:18:56 2007 -0700 Use the new x86 setup code for i386 This patch hooks the new x86 setup code into the Makefile machinery. It also adapts boot/tools/build.c to a two-file (as opposed to three-file) universe, and simplifies it substantially. Signed-off-by: H. Peter Anvin [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] :04 04 6560eb5b7e40d93813276544bced8c478f9067f5 fe5f90d9ca08e526559815789175602ba2c51743 M arch -- Regards Joerg - Ursprüngliche Mail Von: Jordan Crouse [EMAIL PROTECTED] An: Joerg Pommnitz [EMAIL PROTECTED] CC: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org Gesendet: Dienstag, den 25. September 2007, 17:04:52 Uhr Betreff: Re: Problems with 2.6.23-rc6 on AMD Geode LX800 On 25/09/07 01:38 -0700, Joerg Pommnitz wrote: Chuck, Jordan, thanks for taking an interest in this problem. As suggested by Jordan I tried a new BIOS revision from http://www.digitallogic.ch/index.php?id=256dir=/MSEP800%20-%20SM800PCX%20%20-%20MPC20%20-%20MPC21mountpoint=23 Unfortunately the kernel still fails to boot in the same way. You'll have to contact Digital Logic and have them check with the BIOS vendor to see if the fix was made in that version or not. I don't have that particular board, so I can't try out the fixes here. I'm still trying to track down the particulars of the fix from the BIOS vendor. I'll let you know. Do you still need the disassembled reserve_bootmem_core? Sure - you might as well - just to make sure its the same problem. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. __ Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen. www.yahoo.de/clever - 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.23-pre Was: Problems with 2.6.23-rc6 on AMD Geode LX800
There is something very fishy. The only documentation you've given us so far is a screen shot which contained a message (BIOS data check successful) which doesn't occur in the kernel. The loader string doesn't look all that familiar either; it looks like an extremely old version of SYSLINUX, but that doesn't contain that message either. The boot loader is LILO from Ubuntu 7.04, so it should be fairly recent. INT 6 is #UD, the undefined instruction exception. This is consistent with: Its hitting a bug - specifically (from bootmem.c:125): BUG_ON(PFN_DOWN(addr) = bdata-node_low_pfn); However, all that tells us is that reserve_bootmem_core() was either called with a bad address or bdata-node_low_pfn is garbage. In particular, without knowing how it got there it's hard to know for sure. Could you send me the boot messages from a working kernel boot? Attached is a boot log I get where the last patch is f2d98ae63dc64dedb00499289e13a50677f771f9, e.g. Linker script for the new x86 setup code. The kernel is directly from git bisect, make defconfig, make, no local changes or strange patches applied. Build environment is plain Ubuntu-7.04. -- Kind regards Joerg __ Alles was der Gesundheit und Entspannung dient. BE A BETTER MEDIZINMANN! www.yahoo.de/cleverLinux version 2.6.22-gf2d98ae6 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #12 SMP Wed Sep 26 12:45:21 CEST 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 1e7b (usable) BIOS-e820: 1e7b - 1e7bffc0 (ACPI data) BIOS-e820: 1e7bffc0 - 1e7c (ACPI NVS) BIOS-e820: 4040 - 40440004 (reserved) BIOS-e820: f000 - 0001 (reserved) 0MB HIGHMEM available. 487MB LOWMEM available. Entering add_active_range(0, 0, 124848) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 124848 HighMem124848 - 124848 early_node_map[1] active PFN ranges 0:0 - 124848 On node 0 totalpages: 124848 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 943 pages used for memmap Normal zone: 119809 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap DMI not present or invalid. Using APIC driver default ACPI: RSDP 000E9010, 0014 (r0 OID_00) ACPI: RSDT 1E7B2AE0, 0030 (r1 AMDRSDT_000 31303030 AMD 31303030) ACPI: FACP 1E7B29E0, 0084 (r1 AMDFACP_000 31303030 AMD 31303030) ACPI: DSDT 1E7B, 29D6 (r1 INSYDE CS553x 1007 INTL 20030122) ACPI: FACS 1E7BFFC0, 0040 ACPI: BOOT 1E7B2A70, 0028 (r1 AMDBOOT_000 31303030 AMD 31303030) ACPI: DBGP 1E7B2AA0, 0034 (r1 AMDDBGP_000 31303030 AMD 31303030) ACPI: no DMI BIOS year, acpi=force is required to enable ACPI ACPI: Disabling ACPI support Allocating PCI resources starting at 5000 (gap: 40440004:afbbfffc) Built 1 zonelists. Total pages: 123873 Kernel command line: BOOT_IMAGE=Linux2623 ro root=341 No local APIC present or hardware disabled mapped APIC to d000 (013dc000) Initializing CPU#0 PID hash table entries: 2048 (order: 11, 8192 bytes) Detected 498.434 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 488944k/499392k available (3041k kernel code, 9872k reserved, 1517k data, 292k init, 0k highmem) virtual kernel memory layout: fixmap : 0xffe16000 - 0xf000 (1956 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xdf00 - 0xff7fe000 ( 519 MB) lowmem : 0xc000 - 0xde7b ( 487 MB) .init : 0xc057b000 - 0xc05c4000 ( 292 kB) .data : 0xc03f86e0 - 0xc0573ecc (1517 kB) .text : 0xc010 - 0xc03f86e0 (3041 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 998.38 BogoMIPS (lpj=1996769) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0088a93d c0c0a13d CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 128K (32 bytes/line) CPU: After all inits, caps: 0088a93d c0c0a13d Compat vDSO mapped to e000. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 18k freed CPU0: AMD Geode(TM) Integrated Processor by AMD PCS stepping 02 SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. Brought up 1 CPUs NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xff8b7, last bus=0 PCI:
RE: Problems with 2.6.23-rc6 on AMD Geode LX800
Chuck, Jordan, thanks for taking an interest in this problem. As suggested by Jordan I tried a new BIOS revision from http://www.digitallogic.ch/index.php?id=256=/MSEP800%20-%20SM800PCX%20%20-%20MPC20%20-%20MPC21=23 Unfortunately the kernel still fails to boot in the same way. Do you still need the disassembled reserve_bootmem_core? -- Thanks and kind regards Joerg Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever - 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: Problems with 2.6.23-rc6 on AMD Geode LX800
Chuck, Jordan, thanks for taking an interest in this problem. As suggested by Jordan I tried a new BIOS revision from http://www.digitallogic.ch/index.php?id=256dir=/MSEP800%20-%20SM800PCX%20%20-%20MPC20%20-%20MPC21mountpoint=23 Unfortunately the kernel still fails to boot in the same way. Do you still need the disassembled reserve_bootmem_core? -- Thanks and kind regards Joerg Yahoo! Clever: Stellen Sie Fragen und finden Sie Antworten. Teilen Sie Ihr Wissen. www.yahoo.de/clever - 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/
Stable identification of identical USB hardware
Hello all,
I want to be able to distinguish between two (or more) mostly identical USB
serial devices. The devices in question are UMTS modems. AFAIK they are
identical except for the SIM card and the point of attachment. Externally the
cards are CardBus devices with an integrated USB host adapter. The actual UMTS
device is (internally) connected to the USB host adapter.
If I have to cardbus sockets, how do I get from what I know ("the card is in
socket 0") to "I have to talk to ttyUSB2 to talk to the card"? I suspect I have
to follow the thread from /sys/bus/pci to /sys/bus/usb/devices, but how exactly?
Thanks in advance and kind regards
Joerg
__
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen
Massenmails.
http://mail.yahoo.com
-
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/
Stable identification of identical USB hardware
Hello all, I want to be able to distinguish between two (or more) mostly identical USB serial devices. The devices in question are UMTS modems. AFAIK they are identical except for the SIM card and the point of attachment. Externally the cards are CardBus devices with an integrated USB host adapter. The actual UMTS device is (internally) connected to the USB host adapter. If I have to cardbus sockets, how do I get from what I know (the card is in socket 0) to I have to talk to ttyUSB2 to talk to the card? I suspect I have to follow the thread from /sys/bus/pci to /sys/bus/usb/devices, but how exactly? Thanks in advance and kind regards Joerg __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-usb-users] 2.6 PCMCIA/USB question
I had hoped that one can figure things out from /proc and /sys. SHould'n there be a way to do this? And no, trial and error is not really an option. The devices in question are WCDMA/UMTS mobile data cards. They will differ only by the SIM card inserted by the user. The ICCID of the SIM is unknown during development and I would like to avoid to many configuration files. Regards Joerg --- Alan Stern <[EMAIL PROTECTED]> wrote: > On Fri, 15 Apr 2005, Joerg Pommnitz wrote: > > > Hello all, > > I have a question that I could not figure out from other sources. I > have > > the following hardware: an integrated CardBus USB host adapter with a > > connected USB serial device with three interfaces (normally > > ttyUSB0...ttyUSB2). Now I want to use 3 of these devices (remember: > they > > are integrated, so I can't just plug the USB device onto the same host > > adapter). I know device A is in CardBus slot 1, device B is in CardBus > > slot 2 and so on. > > > > Now the question: How do I figure out which ttyUSBx belongs to which > > device? > > You can look in the system log. If you want, you can actually control > which goes where by creating a udev configuration file. > > Alan Stern > > ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6 PCMCIA/USB question
Hello all, I have a question that I could not figure out from other sources. I have the following hardware: an integrated CardBus USB host adapter with a connected USB serial device with three interfaces (normally ttyUSB0...ttyUSB2). Now I want to use 3 of these devices (remember: they are integrated, so I can't just plug the USB device onto the same host adapter). I know device A is in CardBus slot 1, device B is in CardBus slot 2 and so on. Now the question: How do I figure out which ttyUSBx belongs to which device? Thanks in advance Joerg ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6 PCMCIA/USB question
Hello all, I have a question that I could not figure out from other sources. I have the following hardware: an integrated CardBus USB host adapter with a connected USB serial device with three interfaces (normally ttyUSB0...ttyUSB2). Now I want to use 3 of these devices (remember: they are integrated, so I can't just plug the USB device onto the same host adapter). I know device A is in CardBus slot 1, device B is in CardBus slot 2 and so on. Now the question: How do I figure out which ttyUSBx belongs to which device? Thanks in advance Joerg ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-usb-users] 2.6 PCMCIA/USB question
I had hoped that one can figure things out from /proc and /sys. SHould'n there be a way to do this? And no, trial and error is not really an option. The devices in question are WCDMA/UMTS mobile data cards. They will differ only by the SIM card inserted by the user. The ICCID of the SIM is unknown during development and I would like to avoid to many configuration files. Regards Joerg --- Alan Stern [EMAIL PROTECTED] wrote: On Fri, 15 Apr 2005, Joerg Pommnitz wrote: Hello all, I have a question that I could not figure out from other sources. I have the following hardware: an integrated CardBus USB host adapter with a connected USB serial device with three interfaces (normally ttyUSB0...ttyUSB2). Now I want to use 3 of these devices (remember: they are integrated, so I can't just plug the USB device onto the same host adapter). I know device A is in CardBus slot 1, device B is in CardBus slot 2 and so on. Now the question: How do I figure out which ttyUSBx belongs to which device? You can look in the system log. If you want, you can actually control which goes where by creating a udev configuration file. Alan Stern ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select(2), usbserial, tty's and disconnect
Robert Hancock wrote: > I thought this (hangup on remove [jpo]) had been merged, but I could be > wrong. I just checked bitkeeper. The patch went in some time ago: 4 months eolson 1.126 usb-serial: add tty_hangup on disconnect Regards Joerg ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select(2), usbserial, tty's and disconnect
Robert Hancock wrote: > There was discussion at one point about doing a tty_hangup() when the > USB device was disconnected (this causes the read() to return with 0 > > bytes and future open attempts to fail), and a patch was put out to do > this. I thought this had been merged, but I could be wrong. Well, I observed the hanging select with SuSE kernel 2.6.8-24.11, so it is fairly current. I'm seeing this problem with an Option Wireless UMTS data card. This card is interesting. It is a CardBus card that presents a USB OHCI hub to the system. Internally it claims to plug in a USB serial connector. If you issue a RESET AT command, the kernel tells me that the USB device virtually plugged into the hub got disconnected. A few seconds later the gets plugged in again. At this point I would have to reopen the tty. Unfortunately the disconnect event does not propagate to the application. I could poke the tty to see whether it is still really there, but this seems quite hackish. Regards Joerg ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select(2), usbserial, tty's and disconnect
Robert Hancock wrote: There was discussion at one point about doing a tty_hangup() when the USB device was disconnected (this causes the read() to return with 0 bytes and future open attempts to fail), and a patch was put out to do this. I thought this had been merged, but I could be wrong. Well, I observed the hanging select with SuSE kernel 2.6.8-24.11, so it is fairly current. I'm seeing this problem with an Option Wireless UMTS data card. This card is interesting. It is a CardBus card that presents a USB OHCI hub to the system. Internally it claims to plug in a USB serial connector. If you issue a RESET AT command, the kernel tells me that the USB device virtually plugged into the hub got disconnected. A few seconds later the gets plugged in again. At this point I would have to reopen the tty. Unfortunately the disconnect event does not propagate to the application. I could poke the tty to see whether it is still really there, but this seems quite hackish. Regards Joerg ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select(2), usbserial, tty's and disconnect
Robert Hancock wrote: I thought this (hangup on remove [jpo]) had been merged, but I could be wrong. I just checked bitkeeper. The patch went in some time ago: 4 months eolson 1.126 usb-serial: add tty_hangup on disconnect Regards Joerg ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
select(2), usbserial, tty's and disconnect
Hello all, currently it seems that select keeps blocking when the USB device behind ttyUSBx gets unplugged. My understanding is, that select should return when the next call to one of the operations (read/write) will not block. This is certainly true for failing with ENODEV. So, is this an issue that will be fixed or should I poll (not the syscall) the device? Or is there another way to monitor for a vanishing tty (it should not be USB specific). Thanks in advance Joerg ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
select(2), usbserial, tty's and disconnect
Hello all, currently it seems that select keeps blocking when the USB device behind ttyUSBx gets unplugged. My understanding is, that select should return when the next call to one of the operations (read/write) will not block. This is certainly true for failing with ENODEV. So, is this an issue that will be fixed or should I poll (not the syscall) the device? Or is there another way to monitor for a vanishing tty (it should not be USB specific). Thanks in advance Joerg ___ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
> But that foregoes the point that the code is far more complex and > harder to make 'obviously correct', a concept that *does* translate > well to userspace. Check the state threads library from SGI: http://oss.sgi.com/projects/state-threads/ It should provide the code clarity one is used from "real" threads and the efficiency of a state machine. Regards Joerg = -- Regards Joerg __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - 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: Alan Cox quote? (was: Re: accounting for threads)
But that foregoes the point that the code is far more complex and harder to make 'obviously correct', a concept that *does* translate well to userspace. Check the state threads library from SGI: http://oss.sgi.com/projects/state-threads/ It should provide the code clarity one is used from real threads and the efficiency of a state machine. Regards Joerg = -- Regards Joerg __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - 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: TCP capture effect :: estimate queue length ?
> Pathchar, yet another Van Jacobsen toy does this. Unfortunately the old > and rotten pre-version you can find in ftp.ee.lbl.gov/pathchar/ is afaik > the last one. In the past it served me well you find about how ISPs are > lying ... 100mbit backbone = fast ethernet in their computer room ... clink and pchar are reimplementations of pathchar that come with sources: http://www.employees.org/~bmah/Software/pchar http://rocky.wellesley.edu/downey/clink Regards Jörg = -- Regards Joerg __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - 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: TCP capture effect :: estimate queue length ?
Pathchar, yet another Van Jacobsen toy does this. Unfortunately the old and rotten pre-version you can find in ftp.ee.lbl.gov/pathchar/ is afaik the last one. In the past it served me well you find about how ISPs are lying ... 100mbit backbone = fast ethernet in their computer room ... clink and pchar are reimplementations of pathchar that come with sources: http://www.employees.org/~bmah/Software/pchar http://rocky.wellesley.edu/downey/clink Regards Jörg = -- Regards Joerg __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ - 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: "mount -o loop" lockup issue
Ah, now you are arguing semantics. When somebody writes something to improve the Linux kernel this makes them part of the Linux kernel community. The project might be a new file system or a tool to verify the consistency of certain rules. The CHECKER people set out to make a tool that finds potential bugs in the Linux kernel. That they did. "All bugs are shallow" means, that once a potential bug is identified, it will be resolved very quickly. This happened with the CHECKER reports. False positives were immediately identified as such, real bugs were fixed almost in real time. Where did you see the scheme breaking down? Because the bugs should have been found without the tool? Nobody ever claimed the Linux kernel was bug free. The CHECKER people found some of the bugs still in the kernel. Without a comparison one cannot assess whether the bug rate was higher or lower than the average in complex software systems. My impression is, that most of the bugs identified where in well contained subsystems, e.g. drivers or individual file systems. These subsystems are somewhat special. Though they are part of the kernel tree, most are only of interest for a subset of all Linux users. That's why they tend to get less testing and less eye balls. BTW, MS claims that the same is true for Windows. Most bugs are said to be in external drivers. So, overall I think your arguments are flawed. Regards Joerg --- David Konerding <[EMAIL PROTECTED]> wrote: > No, the CHECKER people themselves didn't find any bugs. They wrote a > clever > analyzer > that finds error patterns (actually, just patterns) and submitted them. > Some > false positives, but worse, > an uncountable number of false negatives and as-yet-unknown error > patterns. > That's not "a lot of eyes", it's a few brains and a fast computer. I'm > not > saying that's a *bad* thing but I certainly don't think it's an example > of > "lots of eyes". = -- Regards Joerg __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text - 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: "mount -o loop" lockup issue
David Konerding <[EMAIL PROTECTED]> wrote: > But the attitude that "many eyes make all bugs shallow" and "let the > users test the code for us" just don't hold up. For the former, > clearly, many eyes didn't find a lot of basically obvious bugs, for the > latter, it's just impolite. You mentioned the CHECKER case as proof for your point that "many eyes make all bugs shallow" does not work. One might argue the other way around: The CHECKER people actually found the bugs, so it works. Regards Joerg = -- Regards Joerg __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text - 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: mount -o loop lockup issue
David Konerding [EMAIL PROTECTED] wrote: But the attitude that "many eyes make all bugs shallow" and "let the users test the code for us" just don't hold up. For the former, clearly, many eyes didn't find a lot of basically obvious bugs, for the latter, it's just impolite. You mentioned the CHECKER case as proof for your point that "many eyes make all bugs shallow" does not work. One might argue the other way around: The CHECKER people actually found the bugs, so it works. Regards Joerg = -- Regards Joerg __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/?.refer=text - 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: Better than SYNcookies?
Here is a message from nntp://news.grc.com/news.feedback Somebody with good knowledge of the Linux SYN-Cookies should probably drop by and discuss the matter... Regards Joerg Subject: A *significant* dilemma . . . Date: Mon, 25 Sep 2000 13:15:59 -0700 From: Steve Gibson <[EMAIL PROTECTED]> Organization: Gibson Research Corporation Newsgroups: news.feedback Gang, I'm in a BIG dilemma ... and I think some opinions and discussion would be in order. While detailing exactly why my system is different and superior to what's been done before ... I was thinking through the LINUX SYN Cookie approach and I *cracked* its security -- completely. I can IP spoof flood -- and probably crash -- any (presumably LINUX) kernel that's relying upon SYN Cookies for its "protection" since it would be a connection-establishing ACK flood which is much more dangerous than a fake handshake SYN flood. So, the dilemma is what to do about that knowledge and information. You know that I'd LOVE to explain exactly how and why SYN Cookies can be crumbled. It would -- once and for all -- silence those who claim that I have nothing new to offer. But wouldn't doing so be extremely irresponsible since -- if Torinak's correct -- LINUX servers are currently being "protected" by this insecure system? And since cracking a SYN Cookie protected server is MUCH more damaging than SYN flooding? And if I declare that I've cracked SYN Cookies *without* explaining how, won't people just claim that I haven't?? What do you guys think??? (By the way, if you hadn't already figured it out, SYN Cookies are a REALLY BAD idea! They are *WORSE* than using nothing, since when cracked (which is NOT difficult) they allow direct access to connection establishment, completely bypassing handshaking.) -- _ Steve Gibson,at work on: < http://grc.com/np/np.htm > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Better than SYNcookies?
Here is a message from nntp://news.grc.com/news.feedback Somebody with good knowledge of the Linux SYN-Cookies should probably drop by and discuss the matter... Regards Joerg Subject: A *significant* dilemma . . . Date: Mon, 25 Sep 2000 13:15:59 -0700 From: Steve Gibson [EMAIL PROTECTED] Organization: Gibson Research Corporation Newsgroups: news.feedback Gang, I'm in a BIG dilemma ... and I think some opinions and discussion would be in order. While detailing exactly why my system is different and superior to what's been done before ... I was thinking through the LINUX SYN Cookie approach and I *cracked* its security -- completely. I can IP spoof flood -- and probably crash -- any (presumably LINUX) kernel that's relying upon SYN Cookies for its "protection" since it would be a connection-establishing ACK flood which is much more dangerous than a fake handshake SYN flood. So, the dilemma is what to do about that knowledge and information. You know that I'd LOVE to explain exactly how and why SYN Cookies can be crumbled. It would -- once and for all -- silence those who claim that I have nothing new to offer. But wouldn't doing so be extremely irresponsible since -- if Torinak's correct -- LINUX servers are currently being "protected" by this insecure system? And since cracking a SYN Cookie protected server is MUCH more damaging than SYN flooding? And if I declare that I've cracked SYN Cookies *without* explaining how, won't people just claim that I haven't?? What do you guys think??? (By the way, if you hadn't already figured it out, SYN Cookies are a REALLY BAD idea! They are *WORSE* than using nothing, since when cracked (which is NOT difficult) they allow direct access to connection establishment, completely bypassing handshaking.) -- _ Steve Gibson,at work on: http://grc.com/np/np.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
