Re: rwsem, gcc3 again
mirabilos wrote: > > Hi, > I have got that patch with "movl %2,%%edx" and removing the tmp > and still cannot compile with the same error message I posted yesterday. > The problem seems to be that, with or without "inline", it seems to > put a reference into main.o of arch/i386/boot/compressed. > So I cannot test -ac9 :( > > If anyone could find a (final or at least until gcc is fixed temporarily) > solution please please could either post or mail me? > Please no Cc: as I am on the list. > > -mirabilos > -- Hi, Petr Vandrovic's patch works for me. $ cat /proc/version Linux version 2.4.5-pre1 (tleete@mercury) (gcc version 3.0 20010423 (prerelease)) #6 Tue May 15 07:13:10 EDT 2001 You don't mention the constraint changes, did you apply them too? I posted a simpler patch which miscompiled on gcc3 and 2.95.3. Still trying to understand why, it was Obviously Correct. It was also the cause of my boot hangs. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: rwsem, gcc3 again
mirabilos wrote: Hi, I have got that patch with movl %2,%%edx and removing the tmp and still cannot compile with the same error message I posted yesterday. The problem seems to be that, with or without inline, it seems to put a reference into main.o of arch/i386/boot/compressed. So I cannot test -ac9 :( If anyone could find a (final or at least until gcc is fixed temporarily) solution please please could either post or mail me? Please no Cc: as I am on the list. -mirabilos -- Hi, Petr Vandrovic's patch works for me. $ cat /proc/version Linux version 2.4.5-pre1 (tleete@mercury) (gcc version 3.0 20010423 (prerelease)) #6 Tue May 15 07:13:10 EDT 2001 You don't mention the constraint changes, did you apply them too? I posted a simpler patch which miscompiled on gcc3 and 2.95.3. Still trying to understand why, it was Obviously Correct. It was also the cause of my boot hangs. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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] __up_read and gcc-3.0
Petr Vandrovec wrote:
>
> Hi Alan,
> can you apply this patch to next 2.4.4-acX ? This fixes problem with
> gcc3.0 (20010426) unable to compile this under some conditions. As
> __up_write() uses same code ("i" instead of tmp variable), I think
> that you should apply this. It can cause slower code, as gcc cannot
> move "movl -RWSEM_ACTIVE_READ_BIAS,%edx" away from "xadd" anymore,
> but as "lock xadd" is slow anyway, it should not matter.
>
> I looked at generated code in cases where it originally failed, and
> generated code looks OK to me.
> Thanks,
> Petr Vandrovec
> [EMAIL PROTECTED]
>
> diff -urdN linux/include/asm-i386/rwsem.h linux/include/asm-i386/rwsem.h
> --- linux/include/asm-i386/rwsem.h Fri Apr 27 22:48:24 2001
> +++ linux/include/asm-i386/rwsem.h Wed May 9 16:31:57 2001
> @@ -148,9 +148,9 @@
> */
> static inline void __up_read(struct rw_semaphore *sem)
> {
> - __s32 tmp = -RWSEM_ACTIVE_READ_BIAS;
> __asm__ __volatile__(
> "# beginning __up_read\n\t"
> + " movl %2,%%edx\n\t"
> LOCK_PREFIX" xadd %%edx,(%%eax)\n\t" /* subtracts 1, returns the old
>value */
> " js2f\n\t" /* jump if the lock is being waited upon */
> "1:\n\t"
> @@ -164,9 +164,9 @@
> " jmp 1b\n"
> ".previous\n"
> "# ending __up_read\n"
> - : "+m"(sem->count), "+d"(tmp)
> - : "a"(sem)
> - : "memory", "cc");
> + : "+m"(sem->count)
> + : "a"(sem), "i"(-RWSEM_ACTIVE_READ_BIAS)
> + : "memory", "cc", "edx");
> }
>
> /*
Hi Petr,
My solution to this was to relax +d(tmp) to +m(tmp). Posted a few days ago.
I have larger problems with 2.4.5-pre1 and have not gone back to check what
comes out. Being a product of pure reason (and not much of that), mine
deserves suspicion.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
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: Not a typewriter
"Richard B. Johnson" wrote: > > I noticed that my favorite "errno" has now gotten trashed by > the newer 'C' runtime libraries. > > ENOTTY has been for ages, "Not a typewriter". > It's now been changed to "Inappropriate ioctl for device". > > Methinks that this means that ../linux/include/asm/errno.h now needs > to be updated: > > -#defineENOTTY 25 /* Not a typewriter */ > +#defineENOTTY 25 /* Inappropriate ioctl for device > */ > > None of these strings are in the kernel, but the headers probably should > show the "latest standard". > > Cheers, > Dick Johnson Probably so, but I think: character device => typewriter block => sheet of paper block device => stack of paper is not a bad analogy. Cheers Tom PS. I didn't dare call it a ream of paper ;-) -- The Daemons lurk and are dumb. -- Emerson - 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: Not a typewriter
Richard B. Johnson wrote: I noticed that my favorite errno has now gotten trashed by the newer 'C' runtime libraries. ENOTTY has been for ages, Not a typewriter. It's now been changed to Inappropriate ioctl for device. Methinks that this means that ../linux/include/asm/errno.h now needs to be updated: -#defineENOTTY 25 /* Not a typewriter */ +#defineENOTTY 25 /* Inappropriate ioctl for device */ None of these strings are in the kernel, but the headers probably should show the latest standard. Cheers, Dick Johnson Probably so, but I think: character device = typewriter block = sheet of paper block device = stack of paper is not a bad analogy. Cheers Tom PS. I didn't dare call it a ream of paper ;-) -- The Daemons lurk and are dumb. -- Emerson - 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] __up_read and gcc-3.0
Petr Vandrovec wrote:
Hi Alan,
can you apply this patch to next 2.4.4-acX ? This fixes problem with
gcc3.0 (20010426) unable to compile this under some conditions. As
__up_write() uses same code (i instead of tmp variable), I think
that you should apply this. It can cause slower code, as gcc cannot
move movl -RWSEM_ACTIVE_READ_BIAS,%edx away from xadd anymore,
but as lock xadd is slow anyway, it should not matter.
I looked at generated code in cases where it originally failed, and
generated code looks OK to me.
Thanks,
Petr Vandrovec
[EMAIL PROTECTED]
diff -urdN linux/include/asm-i386/rwsem.h linux/include/asm-i386/rwsem.h
--- linux/include/asm-i386/rwsem.h Fri Apr 27 22:48:24 2001
+++ linux/include/asm-i386/rwsem.h Wed May 9 16:31:57 2001
@@ -148,9 +148,9 @@
*/
static inline void __up_read(struct rw_semaphore *sem)
{
- __s32 tmp = -RWSEM_ACTIVE_READ_BIAS;
__asm__ __volatile__(
# beginning __up_read\n\t
+ movl %2,%%edx\n\t
LOCK_PREFIX xadd %%edx,(%%eax)\n\t /* subtracts 1, returns the old
value */
js2f\n\t /* jump if the lock is being waited upon */
1:\n\t
@@ -164,9 +164,9 @@
jmp 1b\n
.previous\n
# ending __up_read\n
- : +m(sem-count), +d(tmp)
- : a(sem)
- : memory, cc);
+ : +m(sem-count)
+ : a(sem), i(-RWSEM_ACTIVE_READ_BIAS)
+ : memory, cc, edx);
}
/*
Hi Petr,
My solution to this was to relax +d(tmp) to +m(tmp). Posted a few days ago.
I have larger problems with 2.4.5-pre1 and have not gone back to check what
comes out. Being a product of pure reason (and not much of that), mine
deserves suspicion.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
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: REVISED: Experimentation with Athlon and fast_page_copy
Alan Cox wrote: > > > Trace; c01b956a > > Trace; c01b3fb5 > > Trace; c01b9aca > > Trace; c01b9380 > > Trace; c01b9940 > > Trace; c01bd457 > > Trace; c01b4d2a > > Trace; c01b5010 > > Trace; c01b51ff > > We seem to be several layers into recursive use of the ide driver - which > shouldnt happen. In fact if these are the same interface the second dmatable > build would leave HWIF(drive)->sg_table wrong. > > > Trace; c01866ce <__make_request+4ae/6f0> > > Trace; c01866e6 <__make_request+4c6/6f0> > > Trace; c01b956a > > Trace; c01b3fb5 I think maybe it smells like a configuration problem, I have a pair of ATAPI drives on the second ide which I run with SCSI emulation. I'll see if I can get a better look, with arguments to the calls. Thanks, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: REVISED: Experimentation with Athlon and fast_page_copy
Alan Cox wrote: > > > > IIRC this thread is about boot going catatonic right after unloading > > __initmem. > > Nope. Its about memory corruptions. Your bug sounds very different > > > Earlier, it looks like handle_mm_fault is being triggered from > > fast_clear_page. > > That would be messy. The other way around is sane but not that way Indeed, I was confused. Looks like ide-dma is getting goofy somehow. Here is a decoded trace. Typos are likely. If the problem is not obvious to anyone, I'll switch around my serial console setup to get some better info. Warning (Oops_read): Code line not seen, dumping what data is available Trace; 037f Trace; Trace; Trace; 0720 Trace; c01b956a Trace; c01b3fb5 Trace; c01b9aca Trace; c01b9380 Trace; c01b9940 Trace; c01bd457 Trace; c01b4d2a Trace; c01b5010 Trace; c01b51ff Trace; c01b3430 Trace; c0132e45 <__wait_on_buffer+75/90> Trace; c0134026 Trace; c018665c <__make_request+43c/6f0> Trace; c01866ce <__make_request+4ae/6f0> Trace; c01866e6 <__make_request+4c6/6f0> Trace; c018665c <__make_request+43c/6f0> Trace; c01866ce <__make_request+4ae/6f0> Trace; c01866e6 <__make_request+4c6/6f0> Trace; c01b956a Trace; c01b3fb5 Trace; c01b9aca Trace; c01b9380 Trace; c01b9940 Trace; c01bd457 Trace; c01b4d2a Trace; c01b5010 Trace; c01b51ff Trace; c01b546e Trace; c01134d0 Trace; c012bd2c Trace; c012cbd7 <__alloc_pages+87/300> Trace; c022c12f Trace; c0125f4d Trace; c0125f58 Trace; c022c0ca Trace; c0122b7d Trace; c012bd2c Trace; c0122a15 Trace; c022c0ca Trace; c0222b7d Trace; c0225476 Trace; c02254c3 Trace; c0112ba9 Trace; c01239cf Trace; c0112900 Trace; c0106ddc Trace; c022be20 Trace; c0112900 Trace; c0134026 Trace; c018665c <__make_request+43c/6f0> Trace; c01866ce <__make_request+4ae/6f0> Trace; c01866e6 <__make_request+4c6/6f0> Trace; c01b956a Trace; c01b3fb5 Trace; c01b9aca Trace; c01b9380 Trace; c01b9940 Trace; c01bd457 Trace; c01b4d2a Trace; c01b5010 Trace; c01b51ff Trace; c01b546e Trace; c01134d0 Trace; c012be03 Trace; c0124d05 <__find_get_page+35/80> Trace; c013ae1b Trace; c0125d44 Trace; c013af79 Trace; c0122a15 Trace; c012267d Trace; c0112ba9 Trace; c022d075 Trace; c022f396 Trace; c0106cbf 1 warning issued. Results may not be reliable. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: REVISED: Experimentation with Athlon and fast_page_copy
Alan Cox wrote: IIRC this thread is about boot going catatonic right after unloading __initmem. Nope. Its about memory corruptions. Your bug sounds very different Earlier, it looks like handle_mm_fault is being triggered from fast_clear_page. That would be messy. The other way around is sane but not that way Indeed, I was confused. Looks like ide-dma is getting goofy somehow. Here is a decoded trace. Typos are likely. If the problem is not obvious to anyone, I'll switch around my serial console setup to get some better info. Warning (Oops_read): Code line not seen, dumping what data is available Trace; 037f END_OF_CODE+3fcfb2ab/ Trace; END_OF_CODE+3fcfaf2c/ Trace; END_OF_CODE+3fcfaf2c/ Trace; 0720 END_OF_CODE+3fcfb64c/ Trace; c01b956a ide_build_dmatable+2a/120 Trace; c01b3fb5 ide_set_handler+55/60 Trace; c01b9aca ide_dmaproc+11a/210 Trace; c01b9380 ide_dma_intr+0/b0 Trace; c01b9940 dma_timer_expiry+0/70 Trace; c01bd457 do_rw_disk+257/300 Trace; c01b4d2a ide_wait_stat+7a/e0 Trace; c01b5010 start_request+160/210 Trace; c01b51ff ide_do_request+10f/340 Trace; c01b3430 ali_cleanup+10/70 Trace; c0132e45 __wait_on_buffer+75/90 Trace; c0134026 bread+16/70 Trace; c018665c __make_request+43c/6f0 Trace; c01866ce __make_request+4ae/6f0 Trace; c01866e6 __make_request+4c6/6f0 Trace; c018665c __make_request+43c/6f0 Trace; c01866ce __make_request+4ae/6f0 Trace; c01866e6 __make_request+4c6/6f0 Trace; c01b956a ide_build_dmatable+2a/120 Trace; c01b3fb5 ide_set_handler+55/60 Trace; c01b9aca ide_dmaproc+11a/210 Trace; c01b9380 ide_dma_intr+0/b0 Trace; c01b9940 dma_timer_expiry+0/70 Trace; c01bd457 do_rw_disk+257/300 Trace; c01b4d2a ide_wait_stat+7a/e0 Trace; c01b5010 start_request+160/210 Trace; c01b51ff ide_do_request+10f/340 Trace; c01b546e do_ide_request+e/20 Trace; c01134d0 schedule+200/3e0 Trace; c012bd2c free_shortage+1c/c0 Trace; c012cbd7 __alloc_pages+87/300 Trace; c022c12f fast_copy_page+f/90 Trace; c0125f4d filemap_nopage+2bd/420 Trace; c0125f58 filemap_nopage+2c8/420 Trace; c022c0ca fast_clear_page+a/60 Trace; c0122b7d handle_mm_fault+cd/e0 Trace; c012bd2c free_shortage+1c/c0 Trace; c0122a15 do_no_page+45/e0 Trace; c022c0ca fast_clear_page+a/60 Trace; c0222b7d packet_ioctl+17d/350 Trace; c0225476 do_xprt_transmit+46/3d0 Trace; c02254c3 do_xprt_transmit+93/3d0 Trace; c0112ba9 do_page_fault+2a9/450 Trace; c01239cf do_munmap+5f/280 Trace; c0112900 do_page_fault+0/450 Trace; c0106ddc error_code+34/3c Trace; c022be20 clear_user+30/40 Trace; c0112900 do_page_fault+0/450 Trace; c0134026 bread+16/70 Trace; c018665c __make_request+43c/6f0 Trace; c01866ce __make_request+4ae/6f0 Trace; c01866e6 __make_request+4c6/6f0 Trace; c01b956a ide_build_dmatable+2a/120 Trace; c01b3fb5 ide_set_handler+55/60 Trace; c01b9aca ide_dmaproc+11a/210 Trace; c01b9380 ide_dma_intr+0/b0 Trace; c01b9940 dma_timer_expiry+0/70 Trace; c01bd457 do_rw_disk+257/300 Trace; c01b4d2a ide_wait_stat+7a/e0 Trace; c01b5010 start_request+160/210 Trace; c01b51ff ide_do_request+10f/340 Trace; c01b546e do_ide_request+e/20 Trace; c01134d0 schedule+200/3e0 Trace; c012be03 inactive_shortage+33/90 Trace; c0124d05 __find_get_page+35/80 Trace; c013ae1b search_binary_handler+17b/190 Trace; c0125d44 filemap_nopage+b4/420 Trace; c013af79 do_execve+149/200 Trace; c0122a15 do_no_page+45/e0 Trace; c012267d vmtruncate+12d/160 Trace; c0112ba9 do_page_fault+2a9/450 Trace; c022d075 rwsem_down_write_failed+65/140 Trace; c022f396 stext_lock+37a/16bc Trace; c0106cbf system_call+33/38 1 warning issued. Results may not be reliable. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: REVISED: Experimentation with Athlon and fast_page_copy
Alan Cox wrote: Trace; c01b956a ide_build_dmatable+2a/120 Trace; c01b3fb5 ide_set_handler+55/60 Trace; c01b9aca ide_dmaproc+11a/210 Trace; c01b9380 ide_dma_intr+0/b0 Trace; c01b9940 dma_timer_expiry+0/70 Trace; c01bd457 do_rw_disk+257/300 Trace; c01b4d2a ide_wait_stat+7a/e0 Trace; c01b5010 start_request+160/210 Trace; c01b51ff ide_do_request+10f/340 We seem to be several layers into recursive use of the ide driver - which shouldnt happen. In fact if these are the same interface the second dmatable build would leave HWIF(drive)-sg_table wrong. Trace; c01866ce __make_request+4ae/6f0 Trace; c01866e6 __make_request+4c6/6f0 Trace; c01b956a ide_build_dmatable+2a/120 Trace; c01b3fb5 ide_set_handler+55/60 I think maybe it smells like a configuration problem, I have a pair of ATAPI drives on the second ide which I run with SCSI emulation. I'll see if I can get a better look, with arguments to the calls. Thanks, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: REVISED: Experimentation with Athlon and fast_page_copy
Alan Cox wrote: > > > the memory copy in the fast_page_copy routine. The machine then > > proceeded > > not to stop at my panic, but I got my "normal" oopses. I then had an > > Ok > > > idea and removed all the prefetch instructions from the beginning of the > > routine and tried the resultin kernel. I now have no crashes. > > What could this mean? > > I think it has to mean a hardware problem. I don't think so, reasons below > What still stands out is that exactly _zero_ people have reported the same > problem with non VIA chipset Athlons. Not any more :-( Hi Alan, IIRC this thread is about boot going catatonic right after unloading __initmem. I'm seeing that in 2.4.5-pre1 with Athlon stepping 2, AMD 751, MS-6195 mobo, 128M. The machine is fine with kernels up through 2.4.4-pre3, and still works with them. On that gear, there is no crash. The keyboard and display are alive and SysRq works. I have copied the stack trace for pid=1 and the processor dump. I'm short of time but I have a kind typist electrifying the trace, and I'll try to generate something ksymoops can digest. Here is what a quick eyeballing of System.map shows. The code is at the end of init/main.c:init(). The processor dump shows init() halted in default_idle() from the sequence L6 -> init -> cpu_idle. Trace of pid 1 shows it stuck in D state. The last addresses listed are from filemap_nopage -> do_execve -> do_no_page -> handle_mm_fault -> __pmd_alloc -> rwsem_down_write_failed -> stext_lock -> system_call. That looks fishy. Earlier, it looks like handle_mm_fault is being triggered from fast_clear_page. I'll post the full dump soon as I have it. Btw, above happens with both gcc-2.95.3 and gcc-3.0-[20010423] compiled kernels. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: REVISED: Experimentation with Athlon and fast_page_copy
Alan Cox wrote: the memory copy in the fast_page_copy routine. The machine then proceeded not to stop at my panic, but I got my normal oopses. I then had an Ok idea and removed all the prefetch instructions from the beginning of the routine and tried the resultin kernel. I now have no crashes. What could this mean? I think it has to mean a hardware problem. I don't think so, reasons below What still stands out is that exactly _zero_ people have reported the same problem with non VIA chipset Athlons. Not any more :-( Hi Alan, IIRC this thread is about boot going catatonic right after unloading __initmem. I'm seeing that in 2.4.5-pre1 with Athlon stepping 2, AMD 751, MS-6195 mobo, 128M. The machine is fine with kernels up through 2.4.4-pre3, and still works with them. On that gear, there is no crash. The keyboard and display are alive and SysRq works. I have copied the stack trace for pid=1 and the processor dump. I'm short of time but I have a kind typist electrifying the trace, and I'll try to generate something ksymoops can digest. Here is what a quick eyeballing of System.map shows. The code is at the end of init/main.c:init(). The processor dump shows init() halted in default_idle() from the sequence L6 - init - cpu_idle. Trace of pid 1 shows it stuck in D state. The last addresses listed are from filemap_nopage - do_execve - do_no_page - handle_mm_fault - __pmd_alloc - rwsem_down_write_failed - stext_lock - system_call. That looks fishy. Earlier, it looks like handle_mm_fault is being triggered from fast_clear_page. I'll post the full dump soon as I have it. Btw, above happens with both gcc-2.95.3 and gcc-3.0-[20010423] compiled kernels. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Inconsistent constraint in asm-i386/rwsem.h
Hi, In include/asm-i386/rwsem.h:__up_read(), the auto variable 'tmp' is asserted to be in edx. This patch adjusts the constraint to match the variable. It could be argued that tmp should be declared register instead. I didn't because the function is inlined. The compiler will know how much register pressure there is in each instance. Cheers, Tom $ diff -u linux-2.4.5-pre1/include/asm-i386/rwsem.h~ linux-2.4.5-pre1/include/asm-i386/rwsem.h --- linux-2.4.5-pre1/include/asm-i386/rwsem.h~ Sun May 6 05:48:08 2001 +++ linux-2.4.5-pre1/include/asm-i386/rwsem.h Sun May 6 07:17:36 2001 @@ -164,7 +164,7 @@ " jmp 1b\n" ".previous\n" "# ending __up_read\n" - : "+m"(sem->count), "+d"(tmp) + : "+m"(sem->count), "+m"(tmp) : "a"(sem) : "memory", "cc"); } -- The Daemons lurk and are dumb. -- Emerson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Incremental to kill warnings
Hello,
I missed one, patch is incremental to the previous one.
Tom
$ diff -u include/asm-i386/checksum.h.orig include/asm-i386/checksum.h
--- include/asm-i386/checksum.h.origSun May 6 07:05:35 2001
+++ include/asm-i386/checksum.h Sun May 6 07:06:52 2001
@@ -100,10 +100,8 @@
static inline unsigned int csum_fold(unsigned int sum)
{
- __asm__("
- addl %1, %0
- adcl $0x, %0
- "
+ __asm__("addl %1, %0\n\t"
+ "adcl $0x, %0\n"
: "=r" (sum)
: "r" (sum << 16), "0" (sum & 0x)
);
--
The Daemons lurk and are dumb. -- Emerson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kill warning from gcc 3.0
Hello,
This patch stops the warning "Multiline strings are deprecated" from
gcc 3.0 [20010423] in include/asm-i386/checksum.h. I expect there
are more of these to be found.
Cheers,
Tom
$ diff -u include/asm-i386/checksum.h~ include/asm-i386/checksum.h
--- include/asm-i386/checksum.h~Mon Jan 8 10:56:14 2001
+++ include/asm-i386/checksum.h Sun May 6 06:17:28 2001
@@ -69,25 +69,23 @@
unsigned int ihl) {
unsigned int sum;
- __asm__ __volatile__("
- movl (%1), %0
- subl $4, %2
- jbe 2f
- addl 4(%1), %0
- adcl 8(%1), %0
- adcl 12(%1), %0
-1: adcl 16(%1), %0
- lea 4(%1), %1
- decl %2
- jne 1b
- adcl $0, %0
- movl %0, %2
- shrl $16, %0
- addw %w2, %w0
- adcl $0, %0
- notl %0
-2:
- "
+ __asm__ __volatile__("movl (%1), %0\n\t"
+"subl $4, %2\n\t"
+"jbe 2f\n\t"
+"addl 4(%1), %0\n\t"
+"adcl 8(%1), %0\n\t"
+"adcl 12(%1), %0\n"
+"1:adcl 16(%1), %0\n\t"
+"lea 4(%1), %1\n\t"
+"decl %2\n\t"
+"jne 1b\n\t"
+"adcl $0, %0\n\t"
+"movl %0, %2\n\t"
+"shrl $16, %0\n\t"
+"addw %w2, %w0\n\t"
+"adcl $0, %0\n\t"
+"notl %0\n"
+"2:\n"
/* Since the input registers which are loaded with iph and ipl
are modified, we must also specify them as outputs, or gcc
will assume they contain their original values. */
@@ -118,14 +116,12 @@
unsigned short proto,
unsigned int sum)
{
-__asm__("
- addl %1, %0
- adcl %2, %0
- adcl %3, %0
- adcl $0, %0
- "
- : "=r" (sum)
- : "g" (daddr), "g"(saddr), "g"((ntohs(len)<<16)+proto*256), "0"(sum));
+__asm__("addl %1, %0\n\t"
+ "adcl %2, %0\n\t"
+ "adcl %3, %0\n\t"
+ "adcl $0, %0\n\t"
+ : "=r" (sum)
+ : "g" (daddr), "g"(saddr), "g"((ntohs(len)<<16)+proto*256), "0"(sum));
return sum;
}
@@ -158,19 +154,17 @@
unsigned short proto,
unsigned int sum)
{
- __asm__("
- addl 0(%1), %0
- adcl 4(%1), %0
- adcl 8(%1), %0
- adcl 12(%1), %0
- adcl 0(%2), %0
- adcl 4(%2), %0
- adcl 8(%2), %0
- adcl 12(%2), %0
- adcl %3, %0
- adcl %4, %0
- adcl $0, %0
- "
+ __asm__("addl 0(%1), %0\n\t"
+ "adcl 4(%1), %0\n\t"
+ "adcl 8(%1), %0\n\t"
+ "adcl 12(%1), %0\n\t"
+ "adcl 0(%2), %0\n\t"
+ "adcl 4(%2), %0\n\t"
+ "adcl 8(%2), %0\n\t"
+ "adcl 12(%2), %0\n\t"
+ "adcl %3, %0\n\t"
+ "adcl %4, %0\n\t"
+ "adcl $0, %0\n\t"
: "=" (sum)
: "r" (saddr), "r" (daddr),
"r"(htonl(len)), "r"(htonl(proto)), "0"(sum));
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kill warning from gcc 3.0
Hello,
This patch stops the warning Multiline strings are deprecated from
gcc 3.0 [20010423] in include/asm-i386/checksum.h. I expect there
are more of these to be found.
Cheers,
Tom
$ diff -u include/asm-i386/checksum.h~ include/asm-i386/checksum.h
--- include/asm-i386/checksum.h~Mon Jan 8 10:56:14 2001
+++ include/asm-i386/checksum.h Sun May 6 06:17:28 2001
@@ -69,25 +69,23 @@
unsigned int ihl) {
unsigned int sum;
- __asm__ __volatile__(
- movl (%1), %0
- subl $4, %2
- jbe 2f
- addl 4(%1), %0
- adcl 8(%1), %0
- adcl 12(%1), %0
-1: adcl 16(%1), %0
- lea 4(%1), %1
- decl %2
- jne 1b
- adcl $0, %0
- movl %0, %2
- shrl $16, %0
- addw %w2, %w0
- adcl $0, %0
- notl %0
-2:
-
+ __asm__ __volatile__(movl (%1), %0\n\t
+subl $4, %2\n\t
+jbe 2f\n\t
+addl 4(%1), %0\n\t
+adcl 8(%1), %0\n\t
+adcl 12(%1), %0\n
+1:adcl 16(%1), %0\n\t
+lea 4(%1), %1\n\t
+decl %2\n\t
+jne 1b\n\t
+adcl $0, %0\n\t
+movl %0, %2\n\t
+shrl $16, %0\n\t
+addw %w2, %w0\n\t
+adcl $0, %0\n\t
+notl %0\n
+2:\n
/* Since the input registers which are loaded with iph and ipl
are modified, we must also specify them as outputs, or gcc
will assume they contain their original values. */
@@ -118,14 +116,12 @@
unsigned short proto,
unsigned int sum)
{
-__asm__(
- addl %1, %0
- adcl %2, %0
- adcl %3, %0
- adcl $0, %0
-
- : =r (sum)
- : g (daddr), g(saddr), g((ntohs(len)16)+proto*256), 0(sum));
+__asm__(addl %1, %0\n\t
+ adcl %2, %0\n\t
+ adcl %3, %0\n\t
+ adcl $0, %0\n\t
+ : =r (sum)
+ : g (daddr), g(saddr), g((ntohs(len)16)+proto*256), 0(sum));
return sum;
}
@@ -158,19 +154,17 @@
unsigned short proto,
unsigned int sum)
{
- __asm__(
- addl 0(%1), %0
- adcl 4(%1), %0
- adcl 8(%1), %0
- adcl 12(%1), %0
- adcl 0(%2), %0
- adcl 4(%2), %0
- adcl 8(%2), %0
- adcl 12(%2), %0
- adcl %3, %0
- adcl %4, %0
- adcl $0, %0
-
+ __asm__(addl 0(%1), %0\n\t
+ adcl 4(%1), %0\n\t
+ adcl 8(%1), %0\n\t
+ adcl 12(%1), %0\n\t
+ adcl 0(%2), %0\n\t
+ adcl 4(%2), %0\n\t
+ adcl 8(%2), %0\n\t
+ adcl 12(%2), %0\n\t
+ adcl %3, %0\n\t
+ adcl %4, %0\n\t
+ adcl $0, %0\n\t
: =r (sum)
: r (saddr), r (daddr),
r(htonl(len)), r(htonl(proto)), 0(sum));
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Incremental to kill warnings
Hello,
I missed one, patch is incremental to the previous one.
Tom
$ diff -u include/asm-i386/checksum.h.orig include/asm-i386/checksum.h
--- include/asm-i386/checksum.h.origSun May 6 07:05:35 2001
+++ include/asm-i386/checksum.h Sun May 6 07:06:52 2001
@@ -100,10 +100,8 @@
static inline unsigned int csum_fold(unsigned int sum)
{
- __asm__(
- addl %1, %0
- adcl $0x, %0
-
+ __asm__(addl %1, %0\n\t
+ adcl $0x, %0\n
: =r (sum)
: r (sum 16), 0 (sum 0x)
);
--
The Daemons lurk and are dumb. -- Emerson
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Inconsistent constraint in asm-i386/rwsem.h
Hi, In include/asm-i386/rwsem.h:__up_read(), the auto variable 'tmp' is asserted to be in edx. This patch adjusts the constraint to match the variable. It could be argued that tmp should be declared register instead. I didn't because the function is inlined. The compiler will know how much register pressure there is in each instance. Cheers, Tom $ diff -u linux-2.4.5-pre1/include/asm-i386/rwsem.h~ linux-2.4.5-pre1/include/asm-i386/rwsem.h --- linux-2.4.5-pre1/include/asm-i386/rwsem.h~ Sun May 6 05:48:08 2001 +++ linux-2.4.5-pre1/include/asm-i386/rwsem.h Sun May 6 07:17:36 2001 @@ -164,7 +164,7 @@ jmp 1b\n .previous\n # ending __up_read\n - : +m(sem-count), +d(tmp) + : +m(sem-count), +m(tmp) : a(sem) : memory, cc); } -- The Daemons lurk and are dumb. -- Emerson - 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: Athlon and fast_page_copy: What's it worth ? :)
Mark Hahn wrote: > > On Fri, 4 May 2001, Seth Goldberg wrote: > > > Hi, > > > > Before I go any further with this investigation, I'd like to get an > > idea > > of how much of a performance improvement the K7 fast_page_copy will give > > me. > > Can someone suggest the best benchmark to test the speed of this > > routine? > > Arjan van de Ven did the code, and he wrote a little test harness. > I've hacked it a bit (http://brain.mcmaster.ca/~hahn/athlon.c); > on my duron/600, kt133, pc133 cas2, it looks like this: > > clear_page by 'normal_clear_page'took 7221 cycles (324.6 MB/s) > clear_page by 'slow_zero_page' took 7232 cycles (324.1 MB/s) > clear_page by 'fast_clear_page' took 6110 cycles (383.6 MB/s) > clear_page by 'faster_clear_page'took 2574 cycles (910.6 MB/s) > > copy_page by 'normal_copy_page' took 7224 cycles (324.4 MB/s) > copy_page by 'slow_copy_page'took 7223 cycles (324.5 MB/s) > copy_page by 'fast_copy_page'took 4662 cycles (502.7 MB/s) > copy_page by 'faster_copy' took 2746 cycles (853.5 MB/s) > copy_page by 'even_faster' took 2802 cycles (836.5 MB/s) > > 70% faster! > I've played with this some, too. I find that Arjan's tests are very delicate about the number of hw interrupts serviced. On UP I see 2-3 interrupts per page copy on average with my normal workload. On Athlon, interrupts hit 'rep mov' (looong interruptable vector path insn) much worse than they do mmx movq (direct path) instructions. With hands off and no networking, breakeven is about the canonical 512 bytes, and page copy is about 30% better, as Alan says. With ethers up and X running mmx gets better by comparison -- 40-60% for me. I haven't seen 70% better, but I'd like to. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: Athlon and fast_page_copy: What's it worth ? :)
Mark Hahn wrote: On Fri, 4 May 2001, Seth Goldberg wrote: Hi, Before I go any further with this investigation, I'd like to get an idea of how much of a performance improvement the K7 fast_page_copy will give me. Can someone suggest the best benchmark to test the speed of this routine? Arjan van de Ven did the code, and he wrote a little test harness. I've hacked it a bit (http://brain.mcmaster.ca/~hahn/athlon.c); on my duron/600, kt133, pc133 cas2, it looks like this: clear_page by 'normal_clear_page'took 7221 cycles (324.6 MB/s) clear_page by 'slow_zero_page' took 7232 cycles (324.1 MB/s) clear_page by 'fast_clear_page' took 6110 cycles (383.6 MB/s) clear_page by 'faster_clear_page'took 2574 cycles (910.6 MB/s) copy_page by 'normal_copy_page' took 7224 cycles (324.4 MB/s) copy_page by 'slow_copy_page'took 7223 cycles (324.5 MB/s) copy_page by 'fast_copy_page'took 4662 cycles (502.7 MB/s) copy_page by 'faster_copy' took 2746 cycles (853.5 MB/s) copy_page by 'even_faster' took 2802 cycles (836.5 MB/s) 70% faster! I've played with this some, too. I find that Arjan's tests are very delicate about the number of hw interrupts serviced. On UP I see 2-3 interrupts per page copy on average with my normal workload. On Athlon, interrupts hit 'rep mov' (looong interruptable vector path insn) much worse than they do mmx movq (direct path) instructions. With hands off and no networking, breakeven is about the canonical 512 bytes, and page copy is about 30% better, as Alan says. With ethers up and X running mmx gets better by comparison -- 40-60% for me. I haven't seen 70% better, but I'd like to. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: Followup to previous post: Atlon/VIA Instabilities
Seth Goldberg wrote: > > Hi, > > So it seems that CONFIG_X86_USE_3DNOW is simply used to > enable access to the routines in mmx.c (the athlon-optimized > routines on CONFIG_K7 kernels), so then it appears that somehow > this is corrupting memory / not behaving as it should (very > technical, right?) :)... > > --Seth This is a shot in the dark. Do you have floating-point emulation on (CONFIG_MATH_EMULATION=y)? Tom -- The Daemons lurk and are dumb. -- Emerson - 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: Followup to previous post: Atlon/VIA Instabilities
Seth Goldberg wrote: Hi, So it seems that CONFIG_X86_USE_3DNOW is simply used to enable access to the routines in mmx.c (the athlon-optimized routines on CONFIG_K7 kernels), so then it appears that somehow this is corrupting memory / not behaving as it should (very technical, right?) :)... --Seth This is a shot in the dark. Do you have floating-point emulation on (CONFIG_MATH_EMULATION=y)? Tom -- The Daemons lurk and are dumb. -- Emerson - 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: [Semi-OT] Dual Athlon support in kernel
"Mike A. Harris" wrote: > > Would the current state of athlon support be considered stable? > I've got a colleague interested in getting a dual athlon box, and > I'll be making the decision as to what hardware to purchase. I'm > wondering is dual Athlon viable for a business solution right > now, or is it considered "experimental"? > > What hardware would be recommended for a dual CPU system that > needs to be fairly rock solid? Should I recommend to stay with > the P-III Xeon? Or something else? What issues would I expect > to have to deal with if going with a dual Athlon? > > Also, what is a good rock solid SCSI RAID controller? Money is > no object. Reliability, performance and Linux compatibility are > though. > > Chipsets to avoid? > > Any experiences/info good/bad would be greatly appreciated. The build problen with Athlon+SMP was solved by AA's patch. I had tested a similar patch on UP over 2.4.0-test and previous 2.4 releases with nary a problem. This may be too experimental for your purposes, but FWIW I'm writing from a 2.4.4-pre3 built with gcc-2.97-20010205 using -march=athlon set by the k7 config. I've been building kernels with that snapshot since the middle of Feb. With the current image, the box has locked up once in continuous use. I can't say what caused that one, no log survived. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: [Semi-OT] Dual Athlon support in kernel
Mike A. Harris wrote: Would the current state of athlon support be considered stable? I've got a colleague interested in getting a dual athlon box, and I'll be making the decision as to what hardware to purchase. I'm wondering is dual Athlon viable for a business solution right now, or is it considered experimental? What hardware would be recommended for a dual CPU system that needs to be fairly rock solid? Should I recommend to stay with the P-III Xeon? Or something else? What issues would I expect to have to deal with if going with a dual Athlon? Also, what is a good rock solid SCSI RAID controller? Money is no object. Reliability, performance and Linux compatibility are though. Chipsets to avoid? Any experiences/info good/bad would be greatly appreciated. The build problen with Athlon+SMP was solved by AA's patch. I had tested a similar patch on UP over 2.4.0-test and previous 2.4 releases with nary a problem. This may be too experimental for your purposes, but FWIW I'm writing from a 2.4.4-pre3 built with gcc-2.97-20010205 using -march=athlon set by the k7 config. I've been building kernels with that snapshot since the middle of Feb. With the current image, the box has locked up once in continuous use. I can't say what caused that one, no log survived. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[Cc: trimmed] Russell King wrote: > [...] > > Generally it seems like diff needs to produce one more line of context, and > most of these problems will go away. Yes, there will still be the odd > problem, so then it becomes the "how much do you crank the setting" problem. > $ diff -6 ... will give 6 lines of context. patch will understand the output without any extra help. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: Current status of NTFS support
Lee Leahu wrote: > > On Friday 20 April 2001 20:39, you wrote: > > Lee Leahu <[EMAIL PROTECTED]> writes: > > > would somebody be kind enough to explain why writing to > > > the ntfs file system is extremely dangerous, and what are the > > > developers doing to make writing to ntfs filesystem safe? > > > > It's dangerous because NTFS is a proprietary format, and the full > > rules for updating it (including journals etc) are known only to > > Microsoft and those that have signed Microsoft NDAs. If you update it > > incorrectly it gets corrupted and you will lose data. It's certainly > > possible to reverse-engineer these rules, but very difficult and > > time-consuming. > > > > -Doug > > my boss rememebres reading a very indepth article in one of the msdn > magazines. i could scan the articles in and compress them and send them to > the developers. i want to help the ntfs movement on linux. would somebody be > willing to teach me the ropes of reverse engineering of software. i am a > faster learner, and very interested in reverse engineering of software. Copyright interferes with that route, and I'm sure Microsoft would be happy to enforce that. Links to the msdn.microsoft.com library/kb articles would be good. > i have access to the msdn library and maganzies and have lot of free time for > dedicated ntfs code hacking. Also good. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: Current status of NTFS support
Lee Leahu wrote: On Friday 20 April 2001 20:39, you wrote: Lee Leahu [EMAIL PROTECTED] writes: would somebody be kind enough to explain why writing to the ntfs file system is extremely dangerous, and what are the developers doing to make writing to ntfs filesystem safe? It's dangerous because NTFS is a proprietary format, and the full rules for updating it (including journals etc) are known only to Microsoft and those that have signed Microsoft NDAs. If you update it incorrectly it gets corrupted and you will lose data. It's certainly possible to reverse-engineer these rules, but very difficult and time-consuming. -Doug my boss rememebres reading a very indepth article in one of the msdn magazines. i could scan the articles in and compress them and send them to the developers. i want to help the ntfs movement on linux. would somebody be willing to teach me the ropes of reverse engineering of software. i am a faster learner, and very interested in reverse engineering of software. Copyright interferes with that route, and I'm sure Microsoft would be happy to enforce that. Links to the msdn.microsoft.com library/kb articles would be good. i have access to the msdn library and maganzies and have lot of free time for dedicated ntfs code hacking. Also good. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
[Cc: trimmed] Russell King wrote: [...] Generally it seems like diff needs to produce one more line of context, and most of these problems will go away. Yes, there will still be the odd problem, so then it becomes the "how much do you crank the setting" problem. $ diff -6 ... will give 6 lines of context. patch will understand the output without any extra help. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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] Re: Race in fs/proc/generic.c:make_inode_number()
Maneesh Soni wrote:
>
> Just a couple of points:
>
> On Thu, Apr 05, 2001 at 10:36:10AM -0400, Tom Leete wrote:
> [...]
> > +spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
> > +
> Why not make this static?
> Initializer should be SPIN_LOCK_UNLOCKED.
>
Thanks, you're right on both counts.
Linus, Alan, this version is more correct. I also checked for other uses of
proc_alloc_map[], The only case is in deallocation, and it looks ok to me.
Tom
--
The Daemons lurk and are dumb. -- Emerson
diff -u linux-2.4.3/fs/proc/generic.c.orig linux-2.4.3/fs/proc/generic.c
--- linux-2.4.3/fs/proc/generic.c.orig Thu Apr 5 10:03:02 2001
+++ linux-2.4.3/fs/proc/generic.c Thu Apr 5 10:22:48 2001
@@ -192,13 +192,22 @@
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
+spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
+
static int make_inode_number(void)
{
- int i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
- if (i<0 || i>=PROC_NDYNAMIC)
- return -1;
+ int i;
+ spin_lock(_alloc_map_lock);
+ i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
+ if (i<0 || i>=PROC_NDYNAMIC) {
+ i = -1;
+ goto out;
+ }
set_bit(i, (void *) proc_alloc_map);
- return PROC_DYNAMIC_FIRST + i;
+ i += PROC_DYNAMIC_FIRST;
+out:
+ spin_unlock(_alloc_map_lock);
+ return i;
}
static int proc_readlink(struct dentry *dentry, char *buffer, int buflen)
-
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] Re: Race in fs/proc/generic.c:make_inode_number()
Maneesh Soni wrote:
Just a couple of points:
On Thu, Apr 05, 2001 at 10:36:10AM -0400, Tom Leete wrote:
[...]
+spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
+
Why not make this static?
Initializer should be SPIN_LOCK_UNLOCKED.
Thanks, you're right on both counts.
Linus, Alan, this version is more correct. I also checked for other uses of
proc_alloc_map[], The only case is in deallocation, and it looks ok to me.
Tom
--
The Daemons lurk and are dumb. -- Emerson
diff -u linux-2.4.3/fs/proc/generic.c.orig linux-2.4.3/fs/proc/generic.c
--- linux-2.4.3/fs/proc/generic.c.orig Thu Apr 5 10:03:02 2001
+++ linux-2.4.3/fs/proc/generic.c Thu Apr 5 10:22:48 2001
@@ -192,13 +192,22 @@
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
+spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
+
static int make_inode_number(void)
{
- int i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
- if (i0 || i=PROC_NDYNAMIC)
- return -1;
+ int i;
+ spin_lock(proc_alloc_map_lock);
+ i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
+ if (i0 || i=PROC_NDYNAMIC) {
+ i = -1;
+ goto out;
+ }
set_bit(i, (void *) proc_alloc_map);
- return PROC_DYNAMIC_FIRST + i;
+ i += PROC_DYNAMIC_FIRST;
+out:
+ spin_unlock(proc_alloc_map_lock);
+ return i;
}
static int proc_readlink(struct dentry *dentry, char *buffer, int buflen)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Race in fs/proc/generic.c:make_inode_number()
I wrote:
>
> The proc_alloc_map bitfield is unprotected by any lock, and
> find_first_zero_bit() is not atomic. Concurrent module loading can race
> here.
Hello,
Here is a patch for this. It looks like callers are always in user context
(kmalloc flag GFP_KERNEL), so I used a light spinlock.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
--- linux-2.4.3/fs/proc/generic.c.orig Thu Apr 5 10:03:02 2001
+++ linux-2.4.3/fs/proc/generic.c Thu Apr 5 10:22:48 2001
@@ -192,13 +192,22 @@
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
+spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
+
static int make_inode_number(void)
{
- int i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
- if (i<0 || i>=PROC_NDYNAMIC)
- return -1;
+ int i;
+ spin_lock(_alloc_map_lock);
+ i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
+ if (i<0 || i>=PROC_NDYNAMIC) {
+ i = -1;
+ goto out;
+ }
set_bit(i, (void *) proc_alloc_map);
- return PROC_DYNAMIC_FIRST + i;
+ i += PROC_DYNAMIC_FIRST;
+out:
+ spin_unlock(_alloc_map_lock);
+ return i;
}
static int proc_readlink(struct dentry *dentry, char *buffer, int buflen)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: Race in fs/proc/generic.c:make_inode_number()
I wrote:
The proc_alloc_map bitfield is unprotected by any lock, and
find_first_zero_bit() is not atomic. Concurrent module loading can race
here.
Hello,
Here is a patch for this. It looks like callers are always in user context
(kmalloc flag GFP_KERNEL), so I used a light spinlock.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
--- linux-2.4.3/fs/proc/generic.c.orig Thu Apr 5 10:03:02 2001
+++ linux-2.4.3/fs/proc/generic.c Thu Apr 5 10:22:48 2001
@@ -192,13 +192,22 @@
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
+spinlock_t proc_alloc_map_lock = RW_LOCK_UNLOCKED;
+
static int make_inode_number(void)
{
- int i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
- if (i0 || i=PROC_NDYNAMIC)
- return -1;
+ int i;
+ spin_lock(proc_alloc_map_lock);
+ i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
+ if (i0 || i=PROC_NDYNAMIC) {
+ i = -1;
+ goto out;
+ }
set_bit(i, (void *) proc_alloc_map);
- return PROC_DYNAMIC_FIRST + i;
+ i += PROC_DYNAMIC_FIRST;
+out:
+ spin_unlock(proc_alloc_map_lock);
+ return i;
}
static int proc_readlink(struct dentry *dentry, char *buffer, int buflen)
-
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/
Race in fs/proc/generic.c:make_inode_number()
Hello,
The proc_alloc_map bitfield is unprotected by any lock, and
find_first_zero_bit() is not atomic. Concurrent module loading can race
here.
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
static int make_inode_number(void)
{
int i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
if (i<0 || i>=PROC_NDYNAMIC)
return -1;
set_bit(i, (void *) proc_alloc_map);
return PROC_DYNAMIC_FIRST + i;
}
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
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/
Race in fs/proc/generic.c:make_inode_number()
Hello,
The proc_alloc_map bitfield is unprotected by any lock, and
find_first_zero_bit() is not atomic. Concurrent module loading can race
here.
static unsigned char proc_alloc_map[PROC_NDYNAMIC / 8];
static int make_inode_number(void)
{
int i = find_first_zero_bit((void *) proc_alloc_map, PROC_NDYNAMIC);
if (i0 || i=PROC_NDYNAMIC)
return -1;
set_bit(i, (void *) proc_alloc_map);
return PROC_DYNAMIC_FIRST + i;
}
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
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: bug database braindump from the kernel summit
Oliver Xymoron wrote: > > On Sun, 1 Apr 2001, Jeff Garzik wrote: > > > On Sun, 1 Apr 2001, David Lang wrote: > > > if we want to get the .config as part of the report then we need to make > > > it part of the kernel in some standard way (the old /proc/config flamewar) > > > it's difficult enough sometimes for the sysadmin of a box to know what > > > kernel is running on it, let alone a bug reporting script. > > > > Let's hope it's not a flamewar, but here goes :) > > > > We -need- .config, but /proc/config seems like pure bloat. > > As a former proponent of /proc/config (I wrote one of the much-debated > patches), I tend to agree. Debian's make-kpkg does the right thing, namely > treating .config the same way it treats System-map, putting it in the > package and eventually installing it in /boot/config-x.y.z. If Redhat's > kernel-install script did the same it would rapidly become a non-issue. How about /lib/modules/$(uname -r)/build/.config ? It's already there. Tom -- The Daemons lurk and are dumb. -- Emerson - 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: bug database braindump from the kernel summit
Oliver Xymoron wrote: On Sun, 1 Apr 2001, Jeff Garzik wrote: On Sun, 1 Apr 2001, David Lang wrote: if we want to get the .config as part of the report then we need to make it part of the kernel in some standard way (the old /proc/config flamewar) it's difficult enough sometimes for the sysadmin of a box to know what kernel is running on it, let alone a bug reporting script. Let's hope it's not a flamewar, but here goes :) We -need- .config, but /proc/config seems like pure bloat. As a former proponent of /proc/config (I wrote one of the much-debated patches), I tend to agree. Debian's make-kpkg does the right thing, namely treating .config the same way it treats System-map, putting it in the package and eventually installing it in /boot/config-x.y.z. If Redhat's kernel-install script did the same it would rapidly become a non-issue. How about /lib/modules/$(uname -r)/build/.config ? It's already there. Tom -- The Daemons lurk and are dumb. -- Emerson - 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] pcnet32 compilation fix for 2.4.3pre6
Ulrich Drepper wrote: > > [EMAIL PROTECTED] writes: > > > with the new ansi standard, this use of __inline__ is no longer > > necessary, > > This is not correct. Since the semantics of inline in C99 and gcc > differ all code which depends on the gcc semantics should continue to > use __inline__ since this keyword will hopefully forever signal the > gcc semantics. Unfortunately, it seems that gcc will define __inline__ as a synonym for inline, whatever inline is currently in use. I asked this on the gcc list a while ago. The archive there should have the replies. Regards, Tom -- The Daemons lurk and are dumb. -- Emerson - 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] pcnet32 compilation fix for 2.4.3pre6
Ulrich Drepper wrote: [EMAIL PROTECTED] writes: with the new ansi standard, this use of __inline__ is no longer necessary, This is not correct. Since the semantics of inline in C99 and gcc differ all code which depends on the gcc semantics should continue to use __inline__ since this keyword will hopefully forever signal the gcc semantics. Unfortunately, it seems that gcc will define __inline__ as a synonym for inline, whatever inline is currently in use. I asked this on the gcc list a while ago. The archive there should have the replies. Regards, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: [IDE] meaningless #ifndef?
Bill Wendling wrote: > > The use of the ternary operator is superfluous, though...and makes the > code look ugly IMNSHO :). > You are correct. Please ignore my thinko. Tom -- The Daemons lurk and are dumb. -- Emerson - 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: [IDE] meaningless #ifndef?
Bill Wendling wrote:
>
> Also sprach Andre Hedrick:
> } On Mon, 19 Feb 2001, Pozsar Balazs wrote:
> }
> } > from drivers/ide/ide-features.c:
> } >
> } > /*
> } > * All hosts that use the 80c ribbon mus use!
> } > */
> } > byte eighty_ninty_three (ide_drive_t *drive)
> } > {
> } > return ((byte) ((HWIF(drive)->udma_four) &&
> } > #ifndef CONFIG_IDEDMA_IVB
> } > (drive->id->hw_config & 0x4000) &&
> } > #endif /* CONFIG_IDEDMA_IVB */
> } > (drive->id->hw_config & 0x6000)) ? 1 : 0);
> } > }
> } >
> } > If i see well, then this is always same whether CONFIG_IDEDMA_IVB is
> } > defined or not.
> } > What's the clue?
> }
> [snip...]
>
> The use of the ternary operator is superfluous, though...and makes the
> code look ugly IMNSHO :).
>
Check return type. 0 == ((byte) 0x6000).
Tom
-
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: [IDE] meaningless #ifndef?
Bill Wendling wrote:
Also sprach Andre Hedrick:
} On Mon, 19 Feb 2001, Pozsar Balazs wrote:
}
} from drivers/ide/ide-features.c:
}
} /*
} * All hosts that use the 80c ribbon mus use!
} */
} byte eighty_ninty_three (ide_drive_t *drive)
} {
} return ((byte) ((HWIF(drive)-udma_four)
} #ifndef CONFIG_IDEDMA_IVB
} (drive-id-hw_config 0x4000)
} #endif /* CONFIG_IDEDMA_IVB */
} (drive-id-hw_config 0x6000)) ? 1 : 0);
} }
}
} If i see well, then this is always same whether CONFIG_IDEDMA_IVB is
} defined or not.
} What's the clue?
}
[snip...]
The use of the ternary operator is superfluous, though...and makes the
code look ugly IMNSHO :).
Check return type. 0 == ((byte) 0x6000).
Tom
-
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: [IDE] meaningless #ifndef?
Bill Wendling wrote: The use of the ternary operator is superfluous, though...and makes the code look ugly IMNSHO :). You are correct. Please ignore my thinko. Tom -- The Daemons lurk and are dumb. -- Emerson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Athlon-SMP final
Hi Alan,
The polishing is done. Versus 2.4.1 again.
Summary:
struct task_struct{...} moved to a new file, linux/task_struct.h.
struct sigpending{...} moved to a new file, linux/sigpending.h.
remove line linux/capability.c:17 #include (blessed by Andrew
Morgan)
adjust header inclusions in CONFIG_X386_USE_3DNOW section of
asm-i386/string.h.
Changes from the first version of the patch:
revert creation of linux/mm_struct.h (needless)
improve comments in the new files
remove #ifdef guards around dummy declarations (suggested by Manfred
Spraul)
remove dead version of kernel_cap_t support (also Manfred)
remove redundant #include's (Niels Kristian Bech Jensen)
The new task_struct.h may be useful to others. If linux/sched.h is included
just to permit dereference of some 'struct task_struct * tsk',
linux/task_struct.h is a lightweight alternative.
Thanks again to Niels Kristian Bech Jensen, Andrew Morgan, and Manfred
Spraul.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
k7-smp-inlined2.patch.gz
[PATCH] Athlon-SMP final
Hi Alan,
The polishing is done. Versus 2.4.1 again.
Summary:
struct task_struct{...} moved to a new file, linux/task_struct.h.
struct sigpending{...} moved to a new file, linux/sigpending.h.
remove line linux/capability.c:17 #include linux/fs.h (blessed by Andrew
Morgan)
adjust header inclusions in CONFIG_X386_USE_3DNOW section of
asm-i386/string.h.
Changes from the first version of the patch:
revert creation of linux/mm_struct.h (needless)
improve comments in the new files
remove #ifdef guards around dummy declarations (suggested by Manfred
Spraul)
remove dead version of kernel_cap_t support (also Manfred)
remove redundant #include's (Niels Kristian Bech Jensen)
The new task_struct.h may be useful to others. If linux/sched.h is included
just to permit dereference of some 'struct task_struct * tsk',
linux/task_struct.h is a lightweight alternative.
Thanks again to Niels Kristian Bech Jensen, Andrew Morgan, and Manfred
Spraul.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
k7-smp-inlined2.patch.gz
Re: [PATCH] Athlon-SMP compiles & runs. inline fns honored.
Manfred Spraul wrote:
>
> Tom Leete wrote:
> >
> > +
> > +#ifndef _LINUX_MM_H
> > +struct vm_area_struct;
> > +#endif
> > +
> Are the #ifndef's necessary?
> Could you try to remove the #ifndef and always declare the struct? gcc
> shouldn't complain.
Probably not necessary, but that seemed tidier if the struct definition is
available.
>
> > +
> > +/* Try removing /linux/fs.h in capability.h first
> > +#ifndef _LINUX_CAPABILITY_H
> > +typedef struct bogus_cap_struct {
> > + __u32 cap;
> > +} kernel_cap_t;
> > +#endif
> > +*/
> > +
> Is is possible to get rid of that one?
> What if somone modifies capability.h?
Yes, that's provisional and is superfluous if 'capability.h:17 #include
' is to be removed. It is commented out in the preliminary
patch. Awaiting comment from the authors.
>
> --
> Manfred
After critique is in, I'll make a polished final version.
Thanks for the review,
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
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/
[PATCH] Athlon-SMP compiles & runs. inline fns honored.
Hi Alan
I found one way to break the circularity. The association of type and struct
definitions with interlocking inline functions caused the problem. This
extracts task_struct from linux/sched.h to its own header,
linux/task_struct.h. There are a few modifications elsewhere to support
this. I'm not sure all the changes were necessary, but they are working as I
write:
$ uname -a
Linux mercury 2.4.1 #3 SMP Sat Feb 10 08:28:39 EST 2001 i686 unknown
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 1
model name : AMD-K7(tm) Processor
stepping: 2
cpu MHz : 704.949
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx
syscall mmxext 3dnowext 3dnow
bogomips: 1405.74
I don't have access to a real SMP Athlon box, so I'd appreciate test reports
on the real thing. I expect some polishing will be needed.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
diff -uNr linux-2.4.1-pristine/include/asm-i386/string.h
linux/include/asm-i386/string.h
--- linux-2.4.1-pristine/include/asm-i386/string.h Tue Feb 6 03:55:24 2001
+++ linux/include/asm-i386/string.h Sat Feb 10 08:28:32 2001
@@ -289,10 +289,9 @@
/* All this just for in_interrupt() ... */
-#include
-#include
+#include
+#include
#include
-#include
#include
#include
diff -uNr linux-2.4.1-pristine/include/linux/capability.h
linux/include/linux/capability.h
--- linux-2.4.1-pristine/include/linux/capability.h Thu Feb 8 23:55:24 2001
+++ linux/include/linux/capability.hSat Feb 10 07:41:19 2001
@@ -14,7 +14,9 @@
#define _LINUX_CAPABILITY_H
#include
+/* Try removing -- we'll see if there are parasitic users
#include
+*/
/* User-level do most of the mapping between kernel and user
capabilities based on the version tag given by the kernel. The
diff -uNr linux-2.4.1-pristine/include/linux/mm_struct.h
linux/include/linux/mm_struct.h
--- linux-2.4.1-pristine/include/linux/mm_struct.h Wed Dec 31 19:00:00 1969
+++ linux/include/linux/mm_struct.h Sat Feb 10 08:02:15 2001
@@ -0,0 +1,47 @@
+#ifndef _LINUX_MM_STRUCT_H
+#define _LINUX_MM_STRUCT_H
+/*
+ * linux/struct_mm.h
+ * Extracted from linux/sched.h: 02/09/2001 Tom Leete
+ *
+ */
+
+#ifdef __KERNEL__
+
+#include
+#include
+#include
+#include
+
+
+#ifndef _LINUX_MM_H
+struct vm_area_struct;
+#endif
+
+struct mm_struct {
+ struct vm_area_struct * mmap; /* list of VMAs */
+ struct vm_area_struct * mmap_avl; /* tree of VMAs */
+ struct vm_area_struct * mmap_cache; /* last find_vma result */
+ pgd_t * pgd;
+ atomic_t mm_users; /* How many users with user space? */
+ atomic_t mm_count; /* How many references to "struct
+mm_struct" (users count as 1) */
+ int map_count; /* number of VMAs */
+ struct semaphore mmap_sem;
+ spinlock_t page_table_lock;
+
+ struct list_head mmlist;/* List of all active mm's */
+
+ unsigned long start_code, end_code, start_data, end_data;
+ unsigned long start_brk, brk, start_stack;
+ unsigned long arg_start, arg_end, env_start, env_end;
+ unsigned long rss, total_vm, locked_vm;
+ unsigned long def_flags;
+ unsigned long cpu_vm_mask;
+ unsigned long swap_address;
+
+ /* Architecture-specific MM context */
+ mm_context_t context;
+};
+
+#endif /* __KERNEL__ */
+#endif /* _LINUX_MM_STRUCT_H */
diff -uNr linux-2.4.1-pristine/include/linux/sched.h linux/include/linux/sched.h
--- linux-2.4.1-pristine/include/linux/sched.h Thu Feb 8 23:55:24 2001
+++ linux/include/linux/sched.h Sat Feb 10 08:28:32 2001
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -200,30 +201,7 @@
/* Number of map areas at which the AVL tree is activated. This is arbitrary. */
#define AVL_MIN_MAP_COUNT 32
-struct mm_struct {
- struct vm_area_struct * mmap; /* list of VMAs */
- struct vm_area_struct * mmap_avl; /* tree of VMAs */
- struct vm_area_struct * mmap_cache; /* last find_vma result */
- pgd_t * pgd;
- atomic_t mm_users; /* How many users with user space? */
- atomic_t mm_count; /* How many references to "struct
mm_struct" (users count as 1) */
- int map_count; /* number of VMAs */
- struct semaphore mmap_sem;
- spinlock_t page_table_lock;
-
- struct list_head mmlist;/* List of all active mm's */
-
- unsigned long start_code, end_code, start_data, end_data;
- unsigned long start_b
[PATCH] Athlon-SMP compiles runs. inline fns honored.
Hi Alan
I found one way to break the circularity. The association of type and struct
definitions with interlocking inline functions caused the problem. This
extracts task_struct from linux/sched.h to its own header,
linux/task_struct.h. There are a few modifications elsewhere to support
this. I'm not sure all the changes were necessary, but they are working as I
write:
$ uname -a
Linux mercury 2.4.1 #3 SMP Sat Feb 10 08:28:39 EST 2001 i686 unknown
$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 1
model name : AMD-K7(tm) Processor
stepping: 2
cpu MHz : 704.949
cache size : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat mmx
syscall mmxext 3dnowext 3dnow
bogomips: 1405.74
I don't have access to a real SMP Athlon box, so I'd appreciate test reports
on the real thing. I expect some polishing will be needed.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
diff -uNr linux-2.4.1-pristine/include/asm-i386/string.h
linux/include/asm-i386/string.h
--- linux-2.4.1-pristine/include/asm-i386/string.h Tue Feb 6 03:55:24 2001
+++ linux/include/asm-i386/string.h Sat Feb 10 08:28:32 2001
@@ -289,10 +289,9 @@
/* All this just for in_interrupt() ... */
-#include asm/system.h
-#include asm/ptrace.h
+#include linux/task_struct.h
+#include asm/current.h
#include linux/smp.h
-#include linux/spinlock.h
#include linux/interrupt.h
#include asm/mmx.h
diff -uNr linux-2.4.1-pristine/include/linux/capability.h
linux/include/linux/capability.h
--- linux-2.4.1-pristine/include/linux/capability.h Thu Feb 8 23:55:24 2001
+++ linux/include/linux/capability.hSat Feb 10 07:41:19 2001
@@ -14,7 +14,9 @@
#define _LINUX_CAPABILITY_H
#include linux/types.h
+/* Try removing -- we'll see if there are parasitic users
#include linux/fs.h
+*/
/* User-level do most of the mapping between kernel and user
capabilities based on the version tag given by the kernel. The
diff -uNr linux-2.4.1-pristine/include/linux/mm_struct.h
linux/include/linux/mm_struct.h
--- linux-2.4.1-pristine/include/linux/mm_struct.h Wed Dec 31 19:00:00 1969
+++ linux/include/linux/mm_struct.h Sat Feb 10 08:02:15 2001
@@ -0,0 +1,47 @@
+#ifndef _LINUX_MM_STRUCT_H
+#define _LINUX_MM_STRUCT_H
+/*
+ * linux/struct_mm.h
+ * Extracted from linux/sched.h: 02/09/2001 Tom Leete
+ *
+ */
+
+#ifdef __KERNEL__
+
+#include linux/list.h
+#include asm/atomic.h
+#include asm/semaphore.h
+#include asm/spinlock.h
+
+
+#ifndef _LINUX_MM_H
+struct vm_area_struct;
+#endif
+
+struct mm_struct {
+ struct vm_area_struct * mmap; /* list of VMAs */
+ struct vm_area_struct * mmap_avl; /* tree of VMAs */
+ struct vm_area_struct * mmap_cache; /* last find_vma result */
+ pgd_t * pgd;
+ atomic_t mm_users; /* How many users with user space? */
+ atomic_t mm_count; /* How many references to "struct
+mm_struct" (users count as 1) */
+ int map_count; /* number of VMAs */
+ struct semaphore mmap_sem;
+ spinlock_t page_table_lock;
+
+ struct list_head mmlist;/* List of all active mm's */
+
+ unsigned long start_code, end_code, start_data, end_data;
+ unsigned long start_brk, brk, start_stack;
+ unsigned long arg_start, arg_end, env_start, env_end;
+ unsigned long rss, total_vm, locked_vm;
+ unsigned long def_flags;
+ unsigned long cpu_vm_mask;
+ unsigned long swap_address;
+
+ /* Architecture-specific MM context */
+ mm_context_t context;
+};
+
+#endif /* __KERNEL__ */
+#endif /* _LINUX_MM_STRUCT_H */
diff -uNr linux-2.4.1-pristine/include/linux/sched.h linux/include/linux/sched.h
--- linux-2.4.1-pristine/include/linux/sched.h Thu Feb 8 23:55:24 2001
+++ linux/include/linux/sched.h Sat Feb 10 08:28:32 2001
@@ -11,6 +11,7 @@
#include linux/threads.h
#include linux/kernel.h
#include linux/types.h
+#include linux/time.h
#include linux/times.h
#include linux/timex.h
@@ -200,30 +201,7 @@
/* Number of map areas at which the AVL tree is activated. This is arbitrary. */
#define AVL_MIN_MAP_COUNT 32
-struct mm_struct {
- struct vm_area_struct * mmap; /* list of VMAs */
- struct vm_area_struct * mmap_avl; /* tree of VMAs */
- struct vm_area_struct * mmap_cache; /* last find_vma result */
- pgd_t * pgd;
- atomic_t mm_users; /* How many users with user space? */
- atomic_t mm_count; /* How many references to "struct
mm_struct" (users count as 1) */
- int map_count; /* number of VM
Re: [PATCH] Athlon-SMP compiles runs. inline fns honored.
Manfred Spraul wrote:
Tom Leete wrote:
+
+#ifndef _LINUX_MM_H
+struct vm_area_struct;
+#endif
+
Are the #ifndef's necessary?
Could you try to remove the #ifndef and always declare the struct? gcc
shouldn't complain.
Probably not necessary, but that seemed tidier if the struct definition is
available.
+
+/* Try removing /linux/fs.h in capability.h first
+#ifndef _LINUX_CAPABILITY_H
+typedef struct bogus_cap_struct {
+ __u32 cap;
+} kernel_cap_t;
+#endif
+*/
+
Is is possible to get rid of that one?
What if somone modifies capability.h?
Yes, that's provisional and is superfluous if 'capability.h:17 #include
linux/fs.h' is to be removed. It is commented out in the preliminary
patch. Awaiting comment from the authors.
--
Manfred
After critique is in, I'll make a polished final version.
Thanks for the review,
Tom
--
The Daemons lurk and are dumb. -- Emerson
-
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: 2.4.x and SMP fails to compile (`current' undefined)
Andre Hedrick wrote: > > Make it and I will care and post it on kernel.org for you. > I need that patch soon. > > On Thu, 1 Feb 2001, Tom Leete wrote: > > > Alan Cox wrote: > > > The string.h code was fine, someone came along and put in a ridiculous loop > > > in the include dependancies and broke it. Nobody has had the time to untangle > > > it cleanly since > > > > Yes, bitrot. I don't see a rearrangement of system headers happening in 2.4. > > I'm pretty sure if I committed such a patch it would have no measurable > > lifetime. Hi Andre, I meant that nobody should be reshuffling 2.4 headers now, didn't intend to sound like I take that personally. I'll take a look. I may be able to do something with include guards or other #defines + multiple passes. We already have the multiple passes. I think my arguments for the present patch are good. I'm making a mod of Arjan's athlon.c to see if I'm right. If you have a suggestion for another benchmark, I'd like to hear about it. Whatever the results, I'll post them here. Glad if whatever comes out is useful to you. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: 2.4.x and SMP fails to compile (`current' undefined)
Alan Cox wrote: > > We have a very large number of memcpy's of unknown short length (often in > interrupts) that are close to branches. A lot of > > if(foo==NULL) > return > memcpy(.. > > stuff for example. > > Im more than happy for someone to do the benches and prove me wrong Agreed, that is a bad case, and there is overhead for it in my patch. I'm putting together some metrics, will post results here. Regards, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: 2.4.x and SMP fails to compile (`current' undefined)
Alan Cox wrote: > > > It's not an incompatibility with the k7 chip, just bad code in > > include/asm-i386/string.h. in_interrupt() cannot be called from there. > > The string.h code was fine, someone came along and put in a ridiculous loop > in the include dependancies and broke it. Nobody has had the time to untangle > it cleanly since Yes, bitrot. I don't see a rearrangement of system headers happening in 2.4. I'm pretty sure if I committed such a patch it would have no measurable lifetime. > > > I have posted a patch here many times since last May. Most recent was > > Saturday. > > uninlining the code is too high a cost. I question that. Athlon does branch prediction on call targets, function calls are cheap. 3dnow saves 25%-50% of cycles on a copy. How many function calls can be paid for with 1000 cycles or so? My patch still inlines the standard string const_memcpy for the case of small known length. If I configure SMP for a UP box, performance is clearly not my first concern. If I have a real SMP Athlon system, performance should not improve by only using one processor. How about we get it to build before we optimize it? Regards, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: 2.4.x and SMP fails to compile (`current' undefined)
Alan Cox wrote: It's not an incompatibility with the k7 chip, just bad code in include/asm-i386/string.h. in_interrupt() cannot be called from there. The string.h code was fine, someone came along and put in a ridiculous loop in the include dependancies and broke it. Nobody has had the time to untangle it cleanly since Yes, bitrot. I don't see a rearrangement of system headers happening in 2.4. I'm pretty sure if I committed such a patch it would have no measurable lifetime. I have posted a patch here many times since last May. Most recent was Saturday. uninlining the code is too high a cost. I question that. Athlon does branch prediction on call targets, function calls are cheap. 3dnow saves 25%-50% of cycles on a copy. How many function calls can be paid for with 1000 cycles or so? My patch still inlines the standard string const_memcpy for the case of small known length. If I configure SMP for a UP box, performance is clearly not my first concern. If I have a real SMP Athlon system, performance should not improve by only using one processor. How about we get it to build before we optimize it? Regards, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: 2.4.x and SMP fails to compile (`current' undefined)
Alan Cox wrote: We have a very large number of memcpy's of unknown short length (often in interrupts) that are close to branches. A lot of if(foo==NULL) return memcpy(.. stuff for example. Im more than happy for someone to do the benches and prove me wrong Agreed, that is a bad case, and there is overhead for it in my patch. I'm putting together some metrics, will post results here. Regards, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: 2.4.x and SMP fails to compile (`current' undefined)
Andre Hedrick wrote: Make it and I will care and post it on kernel.org for you. I need that patch soon. On Thu, 1 Feb 2001, Tom Leete wrote: Alan Cox wrote: The string.h code was fine, someone came along and put in a ridiculous loop in the include dependancies and broke it. Nobody has had the time to untangle it cleanly since Yes, bitrot. I don't see a rearrangement of system headers happening in 2.4. I'm pretty sure if I committed such a patch it would have no measurable lifetime. Hi Andre, I meant that nobody should be reshuffling 2.4 headers now, didn't intend to sound like I take that personally. I'll take a look. I may be able to do something with include guards or other #defines + multiple passes. We already have the multiple passes. I think my arguments for the present patch are good. I'm making a mod of Arjan's athlon.c to see if I'm right. If you have a suggestion for another benchmark, I'd like to hear about it. Whatever the results, I'll post them here. Glad if whatever comes out is useful to you. Cheers, Tom -- The Daemons lurk and are dumb. -- Emerson - 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: 2.4.x and SMP fails to compile (`current' undefined)
Peter Samuelson wrote: > > [Tom Leete] > > It's not an incompatibility with the k7 chip, just bad code in > > include/asm-i386/string.h. > > So you're saying SMP *is* supported on Athlon? Do motherboards exist? > > Peter No, I'm saying that SMP locking etc. is compatible with Athlon. The failure to build is not a workaround but a coding error. SMP builds for UP machines are supposed to work. Tom -- The Daemons lurk and are dumb. -- Emerson - 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: 2.4.x and SMP fails to compile (`current' undefined)
David Ford wrote: > > Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP? > > > > -d > > Stephen Frost wrote: > > > * David Ford ([EMAIL PROTECTED]) wrote: > > > A person just brought up a problem in #kernelnewbies, building an SMP > > > kernel doesn't work very well, current is undefined. I don't have more > > > time to debug it but I'll strip the config and put it up at > > > http://stuph.org/smp-config > > > > They're trying to compile SMP for Athlon/K7 (CONFIG_MK7=y). > It's not an incompatibility with the k7 chip, just bad code in include/asm-i386/string.h. in_interrupt() cannot be called from there. I have posted a patch here many times since last May. Most recent was Saturday. Tom -- The Daemons lurk and are dumb. -- Emerson - 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: 2.4.x and SMP fails to compile (`current' undefined)
David Ford wrote: Mhm. Is it worth the effort to make a dependancy on the CPU type for SMP? /idle questions -d Stephen Frost wrote: * David Ford ([EMAIL PROTECTED]) wrote: A person just brought up a problem in #kernelnewbies, building an SMP kernel doesn't work very well, current is undefined. I don't have more time to debug it but I'll strip the config and put it up at http://stuph.org/smp-config They're trying to compile SMP for Athlon/K7 (CONFIG_MK7=y). It's not an incompatibility with the k7 chip, just bad code in include/asm-i386/string.h. in_interrupt() cannot be called from there. I have posted a patch here many times since last May. Most recent was Saturday. Tom -- The Daemons lurk and are dumb. -- Emerson - 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: SMP Athlon...(a quiet question)
Andre Hedrick wrote:
>
> ER, they work but must compile as PII/Celeron :-(
> A bunch of memcpy header stuff fails to compile
> current is one of the left overs in some cases.
>
> I will dive deeper in monday, just wanting some feed back first.
>
> Cheers,
>
> Andre Hedrick
> Linux ATA Development
>
> -
> 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/
Hello Andre,
I think that there is no good way to use in_interrupt() in asm/string.h.
Circular dependencies.
I've been using some form of this patch since last May, posted here several
times. It moves the mmx style memcpy into lib.a (mmx.c). I lose some
inlining, but since k7 does branch prediction for call addresses, inline
functions are somewhat less of a win. Certainly the big speedup from mmx is
more than enough to pay for it.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
--- linux/arch/i386/lib/mmx.c.orig Wed Oct 27 21:30:39 1999
+++ linux/arch/i386/lib/mmx.c Tue Jun 6 04:20:01 2000
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
/*
* MMX 3DNow! library helper functions
@@ -88,6 +89,21 @@
stts();
return p;
}
+
+void * __constant_mmx_memcpy3d(void * to, const void * from, size_t len)
+{
+ if(in_interrupt())
+ return __constant_memcpy(to, from, len);
+ return _mmx_memcpy(to, from, len);
+}
+
+void *__mmx_memcpy3d(void *to, const void *from, size_t len)
+{
+ if(in_interrupt())
+ return __memcpy(to, from, len);
+ return _mmx_memcpy(to, from, len);
+}
+
static void fast_clear_page(void *page)
{
--- linux/include/asm-i386/mmx.h.orig Tue Jun 6 03:05:02 2000
+++ linux/include/asm-i386/mmx.hTue Jun 6 04:25:27 2000
@@ -10,5 +10,7 @@
extern void *_mmx_memcpy(void *to, const void *from, size_t size);
extern void mmx_clear_page(void *page);
extern void mmx_copy_page(void *to, void *from);
+extern __inline__ void *__constant_mmx_memcpy3d(void * to, const void * from, size_t
+len);
+extern __inline__ void *__mmx_memcpy3d(void *to, const void *from, size_t len);
#endif
--- linux/include/asm-i386/string.h.origTue Jun 6 03:05:02 2000
+++ linux/include/asm-i386/string.h Tue Jun 6 04:30:37 2000
@@ -287,13 +287,6 @@
#ifdef CONFIG_X86_USE_3DNOW
-/* All this just for in_interrupt() ... */
-
-#include
-#include
-#include
-#include
-#include
#include
/*
@@ -302,16 +295,16 @@
static inline void * __constant_memcpy3d(void * to, const void * from, size_t len)
{
- if(len<512 || in_interrupt())
+ if(len<512)
return __constant_memcpy(to, from, len);
- return _mmx_memcpy(to, from, len);
+ return __constant_mmx_memcpy3d(to, from, len);
}
extern __inline__ void *__memcpy3d(void *to, const void *from, size_t len)
{
- if(len<512 || in_interrupt())
+ if(len<512)
return __memcpy(to, from, len);
- return _mmx_memcpy(to, from, len);
+ return __mmx_memcpy3d(to, from, len);
}
#define memcpy(t, f, n) \
Re: SMP Athlon...(a quiet question)
Andre Hedrick wrote:
ER, they work but must compile as PII/Celeron :-(
A bunch of memcpy header stuff fails to compile
current is one of the left overs in some cases.
I will dive deeper in monday, just wanting some feed back first.
Cheers,
Andre Hedrick
Linux ATA Development
-
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/
Hello Andre,
I think that there is no good way to use in_interrupt() in asm/string.h.
Circular dependencies.
I've been using some form of this patch since last May, posted here several
times. It moves the mmx style memcpy into lib.a (mmx.c). I lose some
inlining, but since k7 does branch prediction for call addresses, inline
functions are somewhat less of a win. Certainly the big speedup from mmx is
more than enough to pay for it.
Cheers,
Tom
--
The Daemons lurk and are dumb. -- Emerson
--- linux/arch/i386/lib/mmx.c.orig Wed Oct 27 21:30:39 1999
+++ linux/arch/i386/lib/mmx.c Tue Jun 6 04:20:01 2000
@@ -1,6 +1,7 @@
#include linux/types.h
#include linux/string.h
#include linux/sched.h
+#include asm/hardirq.h
/*
* MMX 3DNow! library helper functions
@@ -88,6 +89,21 @@
stts();
return p;
}
+
+void * __constant_mmx_memcpy3d(void * to, const void * from, size_t len)
+{
+ if(in_interrupt())
+ return __constant_memcpy(to, from, len);
+ return _mmx_memcpy(to, from, len);
+}
+
+void *__mmx_memcpy3d(void *to, const void *from, size_t len)
+{
+ if(in_interrupt())
+ return __memcpy(to, from, len);
+ return _mmx_memcpy(to, from, len);
+}
+
static void fast_clear_page(void *page)
{
--- linux/include/asm-i386/mmx.h.orig Tue Jun 6 03:05:02 2000
+++ linux/include/asm-i386/mmx.hTue Jun 6 04:25:27 2000
@@ -10,5 +10,7 @@
extern void *_mmx_memcpy(void *to, const void *from, size_t size);
extern void mmx_clear_page(void *page);
extern void mmx_copy_page(void *to, void *from);
+extern __inline__ void *__constant_mmx_memcpy3d(void * to, const void * from, size_t
+len);
+extern __inline__ void *__mmx_memcpy3d(void *to, const void *from, size_t len);
#endif
--- linux/include/asm-i386/string.h.origTue Jun 6 03:05:02 2000
+++ linux/include/asm-i386/string.h Tue Jun 6 04:30:37 2000
@@ -287,13 +287,6 @@
#ifdef CONFIG_X86_USE_3DNOW
-/* All this just for in_interrupt() ... */
-
-#include asm/system.h
-#include asm/ptrace.h
-#include linux/smp.h
-#include linux/spinlock.h
-#include linux/interrupt.h
#include asm/mmx.h
/*
@@ -302,16 +295,16 @@
static inline void * __constant_memcpy3d(void * to, const void * from, size_t len)
{
- if(len512 || in_interrupt())
+ if(len512)
return __constant_memcpy(to, from, len);
- return _mmx_memcpy(to, from, len);
+ return __constant_mmx_memcpy3d(to, from, len);
}
extern __inline__ void *__memcpy3d(void *to, const void *from, size_t len)
{
- if(len512 || in_interrupt())
+ if(len512)
return __memcpy(to, from, len);
- return _mmx_memcpy(to, from, len);
+ return __mmx_memcpy3d(to, from, len);
}
#define memcpy(t, f, n) \
Re: 2.4.1-pre8 and Athlon
Peter Horton wrote: > > Building 2.4.1-pre8 for K7 gives 'current' undefined errors in the headers > included from init/main.c. Looks like something included from asm/string.h > is missing an include. The problems go away if I remove > CONFIG_X86_USE3DNOW=y from the config. > > P. The other choices are to disable SMP, or use one of the patches posted here: Petr Vandrovec's or mine. Tom - 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: 2.4.1-pre8 and Athlon
Peter Horton wrote: Building 2.4.1-pre8 for K7 gives 'current' undefined errors in the headers included from init/main.c. Looks like something included from asm/string.h is missing an include. The problems go away if I remove CONFIG_X86_USE3DNOW=y from the config. P. The other choices are to disable SMP, or use one of the patches posted here: Petr Vandrovec's or mine. Tom - 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: Anybody got 2.4.0 running on a 386 ?
Robert Kaiser wrote: > > Hi list, > > I can't seem to get the new 2.4.0 kernel running on a 386 CPU. > The kernel was built for a 386 Processor, Math emulation has been enabled. > I tried three different 386 boards. Execution seems to get as far as > pagetable_init() in arch/i386/mm/init.c, then it falls back into the BIOS as > if someone had pressed the reset button. The same kernel boots fine on > 486 and Pentium Systems. ^^^ > > Any ideas/suggestions ? > > Rob > This may be off the wall, but since the 386 is diskless the kernel was obviously built elsewhere. Had that tree previously been used for a 486 build? You might decompile vmlinux and look for non-386 instructions at or prior to the crash point. It might be faster to recompile from 'make mrproper' and see if it works then. Tom - 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: Anybody got 2.4.0 running on a 386 ?
Robert Kaiser wrote: Hi list, I can't seem to get the new 2.4.0 kernel running on a 386 CPU. The kernel was built for a 386 Processor, Math emulation has been enabled. I tried three different 386 boards. Execution seems to get as far as pagetable_init() in arch/i386/mm/init.c, then it falls back into the BIOS as if someone had pressed the reset button. The same kernel boots fine on 486 and Pentium Systems. ^^^ Any ideas/suggestions ? Rob This may be off the wall, but since the 386 is diskless the kernel was obviously built elsewhere. Had that tree previously been used for a 486 build? You might decompile vmlinux and look for non-386 instructions at or prior to the crash point. It might be faster to recompile from 'make mrproper' and see if it works then. Tom - 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: Kernel compile trouble
Johan Groth wrote: > > Hi, > I wonder if anyone can help me with compilation of kernel 2.4.0. I've > run make mrproper; make menuconfig; make dep and then I try to build the > kernel with make bzImage but that fails utterly. I get the following > message: [...] > /usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d': > /usr/src/linux/include/asm/string.h:305: `current' undeclared (first use > in this function) > /usr/src/linux/include/asm/string.h: In function `__memcpy3d': > /usr/src/linux/include/asm/string.h:312: `current' undeclared (first use > in this function) > make: *** [init/main.o] Error 1 > Hello, You don't show your .config, but I'll make a wild guess you're compiling for SMP+3DNow (probably by selecting Athlon processor). If so pick one of: a) Deselect SMP, make clean make dep, etc. b) Downgrade processor selection to i686 or k6 c) See the patch I posted here Tuesday. Petr Vandrovec also posted a patch which takes a quite different approach. Cheers, Tom - 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: Kernel compile trouble
Johan Groth wrote: Hi, I wonder if anyone can help me with compilation of kernel 2.4.0. I've run make mrproper; make menuconfig; make dep and then I try to build the kernel with make bzImage but that fails utterly. I get the following message: [...] /usr/src/linux/include/asm/string.h: In function `__constant_memcpy3d': /usr/src/linux/include/asm/string.h:305: `current' undeclared (first use in this function) /usr/src/linux/include/asm/string.h: In function `__memcpy3d': /usr/src/linux/include/asm/string.h:312: `current' undeclared (first use in this function) make: *** [init/main.o] Error 1 Hello, You don't show your .config, but I'll make a wild guess you're compiling for SMP+3DNow (probably by selecting Athlon processor). If so pick one of: a) Deselect SMP, make clean make dep, etc. b) Downgrade processor selection to i686 or k6 c) See the patch I posted here Tuesday. Petr Vandrovec also posted a patch which takes a quite different approach. Cheers, Tom - 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: [OOPS] testing/prerelease of 01/03 on startup
Linus Torvalds wrote: > > On Thu, 4 Jan 2001, Tom Leete wrote: > > > > kernel is 2.4.0-prerelease with testing/prerelease patch of Jan. 3, i486. > > Oops is repeatable. > > Looks like your mm->mmlist list is corrupted from the very start. > > Can you humor me and make sure you do a "make clean" and re-check your > prerelease patch? Is the initialization of mmlist there in linux/sched.h, > for example? > > Linus Ahh... oops is on me. Patch was ok, but there must have been cruft from another build. A rebuild from clean seems to have cured it. Sorry for the noise, Tom - 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/
[OOPS] testing/prerelease of 01/03 on startup
Hello, kernel is 2.4.0-prerelease with testing/prerelease patch of Jan. 3, i486. Oops is repeatable. I caught this one on serial console just as init begins: $ ksymoops -K -L -O -v /boot/vmlinux-2.4.0-prerelease -m /boot/System.map-2.4.0-prerelease tleete.prerelease.oops ksymoops 2.3.5 on i486 2.4.0-test13-pre4. Options used -v /boot/vmlinux-2.4.0-prerelease (specified) -K (specified) -L (specified) -O (specified) -m /boot/System.map-2.4.0-prerelease (specified) Unable to handle kernel paging request at virtual address 08048004 c011240a *pde = 01151067 Oops: 0003 CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 08048000 ebx: c1169120 ecx: c11690ac edx: c1169090 esi: c1169090 edi: c1169154 ebp: esp: c11dbf28 ds: 0018 es: 0018 ss: 0018 Process init (pid: 1, stackpage=c11db000) Stack: c3758000 c116a534 c116aa44 c02210c0 c1167550 c11da000 c11690c4 c1169154 c11690ac c11da000 c116755c c1169090 c0112c52 0011 c3758000 c11da000 ba18 b998 c11dbfbc c11dbf94 fff4 Call Trace: [] [] [] [] Code: 89 78 04 89 43 34 8b 44 24 18 89 47 04 89 7e 34 85 ed 75 22 >>EIP; c011240a<= Trace; c0112c52 Trace; c0107804 Trace; c0108e63 Trace; c0100023 Code; c011240a <_EIP>: Code; c011240a<= 0: 89 78 04 mov%edi,0x4(%eax) <= Code; c011240d 3: 89 43 34 mov%eax,0x34(%ebx) Code; c0112410 6: 8b 44 24 18 mov0x18(%esp,1),%eax Code; c0112414 a: 89 47 04 mov%eax,0x4(%edi) Code; c0112417 d: 89 7e 34 mov%edi,0x34(%esi) Code; c011241a 10: 85 ed test %ebp,%ebp Code; c011241c 12: 75 22 jne36 <_EIP+0x36> c0112440 Kernel panic: Attempted to kill init! $ Everything is looged on the serial console machine, so if you need more, it's here. Hope this helps, Tom - 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/
[OOPS] testing/prerelease of 01/03 on startup
Hello, kernel is 2.4.0-prerelease with testing/prerelease patch of Jan. 3, i486. Oops is repeatable. I caught this one on serial console just as init begins: $ ksymoops -K -L -O -v /boot/vmlinux-2.4.0-prerelease -m /boot/System.map-2.4.0-prerelease tleete.prerelease.oops ksymoops 2.3.5 on i486 2.4.0-test13-pre4. Options used -v /boot/vmlinux-2.4.0-prerelease (specified) -K (specified) -L (specified) -O (specified) -m /boot/System.map-2.4.0-prerelease (specified) Unable to handle kernel paging request at virtual address 08048004 c011240a *pde = 01151067 Oops: 0003 CPU:0 EIP:0010:[c011240a] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010202 eax: 08048000 ebx: c1169120 ecx: c11690ac edx: c1169090 esi: c1169090 edi: c1169154 ebp: esp: c11dbf28 ds: 0018 es: 0018 ss: 0018 Process init (pid: 1, stackpage=c11db000) Stack: c3758000 c116a534 c116aa44 c02210c0 c1167550 c11da000 c11690c4 c1169154 c11690ac c11da000 c116755c c1169090 c0112c52 0011 c3758000 c11da000 ba18 b998 c11dbfbc c11dbf94 fff4 Call Trace: [c0112c52] [c0107804] [c0108e63] [c0100023] Code: 89 78 04 89 43 34 8b 44 24 18 89 47 04 89 7e 34 85 ed 75 22 EIP; c011240a copy_mm+27a/2d0 = Trace; c0112c52 do_fork+472/6c0 Trace; c0107804 sys_fork+14/20 Trace; c0108e63 system_call+33/40 Trace; c0100023 startup_32+23/139 Code; c011240a copy_mm+27a/2d0 _EIP: Code; c011240a copy_mm+27a/2d0 = 0: 89 78 04 mov%edi,0x4(%eax) = Code; c011240d copy_mm+27d/2d0 3: 89 43 34 mov%eax,0x34(%ebx) Code; c0112410 copy_mm+280/2d0 6: 8b 44 24 18 mov0x18(%esp,1),%eax Code; c0112414 copy_mm+284/2d0 a: 89 47 04 mov%eax,0x4(%edi) Code; c0112417 copy_mm+287/2d0 d: 89 7e 34 mov%edi,0x34(%esi) Code; c011241a copy_mm+28a/2d0 10: 85 ed test %ebp,%ebp Code; c011241c copy_mm+28c/2d0 12: 75 22 jne36 _EIP+0x36 c0112440 copy_mm+2b0/2d0 Kernel panic: Attempted to kill init! $ Everything is looged on the serial console machine, so if you need more, it's here. Hope this helps, Tom - 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: [OOPS] testing/prerelease of 01/03 on startup
Linus Torvalds wrote: On Thu, 4 Jan 2001, Tom Leete wrote: kernel is 2.4.0-prerelease with testing/prerelease patch of Jan. 3, i486. Oops is repeatable. Looks like your mm-mmlist list is corrupted from the very start. Can you humor me and make sure you do a "make clean" and re-check your prerelease patch? Is the initialization of mmlist there in linux/sched.h, for example? Linus Ahh... oops is on me. Patch was ok, but there must have been cruft from another build. A rebuild from clean seems to have cured it. Sorry for the noise, Tom - 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/
[PATCH] Re: 2.4.0-testX fails to compile on my Athlon
Matt Wright wrote:
>
> I've looked for answers to this question before, but all I could find was
> someone asking a similar question and no replies...
>
> I'm having great trouble getting 2.4.0-testX to compile on my system when
> I select Athlon/K7 as the Processor Family
>
> I've attached below the error's I'm getting the kernel DOES compile if
> I select anything else... but I don't have anything else :)
>
Hello,
The problem with SMP+K7 builds is that include/asm-i386/string.h has no
business using in_interrupt(). That introduces circular dependencies which
nobody has been able to rearrange away.
Here is a patch I've posted here several times. It moves the mmx functions
from string.h to arch/i386/lib/mmx.c (lib.a).It does not __inline__ the call
for memcpy() of large or unknown length. Athlon supposedly does branch
prediction for function pointers, so that shouldn't hurt too much. The point
is to get it to build: optimize later.
The actual usefulness of this may be limited to development on UP machines.
I don't know whether the AMD-760 SMP boards will be compatable with Linux
SMP. Hearsay is that they will have significant architectural differences
with Intel flavored SMP boards.
Cheers,
Tom
Patch as attachment to avoid mailer brain damage. It has not been tested
lately, but still applies cleanish.
--- linux/arch/i386/lib/mmx.c.orig Wed Oct 27 21:30:39 1999
+++ linux/arch/i386/lib/mmx.c Tue Jun 6 04:20:01 2000
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
/*
* MMX 3DNow! library helper functions
@@ -88,6 +89,21 @@
stts();
return p;
}
+
+void * __constant_mmx_memcpy3d(void * to, const void * from, size_t len)
+{
+ if(in_interrupt())
+ return __constant_memcpy(to, from, len);
+ return _mmx_memcpy(to, from, len);
+}
+
+void *__mmx_memcpy3d(void *to, const void *from, size_t len)
+{
+ if(in_interrupt())
+ return __memcpy(to, from, len);
+ return _mmx_memcpy(to, from, len);
+}
+
static void fast_clear_page(void *page)
{
--- linux/include/asm-i386/mmx.h.orig Tue Jun 6 03:05:02 2000
+++ linux/include/asm-i386/mmx.hTue Jun 6 04:25:27 2000
@@ -10,5 +10,7 @@
extern void *_mmx_memcpy(void *to, const void *from, size_t size);
extern void mmx_clear_page(void *page);
extern void mmx_copy_page(void *to, void *from);
+extern __inline__ void *__constant_mmx_memcpy3d(void * to, const void * from, size_t
+len);
+extern __inline__ void *__mmx_memcpy3d(void *to, const void *from, size_t len);
#endif
--- linux/include/asm-i386/string.h.origTue Jun 6 03:05:02 2000
+++ linux/include/asm-i386/string.h Tue Jun 6 04:30:37 2000
@@ -287,13 +287,6 @@
#ifdef CONFIG_X86_USE_3DNOW
-/* All this just for in_interrupt() ... */
-
-#include
-#include
-#include
-#include
-#include
#include
/*
@@ -302,16 +295,16 @@
static inline void * __constant_memcpy3d(void * to, const void * from, size_t len)
{
- if(len<512 || in_interrupt())
+ if(len<512)
return __constant_memcpy(to, from, len);
- return _mmx_memcpy(to, from, len);
+ return __constant_mmx_memcpy3d(to, from, len);
}
extern __inline__ void *__memcpy3d(void *to, const void *from, size_t len)
{
- if(len<512 || in_interrupt())
+ if(len<512)
return __memcpy(to, from, len);
- return _mmx_memcpy(to, from, len);
+ return __mmx_memcpy3d(to, from, len);
}
#define memcpy(t, f, n) \
[PATCH] Re: 2.4.0-testX fails to compile on my Athlon
Matt Wright wrote:
I've looked for answers to this question before, but all I could find was
someone asking a similar question and no replies...
I'm having great trouble getting 2.4.0-testX to compile on my system when
I select Athlon/K7 as the Processor Family
I've attached below the error's I'm getting the kernel DOES compile if
I select anything else... but I don't have anything else :)
Hello,
The problem with SMP+K7 builds is that include/asm-i386/string.h has no
business using in_interrupt(). That introduces circular dependencies which
nobody has been able to rearrange away.
Here is a patch I've posted here several times. It moves the mmx functions
from string.h to arch/i386/lib/mmx.c (lib.a).It does not __inline__ the call
for memcpy() of large or unknown length. Athlon supposedly does branch
prediction for function pointers, so that shouldn't hurt too much. The point
is to get it to build: optimize later.
The actual usefulness of this may be limited to development on UP machines.
I don't know whether the AMD-760 SMP boards will be compatable with Linux
SMP. Hearsay is that they will have significant architectural differences
with Intel flavored SMP boards.
Cheers,
Tom
Patch as attachment to avoid mailer brain damage. It has not been tested
lately, but still applies cleanish.
--- linux/arch/i386/lib/mmx.c.orig Wed Oct 27 21:30:39 1999
+++ linux/arch/i386/lib/mmx.c Tue Jun 6 04:20:01 2000
@@ -1,6 +1,7 @@
#include linux/types.h
#include linux/string.h
#include linux/sched.h
+#include asm/hardirq.h
/*
* MMX 3DNow! library helper functions
@@ -88,6 +89,21 @@
stts();
return p;
}
+
+void * __constant_mmx_memcpy3d(void * to, const void * from, size_t len)
+{
+ if(in_interrupt())
+ return __constant_memcpy(to, from, len);
+ return _mmx_memcpy(to, from, len);
+}
+
+void *__mmx_memcpy3d(void *to, const void *from, size_t len)
+{
+ if(in_interrupt())
+ return __memcpy(to, from, len);
+ return _mmx_memcpy(to, from, len);
+}
+
static void fast_clear_page(void *page)
{
--- linux/include/asm-i386/mmx.h.orig Tue Jun 6 03:05:02 2000
+++ linux/include/asm-i386/mmx.hTue Jun 6 04:25:27 2000
@@ -10,5 +10,7 @@
extern void *_mmx_memcpy(void *to, const void *from, size_t size);
extern void mmx_clear_page(void *page);
extern void mmx_copy_page(void *to, void *from);
+extern __inline__ void *__constant_mmx_memcpy3d(void * to, const void * from, size_t
+len);
+extern __inline__ void *__mmx_memcpy3d(void *to, const void *from, size_t len);
#endif
--- linux/include/asm-i386/string.h.origTue Jun 6 03:05:02 2000
+++ linux/include/asm-i386/string.h Tue Jun 6 04:30:37 2000
@@ -287,13 +287,6 @@
#ifdef CONFIG_X86_USE_3DNOW
-/* All this just for in_interrupt() ... */
-
-#include asm/system.h
-#include asm/ptrace.h
-#include linux/smp.h
-#include linux/spinlock.h
-#include linux/interrupt.h
#include asm/mmx.h
/*
@@ -302,16 +295,16 @@
static inline void * __constant_memcpy3d(void * to, const void * from, size_t len)
{
- if(len512 || in_interrupt())
+ if(len512)
return __constant_memcpy(to, from, len);
- return _mmx_memcpy(to, from, len);
+ return __constant_mmx_memcpy3d(to, from, len);
}
extern __inline__ void *__memcpy3d(void *to, const void *from, size_t len)
{
- if(len512 || in_interrupt())
+ if(len512)
return __memcpy(to, from, len);
- return _mmx_memcpy(to, from, len);
+ return __mmx_memcpy3d(to, from, len);
}
#define memcpy(t, f, n) \
Re: ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter locking)
"David S. Miller" wrote: > This is basically what is in my tree right now. However, there was > one reporter who claimed that after this kind of change he still was > able to lockup/OOPS his machine by logging into X as a user who had > his home directory over NFS. This was with netfilter enabled as well > so it has to be the same bug. > > Later, > David S. Miller > [EMAIL PROTECTED] 2.4.0-test12+ip_fragment.c.patch is still up. I hadn't previously tried client-side mounts on that box, just exports. I tried to reproduce the problem with nfs home directory mount + X. I am unable to generate the error -- it works for me. I think Alexey is right. There may be either coincidence or confusion in the report. Btw, I am able to compile a kernel over an nfs mount with this. Very handy since the remote is much faster at it. Cheers, Tom - 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: ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter locking)
Harald Welte wrote: > > On Mon, Dec 18, 2000 at 10:11:14AM -0800, David S. Miller wrote: > >From: Rusty Russell <[EMAIL PROTECTED]> > >Date: Mon, 18 Dec 2000 14:15:52 +1100 > > > >Alexey is right, locking is screwed (explains some reports of > >occasional failure during rmmod). > > > > Patch applied, thank you. > > > >I have a patch which compiles for non-linear skb mods to netfilter > >(NAT uses linear packets still, but connection tracking and packet > >filtering only linearize minimal requirements). Waiting for > >DaveM's solution to ip_ct_gather_frags()... > > > > I feel it's best to just skb_clone() the skb arg to ip_defrag > > and this will close the whole thing, I think. > > no. The clone()d skb will still have a skb->dev pointing to NULL. > > The problem occurs only for locally-generated outgoing packets, which > need to be fragmented: > > - ip_build_xmit() discoveres it has to fragment > - ip_build_xmit_slow() generates fragments and calls > - NF_HOOK() for NF_IP_LOCAL_OUT > - ip_conntrack_local() is called, which in turn calls > - ip_conntrack_in(), which calls > - ip_ct_gather_frags(), which calls > - ip_defrag(), which calls > > [now we have two possible oops - caues] > > a ip_find(), which calls > a ip_frag_create(), which initialises a timer with the function > a ip_expire(), which dereferences qp->iif > > b ip_frag_queue(), which dereferences it in qp->iif= skb->dev->ifindex > > as andi kleen pointed out: > > > > Also is it sure that the backtrace involves ip_rcv ? A more likely > > > guess is that it happens during the IP_LOCAL_OUT hook, when skb->dev > > > isn't set yet, but conntrack already has to already reassemble fragments. > > > > Actually, I do not understand how current code could even have worked > > in the past. Once the SKB is passed to ip_defrag, it is nobody's > > buisness to reference that SKB anymore. This ip_defrag call is (from > > mmh... we really don't do this. We use the return value of ip_defrag(), > which is what ip_frag_reasm() returns (== the new datagram consisting > out of all its fragments). > > > Alexey, what have I missed? I don't like the ip_fragment.c proposed > > fix for this reason, what netfilter is doing with ip_defrag here looks > > just wrong. > > Well, my conclusion is: > > - the defragmentation code in the ipv4 stack assumes that skb->dev points > to a valid device. It does this primaryly to send icmp reassembly errors > if a fragment reassembly timeout occurs > > - netfilter wants to use the ip_defrag for defragmentation, not only for > incoming packets from the network at NF_IP_PRE_ROUTING, but also for > locally-generated fragmented packets (at NF_IP_LOCAL_OUT). Unfortunately > we don't have a valid skb->dev at this point. > > I don't think that there is any skb_clone()ing needed, nor this would solve > the problem. The solution is > > a) netfilter conntrack (more exactly: ip_ct_gather_frags) sets skb->dev to >something valid (skb->dst->dev). Dirty hack. > > b) make ip_defrag(), ... aware of the case where skb->dev == NULL. Sounds >like a good idea, since it is only one if(skb->dev) clause. > > c) netfilter stops using ip_defrag() for this case. Bad idea, it had to >reinvent the wheel :( > > - Harald Welte / [EMAIL PROTECTED]http://www.gnumonks.org I'm now testing this small patch based on your suggestion b). I have netfilter running, nfs mounts are behaving well, and fragmented pings dont kill the box. I made no attempt to resolve anything but the derefernce of a netdevice *dev.= NULL The patch only deals with the ip_defrag_queue path. I have not seen the alternate one happen. It's only been up an hour, I'll put some more time on it. Cheers, Tom --- linux/net/ipv4/ip_fragment.c~ Tue Dec 12 06:56:29 2000 +++ linux/net/ipv4/ip_fragment.cTue Dec 19 07:29:53 2000 @@ -485,7 +485,8 @@ else qp->fragments = skb; - qp->iif = skb->dev->ifindex; + if (skb->dev) + qp->iif = skb->dev->ifindex; skb->dev = NULL; qp->meat += skb->len; atomic_add(skb->truesize, _frag_mem); - 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: ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter locking)
Harald Welte wrote: On Mon, Dec 18, 2000 at 10:11:14AM -0800, David S. Miller wrote: From: Rusty Russell [EMAIL PROTECTED] Date: Mon, 18 Dec 2000 14:15:52 +1100 Alexey is right, locking is screwed (explains some reports of occasional failure during rmmod). Patch applied, thank you. I have a patch which compiles for non-linear skb mods to netfilter (NAT uses linear packets still, but connection tracking and packet filtering only linearize minimal requirements). Waiting for DaveM's solution to ip_ct_gather_frags()... I feel it's best to just skb_clone() the skb arg to ip_defrag and this will close the whole thing, I think. no. The clone()d skb will still have a skb-dev pointing to NULL. The problem occurs only for locally-generated outgoing packets, which need to be fragmented: - ip_build_xmit() discoveres it has to fragment - ip_build_xmit_slow() generates fragments and calls - NF_HOOK() for NF_IP_LOCAL_OUT - ip_conntrack_local() is called, which in turn calls - ip_conntrack_in(), which calls - ip_ct_gather_frags(), which calls - ip_defrag(), which calls [now we have two possible oops - caues] a ip_find(), which calls a ip_frag_create(), which initialises a timer with the function a ip_expire(), which dereferences qp-iif b ip_frag_queue(), which dereferences it in qp-iif= skb-dev-ifindex as andi kleen pointed out: Also is it sure that the backtrace involves ip_rcv ? A more likely guess is that it happens during the IP_LOCAL_OUT hook, when skb-dev isn't set yet, but conntrack already has to already reassemble fragments. Actually, I do not understand how current code could even have worked in the past. Once the SKB is passed to ip_defrag, it is nobody's buisness to reference that SKB anymore. This ip_defrag call is (from mmh... we really don't do this. We use the return value of ip_defrag(), which is what ip_frag_reasm() returns (== the new datagram consisting out of all its fragments). Alexey, what have I missed? I don't like the ip_fragment.c proposed fix for this reason, what netfilter is doing with ip_defrag here looks just wrong. Well, my conclusion is: - the defragmentation code in the ipv4 stack assumes that skb-dev points to a valid device. It does this primaryly to send icmp reassembly errors if a fragment reassembly timeout occurs - netfilter wants to use the ip_defrag for defragmentation, not only for incoming packets from the network at NF_IP_PRE_ROUTING, but also for locally-generated fragmented packets (at NF_IP_LOCAL_OUT). Unfortunately we don't have a valid skb-dev at this point. I don't think that there is any skb_clone()ing needed, nor this would solve the problem. The solution is a) netfilter conntrack (more exactly: ip_ct_gather_frags) sets skb-dev to something valid (skb-dst-dev). Dirty hack. b) make ip_defrag(), ... aware of the case where skb-dev == NULL. Sounds like a good idea, since it is only one if(skb-dev) clause. c) netfilter stops using ip_defrag() for this case. Bad idea, it had to reinvent the wheel :( - Harald Welte / [EMAIL PROTECTED]http://www.gnumonks.org I'm now testing this small patch based on your suggestion b). I have netfilter running, nfs mounts are behaving well, and fragmented pings dont kill the box. I made no attempt to resolve anything but the derefernce of a netdevice *dev.= NULL The patch only deals with the ip_defrag_queue path. I have not seen the alternate one happen. It's only been up an hour, I'll put some more time on it. Cheers, Tom --- linux/net/ipv4/ip_fragment.c~ Tue Dec 12 06:56:29 2000 +++ linux/net/ipv4/ip_fragment.cTue Dec 19 07:29:53 2000 @@ -485,7 +485,8 @@ else qp-fragments = skb; - qp-iif = skb-dev-ifindex; + if (skb-dev) + qp-iif = skb-dev-ifindex; skb-dev = NULL; qp-meat += skb-len; atomic_add(skb-truesize, ip_frag_mem); - 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: ip_defrag / ip_conntrack issues (was Re: [PATCH] Fix netfilter locking)
"David S. Miller" wrote: This is basically what is in my tree right now. However, there was one reporter who claimed that after this kind of change he still was able to lockup/OOPS his machine by logging into X as a user who had his home directory over NFS. This was with netfilter enabled as well so it has to be the same bug. Later, David S. Miller [EMAIL PROTECTED] 2.4.0-test12+ip_fragment.c.patch is still up. I hadn't previously tried client-side mounts on that box, just exports. I tried to reproduce the problem with nfs home directory mount + X. I am unable to generate the error -- it works for me. I think Alexey is right. There may be either coincidence or confusion in the report. Btw, I am able to compile a kernel over an nfs mount with this. Very handy since the remote is much faster at it. Cheers, Tom - 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: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
"Mohammad A. Haque" wrote: > > I do the following > > sudo modprobe iptable_nat > > Module Size Used by > iptable_nat17440 0 (unused) > ip_conntrack 19808 1 [iptable_nat] > ip_tables 12320 3 [iptable_nat] > > Oops start flying by when I access via NFS. > > If you need the actual Oops messages we're gonna have to get someone > who can setup a serial console. > see my post of day before yesterday under the nfs thread for serial console+kdb of this. I also posted a simpler one under this thread of a fragmented ping attack which is executable by any user on a peer. # ping -c 100 -s 1470 -f works fine; $ ping -c 1 -s 1478 crashes the target every time. Tom - 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: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
"Mohammad A. Haque" wrote: I do the following sudo modprobe iptable_nat Module Size Used by iptable_nat17440 0 (unused) ip_conntrack 19808 1 [iptable_nat] ip_tables 12320 3 [iptable_nat] Oops start flying by when I access via NFS. If you need the actual Oops messages we're gonna have to get someone who can setup a serial console. see my post of day before yesterday under the nfs thread for serial console+kdb of this. I also posted a simpler one under this thread of a fragmented ping attack which is executable by any user on a peer. # ping -c 100 -s 1470 -f t12-host works fine; $ ping -c 1 -s 1478 t12-host crashes the target every time. Tom - 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: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
"David S. Miller" wrote: > >Date: Thu, 14 Dec 2000 15:35:48 -0500 (EST) >From: "Mohammad A. Haque" <[EMAIL PROTECTED]> > >I'll be trying in a few hours. > > Meanwhile for people wanting the crashes to be fixed, please > apply this patch. > > This was _always_ broken, and really what netfilter is doing > should have never worked. The only theory I have right now > is that people using netfilter never had IP fragments timeout. > :-) > > So the patch below restores previous behavior exactly. > Ie. netfilter sources fragments cannot send ICMP errors > on frag queue timeout :-) > Hello, I posted one of these generated by nfs earlier. This one is from $ ping -c 1 -s 1478 <2.4.0-t12-host> from peer. kdb over serial console -- the module addresses are accurate. Lightly edited for readability. Hope this helps, Tom Unable to handle kernel NULL pointer dereference at virtual address 003c printing eip: c01c0c32 *pde = Entering kdb (current=0xc02c, pid 0) Panic: Oops due to panic @ 0xc01c0c32 eax = 0x ebx = 0x ecx = 0xc11a6fa0 edx = 0x0006 esi = 0xc1376be0 edi = 0x esp = 0xc02c1bac eip = 0xc01c0c32 ebp = 0xc02c1bc8 xss = 0x0018 xcs = 0xc11a0010 eflags = 0x00010246 xds = 0x31010018 xes = 0x0018 origeax = 0x = 0xc02c1b78 kdb> bt EBP EIP Function(args) 0xc02c1bc8 0xc01c0c32 ip_frag_queue+0x222 (0xc11a6fa0, 0xc1376be0) kernel .text 0xc010 0xc01c0a10 0xc01c0c90 0xc02c1bf4 0xc01c1004 ip_defrag+0xc4 (0xc1376be0) kernel .text 0xc010 0xc01c0f40 0xc01c1070 0xc02c1c0c 0xc4093365 [ip_conntrack]ip_ct_gather_frags+0x25 (0xc1376be0) ip_conntrack .text 0xc4091060 0xc4093340 0xc40933e0 0xc02c1c54 0xc40924cd [ip_conntrack]ip_conntrack_in+0x3d (0x3, 0xc02c1cdc, 0x0, 0xc3104800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4092490 0xc40927b0 0xc02c1c70 0xc4094666 [ip_conntrack]ip_conntrack_local+0x56 (0x3, 0xc02c1cdc, 0x0, 0xc3104800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4094610 0xc4094670 0xc02c1c98 0xc01b2d98 nf_iterate+0x28 (0xc0320cd8, 0xc02c1cdc, 0x3, 0x0, 0xc3104800) kernel .text 0xc010 0xc01b2d70 0xc01b2e00 0xc02c1ccc 0xc01b3001 nf_hook_slow+0x71 (0x2, 0x3, 0xc1376be0, 0x0, 0xc3104800) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1d3c 0xc01c2c27 ip_build_xmit_slow+0x387 (0xc11d2730, 0xc01d9a00, 0xc02c1dfc, 0x5e2, 0xc02c1de0) kernel .text 0xc010 0xc01c28a0 0xc01c2d00 0xc02c1d7c 0xc01c2d4b ip_build_xmit+0x4b (0xc11d2730, 0xc01d9a00, 0xc02c1dfc, 0x5e2, 0xc02c1de0) kernel .text 0xc010 0xc01c2d00 0xc01c2ff0 0xc02c1dec 0xc01d9c03 icmp_reply+0x173 (0xc02c1dfc, 0xc136aab0) kernel .text 0xc010 0xc01d9a90 0xc01d9c20 0xc02c1e44 0xc01da1aa icmp_echo+0x3a (0xc0aad824, 0xc136aab0, 0x5c6) more> kernel .text 0xc010 0xc01da170 0xc01da1b0 0xc02c1e68 0xc01da459 icmp_rcv+0xa9 (0xc136aab0, 0x5ce) kernel .text 0xc010 0xc01da3b0 0xc01da490 0xc02c1e88 0xc01c04a4 ip_local_deliver_finish+0x94 (0xc136aab0, 0xc136aab0) kernel .text 0xc010 0xc01c0410 0xc01c0520 0xc02c1ea4 0xc01b3048 nf_hook_slow+0xb8 (0x2, 0x1, 0xc136aab0, 0xc3104800, 0x0) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1ec4 0xc01c02d5 ip_local_deliver+0x45 (0xc136aab0) kernel .text 0xc010 0xc01c0290 0xc01c02e0 0xc02c1ee8 0xc01c06dc ip_rcv_finish+0x1bc (0xc136aab0, 0xc08bd210) kernel .text 0xc010 0xc01c0520 0xc01c0710 0xc02c1f04 0xc01b3048 nf_hook_slow+0xb8 (0x2, 0x0, 0xc136aab0, 0xc3104800, 0x0) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1f38 0xc01c03dc ip_rcv+0xfc (0xc08bd210, 0xc3104800, 0xc02bca84) kernel .text 0xc010 0xc01c02e0 0xc01c0410 0xc02c1f68 0xc01b703d net_rx_action+0x12d (0xc02facf0) kernel .text 0xc010 0xc01b6f10 0xc01b7160 0xc02c1f80 0xc011bd7e do_softirq+0x4e kernel .text 0xc010 0xc011bd30 0xc011bdb0 0xc02c1f98 0xc010ad13 do_IRQ+0xa3 (0xc01074f0, 0xc2532260, 0xc02c, 0xc02c, 0xc02c) kernel .text 0xc010 0xc010ac70 0xc010ad30 0xc01093f0 ret_from_intr kernel .text 0xc010 0xc01093f0 0xc0109410 Interrupt registers: eax = 0x ebx = 0xc01074f0 ecx = 0xc2532260 edx = 0xc02c esi = 0xc02c edi = 0xc02c esp = 0xc02c1fd4 eip = 0xc0107516 ebp = 0xc02c1fd4 xss = 0x0018 xcs = 0x0010 eflags = 0x0246 xds = 0xc0100018 xes = 0xc02c0018 origeax = 0xff0c = 0xc02c1fa0
Re: ip_defrag is broken (was: Re: test12 lockups -- need feedback)
"David S. Miller" wrote: Date: Thu, 14 Dec 2000 15:35:48 -0500 (EST) From: "Mohammad A. Haque" [EMAIL PROTECTED] I'll be trying in a few hours. Meanwhile for people wanting the crashes to be fixed, please apply this patch. This was _always_ broken, and really what netfilter is doing should have never worked. The only theory I have right now is that people using netfilter never had IP fragments timeout. :-) So the patch below restores previous behavior exactly. Ie. netfilter sources fragments cannot send ICMP errors on frag queue timeout :-) Hello, I posted one of these generated by nfs earlier. This one is from $ ping -c 1 -s 1478 2.4.0-t12-host from peer. kdb over serial console -- the module addresses are accurate. Lightly edited for readability. Hope this helps, Tom Unable to handle kernel NULL pointer dereference at virtual address 003c printing eip: c01c0c32 *pde = Entering kdb (current=0xc02c, pid 0) Panic: Oops due to panic @ 0xc01c0c32 eax = 0x ebx = 0x ecx = 0xc11a6fa0 edx = 0x0006 esi = 0xc1376be0 edi = 0x esp = 0xc02c1bac eip = 0xc01c0c32 ebp = 0xc02c1bc8 xss = 0x0018 xcs = 0xc11a0010 eflags = 0x00010246 xds = 0x31010018 xes = 0x0018 origeax = 0x regs = 0xc02c1b78 kdb bt EBP EIP Function(args) 0xc02c1bc8 0xc01c0c32 ip_frag_queue+0x222 (0xc11a6fa0, 0xc1376be0) kernel .text 0xc010 0xc01c0a10 0xc01c0c90 0xc02c1bf4 0xc01c1004 ip_defrag+0xc4 (0xc1376be0) kernel .text 0xc010 0xc01c0f40 0xc01c1070 0xc02c1c0c 0xc4093365 [ip_conntrack]ip_ct_gather_frags+0x25 (0xc1376be0) ip_conntrack .text 0xc4091060 0xc4093340 0xc40933e0 0xc02c1c54 0xc40924cd [ip_conntrack]ip_conntrack_in+0x3d (0x3, 0xc02c1cdc, 0x0, 0xc3104800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4092490 0xc40927b0 0xc02c1c70 0xc4094666 [ip_conntrack]ip_conntrack_local+0x56 (0x3, 0xc02c1cdc, 0x0, 0xc3104800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4094610 0xc4094670 0xc02c1c98 0xc01b2d98 nf_iterate+0x28 (0xc0320cd8, 0xc02c1cdc, 0x3, 0x0, 0xc3104800) kernel .text 0xc010 0xc01b2d70 0xc01b2e00 0xc02c1ccc 0xc01b3001 nf_hook_slow+0x71 (0x2, 0x3, 0xc1376be0, 0x0, 0xc3104800) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1d3c 0xc01c2c27 ip_build_xmit_slow+0x387 (0xc11d2730, 0xc01d9a00, 0xc02c1dfc, 0x5e2, 0xc02c1de0) kernel .text 0xc010 0xc01c28a0 0xc01c2d00 0xc02c1d7c 0xc01c2d4b ip_build_xmit+0x4b (0xc11d2730, 0xc01d9a00, 0xc02c1dfc, 0x5e2, 0xc02c1de0) kernel .text 0xc010 0xc01c2d00 0xc01c2ff0 0xc02c1dec 0xc01d9c03 icmp_reply+0x173 (0xc02c1dfc, 0xc136aab0) kernel .text 0xc010 0xc01d9a90 0xc01d9c20 0xc02c1e44 0xc01da1aa icmp_echo+0x3a (0xc0aad824, 0xc136aab0, 0x5c6) more kernel .text 0xc010 0xc01da170 0xc01da1b0 0xc02c1e68 0xc01da459 icmp_rcv+0xa9 (0xc136aab0, 0x5ce) kernel .text 0xc010 0xc01da3b0 0xc01da490 0xc02c1e88 0xc01c04a4 ip_local_deliver_finish+0x94 (0xc136aab0, 0xc136aab0) kernel .text 0xc010 0xc01c0410 0xc01c0520 0xc02c1ea4 0xc01b3048 nf_hook_slow+0xb8 (0x2, 0x1, 0xc136aab0, 0xc3104800, 0x0) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1ec4 0xc01c02d5 ip_local_deliver+0x45 (0xc136aab0) kernel .text 0xc010 0xc01c0290 0xc01c02e0 0xc02c1ee8 0xc01c06dc ip_rcv_finish+0x1bc (0xc136aab0, 0xc08bd210) kernel .text 0xc010 0xc01c0520 0xc01c0710 0xc02c1f04 0xc01b3048 nf_hook_slow+0xb8 (0x2, 0x0, 0xc136aab0, 0xc3104800, 0x0) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc02c1f38 0xc01c03dc ip_rcv+0xfc (0xc08bd210, 0xc3104800, 0xc02bca84) kernel .text 0xc010 0xc01c02e0 0xc01c0410 0xc02c1f68 0xc01b703d net_rx_action+0x12d (0xc02facf0) kernel .text 0xc010 0xc01b6f10 0xc01b7160 0xc02c1f80 0xc011bd7e do_softirq+0x4e kernel .text 0xc010 0xc011bd30 0xc011bdb0 0xc02c1f98 0xc010ad13 do_IRQ+0xa3 (0xc01074f0, 0xc2532260, 0xc02c, 0xc02c, 0xc02c) kernel .text 0xc010 0xc010ac70 0xc010ad30 0xc01093f0 ret_from_intr kernel .text 0xc010 0xc01093f0 0xc0109410 Interrupt registers: eax = 0x ebx = 0xc01074f0 ecx = 0xc2532260 edx = 0xc02c esi = 0xc02c edi = 0xc02c esp = 0xc02c1fd4 eip = 0xc0107516 ebp = 0xc02c1fd4 xss = 0x0018 xcs = 0x0010 eflags = 0x0246 xds = 0xc0100018 xes = 0xc02c0018 origeax = 0xff0c regs = 0xc02c1fa0
[OOPS] nfs, similar to raid5 bug reports
Hello, This from attempting to read a nfs mounted directory. ext2 in this case, also had one with isofs over nfs. This looks suspiciously like Jasper Spaans' current report on raid5. Tom Unable to handle kernel NULL pointer dereference at virtual address 003c printing eip: c01c0c32 *pde = Entering kdb (current=0xc1abc000, pid 481) Panic: Oops due to panic @ 0xc01c0c32 eax = 0x ebx = 0x ecx = 0xc3544fb0 edx = 0x048c esi = 0xc25d64f0 edi = 0x esp = 0xc1abdc24 eip = 0xc01c0c32 ebp = 0xc1abdc40 xss = 0x0018 xcs = 0xc3540010 eflags = 0x00010246 xds = 0x31010018 xes = 0x0018 origeax = 0x = 0xc1abdbf0 kdb> bt EBP EIP Function(args) 0xc1abdc40 0xc01c0c32 ip_frag_queue+0x222 (0xc3544fb0, 0xc25d64f0) kernel .text 0xc010 0xc01c0a10 0xc01c0c90 0xc1abdc6c 0xc01c1004 ip_defrag+0xc4 (0xc25d64f0) kernel .text 0xc010 0xc01c0f40 0xc01c1070 0xc1abdc84 0xc4093365 [ip_conntrack]ip_ct_gather_frags+0x25 (0xc25d64f0) ip_conntrack .text 0xc4091060 0xc4093340 0xc40933e0 0xc1abdccc 0xc40924cd [ip_conntrack]ip_conntrack_in+0x3d (0x3, 0xc1abdd54, 0x0, 0xc20ea800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4092490 0xc40927b0 0xc1abdce8 0xc4094666 [ip_conntrack]ip_conntrack_local+0x56 (0x3, 0xc1abdd54, 0x0, 0xc20ea800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4094610 0xc4094670 0xc1abdd10 0xc01b2d98 nf_iterate+0x28 (0xc0320cd8, 0xc1abdd54, 0x3, 0x0, 0xc20ea800) kernel .text 0xc010 0xc01b2d70 0xc01b2e00 0xc1abdd44 0xc01b3001 nf_hook_slow+0x71 (0x2, 0x3, 0xc25d64f0, 0x0, 0xc20ea800) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc1abddb4 0xc01c2c27 ip_build_xmit_slow+0x387 (0xc1a757f0, 0xc01d74d0, 0xc1abde5c, 0x1030, 0xc1abde74) kernel .text 0xc010 0xc01c28a0 0xc01c2d00 0xc1abddf4 0xc01c2d4b ip_build_xmit+0x4b (0xc1a757f0, 0xc01d74d0, 0xc1abde5c, 0x1030, 0xc1abde74) kernel .text 0xc010 0xc01c2d00 0xc01c2ff0 0xc1abde80 0xc01d78f3 udp_sendmsg+0x313 (0xc1a757f0, 0xc1abdf04, 0x1014) kernel .text 0xc010 0xc01d75e0 0xc01d7970 0xc1abde98 0xc01dc9e9 inet_sendmsg+0x39 (0xc1a09834, 0xc1abdf04, 0x1014, 0xc1abdec8, 0xc1abc000) more> kernel .text 0xc010 0xc01dc9b0 0xc01dc9f0 0xc1abdedc 0xc01b104a sock_sendmsg+0x7a (0xc1a09834, 0xc1abdf04, 0x1014) kernel .text 0xc010 0xc01b0fd0 0xc01b1070 0xc1abdf20 0xc4054832 [sunrpc]svc_sendto+0x82 (0xc1abf000, 0xc1abf14c, 0x1) sunrpc .text 0xc404e060 0xc40547b0 0xc4054880 0xc1abdf3c 0xc4054cd7 [sunrpc]svc_udp_sendto+0x37 (0xc1abf000) sunrpc .text 0xc404e060 0xc4054ca0 0xc4054d00 0xc1abdf58 0xc4055a66 [sunrpc]svc_send+0x76 (0xc1abf000) sunrpc .text 0xc404e060 0xc40559f0 0xc4055b20 0xc1abdfb0 0xc405442c [sunrpc]svc_process+0x31c (0xc3544570, 0xc1abf000) sunrpc .text 0xc404e060 0xc4054110 0xc4054640 0xc1abdfec 0xc4071332 [nfsd]nfsd+0x192 nfsd .text 0xc4071060 0xc40711a0 0xc40714a0 0xc0107843 kernel_thread+0x23 kernel .text 0xc010 0xc0107820 0xc0107860 - 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/
[OOPS] nfs, similar to raid5 bug reports
Hello, This from attempting to read a nfs mounted directory. ext2 in this case, also had one with isofs over nfs. This looks suspiciously like Jasper Spaans' current report on raid5. Tom Unable to handle kernel NULL pointer dereference at virtual address 003c printing eip: c01c0c32 *pde = Entering kdb (current=0xc1abc000, pid 481) Panic: Oops due to panic @ 0xc01c0c32 eax = 0x ebx = 0x ecx = 0xc3544fb0 edx = 0x048c esi = 0xc25d64f0 edi = 0x esp = 0xc1abdc24 eip = 0xc01c0c32 ebp = 0xc1abdc40 xss = 0x0018 xcs = 0xc3540010 eflags = 0x00010246 xds = 0x31010018 xes = 0x0018 origeax = 0x regs = 0xc1abdbf0 kdb bt EBP EIP Function(args) 0xc1abdc40 0xc01c0c32 ip_frag_queue+0x222 (0xc3544fb0, 0xc25d64f0) kernel .text 0xc010 0xc01c0a10 0xc01c0c90 0xc1abdc6c 0xc01c1004 ip_defrag+0xc4 (0xc25d64f0) kernel .text 0xc010 0xc01c0f40 0xc01c1070 0xc1abdc84 0xc4093365 [ip_conntrack]ip_ct_gather_frags+0x25 (0xc25d64f0) ip_conntrack .text 0xc4091060 0xc4093340 0xc40933e0 0xc1abdccc 0xc40924cd [ip_conntrack]ip_conntrack_in+0x3d (0x3, 0xc1abdd54, 0x0, 0xc20ea800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4092490 0xc40927b0 0xc1abdce8 0xc4094666 [ip_conntrack]ip_conntrack_local+0x56 (0x3, 0xc1abdd54, 0x0, 0xc20ea800, 0xc01c3560) ip_conntrack .text 0xc4091060 0xc4094610 0xc4094670 0xc1abdd10 0xc01b2d98 nf_iterate+0x28 (0xc0320cd8, 0xc1abdd54, 0x3, 0x0, 0xc20ea800) kernel .text 0xc010 0xc01b2d70 0xc01b2e00 0xc1abdd44 0xc01b3001 nf_hook_slow+0x71 (0x2, 0x3, 0xc25d64f0, 0x0, 0xc20ea800) kernel .text 0xc010 0xc01b2f90 0xc01b3080 0xc1abddb4 0xc01c2c27 ip_build_xmit_slow+0x387 (0xc1a757f0, 0xc01d74d0, 0xc1abde5c, 0x1030, 0xc1abde74) kernel .text 0xc010 0xc01c28a0 0xc01c2d00 0xc1abddf4 0xc01c2d4b ip_build_xmit+0x4b (0xc1a757f0, 0xc01d74d0, 0xc1abde5c, 0x1030, 0xc1abde74) kernel .text 0xc010 0xc01c2d00 0xc01c2ff0 0xc1abde80 0xc01d78f3 udp_sendmsg+0x313 (0xc1a757f0, 0xc1abdf04, 0x1014) kernel .text 0xc010 0xc01d75e0 0xc01d7970 0xc1abde98 0xc01dc9e9 inet_sendmsg+0x39 (0xc1a09834, 0xc1abdf04, 0x1014, 0xc1abdec8, 0xc1abc000) more kernel .text 0xc010 0xc01dc9b0 0xc01dc9f0 0xc1abdedc 0xc01b104a sock_sendmsg+0x7a (0xc1a09834, 0xc1abdf04, 0x1014) kernel .text 0xc010 0xc01b0fd0 0xc01b1070 0xc1abdf20 0xc4054832 [sunrpc]svc_sendto+0x82 (0xc1abf000, 0xc1abf14c, 0x1) sunrpc .text 0xc404e060 0xc40547b0 0xc4054880 0xc1abdf3c 0xc4054cd7 [sunrpc]svc_udp_sendto+0x37 (0xc1abf000) sunrpc .text 0xc404e060 0xc4054ca0 0xc4054d00 0xc1abdf58 0xc4055a66 [sunrpc]svc_send+0x76 (0xc1abf000) sunrpc .text 0xc404e060 0xc40559f0 0xc4055b20 0xc1abdfb0 0xc405442c [sunrpc]svc_process+0x31c (0xc3544570, 0xc1abf000) sunrpc .text 0xc404e060 0xc4054110 0xc4054640 0xc1abdfec 0xc4071332 [nfsd]nfsd+0x192 nfsd .text 0xc4071060 0xc40711a0 0xc40714a0 0xc0107843 kernel_thread+0x23 kernel .text 0xc010 0xc0107820 0xc0107860 - 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: kernel BUG at buffer.c:827 in test12-pre6 and 7
Linus Torvalds wrote: > > It's not a new bug - it's an old bug that apparently is uncovered by a > new stricter test. > > Apparently loopback unlocks an already unlocked page - which has always > been a serious offense, but has never been detected before. > > test12-pre6+ detects it, and thus the BUG(). > > Your stack trace isn't symbolic (see Documentation/oops-tracing.txt), so > it's impossible to debug, but it's already interesting information to > see that it seems to be either loopback of vfat. > > Can you test some more? In particular, I'd love to hear if this happens > with vfat even without loopback, or with loopback even without vfat > (make an ext2 filesystem or similar instead). That woul dnarrow down the > bug further. > > Thanks, > Linus Hi, Here is a rather different datapoint. I hope it's different enough to help nail this. test12-pre5 + kdb + Serial Console. Sorry, I didn't get the contents of pointer args. It's probably worth saying that this kernel was compiled with gcc 2.95.2. I have the blessed egcs also, will compile pre7 with that and see what happens. Cheers, Tom from nfs mounted ext2 (2.4.0-test12-pre5): kernel BUG at buffer.c:827! Entering kdb (current=0xc2014000, pid 466) Panic: invalid operand due to panic @ 0xc0130c73 eax = 0x001c ebx = 0xc109ebf8 ecx = 0x edx = 0x0006 esi = 0xc2739af0 edi = 0xc2739b38 esp = 0xc2015dd4 eip = 0xc0130c73 ebp = 0xc2015df4 xss = 0x0018 xcs = 0xc2010010 eflags = 0x00010046 xds = 0x0018 xes = 0x0018 origeax = 0x = 0xc2015da0 kdb> bt EBP EIP Function(args) 0xc2015df4 0xc0130c73 end_buffer_io_async+0xd3 (0xc2739af0, 0x1) kernel .text 0xc010 0xc0130ba0 0xc0130cb0 0xc2015e10 0xc0164756 end_that_request_first+0x66 (0xc11c2c20, 0x1, 0xc031cf04) kernel .text 0xc010 0xc01646f0 0xc01647b0 0xc2015e30 0xc018a128 ide_end_request+0x28 (0x1, 0xc11c5060) kernel .text 0xc010 0xc018a100 0xc018a180 0xc2015e64 0xc018e614 read_intr+0x104 (0xc031ce20) kernel .text 0xc010 0xc018e510 0xc018e650 0xc2015e88 0xc018bad6 ide_intr+0x106 (0xe, 0xc11c5060, 0xc2015ed4, 0x1c0) kernel .text 0xc010 0xc018b9d0 0xc018bb30 0xc2015ea8 0xc010ab50 handle_IRQ_event+0x30 (0xe, 0xc2015ed4, 0xc11de2e0) kernel .text 0xc010 0xc010ab20 0xc010ab80 0xc2015ecc 0xc010ace2 do_IRQ+0x72 (0xc02f4520, 0xc02a92ac, 0xc201c000, 0xc201c000, 0xfc18) kernel .text 0xc010 0xc010ac70 0xc010ad30 0xc01093f0 ret_from_intr kernel .text 0xc010 0xc01093f0 0xc0109410 Interrupt registers: eax = 0x0019 ebx = 0xc02f4520 ecx = 0xc02a92ac edx = 0xc201c000 esi = 0xc201c000 edi = 0xfc18 esp = 0xc2015f08 eip = 0xc0115816 ebp = 0xc2015f4c xss = 0x0018 xcs = 0xc010 eflags = 0x0287 xds = 0xc2070018 xes = 0xc2070018 origeax = 0xff0e = 0xc2015ed4 0xc0115816 schedule+0x1b6 kernel .text 0xc010 0xc0115660 0xc0115b00 0xc2015f70 0xc01155c7 schedule_timeout+0x17 (0xc2014000, 0x1785222) kernel .text 0xc010 0xc01155b0 0xc0115650 0xc2015fac 0xc4055753 [sunrpc]svc_recv+0x1a3 (0xc24b2470, 0xc207be00, 0x7fff) sunrpc .text 0xc404e060 0xc40555b0 0xc4055940 0xc2015fec 0xc40713f3 [nfsd]nfsd+0x253 nfsd .text 0xc4071060 0xc40711a0 0xc40714a0 0xc0107843 kernel_thread+0x23 kernel .text 0xc010 0xc0107820 0xc0107860 - 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: kernel BUG at buffer.c:827 in test12-pre6 and 7
Linus Torvalds wrote: It's not a new bug - it's an old bug that apparently is uncovered by a new stricter test. Apparently loopback unlocks an already unlocked page - which has always been a serious offense, but has never been detected before. test12-pre6+ detects it, and thus the BUG(). Your stack trace isn't symbolic (see Documentation/oops-tracing.txt), so it's impossible to debug, but it's already interesting information to see that it seems to be either loopback of vfat. Can you test some more? In particular, I'd love to hear if this happens with vfat even without loopback, or with loopback even without vfat (make an ext2 filesystem or similar instead). That woul dnarrow down the bug further. Thanks, Linus Hi, Here is a rather different datapoint. I hope it's different enough to help nail this. test12-pre5 + kdb + Serial Console. Sorry, I didn't get the contents of pointer args. It's probably worth saying that this kernel was compiled with gcc 2.95.2. I have the blessed egcs also, will compile pre7 with that and see what happens. Cheers, Tom from nfs mounted ext2 (2.4.0-test12-pre5): kernel BUG at buffer.c:827! Entering kdb (current=0xc2014000, pid 466) Panic: invalid operand due to panic @ 0xc0130c73 eax = 0x001c ebx = 0xc109ebf8 ecx = 0x edx = 0x0006 esi = 0xc2739af0 edi = 0xc2739b38 esp = 0xc2015dd4 eip = 0xc0130c73 ebp = 0xc2015df4 xss = 0x0018 xcs = 0xc2010010 eflags = 0x00010046 xds = 0x0018 xes = 0x0018 origeax = 0x regs = 0xc2015da0 kdb bt EBP EIP Function(args) 0xc2015df4 0xc0130c73 end_buffer_io_async+0xd3 (0xc2739af0, 0x1) kernel .text 0xc010 0xc0130ba0 0xc0130cb0 0xc2015e10 0xc0164756 end_that_request_first+0x66 (0xc11c2c20, 0x1, 0xc031cf04) kernel .text 0xc010 0xc01646f0 0xc01647b0 0xc2015e30 0xc018a128 ide_end_request+0x28 (0x1, 0xc11c5060) kernel .text 0xc010 0xc018a100 0xc018a180 0xc2015e64 0xc018e614 read_intr+0x104 (0xc031ce20) kernel .text 0xc010 0xc018e510 0xc018e650 0xc2015e88 0xc018bad6 ide_intr+0x106 (0xe, 0xc11c5060, 0xc2015ed4, 0x1c0) kernel .text 0xc010 0xc018b9d0 0xc018bb30 0xc2015ea8 0xc010ab50 handle_IRQ_event+0x30 (0xe, 0xc2015ed4, 0xc11de2e0) kernel .text 0xc010 0xc010ab20 0xc010ab80 0xc2015ecc 0xc010ace2 do_IRQ+0x72 (0xc02f4520, 0xc02a92ac, 0xc201c000, 0xc201c000, 0xfc18) kernel .text 0xc010 0xc010ac70 0xc010ad30 0xc01093f0 ret_from_intr kernel .text 0xc010 0xc01093f0 0xc0109410 Interrupt registers: eax = 0x0019 ebx = 0xc02f4520 ecx = 0xc02a92ac edx = 0xc201c000 esi = 0xc201c000 edi = 0xfc18 esp = 0xc2015f08 eip = 0xc0115816 ebp = 0xc2015f4c xss = 0x0018 xcs = 0xc010 eflags = 0x0287 xds = 0xc2070018 xes = 0xc2070018 origeax = 0xff0e regs = 0xc2015ed4 0xc0115816 schedule+0x1b6 kernel .text 0xc010 0xc0115660 0xc0115b00 0xc2015f70 0xc01155c7 schedule_timeout+0x17 (0xc2014000, 0x1785222) kernel .text 0xc010 0xc01155b0 0xc0115650 0xc2015fac 0xc4055753 [sunrpc]svc_recv+0x1a3 (0xc24b2470, 0xc207be00, 0x7fff) sunrpc .text 0xc404e060 0xc40555b0 0xc4055940 0xc2015fec 0xc40713f3 [nfsd]nfsd+0x253 nfsd .text 0xc4071060 0xc40711a0 0xc40714a0 0xc0107843 kernel_thread+0x23 kernel .text 0xc010 0xc0107820 0xc0107860 - 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: 2.4.0-test-11: K7 compile error: `current' missing in string macro.
Ishikawa wrote: > > 2.4.0-test-11: K7 compile error: `current' missing in string macro. > > Symptom: > 2.4.0-test11 won't compile with K7 if we choose it for CPU. > > The compile error is attached at the end. > > The same config except for CPU (AMD K6) works. > The diff of config is shown immediately below. > (I saved the old config from some early test-1x series > compilation.) > [...] > > HALF-HEARTED FIX suggestion.: > > I looked around and found asm/current.h had this > #define current get_current() > > > QUESTION: Shouldn't this code be enabled for AMD K6-III > (not K7), too? (It would boost the performance on this CPU if so.) > Or does K6-III lack some instructions of 3D-Now (available > in K7, Athlon or Duron) and so can't use these macros? > > Either way, asm/current.h needs to be included > somewhere (probably after the include statements quoted above?) Either deselect SMP or see the patch I posted here in May. If you just keep adding headers for stuff in_interrupt() needs, you soon hit a circular dependency. Tom - 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: 2.4.0-test-11: K7 compile error: `current' missing in string macro.
Ishikawa wrote: 2.4.0-test-11: K7 compile error: `current' missing in string macro. Symptom: 2.4.0-test11 won't compile with K7 if we choose it for CPU. The compile error is attached at the end. The same config except for CPU (AMD K6) works. The diff of config is shown immediately below. (I saved the old config from some early test-1x series compilation.) [...] HALF-HEARTED FIX suggestion.: I looked around and found asm/current.h had this #define current get_current() QUESTION: Shouldn't this code be enabled for AMD K6-III (not K7), too? (It would boost the performance on this CPU if so.) Or does K6-III lack some instructions of 3D-Now (available in K7, Athlon or Duron) and so can't use these macros? Either way, asm/current.h needs to be included somewhere (probably after the include statements quoted above?) Either deselect SMP or see the patch I posted here in May. If you just keep adding headers for stuff in_interrupt() needs, you soon hit a circular dependency. Tom - 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/
[PATCH] Typo in test11-pre7 i386 cpu_init
Hi,
Here is another.
Tom
--- linux-2.4.0-test11/arch/i386/kernel/setup.c.origSat Nov 18 01:55:18
2000+++ linux-2.4.0-test11/arch/i386/kernel/setup.c Sat Nov 18 07:43:19 2000
@@ -2178,7 +2178,7 @@
if (tsc_disable && cpu_has_tsc) {
printk("Disabling TSC...\n");
/ FIX-HPA: DOES THIS REALLY BELONG HERE? /
- clear_bit(_cpu_data.x86_capability, X86_FEATURE_TSC);
+ clear_bit(X86_FEATURE_TSC, _cpu_data.x86_capability);
set_in_cr4(X86_CR4_TSD);
}
#endif
-
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/
[PATCH] Typo in test11-pre7 isofs/namei.c
Hi,
The second and third arguments of get_joliet_filename() are swapped.
Tom
--- linux-2.4.0-test11/fs/isofs/namei.c.origSat Nov 18 01:55:55 2000
+++ linux-2.4.0-test11/fs/isofs/namei.c Sat Nov 18 07:08:05 2000
@@ -127,7 +127,7 @@
dpnt = tmpname;
#ifdef CONFIG_JOLIET
} else if (dir->i_sb->u.isofs_sb.s_joliet_level) {
- dlen = get_joliet_filename(de, dir, tmpname);
+ dlen = get_joliet_filename(de, tmpname, dir);
dpnt = tmpname;
#endif
} else if (dir->i_sb->u.isofs_sb.s_mapping == 'a') {
-
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/
[PATCH] Typo in test11-pre7 isofs/namei.c
Hi,
The second and third arguments of get_joliet_filename() are swapped.
Tom
--- linux-2.4.0-test11/fs/isofs/namei.c.origSat Nov 18 01:55:55 2000
+++ linux-2.4.0-test11/fs/isofs/namei.c Sat Nov 18 07:08:05 2000
@@ -127,7 +127,7 @@
dpnt = tmpname;
#ifdef CONFIG_JOLIET
} else if (dir-i_sb-u.isofs_sb.s_joliet_level) {
- dlen = get_joliet_filename(de, dir, tmpname);
+ dlen = get_joliet_filename(de, tmpname, dir);
dpnt = tmpname;
#endif
} else if (dir-i_sb-u.isofs_sb.s_mapping == 'a') {
-
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/
[PATCH] Typo in test11-pre7 i386 cpu_init
Hi,
Here is another.
Tom
--- linux-2.4.0-test11/arch/i386/kernel/setup.c.origSat Nov 18 01:55:18
2000+++ linux-2.4.0-test11/arch/i386/kernel/setup.c Sat Nov 18 07:43:19 2000
@@ -2178,7 +2178,7 @@
if (tsc_disable cpu_has_tsc) {
printk("Disabling TSC...\n");
/ FIX-HPA: DOES THIS REALLY BELONG HERE? /
- clear_bit(boot_cpu_data.x86_capability, X86_FEATURE_TSC);
+ clear_bit(X86_FEATURE_TSC, boot_cpu_data.x86_capability);
set_in_cr4(X86_CR4_TSD);
}
#endif
-
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: Hard lockups solved
"David S. Miller" wrote: > >Date: Mon, 13 Nov 2000 18:05:24 -0500 >From: Tom Leete <[EMAIL PROTECTED]> > >Your net/ipv4/tcp.c patch from the NE2000 thread cured them even >before I found the hardware fault. Has that patch gone to the >queue? I recommend it. > > The bugs I was "fixing" there were due to problems in wait queue > exclusivity nesting. We instead fixed wait queue exclusivity nesting > so it actually worked in test11-pre3, can you see if by itself that > kernel does not show your problems too? > > Thanks. > > Later, > David S. Miller > [EMAIL PROTECTED] Done. Yes, it's fixed in vanilla test11-pre3, to go by limited testing. ftp, 15 Meg in 4 files -- no deathlike sleep, md5sums agree. That load would have certainly triggered the problem before. On to pre5. Thanks again, Tom - 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: Hard lockups solved
"David S. Miller" wrote:
Date: Mon, 13 Nov 2000 18:05:24 -0500
From: Tom Leete [EMAIL PROTECTED]
Your net/ipv4/tcp.c patch from the NE2000 thread cured them even
before I found the hardware fault. Has that patch gone to the
queue? I recommend it.
The bugs I was "fixing" there were due to problems in wait queue
exclusivity nesting. We instead fixed wait queue exclusivity nesting
so it actually worked in test11-pre3, can you see if by itself that
kernel does not show your problems too?
Thanks.
Later,
David S. Miller
[EMAIL PROTECTED]
Done. Yes, it's fixed in vanilla test11-pre3, to go by
limited testing. ftp, 15 Meg in 4 files -- no deathlike
sleep, md5sums agree. That load would have certainly
triggered the problem before. On to pre5.
Thanks again,
Tom
-
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/
Hard lockups solved
Hi, My lockup problems started increasing in frequency, and it became obvious that they were independent of the kernel I booted. The shoe dropped, nic was failing. It's salvage now. The bizarre shift errors on ftp are gone, so the data I sent is irrelevant to the kernel. The soft hangs I was getting were real, though perhaps encouraged by nic failure. Your net/ipv4/tcp.c patch from the NE2000 thread cured them even before I found the hardware fault. Has that patch gone to the queue? I recommend it. Thanks, Tom - 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/
Hard lockups solved
Hi, My lockup problems started increasing in frequency, and it became obvious that they were independent of the kernel I booted. The shoe dropped, nic was failing. It's salvage now. The bizarre shift errors on ftp are gone, so the data I sent is irrelevant to the kernel. The soft hangs I was getting were real, though perhaps encouraged by nic failure. Your net/ipv4/tcp.c patch from the NE2000 thread cured them even before I found the hardware fault. Has that patch gone to the queue? I recommend it. Thanks, Tom - 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/
Large trace of sched.c 505 BUG(), decoded
Hi, This bug was triggered by trying ctrl-alt-del for reboot in test10-pre5. It appears to show schedule() getting stuck in a loop with the stack growing unbounded. Unfortunately, the module list and symbols are not exposed. I don't know what had been unloaded before the bug triggered. The initial module list shouldnt be too different from the current: ppp_deflate40064 0 (autoclean) bsd_comp4320 0 (autoclean) ppp_async 6480 1 (autoclean) nfsd 68624 0 (autoclean) lockd 50704 0 (autoclean) [nfsd] sunrpc 59072 0 (autoclean) [nfsd lockd] ppp_generic13024 3 (autoclean) [ppp_deflate bsd_comp ppp_async] slhc4688 1 (autoclean) [ppp_generic] parport_pc 18864 1 (autoclean) plip 11152 1 (autoclean) parport26240 1 (autoclean) [parport_pc plip] tulip 33904 2 (autoclean) Unzipped, the trace is over 420k. The stack trace is periodic enough that, bzipped, it is marginnaly short enough for l-k. Serial console is a very good thing :) Tom tleete.sched.505.oops.bz2
Large trace of sched.c 505 BUG(), decoded
Hi, This bug was triggered by trying ctrl-alt-del for reboot in test10-pre5. It appears to show schedule() getting stuck in a loop with the stack growing unbounded. Unfortunately, the module list and symbols are not exposed. I don't know what had been unloaded before the bug triggered. The initial module list shouldnt be too different from the current: ppp_deflate40064 0 (autoclean) bsd_comp4320 0 (autoclean) ppp_async 6480 1 (autoclean) nfsd 68624 0 (autoclean) lockd 50704 0 (autoclean) [nfsd] sunrpc 59072 0 (autoclean) [nfsd lockd] ppp_generic13024 3 (autoclean) [ppp_deflate bsd_comp ppp_async] slhc4688 1 (autoclean) [ppp_generic] parport_pc 18864 1 (autoclean) plip 11152 1 (autoclean) parport26240 1 (autoclean) [parport_pc plip] tulip 33904 2 (autoclean) Unzipped, the trace is over 420k. The stack trace is periodic enough that, bzipped, it is marginnaly short enough for l-k. Serial console is a very good thing :) Tom tleete.sched.505.oops.bz2
Re: Patch to remove undefined C code
[CC trimmed] Bill Wendling wrote: > > Also sprach Tom Leete: > } > } You are correct that in C the rightmost argument is always > } at the open end of the stack, and that varargs require that. > } The opposite is called the Pascal convention. > } > Where in the standard does it say this? It's probably done most of the > time in this fashion for convenience, but I don't believe it's in the > standard. > The standard is careful to avoid implementation/ABI issues. It doesn't specify the use of a stack at all. Nonetheless, there exists a C convention for stack based archs, which is as I described. Pascal convention can accomodate varargs by indirection, but that is OT. My point was that stack order of values is independent of the order of evaluation. gcc is neither dumb nor psychic. It will not honor a sequence point which exists only in the programmer's head. Tom - 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: Patch to remove undefined C code
Peter Samuelson wrote: > > [Matti Aarnio] > > > That depends mainly on question: Does your stack grow up or down ? > > [Ben Pfaff] > > No it doesn't. It depends mainly on whether the ABI for the machine > > says that arguments are pushed onto the stack in left-to-right or > > right-to-left order. You could do either on x86, for instance, and > > it has nothing to do with whether the x86 stack grows up or down. > > So, if you choose left-to-right, how do you implement varargs? Keep in > mind that prototypes are optional. I bet anything your solution is > slower and more complex than right-to-left, as all known compilers do. > > Peter You are correct that in C the rightmost argument is always at the open end of the stack, and that varargs require that. The opposite is called the Pascal convention. This thread has incorrectly identified the order of expression evaluation with the physical stack layout of the resulting values. The two properties are orthogonal. The compiler is free to evaluate arguments in any order, and knows which stack slot gets each result. For instance, evaluation reordering might be done to optimize cache coherency. It is conceivable that a SMP-aware compiler would evaluate heavyweight arguments in parallel (though currently Linux would not support that). Tom - 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: Patch to remove undefined C code
Peter Samuelson wrote: [Matti Aarnio] That depends mainly on question: Does your stack grow up or down ? [Ben Pfaff] No it doesn't. It depends mainly on whether the ABI for the machine says that arguments are pushed onto the stack in left-to-right or right-to-left order. You could do either on x86, for instance, and it has nothing to do with whether the x86 stack grows up or down. So, if you choose left-to-right, how do you implement varargs? Keep in mind that prototypes are optional. I bet anything your solution is slower and more complex than right-to-left, as all known compilers do. Peter You are correct that in C the rightmost argument is always at the open end of the stack, and that varargs require that. The opposite is called the Pascal convention. This thread has incorrectly identified the order of expression evaluation with the physical stack layout of the resulting values. The two properties are orthogonal. The compiler is free to evaluate arguments in any order, and knows which stack slot gets each result. For instance, evaluation reordering might be done to optimize cache coherency. It is conceivable that a SMP-aware compiler would evaluate heavyweight arguments in parallel (though currently Linux would not support that). Tom - 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: Patch to remove undefined C code
[CC trimmed] Bill Wendling wrote: Also sprach Tom Leete: } } You are correct that in C the rightmost argument is always } at the open end of the stack, and that varargs require that. } The opposite is called the Pascal convention. } Where in the standard does it say this? It's probably done most of the time in this fashion for convenience, but I don't believe it's in the standard. The standard is careful to avoid implementation/ABI issues. It doesn't specify the use of a stack at all. Nonetheless, there exists a C convention for stack based archs, which is as I described. Pascal convention can accomodate varargs by indirection, but that is OT. My point was that stack order of values is independent of the order of evaluation. gcc is neither dumb nor psychic. It will not honor a sequence point which exists only in the programmer's head. Tom - 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: Bug in "ide-pci.c"
Sean Estabrooks wrote: > > Hi Andre, > > The if() logic must then rely on implementation specific compiler > details and not have any optimizations which break this code. While it may > "WORK" it isn't particularly reliable code. > > Sean Nope, the logical ops are sequence points required by standard to lazy evaluate left to right. For ||, that means they operate in order till they find a true. Tom - 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/
