national problems

[David Feuer]

Now that it seems that George Bush has won the presidency, I am wondering 
whether Linus and other members of the free software community intend to 
leave the U.S. and go to more friendly places.  Imagine what G.W. Bush is 
going to do to export controls, free software, copyright law, patent law, 
etc  Be afraid.

--
This message has been brought to you by the letter alpha and the number pi.
David Feuer
[EMAIL PROTECTED]

-
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: [RANT] Linux-IrDA status

[Linus Torvalds]

On Wed, 8 Nov 2000, Michael Rothwell wrote:
> 
> Like what? I'm not sure what you're saying here. It seems that the pople
> writing the IrDA code have gotten no feedback from you as to why their
> patch is never accepted -- could you clarify?

Just to clarify.

The ONLY message from the IrDA people I've gotten during the last few
weeks has been a SINGLE email from Dag Brattli, with a 330kB patch.

The whole, full, unabridged explanation for those 330kB of patches:

>> Hello Linus,
>> 
>> Here is the latest IrDA patch for Linux-2.4.0-test10. 
>> 
>> Short summary: 
>> 
>> o Fixes IrDA in 2.4
>> o Touches _no_ other files. 
>> 
>> Please apply! 
>> 
>> Best regards
>> 
>> Dag Brattli

That's it.

ONE message during the last month. ONE huge patch. From people who should
have known about 2.4.x being pending for some time. 

10,000+ lines of diff, with _no_ effort to split it up, or explain it with
anything but

"o Fixes IrDA in 2.4"

and these people expect me to reply, sending long explanations of why I
don't like them? After they did nothing of the sort for the code they
claim should have been applied? Nada.

Get a grip. 

Linus

-
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: fs problem in 2.4.0-test10 -- oops in directory access

[Matthew Hanselman]

Many apologies, it's late and I ran the default ksymoops (0.7c) instead of
./ksymoops 

However, after running the real ksymoops against it, it gives nothing
new; I suppose since 'ls' is dying and the stack is from 'ls', that's why.

Is there anything else I should do before booting back to a 2.2.17 kernel?

As proof that I ran the right ksymoops this time:

ksymoops 2.3.5 on i686 2.4.0-test10.  Options used
 -V (default)
 -k /proc/ksyms (default)
 -l /proc/modules (default)
 -o /lib/modules/2.4.0-test10/ (default)
 -m /boot/System.map-2.4.0-test10 (specified)

Nov  8 00:11:42 chewbacca kernel: Oops:  
Nov  8 00:11:42 chewbacca kernel: CPU:0 
Nov  8 00:11:42 chewbacca kernel: EIP:0010:[usb_stor_exit+12588154/-1072693296] 
Nov  8 00:11:42 chewbacca kernel: EFLAGS: 00010206 
Nov  8 00:11:42 chewbacca kernel: eax: 00c014aa   ebx: cf0a1fa4   ecx: da155940   edx: 
c4a70440 
Nov  8 00:11:42 chewbacca kernel: esi:    edi: b020   ebp: b00c   esp: 
cf0a1f94 
Nov  8 00:11:42 chewbacca kernel: ds: 0018   es: 0018   ss: 0018 
Nov  8 00:11:42 chewbacca kernel: Process ls (pid: 9036, stackpage=cf0a1000) 
Nov  8 00:11:42 chewbacca kernel: Stack: c0135dd7 c4a70440 cf0a b020 c4a70440 
eff83540 0003 bfffe830  
Nov  8 00:11:42 chewbacca kernel:bfffe81c 0008 0001 c010a4fb b020 
080549ac 4010fd60 b020  
Nov  8 00:11:42 chewbacca kernel:b020 b00c 00c4 002b 002b 
00c4 400c4e1c 0023  
Nov  8 00:11:42 chewbacca kernel: Call Trace: [sys_lstat64+55/112] [system_call+51/56] 
 
Nov  8 00:11:42 chewbacca kernel: Code:  Bad EIP value. 
Using defaults from ksymoops -t elf32-i386 -a i386

 - Matt

---
Matthew HanselmanQUIQ Inc.
(608) 230-7205 (voice)   25 Kessel Ct #201
(608) 230-7299 (fax) Madison, WI 53711

On Wed, 8 Nov 2000, Keith Owens wrote:

> On Wed, 8 Nov 2000 00:38:33 -0600 (CST), 
> Matthew Hanselman <[EMAIL PROTECTED]> wrote:
> >I can poke around tomorrow morning without a reboot, but then I'll have to
> >reboot (so please respond via email if I can do anything).  I tried
> >grinding the message through ksymoops-2.3.5, and it complains with this
> >error:
> >
> >Warning (Oops_code): trailing garbage ignored on Code: line
> >  Text: 'Code:  Bad EIP value. '
> >  Garbage: 'IP value. '
> >Using defaults from ksymoops -t elf32-i386 -a i386
> >Error (Oops_code_values): invalid value 0xBad in Code line, must be 2, 4, 8 or 1
> >Error (Oops_code_values): invalid value 0xE in Code line, must be 2, 4, 8 or 16 
> 
> Are you sure that is ksymoops 2.3.5?  My version of 2.3.5 handles
> 'Code: Bad EIP value. '.  ksymoops >= 2.3.4 should handle it correctly.
> 
> >Nov  8 00:11:42 chewbacca kernel: Unable to handle kernel paging request at virtual 
>address 00c014aa 
> >Nov  8 00:11:42 chewbacca kernel:  printing eip: 
> >Nov  8 00:11:42 chewbacca kernel: 00c014aa 
> >Nov  8 00:11:42 chewbacca kernel: *pde =  
> >Nov  8 00:11:42 chewbacca kernel: Oops:  
> >Nov  8 00:11:42 chewbacca kernel: CPU:0 
> >Nov  8 00:11:42 chewbacca kernel: EIP:0010:[usb_stor_exit+12588154/-1072693296] 
> >Nov  8 00:11:42 chewbacca kernel: EFLAGS: 00010206 
> >Nov  8 00:11:42 chewbacca kernel: eax: 00c014aa   ebx: cf0a1fa4 ecx: da155940   
>edx: c4a70440 
> >Nov  8 00:11:42 chewbacca kernel: esi:    edi: b020 ebp: b00c   
>esp: cf0a1f94 
> >Nov  8 00:11:42 chewbacca kernel: ds: 0018   es: 0018   ss: 0018 
> >Nov  8 00:11:42 chewbacca kernel: Process ls (pid: 9036, stackpage=cf0a1000) 
> >Nov  8 00:11:42 chewbacca kernel: Stack: c0135dd7 c4a70440 cf0a b020 
>c4a70440 eff83540 0003 bfffe830  
> >Nov  8 00:11:42 chewbacca kernel:bfffe81c 0008 0001 c010a4fb 
>b020 080549ac 4010fd60 b020  
> >Nov  8 00:11:42 chewbacca kernel:b020 b00c 00c4 002b 
>002b 00c4 400c4e1c 0023  
> >Nov  8 00:11:42 chewbacca kernel: Call Trace: [sys_lstat64+55/112] 
>[system_call+51/56]  
> >Nov  8 00:11:42 chewbacca kernel: Code:  Bad EIP value. 
> 
> sys_lstat64+55 has branched to the value in eax and blown up.  It looks like
> the data in eax is a kernel address shifted right one byte.
> 


-
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: problems with grow_inodes: inode-max limit reached

[Chmouel Boudjnah]

"Gregory S. Youngblood" <[EMAIL PROTECTED]> writes:

> The problem occurs with Mandrake 7.0 and 7.1 with kernels 2.2.14, 2.2.16,
> and 2.2.17. These are the secure kernels that Mandrake provides.

can you try with a 2.2.17 kernel rpm standard (no smp no secure) ?

-- 
MandrakeSoft Inc http://www.chmouel.org
  --Chmouel
-
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: Alpha SMP problem

[Richard Henderson]

On Tue, Nov 07, 2000 at 10:09:34AM -0800, Reto Baettig wrote:
> I have a problem whith Alpha SMP's which seems to be kernel-related. I
> discussed this on the bug-glibc list but everybody seems to agree that
> it cannot be a libc problem.

Indeed it does seem to be some sort of tlb flushing problem,
but I've been unable to figure out exactly what.


r~
-
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/

problems with grow_inodes: inode-max limit reached

[Gregory S. Youngblood]

I've got a problem with inodes which spans three kernels when used
as a gateway/firewall.

The problem occurs with Mandrake 7.0 and 7.1 with kernels 2.2.14, 2.2.16,
and 2.2.17. These are the secure kernels that Mandrake provides.

The catch is, it only affects one machine - the machine I set up as a
gateway which is using rp-pppoe and acting as a gateway/firewall for a
windows and linux machine in a small network. As well as using ipmasqadm
for port forwarding.

The system works flawlessly, for about 24 to 72 hours. Then I start
getting:

grow_inodes: inode-max limit reached

repeatedly

Once this happens, I can't log in or reboot the system or access any files
on the system. The network connections appear to still work, as I don't
lose connecitivity with anything I'm currently connected to.

By default, the inode-max is 4096 on this sytem (a compaq deskpro 5133, 32
meg RAM). I've upped it to 131072 to try and buy some time.

The problem does NOT appear on either of my other linux workstations, one
of which has been up for 119 days with a login since Jul 11, 2000, and the
other which has been up for 30+ days at a time. The workstations run a
variety of items, including X, MySQL, PostgreSQL, httpd, sshd, and a
variety of other daemons. The gateway/firewall ONLY has sshd and other
minimal daemons, nothing more. (these other systems are also mandrake 7
using the same secure kernels 2.2.14 and 2.2.16).

I've done several searches for information on this problem, and so far the
only useful information I've found was someone suggesting resetting the
indoe-max value, which I've done. But, that still doesn't answer the
original problem.

Does anyone have any ideas on what is causing these problems? Or how to
fix it once and for all?

Greg

PS: The machine in question is configured:

Compaq Deskpro 5133, P-133, 32 meg RAM, 1.2 gig IDE hard drive, Intel
etherexpress pro 10/100, smc eznet 10/100 running Mandrake 7.1 with kernel
2.2.17 (Mandrake 2.2.17-21mdksecure).

-
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: fs problem in 2.4.0-test10 -- oops in directory access

[Keith Owens]

On Wed, 8 Nov 2000 00:38:33 -0600 (CST), 
Matthew Hanselman <[EMAIL PROTECTED]> wrote:
>I can poke around tomorrow morning without a reboot, but then I'll have to
>reboot (so please respond via email if I can do anything).  I tried
>grinding the message through ksymoops-2.3.5, and it complains with this
>error:
>
>Warning (Oops_code): trailing garbage ignored on Code: line
>  Text: 'Code:  Bad EIP value. '
>  Garbage: 'IP value. '
>Using defaults from ksymoops -t elf32-i386 -a i386
>Error (Oops_code_values): invalid value 0xBad in Code line, must be 2, 4, 8 or 1
>Error (Oops_code_values): invalid value 0xE in Code line, must be 2, 4, 8 or 16 

Are you sure that is ksymoops 2.3.5?  My version of 2.3.5 handles
'Code: Bad EIP value. '.  ksymoops >= 2.3.4 should handle it correctly.

>Nov  8 00:11:42 chewbacca kernel: Unable to handle kernel paging request at virtual 
>address 00c014aa 
>Nov  8 00:11:42 chewbacca kernel:  printing eip: 
>Nov  8 00:11:42 chewbacca kernel: 00c014aa 
>Nov  8 00:11:42 chewbacca kernel: *pde =  
>Nov  8 00:11:42 chewbacca kernel: Oops:  
>Nov  8 00:11:42 chewbacca kernel: CPU:0 
>Nov  8 00:11:42 chewbacca kernel: EIP:0010:[usb_stor_exit+12588154/-1072693296] 
>Nov  8 00:11:42 chewbacca kernel: EFLAGS: 00010206 
>Nov  8 00:11:42 chewbacca kernel: eax: 00c014aa   ebx: cf0a1fa4 ecx: da155940   edx: 
>c4a70440 
>Nov  8 00:11:42 chewbacca kernel: esi:    edi: b020 ebp: b00c   esp: 
>cf0a1f94 
>Nov  8 00:11:42 chewbacca kernel: ds: 0018   es: 0018   ss: 0018 
>Nov  8 00:11:42 chewbacca kernel: Process ls (pid: 9036, stackpage=cf0a1000) 
>Nov  8 00:11:42 chewbacca kernel: Stack: c0135dd7 c4a70440 cf0a b020 c4a70440 
>eff83540 0003 bfffe830  
>Nov  8 00:11:42 chewbacca kernel:bfffe81c 0008 0001 c010a4fb b020 
>080549ac 4010fd60 b020  
>Nov  8 00:11:42 chewbacca kernel:b020 b00c 00c4 002b 002b 
>00c4 400c4e1c 0023  
>Nov  8 00:11:42 chewbacca kernel: Call Trace: [sys_lstat64+55/112] 
>[system_call+51/56]  
>Nov  8 00:11:42 chewbacca kernel: Code:  Bad EIP value. 

sys_lstat64+55 has branched to the value in eax and blown up.  It looks like
the data in eax is a kernel address shifted right one byte.

-
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/

Purpose of inode->i_atomic_write in 2.2.x

[Naren Devaiah]

Hi,

Could somebody tell me why inode->i_atomic_write is used in 2.2.x?
And also why this is absent in 2.4.x (actually replaced by ->i_zombie)?

Thanks,
Naren


-
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/

off topic a bit but i realy need help c++ and kernel

[david]

hi i am writing a video kernel driver for linux lexos and have got
stuck
this is how NVIDIA do their regs
#define NV_PFIFO_RAMHT  
0x2210 /* RW-4R */
#define NV_PFIFO_RAMHT_BASE_ADDRESS
8:4 /* RWIUF */
#define NV_PFIFO_RAMHT_BASE_ADDRESS_1   
0x0010 /* RWI-V */
#define NV_PFIFO_RAMHT_SIZE  
17:16 /* RWIUF */
#define NV_PFIFO_RAMHT_SIZE_4K  
0x /* RWI-V */
#define NV_PFIFO_RAMHT_SIZE_8K  
0x0001 /* RW--V */
#define NV_PFIFO_RAMHT_SIZE_16K 
0x0002 /* RW--V */
#define NV_PFIFO_RAMHT_SIZE_32K 
0x0003 /* RW--V */
#define NV_PFIFO_RAMHT_SEARCH
25:24 /* RWIUF */
#define NV_PFIFO_RAMHT_SEARCH_16
0x /* RWI-V */
#define NV_PFIFO_RAMHT_SEARCH_32
0x0001 /* RW--V */
#define NV_PFIFO_RAMHT_SEARCH_64
0x0002 /* RW--V */
#define NV_PFIFO_RAMHT_SEARCH_128   
0x0003 /* RW--V */
this can be used like setreg( NV_PFIFO_RAMHT , htbase << (
0 ? NV_PFIFO_RAMHT_BASE_ADDRESS)) ;
but i wont to make it better so i tried it this way
#define NV_PFIFO_RAMHT_BASE_ADDRESS 0x2210:8:4:3 /* address
: high bit : low bit : mode 3 = rw
this seemed much better all on one line so you can do setreg(NV_PFIFO_RAMHT_BASE_ADDRESS
, htbase) ;
but ( 2 ? 1:2:3 ) dose not work
and NV_PFIFO_RAMHT_BASE_ADDRESS 0x2210,8,4,3 dose not work
as setreg(a,h,l,m) thinks this is
all one agr
the other would be to have it as a big struct
but then compiler can not optimize it ( i think )
if i can use #define 's the it quicker and setreg can be an inline
asm marco
how would it work if i used 64 bit like this
bits 32 - 63 reg address
bits 24 - 31 high bit
bits 16 - 23 low  bit
bits 0  - 7  mode
#define NV_PFIFO_RAMHT_BASE_ADDRESS  0x221008040003
so if i sent this to the setreg(unsigned long long , data) asm macro
it would be in EAX:EDX (64 bit)
can the kernel use (long long) and (unsigned long long)  (
64 bit ints)
that 64 bit way look good but is it ?
  
( opps i wold need an extr 32 bits for value but can have 64:32 i think
)
has anyone got any help they can give me on this !please email me
thank you!
as i am stuck
also is there a down loadable book on c++ as i am just learning
from others ppl code and really
need a book to do it right
thank you david rundle <[EMAIL PROTECTED]>
 
 
 
 
 
 
 

[PATCH] Obscure possible bug in directory notify

[Stephen Rothwell]

Hi Linus,

This patch fixes a place where we could return with a read/write
lock held.  Also update MAINTAINERS and CREDITS files.

Cheers,
Stephen
-- 
Stephen Rothwell, Open Source Researcher, Linuxcare, Inc.
+61-2-62628990 tel, +61-2-62628991 fax 
[EMAIL PROTECTED], http://www.linuxcare.com/ 
Linuxcare. Support for the revolution.

diff -ruN 2.4.0-test11pre1/CREDITS 2.4.0-test11pre1-not1/CREDITS
--- 2.4.0-test11pre1/CREDITSWed Nov  8 10:07:59 2000
+++ 2.4.0-test11pre1-not1/CREDITS   Wed Nov  8 17:09:20 2000
@@ -2240,11 +2240,12 @@
 S: Germany
 
 N: Stephen Rothwell
-E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
 W: http://linuxcare.com.au/sfr
 P: 1024/BD8C7805 CD A4 9D 01 10 6E 7E 3B  91 88 FA D9 C8 40 AA 02
 D: Boot/setup/build work for setup > 2K
 D: Author, APM driver
+D: Directory notification
 S: 66 Maltby Circuit
 S: Wanniassa ACT 2903
 S: Australia
diff -ruN 2.4.0-test11pre1/MAINTAINERS 2.4.0-test11pre1-not1/MAINTAINERS
--- 2.4.0-test11pre1/MAINTAINERSWed Nov  1 09:36:12 2000
+++ 2.4.0-test11pre1-not1/MAINTAINERS   Wed Nov  8 17:08:05 2000
@@ -353,6 +353,12 @@
 L: [EMAIL PROTECTED]
 S: Maintained
 
+DIRECTORY NOTIFICATION
+P: Stephen Rothwell
+M: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
+S: Supported
+
 DISK GEOMETRY AND PARTITION HANDLING
 P: Andries Brouwer
 M: [EMAIL PROTECTED]
diff -ruN 2.4.0-test11pre1/fs/dnotify.c 2.4.0-test11pre1-not1/fs/dnotify.c
--- 2.4.0-test11pre1/fs/dnotify.c   Wed Oct  4 10:37:09 2000
+++ 2.4.0-test11pre1-not1/fs/dnotify.c  Wed Nov  8 17:06:08 2000
@@ -103,14 +103,14 @@
write_lock(_lock);
prev = >i_dnotify;
while ((dn = *prev) != NULL) {
-   if ((dn->dn_mask & event) == 0) {
-   prev = >dn_next;
-   continue;
-   }
if (dn->dn_magic != DNOTIFY_MAGIC) {
printk(KERN_ERR "__inode_dir_notify: bad magic "
"number in dnotify_struct!\n");
-   return;
+   goto out;
+   }
+   if ((dn->dn_mask & event) == 0) {
+   prev = >dn_next;
+   continue;
}
fown = >dn_filp->f_owner;
if (fown->pid)
@@ -125,6 +125,7 @@
}
if (changed)
redo_inode_mask(inode);
+out:
write_unlock(_lock);
 }
 
-
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: Installing kernel 2.4

[Jeff V. Merkey]

On Tue, Nov 07, 2000 at 06:18:09PM -0800, H. Peter Anvin wrote:
> Jeff Garzik wrote:
> > 
> > "Jeff V. Merkey" wrote:
> > > We need a format that allow multiple executable segments to be combined
> > > in a single executable and the loader have enough smarts to grab the
> > > right one based on architecture.  two options:
> > >
> > > 1.  extend gcc to support this or rearragne linux into segments based on
> > > code type
> > > 2.  Use PE.
> > 
> > The kernel isn't going non-ELF.  Too painful, for dubious advantages,
> > namely:
> > 
> > The current gcc toolchain already supports what you suggest.
> > 
> > I understand that some people have even put some thought into a
> > bootloader that dynamically links your kernel on bootup, so this idea
> > isn't new.  It's a good idea though.
> > 
> 
> Yes, I have been working on it on and off for a while ("off" due to
> various professional and personal issues taking higher priority for some
> time...)


Keep truckin' H. Peter, this is something that's needed.

:-)

Jeff

> 
>   -hpa
> 
> -- 
> <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> http://www.zytor.com/~hpa/puzzle.txt
> -
> 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/
-
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/

fs problem in 2.4.0-test10 -- oops in directory access

[Matthew Hanselman]

I have a directory on my local filesystem that I cannot access on
2.4.0-test10.  It happens when I try to "ls" in this bad directory, and ls
segfaults.

I can poke around tomorrow morning without a reboot, but then I'll have to
reboot (so please respond via email if I can do anything).  I tried
grinding the message through ksymoops-2.3.5, and it complains with this
error:

Warning (Oops_code): trailing garbage ignored on Code: line
  Text: 'Code:  Bad EIP value. '
  Garbage: 'IP value. '
Using defaults from ksymoops -t elf32-i386 -a i386
Error (Oops_code_values): invalid value 0xBad in Code line, must be 2, 4, 8 or 1
Error (Oops_code_values): invalid value 0xE in Code line, must be 2, 4, 8 or 16 

-

Here's the oops from /var/log/messages:

Nov  8 00:11:42 chewbacca kernel: Unable to handle kernel paging request at virtual 
address 00c014aa 
Nov  8 00:11:42 chewbacca kernel:  printing eip: 
Nov  8 00:11:42 chewbacca kernel: 00c014aa 
Nov  8 00:11:42 chewbacca kernel: *pde =  
Nov  8 00:11:42 chewbacca kernel: Oops:  
Nov  8 00:11:42 chewbacca kernel: CPU:0 
Nov  8 00:11:42 chewbacca kernel: EIP:0010:[usb_stor_exit+12588154/-1072693296] 
Nov  8 00:11:42 chewbacca kernel: EFLAGS: 00010206 
Nov  8 00:11:42 chewbacca kernel: eax: 00c014aa   ebx: cf0a1fa4 ecx: da155940   edx: 
c4a70440 
Nov  8 00:11:42 chewbacca kernel: esi:    edi: b020 ebp: b00c   esp: 
cf0a1f94 
Nov  8 00:11:42 chewbacca kernel: ds: 0018   es: 0018   ss: 0018 
Nov  8 00:11:42 chewbacca kernel: Process ls (pid: 9036, stackpage=cf0a1000) 
Nov  8 00:11:42 chewbacca kernel: Stack: c0135dd7 c4a70440 cf0a b020 c4a70440 
eff83540 0003 bfffe830  
Nov  8 00:11:42 chewbacca kernel:bfffe81c 0008 0001 c010a4fb b020 
080549ac 4010fd60 b020  
Nov  8 00:11:42 chewbacca kernel:b020 b00c 00c4 002b 002b 
00c4 400c4e1c 0023  
Nov  8 00:11:42 chewbacca kernel: Call Trace: [sys_lstat64+55/112] [system_call+51/56] 
 
Nov  8 00:11:42 chewbacca kernel: Code:  Bad EIP value. 

Relevant info, probably in decreasing order of relevance:

Adaptec 2940UW
Some sort of IBM scsi disk
784M RAM
Athlon 800

 - Matt

---
Matthew HanselmanQUIQ Inc.
(608) 230-7205 (voice)   25 Kessel Ct #201
(608) 230-7299 (fax) Madison, WI 53711


-
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] Small patches to Configure.help for Alpha (2.2.18pre series)

[Christopher C. Chimelis]

Here's the Configure.help patch for Alpha against the 2.2.18pre
series.  Alan, if you can find time to include this one, I'd appreciate it
:-)

diff -ur linux-2.2.18pre19/Documentation/Configure.help 
linux/Documentation/Configure.help
--- linux-2.2.18pre19/Documentation/Configure.help  Fri Nov  3 16:44:50 2000
+++ linux/Documentation/Configure.help  Fri Nov  3 16:34:55 2000
@@ -1298,32 +1298,38 @@
   have access to a machine on the Internet that has a program like
   lynx or netscape).  In summary:
 
-  Alcor/Alpha-XLT AS 600
+  Alcor/Alpha-XLT AS 600, XL-300, XL-366
   Alpha-XLXL-233, XL-266
   AlphaBook1  Alpha laptop
   Avanti  AS 200, AS 205, AS 250, AS 255, AS 300, AS 400
   Cabriolet   AlphaPC64, AlphaPCI64
-  DP264   DP264
+  DP264   DP264,DS10(L)/20(E),ES40,UP2000(+),XP900/1000,CS20
   EB164   EB164 21164 evaluation board
   EB64+   EB64+ 21064 evaluation board
   EB66EB66 21066 evaluation board
   EB66+   EB66+ 21066 evaluation board
+  Eiger   SMARTEngine SBC models
   Jensen  DECpc 150, DEC 2000 model 300, 
-  DEC 2000 model 500
+   DEC 2000 model 500
   LX164   AlphaPC164-LX
   Miata   Personal Workstation 433a, 433au, 500a,
-  500au, 600a, or 600au
+   500au, 600a, or 600au
   Mikasa  AS 1000
+  NautilusUP1000/1100
   Noname  AXPpci33, UDB (Multia)
   NoritakeAS 1000A, AS 600A, AS 800
+  Platform2000Platform2000
   PC164   AlphaPC164
   Rawhide AS 1200, AS 4000, AS 4100
-  Ruffian RPX164-2, AlphaPC164-UX, AlphaPC164-BX
+  Ruffian AlphaPC164-UX, AlphaPC164-BX
   SX164   AlphaPC164-SX
   Sable   AS 2000, AS 2100
   Takara  Takara
+  Titan   Privateer
+  WildfireAlphaServer GS 40/80/160/320
 
-  If you don't know what to do, choose "generic".
+  Choosing "generic" is the preferred selection, but if you
+  know your system type, you can choose one of the above.
 
 EV5 CPU daughtercard
 CONFIG_ALPHA_PRIMO
@@ -1336,23 +1342,23 @@
 Using SRM as bootloader
 CONFIG_ALPHA_SRM
   There are two different types of booting firmware on Alphas: SRM,
-  which is command line driven, and ARC, which uses menus and arrow
-  keys. Details about the Linux/Alpha booting process are contained in
-  the Linux/Alpha FAQ, accessible on the WWW from
+  which is command line driven, and ARC/AlphaBios, which uses menus and 
+  arrow keys. Details about the Linux/Alpha booting process are contained 
+  in the Linux/Alpha FAQ, accessible on the WWW from
   http://www.alphalinux.org (To browse the WWW, you need to
   have access to a machine on the Internet that has a program like
   lynx or netscape).
 
-  The usual way to load Linux on an Alpha machine is to use MILO
-  (a bootloader that lets you pass command line parameters to the
-  kernel just like lilo does for the x86 architecture) which can be
-  loaded either from ARC or can be installed directly as a permanent
-  firmware replacement from floppy (which requires changing a certain
-  jumper on the motherboard). If you want to do either of these, say N
-  here. If MILO doesn't work on your system (true for Jensen
-  motherboards), you can bypass it altogether and boot Linux directly
-  from an SRM console; say Y here in order to do that. Note that you
-  won't be able to boot from an IDE disk using SRM. 
+  The usual way to load Linux on an Alpha machine is to use SRM console,
+  the same firmware used for loading Tru64 Unix and OpenVMS. The other
+  option being ARC/AlphaBios and MILO (a bootloader that lets you pass
+  command line parameters to the kernel just like lilo does for the 
+  x86 architecture) For more information on MILO please refer to the
+  MILO Howto on the WWW from http://www.alphalinux.org
+
+  If you want to boot via MILO, say N here. If MILO doesn't work on 
+  your system (for example the Jensen, DP264, and Nautilus systems), 
+  you must boot from SRM console; say Y here in order to do that. 
 
   If unsure, say N.
 
@@ -1361,6 +1367,8 @@
   This option controls whether or not the PCI configuration set up by
   SRM is modified.  If you say Y, the existing PCI configuration will
   be left intact.
+
+  If unsure, say N.
 
 Non-standard serial port support
 CONFIG_SERIAL_NONSTANDARD

-
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] Small patches to Configure.help for Alpha

[Christopher C. Chimelis]

Rich Payne (API) and I have made a patch for Documentation/Configure.help
to add some more systems to the list of Alphas.  Since the original list
was compiled, some of the newer system types were added, but not
all.  Also, the list wasn't as inclusive as it should've been (we've been
getting emails saying "which type of system is xxx?").  It also changes
some information regarding SRM, etc, to modernise it a bit.  Multias are
no longer the majority of Alphas out there ;-)

At any rate, this patch is against 2.4.0-test11-pre1.  I'll send a
similar patch for Alan against the 2.2.18pre series.

Thanks!
C

--- linux/Documentation/Configure.help.orig Wed Nov  8 00:28:19 2000
+++ linux/Documentation/Configure.help  Wed Nov  8 00:28:26 2000
@@ -2098,34 +2098,39 @@
   check out the Linux/Alpha FAQ, accessible on the WWW from
   http://www.alphalinux.org . In summary:
 
-  Alcor/Alpha-XLT AS 600
+  Alcor/Alpha-XLT AS 600, XL-300, XL-366
   Alpha-XLXL-233, XL-266
   AlphaBook1  Alpha laptop
   Avanti  AS 200, AS 205, AS 250, AS 255, AS 300, AS 400
   Cabriolet   AlphaPC64, AlphaPCI64
-  DP264   DP264
+  DP264   DP264, DS10(L)/20(E)/ES40, UP2000(+),
+XP900/1000, CS20
   EB164   EB164 21164 evaluation board
   EB64+   EB64+ 21064 evaluation board
   EB66EB66 21066 evaluation board
   EB66+   EB66+ 21066 evaluation board
+  Eiger   SMARTEngine SBC models
   Jensen  DECpc 150, DEC 2000 model 300, 
-  DEC 2000 model 500
+DEC 2000 model 500
   LX164   AlphaPC164-LX
   Miata   Personal Workstation 433a, 433au, 500a,
-  500au, 600a, or 600au
+500au, 600a, or 600au
   Mikasa  AS 1000
+  NautilusUP1000/1100
   Noname  AXPpci33, UDB (Multia)
   NoritakeAS 1000A, AS 600A, AS 800
   PC164   AlphaPC164
+  Platform2000Platform2000
   Rawhide AS 1200, AS 4000, AS 4100
-  Ruffian RPX164-2, AlphaPC164-UX, AlphaPC164-BX
+  Ruffian AlphaPC164-UX, AlphaPC164-BX
   SX164   AlphaPC164-SX
   Sable   AS 2000, AS 2100
   Takara  Takara
   Titan   Privateer
   WildfireAlphaServer GS 40/80/160/320
 
-  If you don't know what to do, choose "generic".
+  Choosing "generic" is the preferred selection, but if you
+  know your system type, you can choose one of the above.
 
 EV5 CPU daughtercard
 CONFIG_ALPHA_PRIMO
@@ -2138,21 +2143,22 @@
 Using SRM as bootloader
 CONFIG_ALPHA_SRM
   There are two different types of booting firmware on Alphas: SRM,
-  which is command line driven, and ARC, which uses menus and arrow
-  keys. Details about the Linux/Alpha booting process are contained in
-  the Linux/Alpha FAQ, accessible on the WWW from
+  which is command line driven, and ARC/AlphaBIOS, which uses menus
+  and arrow keys. Details about the Linux/Alpha booting process
+  are contained in the Linux/Alpha FAQ, accessible on the WWW from
   http://www.alphalinux.org .
 
-  The usual way to load Linux on an Alpha machine is to use MILO
-  (a bootloader that lets you pass command line parameters to the
-  kernel just like lilo does for the x86 architecture) which can be
-  loaded either from ARC or can be installed directly as a permanent
-  firmware replacement from floppy (which requires changing a certain
-  jumper on the motherboard). If you want to do either of these, say N
-  here. If MILO doesn't work on your system (true for Jensen
-  motherboards), you can bypass it altogether and boot Linux directly
-  from an SRM console; say Y here in order to do that. Note that you
-  won't be able to boot from an IDE disk using SRM. 
+  The usual way to load Linux on an Alpha machine is to use the
+  SRM console, the same firmware used for loading Tru64 Unix and
+  OpenVMS. The other option being ARC/AlphaBios and MILO (a
+  bootloader that lets you pass command line parameters to the
+  kernel just like lilo does for the x86 architecture) For more
+  information on MILO please refer to the MILO Howto on the WWW
+  from http://www.alphalinux.org
+
+  If you want to boot via MILO, say N here. If MILO doesn't work on 
+  your system (for example the Jensen, DP264, and Nautilus systems), 
+  you must boot from SRM console; say Y here in order to do that.
 
   If unsure, say N.
 


-
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: [RANT] Linux-IrDA status

[Linus Torvalds]

On Wed, 8 Nov 2000, Michael Rothwell wrote:
> Linus Torvalds wrote:
> > 
> > Also, I've never seen much in the form of explanation, and at least the
> > last patch I saw just the first screenful was so off-putting that I just
> > went "Ok, I have real bugs to fix, I don't need this crap".
>
> Like what? I'm not sure what you're saying here. It seems that the pople
> writing the IrDA code have gotten no feedback from you as to why their
> patch is never accepted -- could you clarify?

There's one _major_ reason why things never get accepted:

 CVS trees

I'm not fed patches. I'm force-fed big changes every once in a while. I
don't like it.

I like it even less when the very first screen of a patch is basically a
stupid change that implies that somebody calls ioctl's from interrupts.

When I get a big patch like that, where the very first screen is
bletcherous, what the hell am I supposed to do? I'm not going to waste my
time on people who cannot send multiple small and well-defined patches,
and who send be big, ugly, "non-maintained" (as far as I'm concerned)
patches.

I'm surprised Alan rants about this. He knows VERY well how I work, and is
(along with Jeff Garzik and Randy Dunlap) one of the people who are very
good at sending me 25 separate patches with explanations of what they do.

Basically, if you send me a big patch with tons of changes, how the hell
DO you expect me to answer them? Does anybodt really expect me to go
through ten thousand lines of code that I do not know, and comment on it?
Obviously not, as anybody with an ounce of sense would see.

So what choice do I have? Apply them blindly?

Quite frankly, I'd rather have a few people hate me deeply than apply
stuff I don't like. If I just start blindly applying big patches, I can
avoid nasty discussions. But I'd rather have people flame me. Maybe some
day people will instead start sending me smaller commented patches.

I'm NOT going to do other peoples work for them. If people can't be
bothered to send me well-specified patches ESPECIALLY now that we're close
to 2.4.x, then I can't be bothered to apply them,

Live with it. Hat eme all you like. I do not care. Th ething I care about
is not letting too much crap through unchecked.

Linus

-
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: [RANT] Linux-IrDA status

[Michael Rothwell]

Linus Torvalds wrote:
> 
> On Tue, 7 Nov 2000, Michael Rothwell wrote:
> >
> > Linus, can you post reasons why you keep ignoring^W rejecting the IrDA
> > patch?
> 
> Basically, whatever Alan rants, I've not seen the patches all that many
> times at all.
> 
> Also, I've never seen much in the form of explanation, and at least the
> last patch I saw just the first screenful was so off-putting that I just
> went "Ok, I have real bugs to fix, I don't need this crap".
> 
> Linus


Like what? I'm not sure what you're saying here. It seems that the pople
writing the IrDA code have gotten no feedback from you as to why their
patch is never accepted -- could you clarify? They're apparently putting
a lot of effort into writing and fixing IrDA for Linux, and have become
very discouraged at the lack of feedback. "Crap" the code may be, but it
seems like it would be a good idea to at least say something substantive
about why their code keeps getting rejected.
-
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: Question on new PCI architecture (2.4.x)

[Jeff Garzik]

Ivan Passos wrote:
> 
> Hello,
> 
> I was just checking the driver changes needed to comply with the new PCI
> architecture in 2.4.x, and then I got into a problem. I noticed that all
> drivers that use this architecture (or at least the ones I found, such as
> the Tulip, EEPro100, 3c59x ...) support boards with only one net_device
> per board. What about boards with more than one net_device??
> 
> In my case, the driver supports one- and two-channel boards, and I don't
> know how to remove a board that has two net_devices (since
> pdev->driver_data can't contain two pointers!! ;).

pdev->driver_data is only there as a convenience, there is no rule about
one device per board.

In the case of multiple net devices per board, pdev->driver_data would
point to a structure which you allocate, which contains pointers to each
of that board's net devices.


> Also, if anyone could give me pointers to documentation on this new PCI
> architecture (sample src code would be great, real documentation, even
> better!!), I'd really appreciate it.

What questions do you have?

Documentation/pci.txt, include/linux/pci.h, drivers/pci/pci.c, and
various PCI drivers are the only documentation available.

Jeff


-- 
Jeff Garzik | "When I do this, my computer freezes."
Building 1024   |  -user
MandrakeSoft| "Don't do that."
|  -level 1
-
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/

Question on new PCI architecture (2.4.x)

[Ivan Passos]

Hello,

I was just checking the driver changes needed to comply with the new PCI
architecture in 2.4.x, and then I got into a problem. I noticed that all
drivers that use this architecture (or at least the ones I found, such as
the Tulip, EEPro100, 3c59x ...) support boards with only one net_device
per board. What about boards with more than one net_device??

In my case, the driver supports one- and two-channel boards, and I don't
know how to remove a board that has two net_devices (since
pdev->driver_data can't contain two pointers!! ;).

Also, if anyone could give me pointers to documentation on this new PCI
architecture (sample src code would be great, real documentation, even
better!!), I'd really appreciate it.

Thanks in advance!

Regards,
Ivan

-
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] deadlock fix

[Linus Torvalds]

On Tue, 7 Nov 2000, Gary E. Miller wrote:
> 
> I see this patch did not make it into test11-pre1.  Without it
> raid1 and SMP do not work together.  Please consider for test11-pre2.

You must have a different test11-pre1 than the one I have.

It's already there in -pre1, as far as I can see.

Linus


-
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: ide-probe.c:400: `rtc_lock' undeclared and /lib/modules/..../build

[Keith Owens]

On Tue, 7 Nov 2000 21:48:59 -0500 (EST), 
"Mike A. Harris" <[EMAIL PROTECTED]> wrote:
>On Tue, 7 Nov 2000, Alan Cox wrote:
>>Actually they do. I agree that it wants sorting. Im just wondering what the
>>best approach is - maybe check modutils rev and only add the link if its high
>>enough ?
>
>What if build-machine != machine-kernel-was-built-for?

Then you are SOL, but that is a generic cross compile problem.  Anybody
doing cross compile has to do extra steps to copy the results to the
other machine and they can take care of problems like the build symlink
themselves.  The patch in 2.2.18-pre20 fixes the problem for local
compiles, which are 95%+ (SWAG) of the compiles.

-
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: Installing kernel 2.4

[davej]

On Tue, 7 Nov 2000, Jeff V. Merkey wrote:

> Your way out in the weeds.  What started this thread was a customer who
> ended up loading the wrong arch on a system and hanging.  I have to
> post a kernel RPM for our release, and it's onerous to make customers
> recompile kernels all the time and be guinea pigs for arch ports.  
> They just want it to boot, and run with the same level of ease of use
> and stability they get with NT and NetWare and other stuff they are used
> to.   This is an easy choice from where I'm sitting.

So you're complaining that as a vendor you have to ship multiple kernels?
The point remains the same.

The only time I recall recently where a kernel hasn't booted was when the
AMD Athlon appeared, and the MTRR code needed fixing.
There wasn't a lot anyone could have done, without seeing documentation
(which iirc wasn't available at the time).
The reason NT & Netware probably loaded fine is that they don't set
the MTRRs themselves, but rely on third party utilities to do this
for them after they've booted.

All other recent cases of non booting that I've seen have been a
case of user error miscompiling for a wrong target.
As a vendor, you don't worry about this as you ship binary kernels,
and $enduser never needs to see a source tree.

davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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: Installing kernel 2.4

[davej]

On Tue, 7 Nov 2000, Jeff V. Merkey wrote:

> What makes more sense is to pack multiple segments for different 
> processor architecures into a single executable package, and have the 
> loader pick the right one (the NT model).  It could be used for 
> SMP and non-SMP images, though, as well as i386, i586, i686, etc.  

Jeff, in x86 alone, there are 13 different compile targets (2.4 tree),
soon to be more when Cyrix III & Pentium IV get added.
Although it doesn't make sense on all of these, it's possible to
compile any of them with SMP support too.

That's 30 different combinations.
Suggesting to put all these into one file isn't a bad idea,
it's bordering on insanity. What do you hope to achieve by doing
this, apart from the end user not having to choose a custom kernel
for their architecture ? Much better to have several kernels built
seperately for each arch, and have the user pick which one
(or even have the distro installer autodetect) at install time,
as SuSE, Red Hat, Mandrake, and several other distros are now doing.

Everything all in one may be the way NT does it, but that does not
mean it's a good idea. In fact it's anything but a good idea.
Please don't try to bring the braindamages of NT to Linux, it
just isn't meant to happen.

regards,

Davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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: ide-probe.c:400: `rtc_lock' undeclared and /lib/modules/..../build

[Mike A. Harris]

On Tue, 7 Nov 2000, Alan Cox wrote:

>Date: Tue, 7 Nov 2000 12:11:57 + (GMT)
>From: Alan Cox <[EMAIL PROTECTED]>
>To: Keith Owens <[EMAIL PROTECTED]>
>Cc: Tomasz Motylewski <[EMAIL PROTECTED]>,
> Alan Cox <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: ide-probe.c:400: `rtc_lock' undeclared and
>/lib/modules//build
>
>> Agreed, I was unhappy that the build symlink was added to 2.2 kernels.
>> Now you need modutils >= 2.3.14 for 2.2 kernels :(.  But nobody asks
>> me, I'm just the kernel module.[ch] and modutils maintainer.
>
>Actually they do. I agree that it wants sorting. Im just wondering what the
>best approach is - maybe check modutils rev and only add the link if its high
>enough ?

What if build-machine != machine-kernel-was-built-for?


--
   NOTE:  My new email address is:  [EMAIL PROTECTED]

  Mike A. Harris  -  Linux advocate  -  Open source advocate
  Computer Consultant - Capslock Consulting
 Copyright 2000 all rights reserved
--

"Facts do not cease to exist because they are ignored."
   - Aldous Huxley


-
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: Installing kernel 2.4

[Jeff V. Merkey]

On Wed, Nov 08, 2000 at 03:39:39AM +, [EMAIL PROTECTED] wrote:
> On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> 
> > > remember it's not just the start of the file that varies based on cachline
> > > size, it's the positioning of code and data thoughout the kernel image.
> > Understood.  I will go off and give some thought and study and respond
> > later after I have a proposal on the best way to do this.   In NetWare,
> > we had indirections in the code all over the place.  NT just make huge
> > and fat programs (NTKRNLOS.DLL is absolutely huge).
> 
> I'm glad you realise this.  The Netware method you mention above sounds
> over complicated for the desired end result, and the NT method just sounds
> like a gross hack.
> 
> The current 'compile for the arch you intend to run on' is right now,
> the simplest, cleanest way to do this.
> 
> If you manage to pull something off in MANOS or whatever other OS,
> to prove all this otherwise (without resorting to ugly hacks like the
> above), great for you, I (and I assume others) would like to hear
> about it.

Your way out in the weeds.  What started this thread was a customer who
ended up loading the wrong arch on a system and hanging.  I have to
post a kernel RPM for our release, and it's onerous to make customers
recompile kernels all the time and be guinea pigs for arch ports.  
They just want it to boot, and run with the same level of ease of use
and stability they get with NT and NetWare and other stuff they are used
to.   This is an easy choice from where I'm sitting.

Jeff  
 
> Davej.
> 
> -- 
> | Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
> | SuSE Labs
-
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: Installing kernel 2.4

[davej]

On Tue, 7 Nov 2000, Marty Fouts wrote:

> There's been a bunch of related work done at the Oregon Graduate Institute
> by Calton Pu and others.  See
> http://www.cse.ogi.edu/DISC/projects/synthetix/publications.html for a list
> of papers.

The only paper that immediately caught my eye of relevance was the one
on dynamic optimization techniques, which is what I assume you
were referring to.

It's interesting stuff, but I think it'd be a cold day in hell before
Linus accepts a dynamic recompiler in kernel space. :)

regards,

davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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: Installing kernel 2.4

[Jeff V. Merkey]

On Wed, Nov 08, 2000 at 03:25:56AM +, [EMAIL PROTECTED] wrote:
> On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> 
> > If the compiler always aligned all functions and data on 16 byte
> > boundries (NetWare)  for all i386 code, it would run a lot faster.
> 
> Except on architectures where 16 byte alignment isn't optimal.
> 
> > Cache line alignment could be an option in the loader  after all,
> > it's hte loader that locates data in memory.  If Linux were PE based,
> > relocation logic would be a snap with this model (like NT).
> 
> Are you suggesting multiple files of differing alignments packed into
> a single kernel image, and have the loader select the correct one at
> runtime ? I really hope I've misinterpreted your intention.

Or more practically, a smart loader than could select a kernel image
based on arch and auto-detect to load the correct image. I don't really
think it matters much what mechanism is used.   

What makes more sense is to pack multiple segments for different 
processor architecures into a single executable package, and have the 
loader pick the right one (the NT model).  It could be used for 
SMP and non-SMP images, though, as well as i386, i586, i686, etc.  

Jeff

> 
> regards,
> 
> Davej.
> 
> -- 
> | Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
> | SuSE Labs
-
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: Installing kernel 2.4

[davej]

On Tue, 7 Nov 2000, Jeff V. Merkey wrote:

> > remember it's not just the start of the file that varies based on cachline
> > size, it's the positioning of code and data thoughout the kernel image.
> Understood.  I will go off and give some thought and study and respond
> later after I have a proposal on the best way to do this.   In NetWare,
> we had indirections in the code all over the place.  NT just make huge
> and fat programs (NTKRNLOS.DLL is absolutely huge).

I'm glad you realise this.  The Netware method you mention above sounds
over complicated for the desired end result, and the NT method just sounds
like a gross hack.

The current 'compile for the arch you intend to run on' is right now,
the simplest, cleanest way to do this.

If you manage to pull something off in MANOS or whatever other OS,
to prove all this otherwise (without resorting to ugly hacks like the
above), great for you, I (and I assume others) would like to hear
about it.

regards,

Davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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 Panic - weird error

[Chmouel Boudjnah]

Sean Middleditch <[EMAIL PROTECTED]> writes:

> I've installed the Linux-Mandrake 7.2 distro (which uses kernel version
> 2.2.17) on a PIII system (Asus motherboard, Award Medallion v6.0 BIOS).
> For some reason, neither LILO nor Grub were able to boot off of the
> second hard-drive (where Linux is).  I've copied over the kernel, and a
> few other LILO files to a Windows partition on the primary drive.  Now,
> LILO can load the kernel, and the kernel begins to boot.
> 
> First, I noticed this during the IDE detection:
>   hdd [PTBL] [784/255/53] hdd1 < hdd5 hdd6 >
> I've never seen the "[PTBL] [784/255/53]" part before on any Linux
> system, so I was unsure if this was important.

have you enabled the optimization ? which add the autotune options
and do some time weird thing.

-- 
MandrakeSoft Inc http://www.chmouel.org
  --Chmouel
-
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: Installing kernel 2.4

[Matthew Kirkwood]

On Tue, 7 Nov 2000, Jeff V. Merkey wrote:

(Please forgive this snippage making Jeff look less literate
than he is, even after several beers.)

> We need a format that allow
[..]
> the right one based on architecture.

Oh, we already have that.  It's called source code.

Matthew.

-
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: Installing kernel 2.4

[davej]

On Tue, 7 Nov 2000, Jeff V. Merkey wrote:

> > > Detecting the CPU isn't the issue (we already do all this), it's what to
> > > do when you've figured out what the CPU is. Show me code that can
> > > dynamically adjust the alignment of the routines/variables/structs
> > > dependant upon cacheline size.
> 
> ftp.timpanogas.org/manos/manos0817.tar.gz   
> 
> Look in the PE loader

The last time I looked at your code, I stopped reading after I got
to a comment mentioning trade secrets, and intellectual property.

> -- Microsoft's PE loader can do this since everything is RVA based.  
> If you want to take the loader and put it in Linux, be my guest.

Why ??

> You can even combine mutiple i86 segments all compiled under different
> options (or architectures) and bundle them into a single executable file

There is nothing stopping us from doing that now, we just choose not to,
as it would result in a ridiculously oversized kernel. Even if the loader
threw away the non-used segments, I don't think anyone can justify an
on-disk kernel image containing mostly code they never execute.

regards,

Davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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: Installing kernel 2.4

[davej]

On Tue, 7 Nov 2000, Jeff V. Merkey wrote:

> If the compiler always aligned all functions and data on 16 byte
> boundries (NetWare)  for all i386 code, it would run a lot faster.

Except on architectures where 16 byte alignment isn't optimal.

> Cache line alignment could be an option in the loader  after all,
> it's hte loader that locates data in memory.  If Linux were PE based,
> relocation logic would be a snap with this model (like NT).

Are you suggesting multiple files of differing alignments packed into
a single kernel image, and have the loader select the correct one at
runtime ? I really hope I've misinterpreted your intention.

regards,

Davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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-test10] zImage, pcmcia, and ufs(44bsd)

[imel96]

> imel96 wrote:
> > 
> > hi all,
> > 
> > just a few reports:
> > 
> > 1. zImage in test10 somehow isn't working
properly. i have a
> > zImage sized a bit more than 500kb on my
harddrive which hangs at
> > the loading process (the one showing dots).
> > i write the image to a floppy, and it boots just
fine. if i
> > recompiled my kernel so the zImage size is
around 490kb, the
> > image gets loaded just fine.
> 
> make bzImage

if someone remove zImage. the zImage built just fine.
my problem is the zImage doesn't boot on a harddrive,
while it's working just fine on floppy disk.




imel


This email was sent using http://webmail.cbn.net.id/


-
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.2.17: do_try_to_free_pages fails, no OOM

[Magnus Naeslund\(b\)]

From: "octave klaba" <[EMAIL PROTECTED]>
> > Oct 24 00:07:39 gimme kernel: VM: do_try_to_free_pages failed for
> > postmaster...
>
> 2.2.18pre19 should fix this problem if andrea's patch is inside.
> if not, you have to patch pre18 with VM-global-2.2.18pre18-7.bz2
> if you are from europe you can downlaod it from:
>
ftp://ftp.ovh.net/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre18/VM
-global-2.2.18pre18-7.bz2
>
> Octave
>

I can confirm that pre20 + arcangelis VM-global seems to apply fine.
No troubles here, compiling it now...

Magnus

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Programmer/Networker [|] Magnus Naeslund
 PGP Key: http://www.genline.nu/mag_pgp.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


-
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: Installing kernel 2.4

[Marty Fouts]

There's been a bunch of related work done at the Oregon Graduate Institute
by Calton Pu and others.  See
http://www.cse.ogi.edu/DISC/projects/synthetix/publications.html for a list
of papers.



> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 07, 2000 3:25 PM
> To: Linux Kernel Mailing List
> Cc: [EMAIL PROTECTED]
> Subject: Re: Installing kernel 2.4
> 
> 
> 
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings.  All of 
> this could
> > be dynamic.  Here's some code that does this, and it's similiar to
> > NetWare.  It detexts CPU type, feature flags, special instructions,
> > etc.  All of this on x86 could be dynamically detected.
> 
> Detecting the CPU isn't the issue (we already do all this), 
> it's what to
> do when you've figured out what the CPU is. Show me code that can
> dynamically adjust the alignment of the routines/variables/structs
> dependant upon cacheline size.
> 
> regards,
> 
> Davej.
> 
> -- 
> | Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
> | SuSE Labs
> 
> -
> 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/
> 
-
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: xterm: no available ptys

[H. Peter Anvin]

Igmar Palsenberg wrote:
> 
> > > I'm missing ptmx. You NEED a writable /dev/pts dir.
> > >
> >
> > Actually, what you need is the devpts filesystem mounted onto
> > /dev/pts.
> 
> Agree. I had a shitload of probs when 2.2.0 came out and I switched.. Was
> due that /dev was readonly here. Bit strange if I think of it.
> 

If you don't have devpts mounted, glibc tries to use a setuid program to
hack around /dev for you.  I'd rather wish it didn't, actually.

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: Installing kernel 2.4

[Marty Fouts]

There is a variation of #2 that is often good enough, based on some research
work done at (among other places) the Oregon Graduate Center.  I don't have
the references handy, but you might want to look for papers on "sandboxing"
authored there.

The basic idea is similar to the one used by many 'recompile on the fly'
systems, and involves marking the code in such a way that even inline pieces
can be replaced on the fly.  Very useful for things like system specific
memcpy implementations.

Marty


> -Original Message-
> From: David Lang [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 07, 2000 4:11 PM
> To: Jeff V. Merkey
> Cc: [EMAIL PROTECTED]; Martin Josefsson; Tigran Aivazian; Anil kumar;
> [EMAIL PROTECTED]
> Subject: Re: Installing kernel 2.4
> 
> 
> Jeff, the problem is not detecting the CPU type at runtime, 
> the problem is
> trying to re-compile the code to take advantage of that CPU 
> at runtime.
> 
> depending on what CPU you have the kernel (and compiler) can 
> use different
> commands/opmizations/etc, if you want to do this on boot you have two
> options.
> 
> 1. re-compile the kernel
> 
> 2. change all the CPU specific places from inline code to 
> function calls
> into a table that get changed at boot to point at the correct calls.
> 
> doing #2 will cost you so much performance that you would be 
> better off
> just compiling for a 386 and not going through the autodetect 
> hassle in
> the first place.
> 
> David Lang
> 
-
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: Installing kernel 2.4

[H. Peter Anvin]

Jeff Garzik wrote:
> 
> "Jeff V. Merkey" wrote:
> > We need a format that allow multiple executable segments to be combined
> > in a single executable and the loader have enough smarts to grab the
> > right one based on architecture.  two options:
> >
> > 1.  extend gcc to support this or rearragne linux into segments based on
> > code type
> > 2.  Use PE.
> 
> The kernel isn't going non-ELF.  Too painful, for dubious advantages,
> namely:
> 
> The current gcc toolchain already supports what you suggest.
> 
> I understand that some people have even put some thought into a
> bootloader that dynamically links your kernel on bootup, so this idea
> isn't new.  It's a good idea though.
> 

Yes, I have been working on it on and off for a while ("off" due to
various professional and personal issues taking higher priority for some
time...)

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
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: Linux 2.2.18pre20

[Michael Rothwell]

Alan Cox wrote:
> 
> > On Tue, Nov 07, 2000 at 09:02:36PM -0500, Michael Rothwell wrote:
> > > 64-bit printk.
> >
> > Please consider this one Alan, if not for v2.2.18, then at least for
> > v2.2.19pre1.
> 
> Nobody has explained why we even need it.

Alan Cox wrote:
> 
> Why do we need it ?

To print 64-bit debugging output on 32-bit machines. I personally need
it to aid with development of a 64-bit filesystem. We're maintaining our
own 2.2.17 patched kernel here, but I figure that other people can make
use of 64-bit printk in their efforts as well.

Perhaps a better question would be, why reject it? 2.4 supports 64-bit
printk, right? It would be nice to have it on 2.2 as well, as it may be
a while before 2.4 is widely used in production machines.

-M
-
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: Linux 2.2.18pre20

[Alan Cox]

> On Tue, Nov 07, 2000 at 09:02:36PM -0500, Michael Rothwell wrote:
> > 64-bit printk.
> 
> Please consider this one Alan, if not for v2.2.18, then at least for
> v2.2.19pre1.

Nobody has explained why we even need it. 

-
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: Linux 2.2.18pre20

[David Weinehall]

On Tue, Nov 07, 2000 at 09:02:36PM -0500, Michael Rothwell wrote:
> 64-bit printk.

Please consider this one Alan, if not for v2.2.18, then at least for
v2.2.19pre1.


/David
  _ _
 // David Weinehall <[EMAIL PROTECTED]> /> Northern lights wander  \\
//  Project MCA Linux hacker//  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/http://www.tux.org/lkml/

Re: Linux 2.2.18pre20

[Michael Rothwell]

64-bit printk.

-M

Alan Cox wrote:
> 
> Ok last call for 2.2.18. The PS/2 cases I've looked at all appear to be
> ghost PS/2 interfaces created due to the USB support fooling programs.

diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified 
linux-2.2.16/include/asm-alpha/div64.h linux/include/asm-alpha/div64.h
--- linux-2.2.16/include/asm-alpha/div64.h  Wed Dec 31 19:00:00 1969
+++ linux/include/asm-alpha/div64.h Fri Aug 11 20:04:18 2000
@@ -0,0 +1,14 @@
+#ifndef __ALPHA_DIV64
+#define __ALPHA_DIV64
+
+/*
+ * Hey, we're already 64-bit, no
+ * need to play games..
+ */
+#define do_div(n,base) ({ \
+   int __res; \
+   __res = ((unsigned long) (n)) % (unsigned) (base); \
+   (n) = ((unsigned long) (n)) / (unsigned) (base); \
+   __res; })
+
+#endif
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified 
linux-2.2.16/include/asm-arm/div64.h linux/include/asm-arm/div64.h
--- linux-2.2.16/include/asm-arm/div64.hWed Dec 31 19:00:00 1969
+++ linux/include/asm-arm/div64.h   Fri Aug 11 20:05:41 2000
@@ -0,0 +1,14 @@
+#ifndef __ASM_ARM_DIV64
+#define __ASM_ARM_DIV64
+
+/* We're not 64-bit, but... */
+#define do_div(n,base) \
+({ \
+   int __res;  \
+   __res = ((unsigned long)n) % (unsigned int)base;\
+   n = ((unsigned long)n) / (unsigned int)base;\
+   __res;  \
+})
+
+#endif
+
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified 
linux-2.2.16/include/asm-i386/div64.h linux/include/asm-i386/div64.h
--- linux-2.2.16/include/asm-i386/div64.h   Wed Dec 31 19:00:00 1969
+++ linux/include/asm-i386/div64.h  Fri Aug 11 20:06:05 2000
@@ -0,0 +1,17 @@
+#ifndef __I386_DIV64
+#define __I386_DIV64
+
+#define do_div(n,base) ({ \
+   unsigned long __upper, __low, __high, __mod; \
+   asm("":"=a" (__low), "=d" (__high):"A" (n)); \
+   __upper = __high; \
+   if (__high) { \
+   __upper = __high % (base); \
+   __high = __high / (base); \
+   } \
+   asm("divl %2":"=a" (__low), "=d" (__mod):"rm" (base), "0" (__low), "1" 
+(__upper)); \
+   asm("":"=A" (n):"a" (__low),"d" (__high)); \
+   __mod; \
+})
+
+#endif
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified 
linux-2.2.16/include/asm-m68k/div64.h linux/include/asm-m68k/div64.h
--- linux-2.2.16/include/asm-m68k/div64.h   Wed Dec 31 19:00:00 1969
+++ linux/include/asm-m68k/div64.h  Fri Aug 11 20:06:57 2000
@@ -0,0 +1,35 @@
+#ifndef _M68K_DIV64_H
+#define _M68K_DIV64_H
+
+/* n = n / base; return rem; */
+
+#if 1
+#define do_div(n, base) ({ \
+   union { \
+   unsigned long n32[2];   \
+   unsigned long long n64; \
+   } __n;  \
+   unsigned long __rem, __upper;   \
+   \
+   __n.n64 = (n);  \
+   if ((__upper = __n.n32[0])) {   \
+   asm ("divul.l %2,%1:%0" \
+   : "=d" (__n.n32[0]), "=d" (__upper) \
+   : "d" (base), "0" (__n.n32[0]));\
+   }   \
+   asm ("divu.l %2,%1:%0"  \
+   : "=d" (__n.n32[1]), "=d" (__rem)   \
+   : "d" (base), "1" (__upper), "0" (__n.n32[1])); \
+   (n) = __n.n64;  \
+   __rem;  \
+})
+#else
+#define do_div(n,base) ({  \
+   int __res;  \
+   __res = ((unsigned long) n) % (unsigned) base;  \
+   n = ((unsigned long) n) / (unsigned) base;  \
+   __res;  \
+})
+#endif
+
+#endif /* _M68K_DIV64_H */
diff -B --unidirectional-new-file --exclude-from=DiffExcludeList --recursive --unified 
linux-2.2.16/include/asm-mips/div64.h linux/include/asm-mips/div64.h
--- linux-2.2.16/include/asm-mips/div64.h   Wed Dec 31 19:00:00 1969
+++ linux/include/asm-mips/div64.h  Fri Aug 11 20:41:49 2000
@@ -0,0 +1,20 @@
+/* $Id: div64.h,v 1.1.2.1 2000/08/12 00:41:49 zapman Exp $
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License.  See the file "COPYING" in the main directory of this archive
+ * for more details.
+ */
+#ifndef 

Linux 2.2.18pre20

[Alan Cox]

Ok last call for 2.2.18. The PS/2 cases I've looked at all appear to be
ghost PS/2 interfaces created due to the USB support fooling programs.

Break it if you can 8)

Alan

[S/390 stuff isnt trivial to merge so will have to wait]

2.2.18pre20
o   Fix ide-probe SMP build error   (Ian Morgan)
o   Fix appletalk physical layer ioctl handling (Andi Kleen)
o   Sparc update(Dave Miller)
o   Update Stephen Tweedie's contact info   (Stephen Tweedie)
o   Fix typo in esp and scsi_obsolete code  (Dave Miller)
o   Bonding ioctl check fix (Willy Tarreau)
o   Fix ipv6 procfs bug (Al Viro)
o   Report PIV in proc as family 15 and uname as(me)
model 6 as discussed
o   Redo Intel cache decodes as code not tables (me)
and add new ones  (based on updates by
Asit Mallick & Andrew Ip)
o   Fix CMOS locking in machine_power_off paths (me)
o   Create build tree symlinks only if insmod is
new enough not to be confused by it (Keith Owens)
o   Fix cmsg handling   (Philippe Troin)
o   Tiny xpds driver changes(Dan Hollis)
o   Fix vmalloc sign bug(Ben LaHaise)
o   SMBFS fixes/changes for find_next problems and  (Urban Widmark)
to avoid truncate bug in netapps
o   Fix ntfs translation bug(Anton Altaparmakov)
o   Fix sparc problem with some soundcards and the  (Jedd Garzik)
_IOC magic
o   Update ppa driver to v2.05  (Tim Waugh)


2.2.18pre19
o   Fix transproxy socket lookup(Val Henson)
o   Add ICS1893 PHY to the SiS900 driver(Lei-Chun Chang)
o   Fix documentation error in matroxfb (Vsevolod Sipakov)
o   Update IDE floppy maintainer(Paul Bristow)
o   Fix remaining cmos locking  (Paul Gortmaker)
o   Fix sparc bitfield/compiler bits on sound   (Dave Miller)
o   Update Pegasus USB driver   (Petko Manolov)
o   Networking updates - move divert header (Andi Kleen)
o   Add ETH_P_ATM* defines  (Matti Aarnio)
o   Fix one more missing GFP_KERNEL/sk->allocation  (Dave Miller)
o   Fix ISDN multilink handler bug  (Kai Germaschewski)
o   Fix ymfpci unload cases (Kai Germaschewski)

2.2.18pre18
o   Fix off by one in net/ipv4/proc (Dave Miller)
o   Move the fpu emu patch that got away(Dave Miller)
o   K6 update for MTRR ability  (Dave Jones)
o   Fix raid1/vm deadlock   (Marcelo Tosatti)
o   Fix usb mouse userspace memory accesses (David Woodhouse)
o   Fix xpdsl if compiled in (typo) (Arjan van de Ven)
o   Rio fixes for modem handling. Fix a small (Patrick van de Lageweg)
generic serial bug
o   IBMtr driver fixes for cable pulls, pcmcia  (Burt Silverman,
behaviour etcMike Sullivan)
o   Tidy up /dev/microcode messages (Daniel Roesen)
o   Add arpfilter   (Andi Kleen)
o   IDE floppy updates for clik support, cleanups   (Paul Bristow)
o   Fix irongate handling on Alpha  (Soohoon Lee)
o   Fix HZ=100 assumption in aha152x.c  (me)
o   Fix power management handling in i810 audio (me)
(From an ALSA fix by Godmar Back)
o   Put the NFS block default back to 4K(Trond Myklebust)
o   Fix misleading comment in printk code   (Riley Williams)
o   Fix fbcon scroll back/paste bug (Herbert Xu)
o   Fix rtc_lock for ide-probe, and hd.c(Richard Johnson)
o   Backport of 2.4 PR_GET/SET_KEEPCAPS (Brian Brunswick)
(from Chris Evans 2.4 code)
o   LRU list corruption fix (Andrea Arcangeli)
o   Initial gcc 2.96+ support for kernel building   (H J Lu)
| Not a recommended compiler for production kernels...
o   ALI silence clearing fix(Ching-Ling Lee)
o   Fix remaining old-style use of copy_strings (Solar Designer)
o   Better pci_resource_start macro for 2.2 (Jeff Garzik)
o   Fix nbd deadlock(Marcelo Tosatti)

2.2.18pre17
o   Move a few escaped m68k headers into the right  (me)
directory
o   Backport 2.4 AF_UNIX garbage collect speedups   (Dave Miller)
o   TCP fixes for NFS   (Saadia Khan)
o   Fix USB audio hangs (David Woodhouse)
o   Sparc64 dcache and exec fixes   (Dave Miller)
o  

Re: [RANT] Linux-IrDA status

[Jean Tourrilhes]

On Tue, Nov 07, 2000 at 08:24:38PM -0500, Jeff Garzik wrote:
> 
> Take a look at
> http://www.uwsg.iu.edu/hypermail/linux/kernel/9908.0/0669.html  This
> happened with ISDN.  Slightly different situation, but similar.

I'm familiar with that. The *BIG* difference is that Dag has
always sent his patch to Linus from the very start, when it was still
small, whereas ISDN did stay on their patch from a long time.

> IMHO Dag should send break up his patches into small chunks, and feed
> those to Linus, with an explanation of each chunk.  That's what
> everybody else does... :)

If you can break up stuff that has accumulated over one year,
please tell me so. Most of the original patches have been lost in the
mist of time. We could send it file by file, but that would give some
interesting results ;-)
There is also a tradeoff between having the maintainer doing
the filtering to make sure that what's get checked in is safe and
getting junk in the kernel. With IrDA, Dag make sure to test and
integrate each patch before sending it to Linus, which of course make
bigger chunks. Also, some of the contribution on the IrDA mailing list
are big chunks of patches by themselves.
Anyway, Linus should read the Linux-IrDA mailing list if he
really want to keep up with the gory details ;-)

>   Jeff

Ciao...

Jean
-
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: malloc(1/0) ??

[Tim Waugh]

On Wed, Nov 08, 2000 at 01:41:40AM +0100, Igmar Palsenberg wrote:

> malloc(0) is bogus in this case. malloc(0) == free();

No, you're thinking of realloc.

Tim.
*/

 PGP signature

Re: Locking Between User Context and Soft IRQs in 2.4.0

[Rusty Russell]

In message <[EMAIL PROTECTED]> you write:
> Paul Gortmaker wrote:
> > - extern void ether_setup(struct net_device *dev);
> > + extern void __ether_setup(struct net_device *dev);
> > + static inline void ether_setup(struct net_device *dev){
> > +   dev->owner = THIS_MODULE;
> > +   __ether_setup(dev);
> > + }
> > 
> > Ugh. Probably should just add it to each probe and be done with it...
> 
> mm..  Seeing as failure to set dev->owner is a fatal mistake,
> it would be good to enforce this via the compiler type system.
> 
> How about making THIS_MODULE an argument to register_netdevice()
> and, hence, register_netdev() and init_etherdev()?

Bear in mind that in 2.5, the THIS_MODULE registration cancer
infesting the kernel[1] will vanish with two-stage module delete[2].

http://www.wcug.wwu.edu/lists/netdev/26/msg00250.html

Rusty.

[1] And getting worse.
[2] Which was the correct solution for 2.4, only I was all out of
`get out of code freeze free' cards.
--
Hacking time.
-
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: Installing kernel 2.4

[Jeff V. Merkey]

Alan Cox wrote:
> 
> > I'll grab the code in linux and port.
> 
> You are welcome
> 
> Make sure you get a pretty current 2.2.x tree however. The ultra deep magic
> for detecting NexGen processors is recent. It took a long time before I found
> someone who knew how it worked 8)

I'll get on it.  Alan, if ELF can do this now, it would be good idea to
do this with the mutiple images.  Sounds like it's just a link option
and a few more smarts in the lilo and boot loader to make it work.

8)

Jeff
-
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: Installing kernel 2.4

[Alan Cox]

> We need a format that allow multiple executable segments to be combined
> in a single executable and the loader have enough smarts to grab the
> right one based on architecture.  two options:

ELF can do that just fine


-
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: Installing kernel 2.4

[Alan Cox]

> I'll grab the code in linux and port.

You are welcome

Make sure you get a pretty current 2.2.x tree however. The ultra deep magic
for detecting NexGen processors is recent. It took a long time before I found
someone who knew how it worked 8)


-
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: Installing kernel 2.4

[Jeff V. Merkey]

Jeff Garzik wrote:
> 
> Jeff Merkey wrote:
> > The PE model uses flags to identify CPU type and capbilities
> 
> So does ELF.

Jeff,

Can we also combine mutiple segments from different processors or is it
a one-sy two-sy king of affair?  If so, we're there, it just becomes a
linking option.

I am building the RPM for Ute Linux with 2.4.0-10 and right now, I have
to do what RedHat does, and create the /config "directory from hell"
with two dosen .config files and create multiple RPMs for each kernel
(i.e. i586, .i686).  It's too convoluted and customers hate it.

8)

Jeff

> 
> --
> Jeff Garzik | "When I do this, my computer freezes."
> Building 1024   |  -user
> MandrakeSoft| "Don't do that."
> |  -level 1
-
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: Installing kernel 2.4

[Jeff V. Merkey]

Alan Cox wrote:
> 
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings.  All of this could
> > be dynamic.  Here's some code that does this, and it's similiar to
> > NetWare.  It detexts CPU type, feature flags, special instructions,
> > etc.  All of this on x86 could be dynamically detected.
> 
> Detection isnt the issue, its optimisations. Our 386 kernel build is the
> detect all run on any one.
> 
> > mov  sp, bx
> > mov  CPU_TYPE, 3  ; 80386 detected
> > jz   end_get_cpuid
> 
> This is wrong btw. You don;t check for Cyrix with CPUID disabled or
> the NexGen or pre CPUID Cyrix...

Thanks Alan, I'll fix immediately.

Jeff

> 
> > check_CMPXCHG8B:
> > mov  ax, word ptr ds:FEATURE_FLAGS
> > and  ax, CMPXCHG8B_FLAG
> > jz   check_4MB_paging
> 
> This needs a few other bits of interesting checking for non intel chips

I'll grab the code in linux and port.

8)

Jeff
-
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: Installing kernel 2.4

[Jeff Garzik]

Jeff Merkey wrote:
> The PE model uses flags to identify CPU type and capbilities

So does ELF.

-- 
Jeff Garzik | "When I do this, my computer freezes."
Building 1024   |  -user
MandrakeSoft| "Don't do that."
|  -level 1
-
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: Installing kernel 2.4

[Alan Cox]

> There are tests for all this in the feature flags for intel and
> non-intel CPUs like AMD -- including MTRR settings.  All of this could
> be dynamic.  Here's some code that does this, and it's similiar to
> NetWare.  It detexts CPU type, feature flags, special instructions,
> etc.  All of this on x86 could be dynamically detected.   

Detection isnt the issue, its optimisations. Our 386 kernel build is the
detect all run on any one.

> mov  sp, bx
> mov  CPU_TYPE, 3  ; 80386 detected
> jz   end_get_cpuid

This is wrong btw. You don;t check for Cyrix with CPUID disabled or
the NexGen or pre CPUID Cyrix...

> check_CMPXCHG8B:
> mov  ax, word ptr ds:FEATURE_FLAGS
> and  ax, CMPXCHG8B_FLAG
> jz   check_4MB_paging

This needs a few other bits of interesting checking for non intel chips

-
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] deadlock fix

[Gary E. Miller]

Yo All!

I see this patch did not make it into test11-pre1.  Without it
raid1 and SMP do not work together.  Please consider for test11-pre2.

RGDS
GARY
---
Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701
[EMAIL PROTECTED]  Tel:+1(541)382-8588 Fax: +1(541)382-8676

> > > Here it is.
> > >
> > > --- drivers/md/raid1.c.orgWed Oct 18 15:30:07 2000
> > > +++ drivers/md/raid1.cWed Oct 18 15:33:08 2000
> > > @@ -91,7 +91,8 @@
> > >
> > >  static inline void raid1_free_bh(raid1_conf_t *conf, struct buffer_head *bh)
> > >  {
> > > - md_spin_lock_irq(>device_lock);
> > > + unsigned long flags;
> > > + md_spin_lock_irqsave(>device_lock, flags);
> > >   while (bh) {
> > >   struct buffer_head *t = bh;
> > >   bh=bh->b_next;
> > > @@ -103,7 +104,7 @@
> > >   conf->freebh_cnt++;
> > >   }
> > >   }
> > > - md_spin_unlock_irq(>device_lock);
> > > + md_spin_unlock_irqrestore(>device_lock, flags);
> > >   wake_up(>wait_buffer);
> > >  }
>


-
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: Pentium 4 and 2.4/2.5

[Alan Cox]

>   As for the 2.2.18 patch for correctly determining 2GHz and above, can
> it be easily  merged into the 2.4.x kernel, and if so, what's the maximum
> clock speed that can be detected?

It should be easy yes. Its good to 100Ghz or so now ;)
-
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: malloc(1/0) ??

[David Schwartz]

> This way all should work. However someone mentioned that the returns
> from "malloc" should be unique. Why would that be? That would prohibit
> my "1" trick. The statement implies you want to go about checking
> pointers for equality. If for example you have a memcmp (a, b) that
> has "if (a == b) return 0;" at the beginning. That would be allowed
> for the NIL pointers. (all malloc-0 results SHOULD compare equal
> anyway: there are 0 differences)

It's a SuSv2 thing:

"Upon successful completion with size not equal to 0, malloc() returns a
pointer to the allocated space. If size is 0, either a null pointer or a
unique pointer that can be successfully passed to free() will be returned.
Otherwise, it returns a null pointer and sets errno to indicate the error."

DS

-
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: malloc(1/0) ??

[Rogier Wolff]

Matti Aarnio wrote:
> needed size is bound to get user burned.   malloc(0)  is insane thing
> (IMO), but at least glibc supports it for some reason.  Likely just due
> to padding and minimum size issues.

Part of the desing of the C language and the library is intended to
make boundary conditions go well automatically. 

So, a program that does:

fscanf (file, "%d", );
squares = malloc (sizeof (struct square) * numsquares);
for (i=0;ihttp://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
*   Common sense is the collection of*
**  prejudices acquired by age eighteen.   -- Albert Einstein 
-
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: Installing kernel 2.4

[Jeff V. Merkey]

David Relson wrote:
> 
> It seems to me that kernel/cpu matching can be broken into two relatively
> simple parts.
> 
> 1 - Put a cpu "signature" in the kernel image indicating cpu requirements; and
> 2 - Have the bootloader (lilo) detect cpu type and match it against the cpu
> "signature".
> 
> The bootloader would then load the kernel, or could give an informative
> diagnostic.
> 

The PE model uses flags to identify CPU type and capbilities and create
a table in the RVA section header that describes all the segments, i.e.

#define IMAGE_SIZEOF_FILE_HEADER20

#define IMAGE_FILE_MACHINE_UNKNOWN  0
#define IMAGE_FILE_MACHINE_I860 0x14d
#define IMAGE_FILE_MACHINE_I386 0x14c
#define IMAGE_FILE_MACHINE_R30000x162
#define IMAGE_FILE_MACHINE_R40000x166
#define IMAGE_FILE_MACHINE_R1   0x168
#define IMAGE_FILE_MACHINE_ALPHA0x184
#define IMAGE_FILE_MACHINE_POWERPC  0x1F0  

typedef struct _IMAGE_DATA_DIRECTORY
{
DWORD   VirtualAddress;
DWORD   Size;
} IMAGE_DATA_DIRECTORY,*PIMAGE_DATA_DIRECTORY;

#define IMAGE_NUMBEROF_DIRECTORY_ENTRIES 16

/* Optional coff header - used by NT to provide additional information.
*/
typedef struct _IMAGE_OPTIONAL_HEADER
{
/*
 * Standard fields.
 */

WORDMagic;
BYTEMajorLinkerVersion;
BYTEMinorLinkerVersion;
DWORD   SizeOfCode;
DWORD   SizeOfInitializedData;
DWORD   SizeOfUninitializedData;
DWORD   AddressOfEntryPoint;
DWORD   BaseOfCode;
DWORD   BaseOfData;

/*
 * NT additional fields.
 */

DWORD   ImageBase;
DWORD   SectionAlignment;
DWORD   FileAlignment;
WORDMajorOperatingSystemVersion;
WORDMinorOperatingSystemVersion;
WORDMajorImageVersion;
WORDMinorImageVersion;
WORDMajorSubsystemVersion;
WORDMinorSubsystemVersion;
DWORD   Reserved1;
DWORD   SizeOfImage;
DWORD   SizeOfHeaders;
DWORD   CheckSum;
WORDSubsystem;
WORDDllCharacteristics;
DWORD   SizeOfStackReserve;
DWORD   SizeOfStackCommit;
DWORD   SizeOfHeapReserve;
DWORD   SizeOfHeapCommit;
DWORD   LoaderFlags;
DWORD   NumberOfRvaAndSizes;
IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER,*PIMAGE_OPTIONAL_HEADER;

/* These are indexes into the DataDirectory array */
#define IMAGE_FILE_EXPORT_DIRECTORY 0
#define IMAGE_FILE_IMPORT_DIRECTORY 1
#define IMAGE_FILE_RESOURCE_DIRECTORY   2
#define IMAGE_FILE_EXCEPTION_DIRECTORY  3
#define IMAGE_FILE_SECURITY_DIRECTORY   4
#define IMAGE_FILE_BASE_RELOCATION_TABLE5
#define IMAGE_FILE_DEBUG_DIRECTORY  6
#define IMAGE_FILE_DESCRIPTION_STRING   7
#define IMAGE_FILE_MACHINE_VALUE8  /* Mips */
#define IMAGE_FILE_THREAD_LOCAL_STORAGE 9
#define IMAGE_FILE_CALLBACK_DIRECTORY   10

/* Directory Entries, indices into the DataDirectory array */

#define IMAGE_DIRECTORY_ENTRY_EXPORT0
#define IMAGE_DIRECTORY_ENTRY_IMPORT1
#define IMAGE_DIRECTORY_ENTRY_RESOURCE  2
#define IMAGE_DIRECTORY_ENTRY_EXCEPTION 3
#define IMAGE_DIRECTORY_ENTRY_SECURITY  4
#define IMAGE_DIRECTORY_ENTRY_BASERELOC 5
#define IMAGE_DIRECTORY_ENTRY_DEBUG 6
#define IMAGE_DIRECTORY_ENTRY_COPYRIGHT 7
#define IMAGE_DIRECTORY_ENTRY_GLOBALPTR 8   /* (MIPS GP) */
#define IMAGE_DIRECTORY_ENTRY_TLS   9
#define IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG   10
#define IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT  11
#define IMAGE_DIRECTORY_ENTRY_IAT   12  /* Import Address Table */

/* Subsystem Values */

#define IMAGE_SUBSYSTEM_UNKNOWN 0
#define IMAGE_SUBSYSTEM_NATIVE  1
#define IMAGE_SUBSYSTEM_WINDOWS_GUI 2   /* Windows GUI subsystem */
#define IMAGE_SUBSYSTEM_WINDOWS_CUI 3   /* Windows character subsystem*/
#define IMAGE_SUBSYSTEM_OS2_CUI 5
#define IMAGE_SUBSYSTEM_POSIX_CUI   7

typedef struct _IMAGE_NT_HEADERS {
DWORD   Signature;
IMAGE_FILE_HEADER   FileHeader;
IMAGE_OPTIONAL_HEADER   OptionalHeader;
} IMAGE_NT_HEADERS,*PIMAGE_NT_HEADERS;

/* Section header format */

#define IMAGE_SIZEOF_SHORT_NAME 8

typedef struct _IMAGE_SECTION_HEADER {
BYTEName[IMAGE_SIZEOF_SHORT_NAME];
union {
DWORD   PhysicalAddress;
DWORD   VirtualSize;
} Misc;
DWORD   VirtualAddress;
DWORD   SizeOfRawData;
DWORD   PointerToRawData;
DWORD   PointerToRelocations;
DWORD   PointerToLinenumbers;
WORDNumberOfRelocations;
WORDNumberOfLinenumbers;
DWORD   Characteristics;
} 

Re: Installing kernel 2.4

[David Relson]

It seems to me that kernel/cpu matching can be broken into two relatively 
simple parts.

1 - Put a cpu "signature" in the kernel image indicating cpu requirements; and
2 - Have the bootloader (lilo) detect cpu type and match it against the cpu 
"signature".

The bootloader would then load the kernel, or could give an informative 
diagnostic.

David



At 06:59 PM 11/7/00, Jeff Garzik wrote:
>Sven Koch wrote:
> >
> > On Tue, 7 Nov 2000, David Lang wrote:
> >
> > > depending on what CPU you have the kernel (and compiler) can use 
> different
> > > commands/opmizations/etc, if you want to do this on boot you have two
> > > options.
> >
> > Wouldn't it be possible to compile the parts of the kernel needed to
> > uncompress and to detect the cpu with lower optimizations and then abort
> > with an error message?
> >
> > "Error: Kernel needs a PIII" sounds much better than just stoping dead.
>
>I agree...   maybe we can solve this simply by giving the CPU detection
>module the -march=i386 flag hardcoded, or editing the bootstrap, or
>something like that...
>
> Jeff


David Relson   Osage Software Systems, Inc.
[EMAIL PROTECTED]   514 W. Keech Ave.
www.osagesoftware.com  Ann Arbor, MI 48103
voice: 734.821.8800fax: 734.821.8800

-
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: Installing kernel 2.4

[Jeff V. Merkey]

Jeff Garzik wrote:
> 
> "Jeff V. Merkey" wrote:
> > We need a format that allow multiple executable segments to be combined
> > in a single executable and the loader have enough smarts to grab the
> > right one based on architecture.  two options:
> >
> > 1.  extend gcc to support this or rearragne linux into segments based on
> > code type
> > 2.  Use PE.
> 
> The kernel isn't going non-ELF.  Too painful, for dubious advantages,
> namely:
> 

perhaps we should extend ELF.  After all, where linux goes, gcc
follows

Jeff

> The current gcc toolchain already supports what you suggest.
> 
> I understand that some people have even put some thought into a
> bootloader that dynamically links your kernel on bootup, so this idea
> isn't new.  It's a good idea though.
> 
> Jeff
> 
> --
> Jeff Garzik | "When I do this, my computer freezes."
> Building 1024   |  -user
> MandrakeSoft| "Don't do that."
> |  -level 1
-
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: Installing kernel 2.4

[Jeff V. Merkey]

David Lang wrote:
> 
> Jeff, the kernel image is already pretty large. if you try and take what
> are basicly independant kernel images and put them in one file you will
> very quickly endup with something that is to large to use.
> 
> As an example a kenel for a boot floppy needs to be <1.4MB compressed,
> it's not uncommon for it to be >800K compressed as it is, how do you fit
> even two of these on a disk.
> 
> remember it's not just the start of the file that varies based on cachline
> size, it's the positioning of code and data thoughout the kernel image.
> 

Understood.  I will go off and give some thought and study and respond
later after I have a proposal on the best way to do this.   In NetWare,
we had indirections in the code all over the place.  NT just make huge
and fat programs (NTKRNLOS.DLL is absolutely huge).

Jeff

> David Lang
> 
>  On Tue, 7 Nov
> 2000, Jeff V. Merkey wrote:
> 
> > Date: Tue, 07 Nov 2000 16:47:08 -0700
> > From: Jeff V. Merkey <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED], Linux Kernel Mailing List <[EMAIL PROTECTED]>
> > Subject: Re: Installing kernel 2.4
> >
> >
> >
> > "Jeff V. Merkey" wrote:
> > >
> > > [EMAIL PROTECTED] wrote:
> > > >
> > > > > There are tests for all this in the feature flags for intel and
> > > > > non-intel CPUs like AMD -- including MTRR settings.  All of this could
> > > > > be dynamic.  Here's some code that does this, and it's similiar to
> > > > > NetWare.  It detexts CPU type, feature flags, special instructions,
> > > > > etc.  All of this on x86 could be dynamically detected.
> > > >
> > > > Detecting the CPU isn't the issue (we already do all this), it's what to
> > > > do when you've figured out what the CPU is. Show me code that can
> > > > dynamically adjust the alignment of the routines/variables/structs
> > > > dependant upon cacheline size.
> >
> > ftp.timpanogas.org/manos/manos0817.tar.gz
> >
> > Look in the PE loader -- Microsoft's PE loader can do this since
> > everything is RVA based.  If you want to take the loader and put it in
> > Linux, be my guest.  You can even combine mutiple i86 segments all
> > compiled under different options (or architectures) and bundle them into
> > a single executable file -- not somthing gcc can do today -- even with
> > DLL.  This code is almost identical to the PE loader used in NT -- with
> > one exception, I omit the fs:_THREAD_DLS startup code...
> >
> > 8)
> >
> > Jeff
> >
> >
> > >
> > > If the compiler always aligned all functions and data on 16 byte
> > > boundries (NetWare)
> > > for all i386 code, it would run a lot faster.  Cache line alignment
> > > could be an option in the loader  after all, it's hte loader that
> > > locates data in memory.  If Linux were PE based, relocation logic would
> > > be a snap with this model (like NT).
> > >
> > > Jeff
> > >
> > > >
> > > > regards,
> > > >
> > > > Davej.
> > > >
> > > > --
> > > > | Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
> > > > | SuSE Labs
> > -
> > 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/
> >
-
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: Installing kernel 2.4

[Jeff Garzik]

"Jeff V. Merkey" wrote:
> We need a format that allow multiple executable segments to be combined
> in a single executable and the loader have enough smarts to grab the
> right one based on architecture.  two options:
> 
> 1.  extend gcc to support this or rearragne linux into segments based on
> code type
> 2.  Use PE.

The kernel isn't going non-ELF.  Too painful, for dubious advantages,
namely:

The current gcc toolchain already supports what you suggest.

I understand that some people have even put some thought into a
bootloader that dynamically links your kernel on bootup, so this idea
isn't new.  It's a good idea though.

Jeff


-- 
Jeff Garzik | "When I do this, my computer freezes."
Building 1024   |  -user
MandrakeSoft| "Don't do that."
|  -level 1
-
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: Installing kernel 2.4

[Jeff V. Merkey]

Code is.  Data isn't.  Gcc packs data into the segment like sardines in
a can (NT code does to).  16 byte align this as well.  NetWare 16 byte
aligns everythin with an align 16 directive in the data segments of
assembler modules.

Jeff

Jeff Garzik wrote:
> 
> "Jeff V. Merkey" wrote:
> > If the compiler always aligned all functions and data on 16 byte
> > boundries (NetWare)
> > for all i386 code, it would run a lot faster.
> 
> Are you saying that it isn't?  Have you look at gcc-generated assembly
> from a recent 2.2.x or 2.4.x kernel?
> 
> 2.2.x build command line, note use of "...align...":
> /usr/bin/kgcc -D__KERNEL__ -I/spare/cvs/linux_2_2/include -Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
> -D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2
> -malign-jumps=2 -malign-functions=2 -DCPU=686   -c -o extable.o
> extable.c
> 
> 2.4.x, note "preferred-stack-boundary" and generated asm code...
> gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall
> -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
> -mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
> /spare/cvs/linux_2_4/include/linux/modversions.h   -c -o emd.o emd.c
> 
> Jeff
> 
> --
> Jeff Garzik | "When I do this, my computer freezes."
> Building 1024   |  -user
> MandrakeSoft| "Don't do that."
> |  -level 1
> -
> 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/
-
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: Installing kernel 2.4

[David Lang]

Jeff, the kernel image is already pretty large. if you try and take what
are basicly independant kernel images and put them in one file you will
very quickly endup with something that is to large to use.

As an example a kenel for a boot floppy needs to be <1.4MB compressed,
it's not uncommon for it to be >800K compressed as it is, how do you fit
even two of these on a disk.

remember it's not just the start of the file that varies based on cachline
size, it's the positioning of code and data thoughout the kernel image.

David Lang

 On Tue, 7 Nov
2000, Jeff V. Merkey wrote:

> Date: Tue, 07 Nov 2000 16:47:08 -0700
> From: Jeff V. Merkey <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], Linux Kernel Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Installing kernel 2.4
> 
> 
> 
> "Jeff V. Merkey" wrote:
> > 
> > [EMAIL PROTECTED] wrote:
> > >
> > > > There are tests for all this in the feature flags for intel and
> > > > non-intel CPUs like AMD -- including MTRR settings.  All of this could
> > > > be dynamic.  Here's some code that does this, and it's similiar to
> > > > NetWare.  It detexts CPU type, feature flags, special instructions,
> > > > etc.  All of this on x86 could be dynamically detected.
> > >
> > > Detecting the CPU isn't the issue (we already do all this), it's what to
> > > do when you've figured out what the CPU is. Show me code that can
> > > dynamically adjust the alignment of the routines/variables/structs
> > > dependant upon cacheline size.
> 
> ftp.timpanogas.org/manos/manos0817.tar.gz   
> 
> Look in the PE loader -- Microsoft's PE loader can do this since
> everything is RVA based.  If you want to take the loader and put it in
> Linux, be my guest.  You can even combine mutiple i86 segments all
> compiled under different options (or architectures) and bundle them into
> a single executable file -- not somthing gcc can do today -- even with
> DLL.  This code is almost identical to the PE loader used in NT -- with
> one exception, I omit the fs:_THREAD_DLS startup code...
> 
> 8)
> 
> Jeff
> 
> 
> > 
> > If the compiler always aligned all functions and data on 16 byte
> > boundries (NetWare)
> > for all i386 code, it would run a lot faster.  Cache line alignment
> > could be an option in the loader  after all, it's hte loader that
> > locates data in memory.  If Linux were PE based, relocation logic would
> > be a snap with this model (like NT).
> > 
> > Jeff
> > 
> > >
> > > regards,
> > >
> > > Davej.
> > >
> > > --
> > > | Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
> > > | SuSE Labs
> -
> 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/
> 
-
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: Installing kernel 2.4

[Jeff V. Merkey]

Jeff Garzik wrote:
> 
> Jeff Merkey wrote:
> > here are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings.  All of this could
> > be dynamic.  Here's some code that does this, and it's similiar to
> > NetWare.  It detexts CPU type, feature flags, special instructions,
> > etc.  All of this on x86 could be dynamically detected.
> 
> Jeff, I think you miss the point that 100% dynamic detection comes with
> a penalty over the current system.
> 
> Using CONFIG_M586 enables us to compile with Pentium-specific
> instructions, and eliminate any code specific to 386's or 486's.  This
> includes inlining Pentium-specific code into drivers and the core kernel
> where possible, for the maximum possible performance.  Your scheme
> doesn't work because of all the inlined code, nor does it support
> maximum performance code on all processors without massive code bloat...
> 
> You do bring up a good point though.  Users compile their own kernels to
> get the advantages I describe above.  Vendors, on the other hand, must
> compile one-size-fits-all generic kernels.  Your expertise and
> assistance would definitely benefit this case.
> 

We need a format that allow multiple executable segments to be combined
in a single executable and the loader have enough smarts to grab the
right one based on architecture.  two options:

1.  extend gcc to support this or rearragne linux into segments based on
code type
2.  Use PE.

Jeff

> One change I would like to make in 2.5.x along these lines -- the Alpha
> AXP port allow one to define either CONFIG_ALPHA_GENERIC -- support all
> processors/machines -- or CONFIG_ALPHA_$MYMACHINE.  It would be nice to
> follow that model for x86 too.  Currently, when I select CONFIG_M586, I
> get code for 686, etc.  There is no way to simply say "Pentium and
> nothing else".
> 
> Jeff
> 
> --
> Jeff Garzik | "When I do this, my computer freezes."
> Building 1024   |  -user
> MandrakeSoft| "Don't do that."
> |  -level 1
-
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: Installing kernel 2.4

[Jeff Garzik]

"Jeff V. Merkey" wrote:
> If the compiler always aligned all functions and data on 16 byte
> boundries (NetWare)
> for all i386 code, it would run a lot faster.

Are you saying that it isn't?  Have you look at gcc-generated assembly
from a recent 2.2.x or 2.4.x kernel?

2.2.x build command line, note use of "...align...":
/usr/bin/kgcc -D__KERNEL__ -I/spare/cvs/linux_2_2/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing
-D__SMP__ -pipe -fno-strength-reduce -m486 -malign-loops=2
-malign-jumps=2 -malign-functions=2 -DCPU=686   -c -o extable.o
extable.c

2.4.x, note "preferred-stack-boundary" and generated asm code...
gcc -D__KERNEL__ -I/spare/cvs/linux_2_4/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mpreferred-stack-boundary=2 -march=i686 -DMODULE -DMODVERSIONS -include
/spare/cvs/linux_2_4/include/linux/modversions.h   -c -o emd.o emd.c


Jeff


-- 
Jeff Garzik | "When I do this, my computer freezes."
Building 1024   |  -user
MandrakeSoft| "Don't do that."
|  -level 1
-
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: Installing kernel 2.4

[Jeff Garzik]

Sven Koch wrote:
> 
> On Tue, 7 Nov 2000, David Lang wrote:
> 
> > depending on what CPU you have the kernel (and compiler) can use different
> > commands/opmizations/etc, if you want to do this on boot you have two
> > options.
> 
> Wouldn't it be possible to compile the parts of the kernel needed to
> uncompress and to detect the cpu with lower optimizations and then abort
> with an error message?
> 
> "Error: Kernel needs a PIII" sounds much better than just stoping dead.

I agree...   maybe we can solve this simply by giving the CPU detection
module the -march=i386 flag hardcoded, or editing the bootstrap, or
something like that...

Jeff



-- 
Jeff Garzik | "When I do this, my computer freezes."
Building 1024   |  -user
MandrakeSoft| "Don't do that."
|  -level 1
-
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: Installing kernel 2.4

[Jeff Garzik]

Jeff Merkey wrote:
> here are tests for all this in the feature flags for intel and
> non-intel CPUs like AMD -- including MTRR settings.  All of this could
> be dynamic.  Here's some code that does this, and it's similiar to
> NetWare.  It detexts CPU type, feature flags, special instructions,
> etc.  All of this on x86 could be dynamically detected.   

Jeff, I think you miss the point that 100% dynamic detection comes with
a penalty over the current system.

Using CONFIG_M586 enables us to compile with Pentium-specific
instructions, and eliminate any code specific to 386's or 486's.  This
includes inlining Pentium-specific code into drivers and the core kernel
where possible, for the maximum possible performance.  Your scheme
doesn't work because of all the inlined code, nor does it support
maximum performance code on all processors without massive code bloat...

You do bring up a good point though.  Users compile their own kernels to
get the advantages I describe above.  Vendors, on the other hand, must
compile one-size-fits-all generic kernels.  Your expertise and
assistance would definitely benefit this case.

One change I would like to make in 2.5.x along these lines -- the Alpha
AXP port allow one to define either CONFIG_ALPHA_GENERIC -- support all
processors/machines -- or CONFIG_ALPHA_$MYMACHINE.  It would be nice to
follow that model for x86 too.  Currently, when I select CONFIG_M586, I
get code for 686, etc.  There is no way to simply say "Pentium and
nothing else".

Jeff


-- 
Jeff Garzik | "When I do this, my computer freezes."
Building 1024   |  -user
MandrakeSoft| "Don't do that."
|  -level 1
-
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: Installing kernel 2.4

[Sven Koch]

On Tue, 7 Nov 2000, David Lang wrote:

> depending on what CPU you have the kernel (and compiler) can use different
> commands/opmizations/etc, if you want to do this on boot you have two
> options.

Wouldn't it be possible to compile the parts of the kernel needed to
uncompress and to detect the cpu with lower optimizations and then abort
with an error message?

"Error: Kernel needs a PIII" sounds much better than just stoping dead.

c'ya
sven

-- 

The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)

-
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: Installing kernel 2.4

[Jeff V. Merkey]

"Jeff V. Merkey" wrote:
> 
> [EMAIL PROTECTED] wrote:
> >
> > > There are tests for all this in the feature flags for intel and
> > > non-intel CPUs like AMD -- including MTRR settings.  All of this could
> > > be dynamic.  Here's some code that does this, and it's similiar to
> > > NetWare.  It detexts CPU type, feature flags, special instructions,
> > > etc.  All of this on x86 could be dynamically detected.
> >
> > Detecting the CPU isn't the issue (we already do all this), it's what to
> > do when you've figured out what the CPU is. Show me code that can
> > dynamically adjust the alignment of the routines/variables/structs
> > dependant upon cacheline size.

ftp.timpanogas.org/manos/manos0817.tar.gz   

Look in the PE loader -- Microsoft's PE loader can do this since
everything is RVA based.  If you want to take the loader and put it in
Linux, be my guest.  You can even combine mutiple i86 segments all
compiled under different options (or architectures) and bundle them into
a single executable file -- not somthing gcc can do today -- even with
DLL.  This code is almost identical to the PE loader used in NT -- with
one exception, I omit the fs:_THREAD_DLS startup code...

8)

Jeff


> 
> If the compiler always aligned all functions and data on 16 byte
> boundries (NetWare)
> for all i386 code, it would run a lot faster.  Cache line alignment
> could be an option in the loader  after all, it's hte loader that
> locates data in memory.  If Linux were PE based, relocation logic would
> be a snap with this model (like NT).
> 
> Jeff
> 
> >
> > regards,
> >
> > Davej.
> >
> > --
> > | Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
> > | SuSE Labs
-
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: Alpha SMP problem

[Reto Baettig]

Update: I just tested it on Alpha UP and everything's fine. It really
seems to be a SMP problem...

Reto Baettig wrote:
> 
> Hi
> 
> I have a problem whith Alpha SMP's which seems to be kernel-related. I
> discussed this on the bug-glibc list but everybody seems to agree that
> it cannot be a libc problem.
> 
> I attached a little testprogram which reproduces the bug in < 1Minute.
> BUT: IT MUST BE STARTED AT LEAST TWICE!
> 
> The strange thing is that a single instance of the program runs just
> fine. When I start the program a second time, I get segfaults and/or
> stuck threads.
> 
> We could reproduce this behaviour on different Machines, both with linux
> 2.2.14 and 2.4.0-test10, but
> ONLY ON ALPHA SMP MACHINES.
> 
> Here's my configuration:
> 
> Linux reto1 2.4.0-test10 #2 SMP Tue Oct 31 19:39:51 PST 2000 alpha
> unknown
> ^^^  ^
> Kernel modules 2.3.19
> Gnu C  egcs-2.91.66
> Gnu Make   3.78.1
> Binutils   2.9.5.0.22
> Linux C Library2.1.3
> Dynamic linker ldd (GNU libc) 2.1.3
> Procps 2.0.6
> Mount  2.10f
> Net-tools  1.54
> Console-tools  0.3.3
> Sh-utils   2.0
> Modules Loaded nfs lockd sunrpc
> 
> Any ideas?
> 
> Please tell me when you need more information, or give me some pointers
> where I could start to dig...
> 
> TIA
> 
> Reto
> 
>   
>  Name: malloctest.tgz
>malloctest.tgzType: unspecified type (application/octet-stream)
>  Encoding: base64
-
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: malloc(1/0) ??

[Igmar Palsenberg]

On Tue, 7 Nov 2000, Lyle Coder wrote:

> When a program does a malloc... the glibc gets atleast on page (brk)
> [actually, glibs determins of it needs to brk more memory from the kernel...
> because it maintains it;s own pool].. so if you malloc 4 byts, you can copy
> to that pointer more than 4 bytes (upto a page size, ex 4K)... hope that
> answers one of your questions... as far as why malloc(0) works... I dunno

Hmm.. Don't read a manpage in the middle of the night.. the issue is only
with realloc(0) that is equal to free().

Maybe one of the glibc guys can tell what the behaviour is with malloc(0).
 
> Best Wishes,
> Lyle


Igmar

-
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: malloc(1/0) ??

[Igmar Palsenberg]

>   The program does not work. A program works if it does what it's supposed to
> do. If you want to argue that this program is supposed to print "ff"
> then explain to me why the 'malloc' contains a zero in parenthesis.
> 
>   The program can't possibly work because it invokes undefined behavior. It
> is impossible to determine what a program that invokes undefined behavior is
> 'supposed to do'.

May I remind you guys that a malloc(0) is equal to a free(). There is no
way that any mem get's malloced. 

You only get a coredump if the program accesses a page it shouln't, and
since whe're talking 5 bytes here or so, you have a change that you don't
cross a boundary.

>   DS


Igmar

-
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: Installing kernel 2.4

[Jeff V. Merkey]

David Lang wrote:
> 
> Jeff, the problem is not detecting the CPU type at runtime, the problem is
> trying to re-compile the code to take advantage of that CPU at runtime.
> 
> depending on what CPU you have the kernel (and compiler) can use different
> commands/opmizations/etc, if you want to do this on boot you have two
> options.
> 
> 1. re-compile the kernel
> 
> 2. change all the CPU specific places from inline code to function calls
> into a table that get changed at boot to point at the correct calls.

The macros would be a problem.  Some of the options, like MTRR, should
be auto-detected.

Jeff

> 
> doing #2 will cost you so much performance that you would be better off
> just compiling for a 386 and not going through the autodetect hassle in
> the first place.
> 
> David Lang
> 
>  On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> 
> > Date: Tue, 07 Nov 2000 16:10:58 -0700
> > From: Jeff V. Merkey <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Cc: Martin Josefsson <[EMAIL PROTECTED]>,
> >  Tigran Aivazian <[EMAIL PROTECTED]>, Anil kumar <[EMAIL PROTECTED]>,
> >  [EMAIL PROTECTED]
> > Subject: Re: Installing kernel 2.4
> >
> >
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings.  All of this could
> > be dynamic.  Here's some code that does this, and it's similiar to
> > NetWare.  It detexts CPU type, feature flags, special instructions,
> > etc.  All of this on x86 could be dynamically detected.
> >
> > :-)
> >
> > ;*
> > ;
> > ;  check current processor type and state
> > ;
> > ;*
> >
> > public DetectProcessorInformation
> > DetectProcessorInformation proc near
> >
> > mov   ax, cs
> > mov   ds, ax
> > mov   es, ax
> >
> > pushf
> > call  get_cpuid
> > call  get_fpuid
> > call  print
> > popf
> > ret
> >
> > DetectProcessorInformation endp
> >
> > get_cpuid proc near
> >
> > check_8086:
> >
> > pushf
> > pop   ax
> > mov   cx, ax
> > and   ax, 0fffh
> > push  ax
> > popf
> > pushf
> > pop   ax
> > and   ax, 0f000h
> > cmp   ax, 0f000h; flag bits 12-15 are always set on an 8086
> > mov   CPU_TYPE, 0   ; 8086 detected
> > jeend_get_cpuid
> >
> > check_80286:
> > orcx, 0f000h
> > push  cx
> > popf
> > pushf
> > pop   ax
> > and   ax, 0f000h   ; flag bits 12-15 are always clear on 80286 in
> > real mode
> > mov   CPU_TYPE, 2  ; 80286 processor
> > jzend_get_cpuid
> >
> > check_80386:
> > mov bx, sp
> > and sp, not 3
> > OPND32
> > pushf
> > OPND32
> > pop ax
> > OPND32
> > mov  cx, ax
> > OPND32   35h, 4h
> > OPND32
> > push ax
> > OPND32
> > popf
> > OPND32
> > pushf
> > OPND32
> > pop  ax
> > OPND32
> > xor  ax, cx   ; AC bit won't toggle, 80386 detected
> > mov  sp, bx
> > mov  CPU_TYPE, 3  ; 80386 detected
> > jz   end_get_cpuid
> >
> > and  sp, not 3
> > OPND32
> > push cx
> > OPND32
> > popf
> > mov  sp, bx ; restore stack
> >
> >
> > check_80486:
> > mov  CPU_TYPE, 4 ; default to 80486
> >
> > OPND32
> > mov  ax, cx
> > OPND32   35h, 20h  ; xor ID bit
> > OPND32
> > push ax
> > OPND32
> > popf
> > OPND32
> > pushf
> > OPND32
> > pop  ax
> > OPND32
> > xor  ax, cx   ; cant toggle ID bit
> > je   end_get_cpuid
> >
> >
> > check_vendor:
> > mov ID_FLAG, 1
> > OPND32
> > xor ax, ax
> > CPUID
> > OPND32
> > mov word ptr VENDOR_ID, bx
> > OPND32
> > mov word ptr VENDOR_ID[+4], dx
> > OPND32
> > mov word ptr VENDOR_ID[+8], cx
> > mov si, offset VENDOR_ID
> > mov di, offset intel_id
> > mov cx, length intel_id
> >
> > compare:
> > repecmpsb
> > or  cx, cx
> > jnz end_get_cpuid
> >
> > intel_processor:
> > mov INTEL_PROC, 1
> >
> > cpuid_data:
> > OPND32
> > cmp ax, 1
> >
> > jl  end_get_cpuid
> > OPND32
> > xor ax, ax
> > OPND32
> > inc ax
> > CPUID
> > mov byte ptr ds:STEPPING, al
> > and STEPPING, STEPPING_MASK
> >
> > and al, MODEL_MASK
> > shr al, MODEL_SHIFT
> > mov byte ptr ds:CPU_MODEL, al
> >
> > and ax, FAMILY_MASK
> > shr ax, FAMILY_SHIFT
> > mov byte ptr ds:CPU_TYPE, al
> >
> > mov dword ptr FEATURE_FLAGS, edx
> >
> > end_get_cpuid:
> > ret
> >
> > get_cpuid  endp
> >
> >
> > get_fpuid proc near
> >
> > fninit
> > mov  word ptr ds:FP_STATUS, 5a5ah
> >
> > fnstsw   word ptr ds:FP_STATUS
> > mov  ax, word ptr 

Re: Installing kernel 2.4

[Jeff V. Merkey]

[EMAIL PROTECTED] wrote:
> 
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings.  All of this could
> > be dynamic.  Here's some code that does this, and it's similiar to
> > NetWare.  It detexts CPU type, feature flags, special instructions,
> > etc.  All of this on x86 could be dynamically detected.
> 
> Detecting the CPU isn't the issue (we already do all this), it's what to
> do when you've figured out what the CPU is. Show me code that can
> dynamically adjust the alignment of the routines/variables/structs
> dependant upon cacheline size.

If the compiler always aligned all functions and data on 16 byte
boundries (NetWare) 
for all i386 code, it would run a lot faster.  Cache line alignment
could be an option in the loader  after all, it's hte loader that
locates data in memory.  If Linux were PE based, relocation logic would
be a snap with this model (like NT).

Jeff

> 
> regards,
> 
> Davej.
> 
> --
> | Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
> | SuSE Labs
-
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: linux-2.4.0-test10 and X4.0.1 don't like each other on Libretto110CT

[Miles Lane]

You must upgrade to the latest release:  4.0.1e

The fix for this problem went into 4.0.1d, but since you
need to upgrade, you might as well get the latest code.

Miles

On Wed, 8 Nov 2000, David Luyer wrote:

> 
> I'm having problems with X 4.0.1 and 2.4.0-test kernels on a Toshiba Libretto
> 110CT.  Is this likely to be related to a known problem or can someone
> recommend some random intermediate kernel versions to try (binary elimination
> avoiding known-bad kernel versions...)?
> 
> H/w: Toshiba Libretto 110CT (NM2160), Xircom CEM336 modem/ethernet
> S/w: Debian woody as at Wed Nov 8, with old xserver-svga package for testing
> 
> Kernel xserver-xfree86 4.0.1-1xserver-svga 3.3.6-10
> 2.4.0-test10   Fail   OK
> 2.4.0-test4pre3Fail   OK
> 2.2.15 (Debian build)  OK OK
> 
> "Fail" here means X startup results in a blank LCD, unable to switch to 
> text consoles either, SAK results in a screen full of previous graphics-mode
> display on LCD, even if it was pre-reboot, at that screen it is possible to
> type (although not to see the result), login, reboot the system, try a
> different version of X, etc (as long as you can remember what you've typed).
> 
> Thanks for any help,
> David.
> -
> 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/
> 

-
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: malloc(1/0) ??

[Igmar Palsenberg]

> I'm not sure that is fully responsive, Dan. Why doesn't the
> strcpy throw a hissyfit and coredump?

Because he's a lucky guy and doesn't cross a page boundary. If the
"" thing is the entire Wind95 source code it will dump :-)

> {^_^}


Igmar

-
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: How to study linux kernel?

[Rik van Riel]

On Tue, 7 Nov 2000, Su Hwan Hwang wrote:

> I'm interested in linux-kernel but I'm beginner.
> 
> So I don't know how to study linux-kernel.

http://kernelnewbies.org/

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

http://www.conectiva.com/   http://www.surriel.com/

-
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: malloc(1/0) ??

[Igmar Palsenberg]

On Mon, 6 Nov 2000, RAJESH BALAN wrote:

> hi,
> why does this program works. when executed, it doesnt
> give a segmentation fault. when the program requests
> memory, is a standard chunk is allocated irrespective
> of the what the user specifies. please explain.
>  
> main()
> {
>char *s;
>s = (char*)malloc(0);

malloc(0) is bogus in this case. malloc(0) == free();

>strcpy(s,"f");
>printf("%s\n",s);
> }
> 
> NOTE:
>   i know its a 'C' problem. but i wanted to know how
> this works 

The most plausible reason is you're not crossing a page boundary, and you
don't get a access violation.



Igmar

-
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]

[Bartlomiej Zolnierkiewicz]

Yeach... I'm a bit sleepy...

first  [PATCH]: kmalloc/kfree bugs hit 1
second [PATCH]: ide modules and /proc fs

--
bkz

-
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/

linux-2.4.0-test10 and X4.0.1 don't like each other on Libretto 110CT

[David Luyer]

I'm having problems with X 4.0.1 and 2.4.0-test kernels on a Toshiba Libretto
110CT.  Is this likely to be related to a known problem or can someone
recommend some random intermediate kernel versions to try (binary elimination
avoiding known-bad kernel versions...)?

H/w: Toshiba Libretto 110CT (NM2160), Xircom CEM336 modem/ethernet
S/w: Debian woody as at Wed Nov 8, with old xserver-svga package for testing

Kernel xserver-xfree86 4.0.1-1xserver-svga 3.3.6-10
2.4.0-test10   Fail   OK
2.4.0-test4pre3Fail   OK
2.2.15 (Debian build)  OK OK

"Fail" here means X startup results in a blank LCD, unable to switch to 
text consoles either, SAK results in a screen full of previous graphics-mode
display on LCD, even if it was pre-reboot, at that screen it is possible to
type (although not to see the result), login, reboot the system, try a
different version of X, etc (as long as you can remember what you've typed).

Thanks for any help,
David.
-
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: Looking for better 2.2-based VM (do_try_to_free_pages fails, machine hangs)

[Yann Dirson]

On Mon, Nov 06, 2000 at 02:48:27PM -0700, Jeff V. Merkey wrote:
> Yann Dirson wrote:
> > Nov  5 22:36:17 bylbo nscd: 925: while accepting connection: Cannot allocate memory
> > 
> > They usually appear at cron.daily time, although it looks like I kinda can
> > reproduce them.  I'm still investigating and narrowing - they seem to avoid
> > me unfortunately :(  Will launch a tracking job for the night, hopefully
> > I'll narrow to the single cron job this time.

Hm... 12h non-stop looping on the cron jobs and nothing in the logs.

Heisenbug :}


> > Anyone seen that ?
> 
> I see it with sendmail all the time when the fs gets really busy, and
> memory gets low in 
> box. 

But if your memory gets low it seems at least less anormal...  In my case it
occured at night when only the cron job was running.

-- 
Yann Dirson<[EMAIL PROTECTED]> |Why make M$-Bill richer & richer ?
debian-email:   <[EMAIL PROTECTED]> |   Support Debian GNU/Linux:
| Cheaper, more Powerful, more Stable !
http://ydirson.free.fr/ | Check 
-
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: Installing kernel 2.4

[David Lang]

Jeff, the problem is not detecting the CPU type at runtime, the problem is
trying to re-compile the code to take advantage of that CPU at runtime.

depending on what CPU you have the kernel (and compiler) can use different
commands/opmizations/etc, if you want to do this on boot you have two
options.

1. re-compile the kernel

2. change all the CPU specific places from inline code to function calls
into a table that get changed at boot to point at the correct calls.

doing #2 will cost you so much performance that you would be better off
just compiling for a 386 and not going through the autodetect hassle in
the first place.

David Lang

 On Tue, 7 Nov 2000, Jeff V. Merkey wrote:

> Date: Tue, 07 Nov 2000 16:10:58 -0700
> From: Jeff V. Merkey <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Cc: Martin Josefsson <[EMAIL PROTECTED]>,
>  Tigran Aivazian <[EMAIL PROTECTED]>, Anil kumar <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> Subject: Re: Installing kernel 2.4
> 
> 
> There are tests for all this in the feature flags for intel and
> non-intel CPUs like AMD -- including MTRR settings.  All of this could
> be dynamic.  Here's some code that does this, and it's similiar to
> NetWare.  It detexts CPU type, feature flags, special instructions,
> etc.  All of this on x86 could be dynamically detected.   
> 
> :-)
> 
> ;*
> ;
> ;  check current processor type and state
> ;
> ;*
> 
> public DetectProcessorInformation
> DetectProcessorInformation proc near
> 
> mov   ax, cs
> mov   ds, ax
> mov   es, ax
> 
> pushf
> call  get_cpuid
> call  get_fpuid
> call  print
> popf
> ret
> 
> DetectProcessorInformation endp
> 
> get_cpuid proc near
> 
> check_8086:
> 
> pushf
> pop   ax
> mov   cx, ax
> and   ax, 0fffh
> push  ax
> popf
> pushf
> pop   ax
> and   ax, 0f000h
> cmp   ax, 0f000h; flag bits 12-15 are always set on an 8086
> mov   CPU_TYPE, 0   ; 8086 detected
> jeend_get_cpuid
> 
> check_80286:
> orcx, 0f000h
> push  cx
> popf
> pushf
> pop   ax
> and   ax, 0f000h   ; flag bits 12-15 are always clear on 80286 in
> real mode
> mov   CPU_TYPE, 2  ; 80286 processor
> jzend_get_cpuid
> 
> check_80386:
> mov bx, sp
> and sp, not 3
> OPND32
> pushf
> OPND32
> pop ax
> OPND32
> mov  cx, ax
> OPND32   35h, 4h
> OPND32
> push ax
> OPND32
> popf
> OPND32
> pushf
> OPND32
> pop  ax
> OPND32
> xor  ax, cx   ; AC bit won't toggle, 80386 detected
> mov  sp, bx
> mov  CPU_TYPE, 3  ; 80386 detected
> jz   end_get_cpuid
> 
> and  sp, not 3
> OPND32
> push cx
> OPND32
> popf
> mov  sp, bx ; restore stack
> 
> 
> check_80486:
> mov  CPU_TYPE, 4 ; default to 80486
> 
> OPND32
> mov  ax, cx
> OPND32   35h, 20h  ; xor ID bit
> OPND32
> push ax
> OPND32
> popf
> OPND32
> pushf
> OPND32
> pop  ax
> OPND32
> xor  ax, cx   ; cant toggle ID bit
> je   end_get_cpuid
> 
> 
> check_vendor:
> mov ID_FLAG, 1
> OPND32
> xor ax, ax
> CPUID
> OPND32
> mov word ptr VENDOR_ID, bx
> OPND32
> mov word ptr VENDOR_ID[+4], dx
> OPND32
> mov word ptr VENDOR_ID[+8], cx
> mov si, offset VENDOR_ID
> mov di, offset intel_id
> mov cx, length intel_id
> 
> compare:
> repecmpsb
> or  cx, cx
> jnz end_get_cpuid
> 
> intel_processor:
> mov INTEL_PROC, 1
> 
> cpuid_data:
> OPND32
> cmp ax, 1
> 
> jl  end_get_cpuid
> OPND32
> xor ax, ax
> OPND32
> inc ax
> CPUID
> mov byte ptr ds:STEPPING, al
> and STEPPING, STEPPING_MASK
> 
> and al, MODEL_MASK
> shr al, MODEL_SHIFT
> mov byte ptr ds:CPU_MODEL, al
> 
> and ax, FAMILY_MASK
> shr ax, FAMILY_SHIFT
> mov byte ptr ds:CPU_TYPE, al
> 
> mov dword ptr FEATURE_FLAGS, edx
> 
> end_get_cpuid:
> ret
> 
> get_cpuid  endp
> 
> 
> get_fpuid proc near
> 
> fninit
> mov  word ptr ds:FP_STATUS, 5a5ah
> 
> fnstsw   word ptr ds:FP_STATUS
> mov  ax, word ptr ds:FP_STATUS
> cmp  al, 0
> 
> mov  FPU_TYPE, 0
> jne  end_get_fpuid
> 
> check_control_word:
> fnstcw   word ptr ds:FP_STATUS
> mov  ax, word ptr ds:FP_STATUS
> and  ax, 103fh
> cmp  ax, 3fh
> 
> mov  FPU_TYPE, 0
> jne  end_get_fpuid
> mov  FPU_TYPE, 1
> 
> 
> check_infinity:
> cmp  CPU_TYPE, 3
> jne  end_get_fpuid
> fld1
> fldz
> fdiv
> fld  st
> fchs
> fcompp

Re: Installing kernel 2.4

[davej]

> There are tests for all this in the feature flags for intel and
> non-intel CPUs like AMD -- including MTRR settings.  All of this could
> be dynamic.  Here's some code that does this, and it's similiar to
> NetWare.  It detexts CPU type, feature flags, special instructions,
> etc.  All of this on x86 could be dynamically detected.

Detecting the CPU isn't the issue (we already do all this), it's what to
do when you've figured out what the CPU is. Show me code that can
dynamically adjust the alignment of the routines/variables/structs
dependant upon cacheline size.

regards,

Davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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: xterm: no available ptys

[Igmar Palsenberg]

> > I'm missing ptmx. You NEED a writable /dev/pts dir.
> > 
> 
> Actually, what you need is the devpts filesystem mounted onto
> /dev/pts.

Agree. I had a shitload of probs when 2.2.0 came out and I switched.. Was
due that /dev was readonly here. Bit strange if I think of it. 

> 
>   -hpa
> 


Igmar

-
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]

[Bartlomiej Zolnierkiewicz]

Patch fixes ide-disk/ide-floppy/ide-probe modules interaction
with /proc fs. Last chunk is needed to compile ide-probe as
module without /proc support.

--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>


--- linux-240t10p6/drivers/ide/ide-disk.c   Thu Oct 19 22:05:01 2000
+++ linux/drivers/ide/ide-disk.cSat Oct 28 22:59:22 2000
@@ -891,8 +891,10 @@
}
/* We must remove proc entries defined in this module.
   Otherwise we oops while accessing these entries */
+#ifdef CONFIG_PROC_FS
if (drive->proc)
ide_remove_proc_entries(drive->proc, idedisk_proc);
+#endif
}
ide_unregister_module(_module);
 }
--- linux-240t10p6/drivers/ide/ide-floppy.c Tue Jun 13 20:32:00 2000
+++ linux/drivers/ide/ide-floppy.c  Sat Oct 28 22:59:51 2000
@@ -1683,8 +1683,10 @@
}
/* We must remove proc entries defined in this module.
   Otherwise we oops while accessing these entries */
+#ifdef CONFIG_PROC_FS
if (drive->proc)
ide_remove_proc_entries(drive->proc, idefloppy_proc);
+#endif
}
ide_unregister_module(_module);
 }
--- linux-240t10p6/drivers/ide/ide-probe.c  Tue Oct  3 00:16:51 2000
+++ linux/drivers/ide/ide-probe.c   Sat Oct 28 22:58:09 2000
@@ -906,7 +906,9 @@
for (index = 0; index < MAX_HWIFS; ++index)
ide_unregister(index);
ideprobe_init();
+#ifdef CONFIG_PROC_FS
create_proc_ide_interfaces();
+#endif
return 0;
 }
 

Re: How to study linux kernel?

[davej]

> I'm interested in linux-kernel but I'm beginner.
> So I don't know how to study linux-kernel.
> Please tell me.

http://www.kernelnewbies.org

regards,

Davej.

-- 
| Dave Jones <[EMAIL PROTECTED]>  http://www.suse.de/~davej
| SuSE Labs

-
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: Installing kernel 2.4

[Jeff V. Merkey]

There are tests for all this in the feature flags for intel and
non-intel CPUs like AMD -- including MTRR settings.  All of this could
be dynamic.  Here's some code that does this, and it's similiar to
NetWare.  It detexts CPU type, feature flags, special instructions,
etc.  All of this on x86 could be dynamically detected.   

:-)

;*
;
;  check current processor type and state
;
;*

public DetectProcessorInformation
DetectProcessorInformation proc near

mov   ax, cs
mov   ds, ax
mov   es, ax

pushf
call  get_cpuid
call  get_fpuid
call  print
popf
ret

DetectProcessorInformation endp

get_cpuid proc near

check_8086:

pushf
pop   ax
mov   cx, ax
and   ax, 0fffh
push  ax
popf
pushf
pop   ax
and   ax, 0f000h
cmp   ax, 0f000h; flag bits 12-15 are always set on an 8086
mov   CPU_TYPE, 0   ; 8086 detected
jeend_get_cpuid

check_80286:
orcx, 0f000h
push  cx
popf
pushf
pop   ax
and   ax, 0f000h   ; flag bits 12-15 are always clear on 80286 in
real mode
mov   CPU_TYPE, 2  ; 80286 processor
jzend_get_cpuid

check_80386:
mov bx, sp
and sp, not 3
OPND32
pushf
OPND32
pop ax
OPND32
mov  cx, ax
OPND32   35h, 4h
OPND32
push ax
OPND32
popf
OPND32
pushf
OPND32
pop  ax
OPND32
xor  ax, cx   ; AC bit won't toggle, 80386 detected
mov  sp, bx
mov  CPU_TYPE, 3  ; 80386 detected
jz   end_get_cpuid

and  sp, not 3
OPND32
push cx
OPND32
popf
mov  sp, bx ; restore stack


check_80486:
mov  CPU_TYPE, 4 ; default to 80486

OPND32
mov  ax, cx
OPND32   35h, 20h  ; xor ID bit
OPND32
push ax
OPND32
popf
OPND32
pushf
OPND32
pop  ax
OPND32
xor  ax, cx   ; cant toggle ID bit
je   end_get_cpuid


check_vendor:
mov ID_FLAG, 1
OPND32
xor ax, ax
CPUID
OPND32
mov word ptr VENDOR_ID, bx
OPND32
mov word ptr VENDOR_ID[+4], dx
OPND32
mov word ptr VENDOR_ID[+8], cx
mov si, offset VENDOR_ID
mov di, offset intel_id
mov cx, length intel_id

compare:
repecmpsb
or  cx, cx
jnz end_get_cpuid

intel_processor:
mov INTEL_PROC, 1

cpuid_data:
OPND32
cmp ax, 1

jl  end_get_cpuid
OPND32
xor ax, ax
OPND32
inc ax
CPUID
mov byte ptr ds:STEPPING, al
and STEPPING, STEPPING_MASK

and al, MODEL_MASK
shr al, MODEL_SHIFT
mov byte ptr ds:CPU_MODEL, al

and ax, FAMILY_MASK
shr ax, FAMILY_SHIFT
mov byte ptr ds:CPU_TYPE, al

mov dword ptr FEATURE_FLAGS, edx

end_get_cpuid:
ret

get_cpuid  endp


get_fpuid proc near

fninit
mov  word ptr ds:FP_STATUS, 5a5ah

fnstsw   word ptr ds:FP_STATUS
mov  ax, word ptr ds:FP_STATUS
cmp  al, 0

mov  FPU_TYPE, 0
jne  end_get_fpuid

check_control_word:
fnstcw   word ptr ds:FP_STATUS
mov  ax, word ptr ds:FP_STATUS
and  ax, 103fh
cmp  ax, 3fh

mov  FPU_TYPE, 0
jne  end_get_fpuid
mov  FPU_TYPE, 1


check_infinity:
cmp  CPU_TYPE, 3
jne  end_get_fpuid
fld1
fldz
fdiv
fld  st
fchs
fcompp
fstswword ptr ds:FP_STATUS
mov  ax, word ptr ds:FP_STATUS
mov  FPU_TYPE, 2

sahf
jz   end_get_fpuid
mov  FPU_TYPE, 3
end_get_fpuid:
ret
get_fpuid endp



print proc near
cmp  ID_FLAG, 1
je   print_cpuid_data

if (VERBOSE)
mov  dx, offset id_msg
call OutputMessage
endif

print_86:
cmp  CPU_TYPE, 0
jne  print_286

if (VERBOSE)
mov  dx, offset c8086
call OutputMessage
endif
cmp  FPU_TYPE, 0
je   end_print

if (VERBOSE)
mov  dx, offset fp_8087
call OutputMessage
endif
jmp  end_print

print_286:
cmp  CPU_TYPE, 2
jne  print_386
if (VERBOSE)
mov  dx, offset c286
call OutputMessage
endif
cmp  FPU_TYPE, 0
je   end_print
if (VERBOSE)
mov  dx, offset fp_80287
call OutputMessage
endif
jmp  end_print

print_386:
cmp  CPU_TYPE, 3
jne  print_486
if (VERBOSE)
mov  dx, offset c386
call OutputMessage
endif
cmp  FPU_TYPE, 0
je   end_print
cmp  FPU_TYPE, 2
jne  print_387
if (VERBOSE)
mov  dx, offset fp_80287
call OutputMessage
endif
jmp  end_print

print_387:
if (VERBOSE)
mov  dx, offset fp_80387
call OutputMessage
endif
jmp  end_print

Alpha SMP problem

[Reto Baettig]

Hi

I have a problem whith Alpha SMP's which seems to be kernel-related. I
discussed this on the bug-glibc list but everybody seems to agree that
it cannot be a libc problem.

I attached a little testprogram which reproduces the bug in < 1Minute. 
BUT: IT MUST BE STARTED AT LEAST TWICE!

The strange thing is that a single instance of the program runs just
fine. When I start the program a second time, I get segfaults and/or
stuck threads.

We could reproduce this behaviour on different Machines, both with linux
2.2.14 and 2.4.0-test10, but 
ONLY ON ALPHA SMP MACHINES.

Here's my configuration:

Linux reto1 2.4.0-test10 #2 SMP Tue Oct 31 19:39:51 PST 2000 alpha
unknown
^^^  ^
Kernel modules 2.3.19
Gnu C  egcs-2.91.66
Gnu Make   3.78.1
Binutils   2.9.5.0.22
Linux C Library2.1.3
Dynamic linker ldd (GNU libc) 2.1.3
Procps 2.0.6
Mount  2.10f
Net-tools  1.54
Console-tools  0.3.3
Sh-utils   2.0
Modules Loaded nfs lockd sunrpc

Any ideas?

Please tell me when you need more information, or give me some pointers
where I could start to dig...

TIA

Reto
 malloctest.tgz

[PATCH]

[Bartlomiej Zolnierkiewicz]

I hitted few items from Dawson Engler's list of potential kmalloc/kfree
bugs...

--
Bartlomiej Zolnierkiewicz
<[EMAIL PROTECTED]>


--- linux-240t10/drivers/ide/ide-probe.cTue Oct  3 00:16:51 2000
+++ linux/drivers/ide/ide-probe.c   Tue Nov  7 00:25:35 2000
@@ -652,6 +653,10 @@
hwgroup = match->hwgroup;
} else {
hwgroup = kmalloc(sizeof(ide_hwgroup_t), GFP_KERNEL);
+   if(!hwgroup) {
+   restore_flags(flags);
+   return 1;
+   }
memset(hwgroup, 0, sizeof(ide_hwgroup_t));
hwgroup->hwif = hwif->next = hwif;
hwgroup->rq   = NULL;
@@ -746,11 +751,23 @@
}
minors= units * (1sizes)
+   goto cleanup_gd_sizes;
gd->part  = kmalloc (minors * sizeof(struct hd_struct), GFP_KERNEL);
+   if(!gd->part)
+   goto cleanup_gd_part;
bs= kmalloc (minors*sizeof(int), GFP_KERNEL);
+   if(!bs)
+   goto cleanup_bs;
max_sect  = kmalloc (minors*sizeof(int), GFP_KERNEL);
+   if(!max_sect)
+   goto cleanup_max_sect;
max_ra= kmalloc (minors*sizeof(int), GFP_KERNEL);
+   if(!max_ra)
+   goto cleanup_max_ra;
 
memset(gd->part, 0, minors * sizeof(struct hd_struct));
 
@@ -779,12 +796,16 @@
gd->real_devices= hwif; /* ptr to internal data */
gd->next= NULL; /* linked list of major devs */
gd->fops= ide_fops; /* file operations */
-   gd->de_arr  = kmalloc (sizeof *gd->de_arr * units, GFP_KERNEL);
-   gd->flags   = kmalloc (sizeof *gd->flags * units, GFP_KERNEL);
-   if (gd->de_arr)
-   memset (gd->de_arr, 0, sizeof *gd->de_arr * units);
-   if (gd->flags)
-   memset (gd->flags, 0, sizeof *gd->flags * units);
+   if(units) {
+   gd->de_arr = kmalloc (sizeof *gd->de_arr * units, GFP_KERNEL);
+   if(!gd->de_arr)
+   goto cleanup_gd_de_arr;
+   gd->flags  = kmalloc (sizeof *gd->flags * units, GFP_KERNEL);
+   if(!gd->flags)
+   goto cleanup_gd_flags;
+   memset(gd->de_arr, 0, sizeof *gd->de_arr * units);
+   memset(gd->flags, 0, sizeof *gd->flags * units);
+   }
 
for (gdp = _head; *gdp; gdp = &((*gdp)->next)) ;
hwif->gd = *gdp = gd;   /* link onto tail of list */
@@ -802,6 +823,26 @@
devfs_mk_dir (ide_devfs_handle, name, NULL);
}
}
+   return;
+
+cleanup_gd_flags:
+   kfree(gd->flags);
+cleanup_gd_de_arr:
+   kfree(gd->de_arr);
+cleanup_max_ra:
+   kfree(max_ra);
+cleanup_max_sect:
+   kfree(max_sect);
+cleanup_bs:
+   kfree(bs);
+cleanup_gd_part:
+   kfree(gd->part);
+cleanup_gd_sizes:
+   kfree(gd->sizes);
+cleanup_gd:
+   kfree(gd);
+
+   printk(KERN_ERR "ide-probe: not enough memory for init_gendisk()\n");
 }
 
 static int hwif_init (ide_hwif_t *hwif)
--- linux-240t10/drivers/i2o/i2o_config.c   Tue Oct  3 00:15:34 2000
+++ linux/drivers/i2o/i2o_config.c  Mon Nov  6 22:41:41 2000
@@ -499,6 +499,8 @@
if(!res)
{
i2o_unlock_controller(c);
+   printk(KERN_INFO "i2o_config: could not get res\n");
+   if(kcmd.qlen) kfree(query);
return -ENOMEM;
}
 
--- linux-240t10/drivers/i2o/i2o_core.c Thu Oct 19 22:05:01 2000
+++ linux/drivers/i2o/i2o_core.cMon Nov  6 22:49:55 2000
@@ -1664,6 +1664,7 @@
{
printk(KERN_ERR "%s: Timeout waiting for IOP 
reset.\n", 
c->name); 
+   kfree(status);
return -ETIMEDOUT; 
} 
schedule(); 
--- linux-240t10/drivers/scsi/eata_dma.cTue Oct  3 14:27:44 2000
+++ linux/drivers/scsi/eata_dma.c   Mon Nov  6 23:21:04 2000
@@ -909,8 +909,17 @@
 
 cp = (struct eata_ccb *) kmalloc(sizeof(struct eata_ccb),
 GFP_ATOMIC | GFP_DMA);
+if(!cp) {
+   printk(KERN_ERR "eata_dma: out of DMA memory\n");
+   return NULL;
+}
 sp = (struct eata_sp *) kmalloc(sizeof(struct eata_sp), 
 GFP_ATOMIC | GFP_DMA);
+if(!sp) {
+   printk(KERN_ERR "eata_dma: out of DMA memory\n");
+   kfree(cp);
+   return NULL;
+}
 
 buff = dma_scratch;
  
@@ -1459,11 +1468,15 @@
 tpnt->proc_name = "eata_dma";
 
 status = kmalloc(512, GFP_ATOMIC | 

Re: Dual XEON - >>SLOW<< on SMP

[Jeff V. Merkey]

Marc Lehman verified that PII systems will generate tons of AGIs with
gcc.  Perhaps this is the cause of this problem.  You could run EMON and
see if there is something obvious in the numbers ...

Jeff

"Richard B. Johnson" wrote:
> 
> On Wed, 8 Nov 2000, Keith Owens wrote:
> 
> > On Tue, 7 Nov 2000 17:31:19 -0500 (EST),
> > "Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
> > >Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
> > >
> > >Nov  7 17:17:54 chaos nmbd[115]:   Samba server CHAOS is now a domain master 
>browser for workgroup LINUX on subnet 204.178.40.224
> > >Nov  7 17:17:54 chaos nmbd[115]:
> > >Nov  7 17:17:54 chaos nmbd[115]:   *
> > >Nov  7 17:18:54 chaos kernel: NMI Watchdog detected LOCKUP on CPU0,
>  registers:
> > >Nov  7 17:18:54 chaos kernel: CPU:0
> > >Nov  7 17:19:01 chaos login: ROOT LOGIN ON tty2
> >
> > Which means that one of the cpus is spinning for 5 seconds with
> > interrupts disabled.  CPU watchdogs are *good*.
> >
> 
> Well no. I won't buy that. What it means is that some so-called
> watchdog timer code is broken.
> 
> The following, tight loop user-mode code will trip it off and the
> interrupts are not disabled from user-mode code:
> 
> #include 
> 
> int main(void);
> int main()
> {
>for(;;)
>   {
>__asm__ __volatile__(
>"\tpushl %ecx\n"
>"\txorl  %ecx,%ecx\n"
>"1:\tloop1b\n"
>"\tpopl  %ecx\n"
> );
>}
>return 0;
> }
> 
> When it trips off, this code is seg-faulted without any core-dump.
> This code must never seg-fault. It doesn't access memory that was
> not allocated upon startup and, if the kernel wants the CPU, it
> will take it away. It is, after all , supposed to be premptive.
> 
> Somebody has severly broken Linux.
> 
> > >
> > >   CPU0   CPU1
> > >  0:  10945  11869IO-APIC-edge  timer
> > >  1:419393IO-APIC-edge  keyboard
> > >  2:  0  0  XT-PIC  cascade
> > >  8:  0  0IO-APIC-edge  rtc
> > > 10:   2990   2904   IO-APIC-level  eth0
> > > 11:   1066   1124   IO-APIC-level  BusLogic BT-958
> > > 13:  0  0  XT-PIC  fpu
> > >NMI:  22748  22748
> > >LOC:  21731  9
> > >ERR:  0
> > >
> > >
> > >The NMI and LOC (timers) run faster than timer channel 0. This
> > >cannot be correct. Anybody know what this is and how to get
> > >rid of these CPU time stealers?
> >
> > The timer is directed both as a normal interrupt 0 and as a broadcast
> > non maskable interrupt.  The NMI count on each cpu should be roughly
> > the sum of the interrupt 0 count across all cpus.
> >
> 
> How do I get these things turned OFF? These CPUs and this machine
> worked fine for two years. It now runs at 1/4 the speed.
> 
> > The NMI path is fairly fast so the overhead is small.  When it does
> > trip you have a problem, a cpu is spinning for far too long.  Extract
> > the NMI report from the log, run it through ksymoops and mail the
> > decoded result.
> >
> 
> I sincerely doubt that the overhead is small. The overhead is
> enormous. It can be felt!
> 
> All I got from the log was what was reported. There is a colon
> after 'registers' and that's that. The system continued to run.
> It did not panic.
> 
> Cheers,
> Dick Johnson
> 
> Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).
> 
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
> 
> -
> 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/
-
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: swapout vs. filemap_sync_pte...?

[Alexander Viro]

On Mon, 6 Nov 2000, Jeff Garzik wrote:

> The address_space::writepage callback is called from try_to_swap_out()
> path, and also from the filemap_sync_pte() path.  There appears to be no
> way to tell the difference between the two callers.  This is not good
> because the semantics are very different:  "sync this page" versus "page
> is going away".

For the filemap VMAs (i.e. ones that are based on address_space with
backstore) it is the same thing. For something like tmpfs you have
different VMA-level semantics. Ergo, different VMA methods. They can
be shared with filemap ones, but you definitely don't want ->vm_ops->sync().
End of the problem...

-
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: Pentium 4 and 2.4/2.5

[Frank Davis]

Alan,
  As for 'rep nop', couldn't we add in the code, as an example:  
#ifdef Pentium_4
rep nop
#endif

  As for the 2.2.18 patch for correctly determining 2GHz and above, can
it be easily  merged into the 2.4.x kernel, and if so, what's the maximum
clock speed that can be detected?

Regards,
-Frank

On Tue, 7 Nov 2000 21:48:40 + (GMT) Alan Cox
<[EMAIL PROTECTED]> writes:
> > are you saying that rep;nop is not needed in the spinlocks? 
> (because they
> > are for P4)
> 
> rep;nop is a magic instruction on the PIV and possibly some PIII 
> series CPUs
> [not sure]. As far as I can make out it naps momentarily or until 
> bus
> activity thus saving power on spinlocks.
> 
> The problem is 'rep nop' is not defined on other cpus so we can only 
> really use
> it on the PIII/PIV kernel builds
> 
-
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: How to study linux kernel?

[Jeff V. Merkey]

Su Hwan Hwang wrote:
> 
> I'm interested in linux-kernel but I'm beginner.
> 
> So I don't know how to study linux-kernel.

1.  Go to www.linuxdoc.org and read the HOWTOs on the Linux kernel.
2.  Buy a coffee maker and 3000 lbs. of coffee beans.  You will also
need a coffee grinder to grind the beans so you can stay awake around
the clock reviewing code.
3.  Grow a very thick skin and expect "baptism by fire" when asking any
question on this list.
4.  Be very nice to Alan Cox.  He will answer questions and if you are
really wanting to help out.
5.  Buy a copy of "Unix - a practical implementation" and read it.  
6.  "Linux Kernel Internals" is another great book, get it -- the basics
are there.
7.  Grow a ponytail -- view it as your telepathic antenna to other Linux
Kernel Developers.

:-)

Jeff   

> 
> Please tell me.
> _
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
> 
> Share information about yourself, create your own public profile at
> http://profiles.msn.com.
> 
> -
> 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/
-
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: Dual XEON - >>SLOW<< on SMP

[Richard B. Johnson]

On Wed, 8 Nov 2000, Keith Owens wrote:

> On Tue, 7 Nov 2000 17:31:19 -0500 (EST), 
> "Richard B. Johnson" <[EMAIL PROTECTED]> wrote:
> >Also, I get some CPU watchdog timeout that I didn't ask for Grrr...
> >
> >Nov  7 17:17:54 chaos nmbd[115]:   Samba server CHAOS is now a domain master 
>browser for workgroup LINUX on subnet 204.178.40.224 
> >Nov  7 17:17:54 chaos nmbd[115]:
> >Nov  7 17:17:54 chaos nmbd[115]:   * 
> >Nov  7 17:18:54 chaos kernel: NMI Watchdog detected LOCKUP on CPU0,
 registers: 
> >Nov  7 17:18:54 chaos kernel: CPU:0 
> >Nov  7 17:19:01 chaos login: ROOT LOGIN ON tty2
> 
> Which means that one of the cpus is spinning for 5 seconds with
> interrupts disabled.  CPU watchdogs are *good*.
>

Well no. I won't buy that. What it means is that some so-called
watchdog timer code is broken.

The following, tight loop user-mode code will trip it off and the
interrupts are not disabled from user-mode code:

#include 

int main(void);
int main()
{
   for(;;)
  {
   __asm__ __volatile__(
   "\tpushl %ecx\n"
   "\txorl  %ecx,%ecx\n"
   "1:\tloop1b\n"
   "\tpopl  %ecx\n"
);
   }
   return 0;
}

When it trips off, this code is seg-faulted without any core-dump.
This code must never seg-fault. It doesn't access memory that was
not allocated upon startup and, if the kernel wants the CPU, it
will take it away. It is, after all , supposed to be premptive. 

Somebody has severly broken Linux.

> >
> >   CPU0   CPU1   
> >  0:  10945  11869IO-APIC-edge  timer
> >  1:419393IO-APIC-edge  keyboard
> >  2:  0  0  XT-PIC  cascade
> >  8:  0  0IO-APIC-edge  rtc
> > 10:   2990   2904   IO-APIC-level  eth0
> > 11:   1066   1124   IO-APIC-level  BusLogic BT-958
> > 13:  0  0  XT-PIC  fpu
> >NMI:  22748  22748 
> >LOC:  21731  9 
> >ERR:  0
> >
> >
> >The NMI and LOC (timers) run faster than timer channel 0. This
> >cannot be correct. Anybody know what this is and how to get
> >rid of these CPU time stealers?
> 
> The timer is directed both as a normal interrupt 0 and as a broadcast
> non maskable interrupt.  The NMI count on each cpu should be roughly
> the sum of the interrupt 0 count across all cpus.
>

How do I get these things turned OFF? These CPUs and this machine
worked fine for two years. It now runs at 1/4 the speed.
 
> The NMI path is fairly fast so the overhead is small.  When it does
> trip you have a problem, a cpu is spinning for far too long.  Extract
> the NMI report from the log, run it through ksymoops and mail the
> decoded result.
>

I sincerely doubt that the overhead is small. The overhead is
enormous. It can be felt!
 
All I got from the log was what was reported. There is a colon
after 'registers' and that's that. The system continued to run.
It did not panic.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.0 on an i686 machine (799.54 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.


-
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: Installing kernel 2.4

[J Sloan]

"Jeff V. Merkey" wrote:

> So how come NetWare and NT can detect this at run time, and we have to
> use a .config option to specifiy it?  Come on guys.

Linux detects this as well -

However this is not about detection, but optimizations.

Optimizations e.g. for xeon could keep a K6/2 from booting!

It should probably default to something safe like 386 though...


jjs


-
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: Installing kernel 2.4

[kernel]

On Tue, 7 Nov 2000, Jeff V. Merkey wrote:

> So how come NetWare and NT can detect this at run time, and we have to
> use a .config option to specifiy it?  Come on guys.

Then run a kernel compiled for i386 and suffer the poorer code quality
that comes with not using newer instructions and including the
workarounds for ancient hardware.

-ben

-
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: Installing kernel 2.4

[Bruce_Holzrichter]

I don't know about you, but I like having the option to cut out code from
my kernel that will never get used for a particular cpu arch.;o)

Or was that just a troll ;o)
- Forwarded by Bruce Holzrichter/US/Infinium Software on 11/07/2000
05:46 PM -
   
  
"Jeff V. Merkey"   
  
<[EMAIL PROTECTED]>To: Martin Josefsson   
  
Sent by:<[EMAIL PROTECTED]>   
  
linux-kernel-owner@vger.cc: Tigran Aivazian
  
kernel.org  <[EMAIL PROTECTED]>, Anil kumar   
  
<[EMAIL PROTECTED]>,   
  
[EMAIL PROTECTED]   
  
11/07/2000 05:32 PM Subject: Re: Installing kernel 
2.4   
   
  
   
  





So how come NetWare and NT can detect this at run time, and we have to
use a .config option to specifiy it?  Come on guys.

Jeff

Martin Josefsson wrote:
>
> On Tue, 7 Nov 2000, Tigran Aivazian wrote:
>
> > On Tue, 7 Nov 2000, Anil kumar wrote:
> > >   The system hangs after messages:
> > >   loading linux..
> > >   uncompressing linux, booting linux kernel OK.
> > >
> > >   The System hangs here.
> > >
> > >   Please let me know where I am wrong
> >
> > Hi Anil,
> >
> > The only serious mistake you did was using test9 kernel when
test11-pre1
> > (or at least test10) was available. So, redo everything you have done
with
> > test11-pre1 and if you still cannot boot then send a message to this
list
> > with details like your CPUs, motherboard etc. etc.
>
> Have you chosen the right cpu type in the configuration?
>
> /Martin
>
> -
> 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/
-
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/


-
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: Persistent module storage - modutils design

[Keith Owens]

On Tue, 7 Nov 2000 16:30:22 -0600 (CST), 
Jesse Pollard <[EMAIL PROTECTED]> wrote:
> From: Keith Owens <[EMAIL PROTECTED]> 
>> No need for a separate size field.  Note that MODULE_PARM is built at
>> compile time so all persistent data must have a fixed compile time
>> size.
>
>I'll buy that - but it does mean that if there are 300 items then it
>will get LONG... but then, that can be handled. I was thinking of the
>"parameter" to possibly being a full data structure that could be updated
>in an atomic manner, with a minimum of overhead (no number conversions
>in the kernel).

Irrelevant.  Remember that persistent module data is only set when the
module is loaded and retrieved when it removed.  Atomicity and speed
are not an issue at those points.

>> Pure binary immediately runs into kernel version skew problems.
>
>The identification of data version should be left up to the userspace
>utility that retrieves the data.

The userspace utilities are insmod and rmmod.  No, I am not going to
put version numbers into the saved data.

>For some things, yes. I was thinking of things like automatically changing
>the scheduling priorities for batch+interactive use. Also things like
>fair-share scheduler parameters, resident set size/swap resource control,
>(other large system capabilities, I admit).

All of which are system level tuning parameters that vary based on time
and/or load.  My MVS sysprog hat says that there is no point in saving
these parameters across a reboot.  Instead you have global targets
which rarely change and let the system tue to meet the targets - like
MVS Work Load Manager.  These settings are nothing to do with modules.

>I know it wasn't considered, but batch schedulers may have their parameters
>changed hourly. My site currently works with one that has parameters changed
>to reflect available resources for future scheduling cycles that use updated
>job priorities to determine how the system should respond.

And what is the point of saving those parameters?  Firstly they will
not be implemented via modules.  Secondly the values just before
shutdown and at startup will not be useful for the peak hour load, nor
for the overnight backup window.  Again, set targets and let the system
auto tune.  The only thing you save are the overall targets, those are
already in text files with their own specific format.

-
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: Installing kernel 2.4

[J . A . Magallon]

On Tue, 07 Nov 2000 23:32:46 Jeff V. Merkey wrote:
> 
> So how come NetWare and NT can detect this at run time, and we have to
> use a .config option to specifiy it?  Come on guys.
> 

If you can get NT to boot on a 486, perhaps that shows that NT does not use
any optimization...so does not worry about what is it running on, just
prints the name...

-- 
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer

-
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: Dual XEON - >>SLOW<< on SMP

[J . A . Magallon]

On Tue, 07 Nov 2000 23:31:19 Richard B. Johnson wrote:
> On Tue, 7 Nov 2000, Dr. Kelsey Hudson wrote:
..
> >  15:111130   IO-APIC-level  bttv
> > NMI:  190856196  190856196 
> > LOC:  190858464  190858463 
> > ERR:  0
> > 
..
> 
>CPU0   CPU1   
>   0:  10945  11869IO-APIC-edge  timer
>   1:419393IO-APIC-edge  keyboard
>   2:  0  0  XT-PIC  cascade
>   8:  0  0IO-APIC-edge  rtc
>  10:   2990   2904   IO-APIC-level  eth0
>  11:   1066   1124   IO-APIC-level  BusLogic BT-958
>  13:  0  0  XT-PIC  fpu
> NMI:  22748  22748 
> LOC:  21731  9 
> ERR:  0
> 

I have also 2xPII@400, on a SuperMicro mobo. I just get:

werewolf:~/soft/in# uptime
 11:46pm  up  8:38,  0 users,  load average: 0.00, 0.00, 0.00
werewolf:~/soft/in# cat /proc/interrupts
   CPU0   CPU1   
  0:15536081555092IO-APIC-edge  timer
  1:   1784   1800IO-APIC-edge  keyboard
  2:  0  0  XT-PIC  cascade
  8:  0  1IO-APIC-edge  rtc
  9:  12053  11483IO-APIC-edge  aha152x
 10:  31594  31168   IO-APIC-level  aic7xxx, EMU10K1
 11:   42836648   42865890   IO-APIC-level  eth0, nvidia
 12: 134421 134916IO-APIC-edge  PS/2 Mouse
 13:  1  0  XT-PIC  fpu
 14: 16  4IO-APIC-edge  ide0
 15: 10  0IO-APIC-edge  ide1
NMI:  0
ERR:  0

The only diff I see is:
> model name: Pentium II (Deschutes)
> stepping  : 1
> cpu MHz   : 400.000915

model name  : Pentium II (Deschutes)
stepping: 2 <
cpu MHz : 400.912

Something related to version-detection of processors in kernel init ?

-- 
Juan Antonio Magallon Lacarta #> cd /pub
mailto:[EMAIL PROTECTED] #> more beer

-
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/