I am on leave from 7/12/98 till 9/12/98.  For urgent matters you may resend the mail to :  
      
    Soo Heng (AUDTQSH) on Network Security related matters  
    Jenny (AUDTJCG) on PC and LAN matters.  
      
    Thank you.  
      
    >>> "linux-kernel@vger.rutgers.edu" 12/05/98 21:02 >>>  
      
    linux-kernel-digest      Saturday, 5 December 1998     Volume 01 : Number 2945  
      
    In this issue:  
      
     Re: /proc and /kern  
     Gravis Ultrasound [classic] artefacts partly solved on 2.1.131  
     Re: Internationalizing Linux  
     Re: linux-kernel-digest V1 #2839 (writable /proc/<pid>/cmdli  
     Re: disks stats through /proc  
     Re: aic7xxx Driver support faster than 20MB/sec?  
     Re: 960MB limitation for 2.2 ?  
     Re: Problem with 1G RAM  
     Re: patch to drivers/char/serial.c to fix kernel lock-up  
     kernel debugging & x86 emulators  
     Re: IDE disk geometry + patch  
     Re: Problem with 1G RAM  
     Re: Problem with 1G RAM  
     Re: NO ROM BASIC   
     Re: Dead Machine & 2.1.131  
     Re: IDE disk geometry + patch  
     Re: kerneli blowfish/twofish compromised?  
     Re: kernel knowledge of localtime (user-level implememntation)   
     Re: Absolutely horrid IDE performance...  
     Re: Dumb question: Which is "better" SCSI or IDE disks?  
     Re: NIS/RPC Dead on 2.1.130 Alpha  
     Linux/98?!?  
     Re: Internationalizing Linux  
     Re: Y2k compliance  
     RE: Y2k compliance  
     Harmless? "oops" on MCA, 3c523  
     Re: cua* on kernel 2.1 and beyond  
     CAUGHT IN THE ACT: evidence of clock skew on Intel SMP  
     Re: IDE freeze for seconds  
     Re: 960MB limitation for 2.2 ?  
     RE: aic7xxx Driver support faster than 20MB/sec?  
     Re: NO ROM BASIC  
      
    See the end of the digest for information on subscribing to the linux-kernel  
    or linux-kernel-digest mailing lists.  
      
    >>>>> "dp" == david parsons <o.r.c@p.e.l.l.p.o.r.t.l.a.n.d.o.r.u.s> writes:  
      
    >> Another thought I had is to make the pseudo files in /proc and /kern  
    >> display real size information instead of 0, as they do under BSD,  
      
    dp>      That would be really nice, if you could have come guarantee that  
    dp>      the size wouldn't change between stat time and access time.  
      
    Why would you need such a guarantee?  Even the sizes of regular  
    files can change between stat time and access time under  
    multiprocessing process..  
      
    Hello all!  
      
    I've been having trouble playing sounds on my Gravis UltraSound 3.7 (512k)  
    but while browsing the web lately I found something that you might find  
    interesting: irqtune  
      
    It can be found at http://www.best.com/~cae/irqtune and enables you to set  
    the priority assigned to IRQs.  
      
    I've used this to give GUS-interrupts the highest priority and now the  
    sounds play beautifully - even when the system is loaded heavily.  
      
    I advice everyone having trouble playing sounds on their GUSses to try this;  
    I'm happy with it.  
      
    Just one question remaining for the guru's, what could be causing this, is  
    my machine too slow handling interrupts? It's just an almost ancient   
    AMD 5x86/133  
      
    Hmm, on the other hand, it seems like my CD-ROM writer just gave up. Maybe  
    it wants some priority. Darn.  
    - --   
      __ ___ __  C. Jasper Spaans            <spaans@corps.nl>   -o)  
     /     //__                                                  /\\  
    /__ __/ __/  Donkerstraat 9-A  2611 TE  DELFT  015-2133685  _\_v   
                                                      join the penguin force!  
     22:00pm  up  7962 days, 13:47,  1 user,  load average: 0.00, 0.00, 0.00  
      
    So now we require anyone who writes a device driver/module/etc to put a  
    unique identifier for every string that they print out?  We have enough  
    trouble with device numbering...  Maybe eventually things can be made much  
    more standard across drivers so that all drivers of a type will present  
    information in the same way so that something like this can be done;  
    multiple language support is a great idea in theory, but I just don't see  
    it happening yet.  
      
    - -Tymm  
      
    > On Fri, Dec 04, 1998 at 11:52:17AM +0900, Drago Goricanec wrote:  
    > > On 03 Dec 1998 16:25:16 +0100, Jes Sorensen writes:  
    > > > Oh and how to you expect kernel hackers to be able to help debug a  
    > > > problem when someone posts dmesg output in Chinese to linux-kernel?  
    > >   
    > > So is that why the old IBM mainframes tagged every system message with  
    > > a unique identifier?  
    >   
    > And it's a very good idea. If you want to create tools which parse your  
    > logs, you probably don't want to scan for multiple languages ...  
    >   
    > > > We've had this discussion before, about a year ago I think, forget it  
    > > > once and for all, please.  
    > >   
    > > I think having messages appear in the sysadmin's native language has  
    > > merit.  The front line for Linux support is moving away from this  
    > > list.  
    > >   
    > > Once messages permeate back to this list, they can be converted back  
    > > to English just as the original message was converted originally to  
    > > the native language.  
    >   
    > Which is much harder for the sysadmin than understanding the meaning of an  
    > english message.   
    >   
    > I'd suggest the following: Add numbers to the printk messages and leave the  
    > english as it is.   
    > printk ("<4> [00002] Calibrating delay loop ... [] 12.32 BogoMIPS");  
    > (We don't want userspace tools to translate these numbers into english.  
    > Think of installation or boot problems.) You can create a userspace tool to  
    > pick up these numbers, to remove the english text and put the native  
    > language text instead. [00002] would be translated into "Kalibriere  
    > Verzoegerungsschleife ..." (german, in my native language) and [] would not  
    > be translated.  
    > klogd would normally (option) just strip these [00002] and [] messages, but  
    > with a plugin module for translation it will remove the english text and put  
    > the text delivered by the translator instead. There are grammar problems for  
    > some languages with such an approach, however.  
    >   
    > I'm very satisfied with kernel messages in english. And I'm rather annoyed  
    > to have the glibc display perrors in german: When programming my own little  
    > tools, I create error messages this way:   
    > if (errno)  
    >   fprintf (stderr, "tool: Can't open file \"foo\": %s\n", strerror(errnor));  
    > which results in bilingual messages.  
    >   
    > Regards,  
    > --   
    > Kurt Garloff <K.Garloff@ping.de>  (Dortmund, FRG)  
    > PGP key on http://student.physik.uni-dortmund.de/homepages/garloff  
    >   
    >  Microsoft gives you Windows, Linux gives you the whole house     
    >   
    > -  
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in  
    > the body of a message to majordomo@vger.rutgers.edu  
      
    PJ> On linux all that is required is coping a new string into argv[0].  This is  
      
    Will it fit? If my current arv is "a.out" can I write "aaaa.out" there?  
    - --   
    Meelis Roos (mroos@tartu.cyber.ee)  
      
    Lately, Tigran Aivazian announced:  
    >   
    > PS. Btw, whoever is responsible for add_request() the if (disk_index < 4)  
    > should really be if (disk_index < DK_NDRIVE) in there.  
      
    I posted a patch to fix this a while ago (although I'm not responsible  
    for the original code.) I use it for over a year now...  
    See the patch below against 2.1.131.  
      
    It would be better to determine the number of disk at boottime and dynamically  
    allocate space for disk statistics array. Or even better to make it a list  
    so we can keep stats on dynamically added disks.  
      
    - -Marcel  
    - --   
         ======--------         Marcel J.E. Mol                MESA Consulting B.V.  
        =======---------        ph. 015-3101310/06-54724868    P.O. Box 9  
        =======---------        marcel@mesa.nl                 2270 AA  Voorburg  
    __==== www.mesa.nl ---____U_n_i_x______I_n_t_e_r_n_e_t____ The Netherlands ____  
    - --- linux-2.1.131/drivers/block/ll_rw_blk.c Thu Nov 12 07:30:16 1998  
    +++ linux/drivers/block/ll_rw_blk.c Fri Dec  4 23:17:23 1998  
    @@ -3,6 +3,9 @@  
      *  
      * Copyright (C) 1991, 1992 Linus Torvalds  
      * Copyright (C) 1994,      Karl Keyte: Added support for disk statistics  
    + *   
    + * Marcel Mol          : 18feb1998 marcel@mesa.nl  
    + *                       Disk statistics depend on DK_NDRIVE  
      */  
      
     /*  
    @@ -268,6 +271,9 @@  
     static inline void drive_stat_acct(int cmd, unsigned long nr_sectors,  
                                        short disk_index)  
     {  
    + if (disk_index >= DK_NDRIVE)  
    +  return;  
    +  
      kstat.dk_drive[disk_index]++;  
      if (cmd == READ) {  
       kstat.dk_drive_rio[disk_index]++;  
    @@ -299,20 +305,19 @@  
      switch (MAJOR(req->rq_dev)) {  
       case SCSI_DISK0_MAJOR:  
        disk_index = (MINOR(req->rq_dev) & 0x00f0) >> 4;  
    - -   if (disk_index < 4)  
    - -    drive_stat_acct(req->cmd, req->nr_sectors, disk_index);  
        break;  
       case IDE0_MAJOR: /* same as HD_MAJOR */  
       case XT_DISK_MAJOR:  
        disk_index = (MINOR(req->rq_dev) & 0x0040) >> 6;  
    - -   drive_stat_acct(req->cmd, req->nr_sectors, disk_index);  
        break;  
       case IDE1_MAJOR:  
        disk_index = ((MINOR(req->rq_dev) & 0x0040) >> 6) + 2;  
    - -   drive_stat_acct(req->cmd, req->nr_sectors, disk_index);  
       default:  
    +   disk_index = -1;  
        break;  
      }  
    + if (disk_index >= 0)  
    +  drive_stat_acct(req->cmd, req->nr_sectors, disk_index);  
      
      req->next = NULL;  
      
    diff -u --recursive --ignore-all-space linux-2.1.131/fs/proc/array.c linux/fs/proc/array.c  
    - --- linux-2.1.131/fs/proc/array.c Sun Nov 22 20:38:46 1998  
    +++ linux/fs/proc/array.c Fri Dec  4 19:50:10 1998  
    @@ -42,6 +42,8 @@  
      * Alan Cox      :  security fixes.   
      *   <Alan.Cox@linux.org>  
      *  
    + * Marcel Mol        : 18feb1998 marcel@mesa.nl  
    + *                     Disk info in /proc/stat depends on DK_NDRIVE  
      */  
      
     #include <linux/types.h>  
    @@ -237,13 +239,13 @@  
      for (i = 0 ; i < NR_IRQS ; i++)  
       sum += kstat_irqs(i);  
      
    - -#ifdef __SMP__  
      len = sprintf(buffer,  
       "cpu  %u %u %u %lu\n",  
       kstat.cpu_user,  
       kstat.cpu_nice,  
       kstat.cpu_system,  
    - -  jiffies*smp_num_cpus - (kstat.cpu_user + kstat.cpu_nice + kstat.cpu_system));  
    +  ticks - (kstat.cpu_user + kstat.cpu_nice + kstat.cpu_system));  
    +#ifdef __SMP__  
      for (i = 0 ; i < smp_num_cpus; i++)  
       len += sprintf(buffer + len, "cpu%d %u %u %u %lu\n",  
        i,  
    @@ -253,41 +255,27 @@  
        jiffies - (  kstat.per_cpu_user[cpu_logical_map(i)] \  
                   + kstat.per_cpu_nice[cpu_logical_map(i)] \  
                   + kstat.per_cpu_system[cpu_logical_map(i)]));  
    +#endif  
    + len += sprintf(buffer + len, "disk");  
    + for (i = 0 ; i < DK_NDRIVE; i++)  
    +  len += sprintf(buffer + len, " %u", kstat.dk_drive[i]);  
    + len += sprintf(buffer + len, "\ndisk_rio");  
    + for (i = 0 ; i < DK_NDRIVE; i++)  
    +  len += sprintf(buffer + len, " %u", kstat.dk_drive_rio[i]);  
    + len += sprintf(buffer + len, "\ndisk_wio");  
    + for (i = 0 ; i < DK_NDRIVE; i++)  
    +  len += sprintf(buffer + len, " %u", kstat.dk_drive_wio[i]);  
    + len += sprintf(buffer + len, "\ndisk_rblk");  
    + for (i = 0 ; i < DK_NDRIVE; i++)  
    +  len += sprintf(buffer + len, " %u", kstat.dk_drive_rblk[i]);  
    + len += sprintf(buffer + len, "\ndisk_wblk");  
    + for (i = 0 ; i < DK_NDRIVE; i++)  
    +  len += sprintf(buffer + len, " %u", kstat.dk_drive_wblk[i]);  
      len += sprintf(buffer + len,  
    - -  "disk %u %u %u %u\n"  
    - -  "disk_rio %u %u %u %u\n"  
    - -  "disk_wio %u %u %u %u\n"  
    - -  "disk_rblk %u %u %u %u\n"  
    - -  "disk_wblk %u %u %u %u\n"  
    - -  "page %u %u\n"  
    - -  "swap %u %u\n"  
    - -  "intr %u",  
    - -#else  
    - - len = sprintf(buffer,  
    - -  "cpu  %u %u %u %lu\n"  
    - -  "disk %u %u %u %u\n"  
    - -  "disk_rio %u %u %u %u\n"  
    - -  "disk_wio %u %u %u %u\n"  
    - -  "disk_rblk %u %u %u %u\n"  
    - -  "disk_wblk %u %u %u %u\n"  
    +  "\n"  
       "page %u %u\n"  
       "swap %u %u\n"  
       "intr %u",  
    - -  kstat.cpu_user,  
    - -  kstat.cpu_nice,  
    - -  kstat.cpu_system,  
    - -  ticks - (kstat.cpu_user + kstat.cpu_nice + kstat.cpu_system),  
    - -#endif  
    - -  kstat.dk_drive[0], kstat.dk_drive[1],  
    - -  kstat.dk_drive[2], kstat.dk_drive[3],  
    - -  kstat.dk_drive_rio[0], kstat.dk_drive_rio[1],  
    - -  kstat.dk_drive_rio[2], kstat.dk_drive_rio[3],  
    - -  kstat.dk_drive_wio[0], kstat.dk_drive_wio[1],  
    - -  kstat.dk_drive_wio[2], kstat.dk_drive_wio[3],  
    - -  kstat.dk_drive_rblk[0], kstat.dk_drive_rblk[1],  
    - -  kstat.dk_drive_rblk[2], kstat.dk_drive_rblk[3],  
    - -  kstat.dk_drive_wblk[0], kstat.dk_drive_wblk[1],  
    - -  kstat.dk_drive_wblk[2], kstat.dk_drive_wblk[3],  
       kstat.pgpgin,  
       kstat.pgpgout,  
       kstat.pswpin,  
      
    I'm getting 40MB/sec under version 5.1.4, with a 2940UW and Seagate  
    ST34501W drives.  
      
    On Thu, Dec 03, 1998 at 04:42:25PM -0800, Timm Gleason wrote:  
    > Does anyone know if the current version of the aic7xxx driver(5.1.4) support  
    > faster than 20MB/sec maximum transfer rate? I compiled a 2.0.36 kernel using  
    > the pre13 patch and the patch text had references in it to the aic7xxx  
    > driver being 5.0.20. This kernel did support the higher rates. However, I  
    > find that the kernel we compiled using the final release of 2.0.36 contains  
    > aic7xxx driver 5.1.4 and does not seem to accept negotiation higher than  
    > 20MB/sec. Yes, I have checked the SCSI BIOS for the controller and all ID's  
    > are set to 80MB/sec rate.  
      
    On Fri, 4 Dec 1998, Kurt Garloff wrote:  
      
    > Hi everybody,  
    >   
    > Linux-2.2 is likely to be released within the next few months.  
    > I think people will start to use it then, maybe upgrade to 2.2.XX and staying  
    > with that for a long time, just as a lot of people stay with 2.0 kernels.  
    >   
    > There will be probably quite some 2GB iA32 machines in, say, a year or two.  
    > (And while I hope, people switch to better architectures such as alpha, they  
    > won't.)   
    > You can predict what will happen: People tell: "No, Linux does not support  
    > 2GB (not even 1GB) RAM, unless you do strange kernel hacking." (And a lot of  
      
    if you have followed how 2.1 evolved, it _was_ actually a kernel config  
    option when my patch went in. So people started playing with it and it was  
    very easy to mess the kernel up. Yes it had a help entry. It happened a  
    few times, then the config option was removed.   
      
    - -- mingo  
      
    On Fri, 4 Dec 1998, Neil Conway wrote:  
      
    > OK, who wants to volunteer to insert a check in the kernel: STOP if  
    > __PAGE_OFFSET is incompatible with the amount of RAM specified by  
    > "mem=xxxM" ?  Failing that, print a warning, and reduce the RAM to (say)  
    > 960MB or whatever.  
      
    if you are talking about 2.1, then it's already there in 2.1.131:  
      
    #define VMALLOC_RESERVE (64 << 20)      /* 64MB for vmalloc */  
    #define MAXMEM  ((unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE))  
            if (memory_end > MAXMEM)  
                    memory_end = MAXMEM;  
    there should be a warning that we have clipped memory though:   
      
    +  printk("WARNING: clipping memory to %dK!\n", MAXMEM/1024);  
    +  mdelay(3);  
      
    - -- mingo  
      
    Hi Ted,  
      
    I know that the IRQ chain had a cycle, and that this was caused by  
    startup being called a second time during initialization (from  
    set_serial_info), because I made extensive use of printk to debug  
    the problem.  Why this happens, I dont know.  It may be the old  
    version of kermit I am using, it may be that I have shared serial  
    IRQs enabled (although for this particular port, ttyS1, it has IRQ  
    3 all to itself).  It may be that I am running on a single CPU machine,  
    but compiled my kernel with SMP=1.  I do know that this problem occured  
    with linux-2.1.130-pre3, but not with linux-2.1.115.  Also, that the  
    problem only occurs when I run kermit as non-root (this may be  
    kermit's doing).  The bug does happen after booting directly to  
    single user mode (no programs are running, nor are any other  
    serial ports open).  
      
    I used the strace output from kermit to create a test program to  
    demonstrate the bug.  This could probably be trimmed down a little  
    and still demonstrate the bug.  I verified that this program  
    completely hoses three different linux boxes.  Try running this  
    as non-root:  
      
    #include <stdio.h>  
    #include <sys/types.h>  
    #include <fcntl.h>  
    #include <sys/ioctl.h>  
      
    main()  
    {  
      int h1, h2 ;  
      char argp[1024] ;  
      char argp2[1024] ;  
      h1=open("/dev/ttyS1", O_RDWR|O_NONBLOCK) ;  
      ioctl(h1, TCGETS, argp) ;  
      ioctl(h1, TCGETS, argp) ;  
      ioctl(h1, TCGETS, argp) ;  
      fcntl(h1, F_GETFL) ;  
      fcntl(h1, F_GETFL) ;  
      fcntl(h1, F_SETFL, O_RDWR) ;  
      h2=open("/dev/ttyS1", O_RDWR) ;  
      close(h2) ;  
      
      ioctl(h1, TCSETSW, argp) ;  
      ioctl(h1, TCGETS, argp) ;  
      ioctl(h1, TIOCGSERIAL, argp) ;  
      ioctl(h1, TCGETS, argp) ;  
      ioctl(h1, TIOCGSERIAL, argp) ;  
      ioctl(h1, TCGETS, argp2) ;  
      ioctl(h1, TIOCGSERIAL, argp) ;  
      ioctl(h1, TIOCSSERIAL, argp) ;  
      ioctl(h1, TCSETSW, argp2) ;  
      
      ioctl(h1, TCGETS, argp2) ;  
      ioctl(h1, TIOCGSERIAL, argp) ;  
      
      close(h1) ;  
    }  
      
    On Fri, 4 Dec 1998, Theodore Y. Ts'o wrote:  
      
    >    Date:  Fri, 4 Dec 1998 01:25:09 -0800 (PST)  
    >    From: Truxton Fulton <trux@truxton.com>  
      
    >    Please take this patch to drivers/char/serial.c.  It fixes a problem I was  
    >    having where the kernel would lock up solidly (infinite loop in serial.c).  
    >    The problem is that startup() was being called multiple times, creating  
    >    a cycle in the IRQ chain.  This was happening under vanilla 2.1.130 after  
    >    booting directly to single user mode.  The lock-up would occur when I ran  
    >    'kermit -l /dev/ttyS1 -b 38400 -c' as any other user than root.  For root,  
    >    startup() would only be called once.  
      
    > Umm... can you give me more information about exactly how to reproduce  
    > this?  I've tried, and I can't reproduce it.  Note that startup() checks  
    > the flag ASYNC_INITIALIZED, and will exit if the port is already  
    > initialized.  Therefore, running startup() multiple times doesn't cause  
    > a problem.  It's also the case that a single open will not call  
    > startup() multiple times, so I'm very curious how you can to the  
    > conclusion that was actually what was going on.  
      
    > Given that no one else has reported anything vaguely like this, and the  
    > serial driver hasn't change significantly recently, I must conclude that  
    > you must be doing something different, or your system must be different  
    > in some way from most other people's.    
      
    > Are you using a SMP machine?  Were any other serial ports open when you  
    > ran kermit?  How are your irq's and ports configured?  Etc.    
      
    > Before I apply your patch, I want to understand why it's necessary,  
    > because as near as I can tell, it shouldn't be needed at all.  
      
    >       - Ted  
      
    Has anyone given the Bochs x86 emulator (or any other) a try for doing linux  
    kernel debugging?  I've got a build of the kernel that's freezing when it's  
    been brought into memory for booting, and having a working emulator would at  
    least let me see what instruction(s) are causing the freeze.  
      
    Any ideas?  
      
    Thanks,  
    B  
      
    - --   
    Brendan Kehoe                                               brendan@cygnus.com  
    Cygnus Solutions, Sunnyvale, CA                                +1 408 542 9600  
      
    Web page: http://www.zen.org/~brendan/  
      
        Please be careful, last time changes like that were made  
        it killed my setup:  
      
                      Heads: 16   Sectors per Track: 63   Cylinders: 2100  
      
    Yes, let us be careful - that is also what mlord said,  
    and I reacted a bit irritated because he knows these things  
    and would have understood that the change was good, even necessary,  
    had he thought about it.  
      
    Now that you do not seem to know this stuff, and you are not alone,  
    let me try to explain a bit more.  
      
    There are 1-dimensional disk addresses: just give a sector number n.  
    And there are 3-dimensional disk addresses: give cylinder c, head h,  
    sector s. If the disk has in total C cylinders, H heads, S sectors/track,  
    then the conversion is n = c*H*S + h*S + s.  
      (Yes, I know, some misguided people prefer to start counting sectors  
       at 1 instead of 0 - they may have to subtract 1 if they count n  
       from 0 but s from 1.)  
    Converting back goes like c = n/(H*S), r = n%(H*S), h = r/S, s = r%S.  
      
    Under some circumstances the 3D address is used, under some  
    the 1D. For example, LILO uses the 3D address, but uses the 1D  
    address if you give the keyword "linear". And fdisk describes  
    a partition both in 3D and in 1D addresses.  
      
    Now look at the conversion between the two.  
    This conversion uses H and S. So, if someone comes along  
    and changes the system's idea about H and S, then Bad Things  
    may happen - the correspondence between 3D and 1D addresses  
    has changed. Maybe DOS and Linux now disagree about where  
    the partitions are and your filesystems are corrupted.  
      
    So: Never change H and S if you can avoid it.  
      
    On the other hand, C does not occur in these equations.  
    The only place C is used is for the computation of the  
    total capacity of the disk C*H*S. So, if you know the  
    total capacity T, and you are careful not to change H and S,  
    then you have to compute C = T/(H*S).  
      
    OK - that is the general theory. See the Large Disk Howto  
    for more details. Now what is the current point of discussion?  
      
    If you ask a current 8+ GB disk about its geometry using the  
    IDENTIFY command, it will return C/H/S=16383/16/63. These  
    values are a convention, and just as you recognize 1 Jan 1970  
    as "no date", so does "16383/16/63" mean "big disk, look at  
    LBA capacity to see how big". Such large IDE disks did not  
    exist until recently, since it was unclear how DOS could  
    use them, but these days 12 GB and 16 GB IDE disks are cheap.  
    Old kernels did not know about this convention, and didnt believe  
    the LBA capacity if it differed more than 10% from C*H*S.  
    Since 2.1.90 and 2.0.35 the Linux kernel knows about this,  
    and people who do not use translation have no problems with  
    these big disks.  
      
    But most BIOSes allow you to complicate matters by choosing  
    "LBA" or "Large" or "Extended" or "Translation", in which case  
    C,H,S will be replaced by the BIOS by C',H',S' such that  
    C*H*S = C'*H'*S'. If the BIOS does not know about the  
    abovementioned convention, then it will replace 16383/16/63  
    by 1023/255/63 (or 1024/255/63 or so).  
    At present Linux recognizes 16383/16/63 and knows that it is  
    not for real, and looks at LBA capacity to see how large the  
    disk is in reality, but the kernel does not recognize such  
    translated geometries like 1023/255/63.  
    This leads to the situation where fdisk can only describe  
    8 GB of a much larger disk in case the BIOS uses some translation.  
      
    The solution is very simple. When the kernel has decided on  
    what the total capacity T of the disk is, and the BIOS has  
    mentioned its favourite H and S, the kernel must compute  
    C = T/(H*S).  
      
    Andries  
      
    > matter of running out of kernel + user address space.  In these  
    > sparc32 cases the PAGE_OFFSET is set dynamically at boot time based  
    > upon how much memory is in the machine.  
      
    Wouldn't making PAGE_OFFSET a variable be a win on x86 too?  Consider this:  
      
    For every operation involving PAGE_OFFSET, an immediate value must be loaded  
    as part of an equation.  If we made it a variable, GCC, in combination with  
    the CPU could keep the PAGE_OFFSET register resident (on older chips it could  
    not be a big win, but on chips that do register aliasing and such, it could  
    be an even bigger win) or at the minimum, cache resident.  
      
    Assuming the following sequence:  
      
    calculate an address involving PAGE_OFFSET;  
    do some other addition with register results;  
    store;  
    calculate an address involving PAGE_OFFSET;  
      
    With the above, a PPro could do OOOE and SE, and reuse a single register.  
    Otherwise it would involve 2 loads (just for the sake of argument).  
      
    On a 386, it would be similar in both cases, unless more work took place  
    between operations, in which a reload would take place and a cache could  
    be used for that.  
      
    mov cx, PAGE_OFFSET immediate  
    mov ax, value  
    mul cx  
    mov bx, value  
    add bx, ax  
    mov [blah], bx  
    mov ax, value  
    mul cx  
      
    Does any of this make sense? Or am I just off my rocker? I thought of dynamicising  
    PAGE_OFFSET for x86, but I figured that Linus, et al, would have a fit over performance.  
      
    >   
    > Later,  
    > David S. Miller  
    > davem@dm.cobaltmicro.com  
    >   
      
    - --Perry  
      
    - --   
    Perry Harrington       Linux rules all OSes.    APSoft      ()  
    email: perry@apsoft.com    Think Blue. /\  
      
    Please read the FAQ at http://www.tux.org/lkml/  
      
    ------------------------------  
    From: "David S. Miller" <davem@dm.cobaltmicro.com>  
    Date: Fri, 4 Dec 1998 15:09:18 -0800  
    Subject: Re: Problem with 1G RAM  
      
       From: Perry Harrington <pedward@sun4.apsoft.com>  
       Date: Fri, 4 Dec 1998 14:58:51 -0800 (PST)  
      
       Does any of this make sense? Or am I just off my rocker? I thought  
       of dynamicising PAGE_OFFSET for x86, but I figured that Linus, et  
       al, would have a fit over performance.  
      
    Look at the BTFIXUP stuff we do on sparc32 to see another idea of how  
    to taper off most of the performance problems assosciated with a  
    dynamic PAGE_OFFSET.  (TASK_UNMAPPED_BASE was a real killer before we  
    added the BTFIXUP stuff, it put a divide into a critical path).  
      
    Later,  
    David S. Miller  
    davem@dm.cobaltmicro.com  
      
    In message <Pine.LNX.3.96.981204010439.1703A-100000@fire.fireplace>, Gerhard   
    Ma  
    ck writes:  
    +-----  
    | The early XTS would looks for basic in rom if they couldn't find a  
    | bootable device, if none then that error came up. some of the bios  
    | maufacturers still keep that message for some unknown reason.   
    +--->8  
    Actually, the BIOS boot sequence tries the floppy, then the hard drive, then   
    does INT 18H (IIRC).  On an original IBM PC or PC/XT, this invokes ROM   
    BASIC; on some clone XTs it invokes BIOS diagnostics; on most machines these   
    days it invokes a stub that prints the "NO ROM BASIC" message.  
      
    Note that this happens only if the MBR is unreadable (drive 0 not present,   
    not low level formatted, or track 0 bad) and possibly if the magic number in   
    the partition table (0x55AA IIRC) isn't there.  Garbage in the MBR usually   
    leads to a hang, however, as opposed to the INT 18 trap.  
      
    - --   
    brandon s. allbery [os/2][linux][solaris][japh]  allbery@kf8nh.apk.net  
    system administrator      [WAY too many hats]    allbery@ece.cmu.edu  
    carnegie mellon / electrical and computer engineering    KF8NH  
         Kiss my bits, Billy-boy.  
      
    > Hello,  
    >   
    > And to keep following up on my own posts before I see any reponses =), it was  
    > MOST certainly xfstt killing my machine. First it would cause random X lockups  
    > after usage, then it would kill my machine when xdm tried to startup my  
    > session. Removing the xfstt related lines from .xsession/.xinitrc solved the  
    > problem totally.  
    >   
    > It was still quite nasty... I'm disappointed that a user-space program  
    > interacting closely with X was able to bring my machine down  
      
    Are you sure your machine was *totally* locked up?   
      
    I've had this problem with xfstt aswell - X totally locked up. But the  
    machine is still going. It appears that xfstt can't handle some TT  
    fonts, so eg X requests a font, xfstt can't handle it and never get's  
    back to the X server. The X server waits an indeterminate time for a  
    response from the font server.. and so appears hung.  
      
    I've since switched to xfsft, an font server based on the free type  
    library, which hasn't given me any trouble at all. Also, as it's the  
    original xfs with true type support added, it can also serve your other  
    X fonts, so you can replace xfs with it. Configuration is exactly like  
    xfs aswell.  
      
    regards,  
    - --   
    Paul Jakma paul@clubi.ie  
    **********************************************************  
    /etc/crontab:  
    01 5 * * * root find / -name windows -type d \   
     -fstype msdos -o -fstype vfat -exec rm -rf {} \;  
    **********************************************************  
    PGP5 public key: http://www.clubi.ie/jakma/publickey.txt  
      
    "Richard B. Johnson" wrote:  
      
    > > The number of people with 8+ GB disks increases quickly.  
    > > The handling of large IDE disks has always been broken,  
    > > but in 2.0.35 and 2.1.90 this problem was partially  
    > > corrected by inserting the test for C/H/S=16383/16/63.  
      
    Yes, that correction is straight from the Enhanced BIOS Specification  
    for handling of large disks.  
      
    > You can't have 16,383 Cylinders. There is no room in the registers  
    > passed to the BIOS.  
      
    There is no room to pass them to the BIOS unless extended Int13 calls  
    are used instead of the regular Int13 stuff.    
      
    Note that Linux itself uses LBA, not CHS, and talks directly to the  
    bare metal, so the only restriction there is the basic IDE disk  
    hardware limit of 65536 cyls, or roughly.. 128GB per drive.  
      
    The proposal from Andries would not affect Linux at all,  
    but does affect "fdisk" and "LILO".  All appearances suggest  
    that the change would be a *positive* effect, in that it would  
    not hurt anything, and would allow linux fdisk to be used to   
    create partitions beyond the 1024 BIOS cyl limit.  
      
    Note that this is a BIOS-specific problem:  many BIOSs do not  
    have this problem today with drives > 8GB (I know, I have some  
    drives like that, and don't have any problems).  
    But other BIOSs do mis-report the translated geometry.  
    I think there should be no problem with the change,  
    but urge great caution at this point in the release process.  
    - --   
    mlord@pobox.com  
    (ex IDE guy)  
      
    >    > Hell, we should just do this. We need a patch to postal gateway which  
    >    > delivers to the nearest free soil and some volunteers to do OCR and some  
    >    > filing of received mail to show that transfers are legit. Tools to  
    >    > make OCR of source code relatively easy already exist, such as those used   
    >    > by the international PGP group.   
    >   
    >    Here's a question. Is it legal to fax it with checksums to an OCR reader  
    >    automatically ?  
    >   
    > In order to be completely clean and reduce risk on the U.S. side for the  
    > submitter, it's probably best to issue an ISBN number for each one of  
    > these transmissions.  :-)  
    >   
      
    Get an ISSN number and declare yourself a periodical.  Provide copies  
    to anyone that subscribes -- except from Iraq, Libya, North Korea etc;  
    for a subscription fee, of course.  
      
     -hpa  
    - --   
        PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74  
        See http://www.zytor.com/~hpa/ for web page and full PGP public key  
            I am Bahá'í -- ask me about it or see http://www.bahai.org/  
       "To love another person is to see the face of God." -- Les Misérables  
      
    Feuer said something like ...  
     I don't understand this.  Why not just use UTC everywhere?  If worried  
     about backwards time, can use slow time changes, or perhaps is there  
     any clock on motherboard that just keeps ticking?  Who cares about  
     local time anyway?  
      
    umm, various filesystems (dos/mac-based) deal with everything in local  
    time. not dealing with them in that way will break cross-platform  
    behaviour. similarly, assuming that local time is really the same as  
    shifted-UTC will also fail as you have no idea in what timezone a  
    particular file was created in.  
      
    - -a  
      
    > On Wed, 2 Dec 1998, Mark Lord wrote:  
    >   
    > > >              -------Sequential Output-------- ---Sequential Input-- --Random--  
    > > >              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---  
    > > >Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec  
    > > >%CPU  
    > > >          256 17374 95.5 32681 33.2 10706 24.3 15683 68.4 23710 24.3 214.6  1.8  
    >   
    > Just my comments on this benchmark results:  
    >   
    > 1) Block write = 32681 KB/second  
    >    Comment: Not relevant, if as I guess the machine has probably 128 MB  
    >             memory.  
      
    Yes, but the same results are achievable on less.  
    The test file was 256MB.  Those are *real* throughput rates,  
    not buffer-cache buggered speeds.  
      
    > 2) Block read 23710 KB/second against Character Read 15683 KB/s  
    >    and only 68.4 % CPU.  
    >    Comment: You should get at least 90 %. Something is behaving not well  
    >             somewhere.  
      
    Why should it get 90%?  The machine is very fast, and has to wait  
    sometimes for I/O.  Again, no bogosity there.  
    >   
    > For your information, here is a benchmark result with Linux 2.1.30 and the  
    > stock driver I got a couple of days ago using a single Cheatah2.  
    > (PII 233 / 66MHz SDRAM + 64MB + SYM53C895)  
    >   
    >               -------Sequential Output-------- ---Sequential Input-- --Random--  
    >               -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---  
    > Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU  
    > 4K ext2   300 10656 97.7 19235 23.7  8346 26.5 13097 91.8 18602 21.0 229.2  4.7  
      
    Looks pretty wimpy, even by IDE standards.  
    - --   
    mlord@pobox.com  
      
    1. Some hard disk manufactures are using same disk drive (physically) to  
    make SCSI and ATA.  They only change the PCB board.  
      
    2. SCSI-1 and SCSI-2 have 8 bit data bus, while ATA have 16 bit data bus.  
      
    3. ATA got disk cache built in as well.  
      
    4. Some low end of SCSI host card is only 8 Bit card.  
      
    Compare by yourself.  
      
    Leonard  
      
    On Fri, 4 Dec 1998, Alan Cox wrote:  
      
    > > IDE is cheaper and faster than SCSI, but you can't have so much IDE hard  
    > > disks hooked up to your machine as SCSI.  
    >   
    > For real work patterns SCSI tends to be faster than IDE. Also for high  
    > end devices SCSI is wonderful. Most of my smaller boxes are IDE- its just  
    > not worth the price difference  
    >   
    >   
      
    Hi,  
      
    I compiled Linux 2.1.131 with egcs 1.1.1 on Linux/alpha:  
      
    # cat /proc/cpuinfo  
    cpu                     : Alpha  
    cpu model               : EV4  
    cpu variation           : 0  
    cpu revision            : 0  
    cpu serial number       : Linux_is_Great!  
    system type             : EB64+  
    system variation        : Cabriolet  
    system revision         : 0  
    system serial number    : MILO-0000  
    cycle frequency [Hz]    : 274995720 est.  
    timer frequency [Hz]    : 1024.00  
    page size [bytes]       : 8192  
    phys. address bits      : 34  
    max. addr. space #      : 63  
    BogoMIPS                : 270.53  
    kernel unaligned acc    : 0 (pc=0,va=0)  
    user unaligned acc      : 12061 (pc=2000029d704,va=11fff614c)  
    platform string         : N/A  
    # uname -a  
    Linux creek.lucon.org 2.1.131 #9 Fri Dec 4 08:33:03 PST 1998 alpha unknown  
    NIS seems to work just fine. BTW, I am running RedHat 5.2.  
      
    - --   
    H.J. Lu (hjl@gnu.org)  
      
    Hi,  
      
    CUT out of XFree86-3.3.3/README:  
      
    2.  Systems XFree86 has been tested on  
      
    ...  
          Others:  
                    o Linux (Intel x86, DEC Alpha/AXP and m68k)  
      
    ...  
          PC98:  
                   o Linux/98  
      
    CUT  
      
    Did I miss something? What is Linux/98 ?  
      
    - --   
    _ciao, Jens_______________________________ http://www.pinguin.conetix.de  
        cat /dev/boiler/water | tea | sieve > /cup  
        mount -t hdev /dev/human/mouth01 /mouth ; cat /cup >/mouth/gulp  
      
    On Fri, Dec 04, 1998 at 09:53:08AM +0100, Jes Sorensen wrote:  
      
    >>> Oh and how to you expect kernel hackers to be able to help debug a  
    >>> problem when someone posts dmesg output in Chinese to linux-kernel?  
    >> So is that why the old IBM mainframes tagged every system  
    >> message with a unique identifier?  
    > Oh and everybody should have a 2000 page translation table on paper?  
      
    Come on. You know these "SYS3175: Das Program hat eine illegale Instruktion  
    ausgeführt und wird deshalb beendet." messages, ANY IBM programmer will be  
    able to backtrack the message by using the SYS number.  
      
    What do you need a 2000 page translation table for then?  
      
    YOU don't need to translate ANYTHING. But making it POSSIBLE to be  
    translated is, I believe, quite important. Even the Palm OS has been  
    translated. :)  
      
    >>> We've had this discussion before, about a year ago I think, forget  
    >>> it once and for all, please.  
    >> I think having messages appear in the sysadmin's native  
    >> language has merit.  The front line for Linux support is moving  
    >> away from this list.  
    > I really can't see the point here, all the commands on the system are  
    > in english anyway, C is using English. If you don't understand the  
    > basic English terms used by a computer, how can you adminitrate them.  
      
    Simple. Get an OS that gives you the messages in the language you know best  
    and understand best. I know of quite a couple friends whose only reasons for  
    not trying out something other than Windows is that in Windows, everything  
    is in their native tongue (German, in my example). They are too lazy to  
    learn English just to use another OS. And they ARE in fact missing  
    something.  
      
    >> Once messages permeate back to this list, they can be converted  
    >> back to English just as the original message was converted  
    >> originally to the native language.  
    > Sorry but I am not going to waste my time trying to decode error  
    > messages from my own code just because someone wants to print it in  
    > a different language.  
      
    You don't have to. Please think about the above message number idea and THEN  
    reply (if necessary).  
      
    Is it a big problem adding a kind of language definitions (and perhaps a  
    utility that interactively creates these files) AND an unique(!) error  
    number scheme to avoid miscromprehension for bug reports? Something like  
      
    "kernel_999: Dieser Fehler existiert nicht. Es ist sicherlich Ihre Schuld."  
    "libc2.1_666: Hier spricht der BAADH: Ich habe gerade ihr $HOME gelöscht."  
    (now what ever does BAADH mean? ;-)  
      
    or something.   
      
    - --   
    _ciao, Jens_______________________________ http://www.pinguin.conetix.de  
        cat /dev/boiler/water | tea | sieve > /cup  
        mount -t hdev /dev/human/mouth01 /mouth ; cat /cup >/mouth/gulp  
      
    Hello;  
      
    You obviously have not dealt with Microsoft Winnt 4.0  
    and all the Service Pack then. While one Service Pack  
    did somewhat correct the Y2K problem was not aware that  
    2000 was in fact a leap year. There was no way to set  
    the date to Feb 29, 2000.  
      
    So yes there are braindead programmers out there.  
      
    Myreen Johan wrote:  
    >   
    > >So how does it cope with 2000 being a leep year?  
    >   
    > I don't understand the fuzz about year 2000 being  
    > a leap year. The simplistic formula for finding  
    > out if a year is a leap year is to check if it is  
    > divisible by four. That formula is valid from the  
    > year 1901 until the year 2100. We're talking sbout  
    > lazy programmers not being able to see even 5-10  
    > years into the future. The "Year 2000 is a Leap  
    > Year" problem is kind of the Y2K problem inversed.  
    >   
    > Do do you really expect to find programs out there  
    > written by programmers informed enough to take  
    > into account that years divisible by 100 are not  
    > leap years, but *at* *the* *same* *time* don't  
    > know that years divisible by 400 are leap years  
    > after all?  
    >   
    > Has anybody ever bumped into this problem in real  
    > life? I suspect this "problem" is just the product  
    > of the Y2K consultants' imagination.  
    >   
    > Johan Myréen  
    > jem@iki.fi  
    >   
      
    - --   
    Terry L. Ridder  
    Blue Danube Software (Blaue Donau Software)  
    "We do not write software, we compose it."  
      
     entertaining angels  
     by the light of my computer screen  
     24-7 you wait for me  
     entertaining angels  
     while the night becomes history  
     host of heaven, sing over me  
     ==Entertaining Angels==Newsboys  
      
    On Fri, 4 Dec 1998, Myreen Johan wrote:  
      
    >>So how does it cope with 2000 being a leep year?  
    >  
    >I don't understand the fuzz about year 2000 being  
    >a leap year. The simplistic formula for finding  
    >out if a year is a leap year is to check if it is  
    >divisible by four. That formula is valid from the  
    [snip]  
      
    because the formula you consider valid isn't the complete formula.  
    from an altavista search for "leap year":  
      
    The Gregorian calendar schedules leap years every fourth year to make up  
    for the fact that the Earth takes a little longer than 365 days to revolve  
    around the sun. The problem is that over a few centuries, adding this  
    extra day overcompensates. The built-in Gregorian solution was that years  
    evenly divisible by 100 do not have a leap year -- except for years  
    divisible by 400, like 2000. In other words, 1600 was a leap year; 1700,  
    1800 and 1900 were not; 2000 will be.   
      
    >  
    >Johan Myréen  
    >jem@iki.fi  
      
    now, if we were to 'spin down the earth' we wouldn't have to worry about  
    all this leap year mumbo-jumbo.  
      
    Chipper  
      
    - ------  
                        Please encrypt anything important.  
    PGP Key: http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x6CFA486D  
      
    Short form:  
    eth0: strange ... timeout with CU active?!?  
    eth0: X0: a040 N0: a000 N1: a000 0  
    eth0: oops! CU has left active state. stat: a000/0240.  
      
    This happens about the time that I send the first tcp packets out on  
    the ethernet.  Until I create a client tcp session, I can't get the  
    linux box to receive anything via ethernet.  [This isn't new to 2.1.131,  
    I've been dealing with this forever it seems like.]  
      
    Long form  
    - ---------  
    Dmesg:  
    Linux version 2.1.131 (rdm@rdm) (gcc version 2.7.2.3) #2 SMP Fri Dec 4 20:01:15 EST 1998  
    mapped APIC to ffffe000 (002ac000)  
    mapped IOAPIC to ffffd000 (002ad000)  
    Console: colour VGA+ 80x25  
    Calibrating delay loop... 24.88 BogoMIPS  
    Memory: 30256k/32768k available (1396k kernel code, 412k reserved, 660k data, 44k init)  
    Checking if this processor honours the WP bit even in supervisor mode... Ok.  
    VFS: Diskquotas version dquot_6.4.0 initialized  
    Checking 386/387 coupling... OK, FPU using exception 16 error reporting.  
    Checking 'hlt' instruction... OK.  
    POSIX conformance testing by UNIFIX  
    CPU0: 486  
    SMP motherboard not detected. Using dummy APIC emulation.  
    Micro Channel bus detected.  
    Swansea University Computer Society NET3.039 for Linux 2.1  
    NET3: Unix domain sockets 0.16 for Linux NET3.038.  
    Swansea University Computer Society TCP/IP for NET3.037  
    IP Protocols: ICMP, UDP, TCP  
    IPv4 over IPv4 tunneling driver  
    early initialization of device tunl0 is deferred  
    GRE over IPv4 tunneling driver  
    early initialization of device gre0 is deferred  
    IPv6 v0.2 for NET3.037  
    IPv6 over IPv4 tunneling driver  
    early initialization of device sit0 is deferred  
    Swansea University Computer Society IPX 0.38 for NET3.037  
    IPX Portions Copyright (c) 1995 Caldera, Inc.  
    Initializing RT netlink socket  
    Starting kswapd v 1.5   
    parport0: PC-style at 0x3bc [SPP,PS2]  
    Serial driver version 4.26 with no serial options enabled  
    ttyS00 at 0x03f8 (irq = 4) is a 16550A  
    lp0: using parport0 (polling).  
    Software Watchdog Timer: 0.05, timer margin: 60 sec  
    Real Time Clock Driver v1.09  
    Non-volatile memory driver v1.0  
    tpqic02: Runtime config, $Revision: 1.10 $, $Date: 1997/01/26 07:13:20 $  
    tpqic02: DMA buffers: 20 blocks  
    RAM disk driver initialized:  16 RAM disks of 4096K size  
    loop: registered device at major 7  
    Floppy drive(s): fd0 is 2.88M  
    FDC 0 is a post-1991 82077  
    IBM MCA SCSI: IBM SCSI Adapter w/Cache found in slot 1, io=0x3540, scsi id=7.  
    IBM MCA SCSI: Removing current logical SCSI-device mapping.  
    IBM MCA SCSI: Probing SCSI-devices.  
    IBM MCA SCSI: Mapping SCSI-devices.  
    IBM MCA SCSI: SCSI-access-order: IBM/ANSI.  
    scsi0 : IBMMCA  
    scsi : 1 host.  
      Vendor: IBM       Model: 0663L12       !H  Rev: s z   
      Type:   Direct-Access                      ANSI SCSI revision: 02  
    Detected scsi disk sda at scsi0, channel 0, id 0, lun 0  
      Vendor: EXABYTE   Model: EXB-8200          Rev: 2680  
      Type:   Sequential-Access                  ANSI SCSI revision: 01 CCS  
    Detected scsi tape st0 at scsi0, channel 0, id 1, lun 0  
      Vendor: IBM       Model: 0663L12       !H  Rev: s z   
      Type:   Direct-Access                      ANSI SCSI revision: 02  
    Detected scsi disk sdb at scsi0, channel 0, id 2, lun 0  
    scsi : detected 1 SCSI tape 2 SCSI disks total.  
    SCSI device sda: hdwr sector= 512 bytes. Sectors= 1955886 [955 MB] [1.0 GB]  
    SCSI device sdb: hdwr sector= 512 bytes. Sectors= 1962030 [958 MB] [1.0 GB]  
    early initialization of device teql0 is deferred  
    PPP: version 2.3.3 (demand dialling)  
    TCP compression code copyright 1989 Regents of the University of California  
    PPP line discipline registered.  
    SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).  
    CSLIP: code copyright 1989 Regents of the University of California.  
    eth0: 3c523 adapter found in slot 8  
    eth0: 3Com 3c523 Rev 0x1 at 0x300  
    eth0: IRQ 3, internal xcvr, memory 0xd8000-0xdbfff.  
    eth0: hardware address  02 60 8c 8c ef bd  
    Partition check:  
     sda: sda1 sda2 sda3 sda4  
     sdb: sdb1  
    Coda Kernel/Venus communications, v4.6.0, braam@cs.cmu.edu  
    VFS: Mounted root (ext2 filesystem) readonly.  
    Freeing unused kernel memory: 44k freed  
    Adding Swap: 122876k swap-space (priority -1)  
    diald uses obsolete (PF_INET,SOCK_PACKET)  
    eth0: strange ... timeout with CU active?!?  
    eth0: X0: a040 N0: a000 N1: a000 0  
    eth0: oops! CU has left active state. stat: a000/a240.  
    eth0: no IPv6 routers present  
    registered device ppp0  
    Config:  
    CONFIG_EXPERIMENTAL=y  
    CONFIG_M486=y  
    CONFIG_MODULES=y  
    CONFIG_MODVERSIONS=y  
    CONFIG_KMOD=y  
    CONFIG_NET=y  
    CONFIG_MCA=y  
    CONFIG_SYSVIPC=y  
    CONFIG_BSD_PROCESS_ACCT=y  
    CONFIG_SYSCTL=y  
    CONFIG_BINFMT_AOUT=y  
    CONFIG_BINFMT_ELF=y  
    CONFIG_BINFMT_MISC=y  
    CONFIG_BINFMT_JAVA=y  
    CONFIG_PARPORT=y  
    CONFIG_PARPORT_PC=y  
    CONFIG_BLK_DEV_FD=y  
    CONFIG_BLK_DEV_LOOP=y  
    CONFIG_BLK_DEV_RAM=y  
    CONFIG_BLK_DEV_INITRD=y  
    CONFIG_PARIDE_PARPORT=y  
    CONFIG_PACKET=y  
    CONFIG_FIREWALL=y  
    CONFIG_NET_ALIAS=y  
    CONFIG_UNIX=y  
    CONFIG_INET=y  
    CONFIG_IP_ADVANCED_ROUTER=y  
    CONFIG_RTNETLINK=y  
    CONFIG_NETLINK=y  
    CONFIG_IP_MULTIPLE_TABLES=y  
    CONFIG_IP_ROUTE_TOS=y  
    CONFIG_IP_ROUTE_VERBOSE=y  
    CONFIG_IP_ROUTE_NAT=y  
    CONFIG_IP_FIREWALL=y  
    CONFIG_IP_FIREWALL_NETLINK=y  
    CONFIG_NETLINK_DEV=y  
    CONFIG_NET_IPIP=y  
    CONFIG_NET_IPGRE=y  
    CONFIG_IP_ALIAS=y  
    CONFIG_SYN_COOKIES=y  
    CONFIG_INET_RARP=y  
    CONFIG_IP_NOSR=y  
    CONFIG_SKB_LARGE=y  
    CONFIG_IPV6=y  
    CONFIG_IPV6_EUI64=y  
    CONFIG_IPV6_NO_PB=y  
    CONFIG_IPX=y  
    CONFIG_CPU_IS_SLOW=y  
    CONFIG_NET_SCHED=y  
    CONFIG_NETLINK=y  
    CONFIG_RTNETLINK=y  
    CONFIG_NET_SCH_CBQ=y  
    CONFIG_NET_SCH_CSZ=y  
    CONFIG_NET_SCH_PRIO=y  
    CONFIG_NET_SCH_RED=y  
    CONFIG_NET_SCH_SFQ=y  
    CONFIG_NET_SCH_TEQL=y  
    CONFIG_NET_SCH_TBF=y  
    CONFIG_NET_QOS=y  
    CONFIG_NET_ESTIMATOR=y  
    CONFIG_NET_CLS=y  
    CONFIG_NET_CLS_ROUTE=y  
    CONFIG_NET_CLS_FW=y  
    CONFIG_NET_CLS_U32=y  
    CONFIG_NET_CLS_RSVP=y  
    CONFIG_NET_CLS_RSVP6=y  
    CONFIG_SCSI=y  
    CONFIG_BLK_DEV_SD=y  
    CONFIG_CHR_DEV_ST=y  
    CONFIG_SCSI_MULTI_LUN=y  
    CONFIG_SCSI_CONSTANTS=y  
    CONFIG_SCSI_LOGGING=y  
    CONFIG_SCSI_IBMMCA=y  
    CONFIG_IBMMCA_SCSI_ORDER_STANDARD=y  
    CONFIG_NETDEVICES=y  
    CONFIG_DUMMY=y  
    CONFIG_NET_ETHERNET=y  
    CONFIG_NET_VENDOR_3COM=y  
    CONFIG_ELMC=y  
    CONFIG_PPP=y  
    CONFIG_SLIP=y  
    CONFIG_SLIP_COMPRESSED=y  
    CONFIG_VT=y  
    CONFIG_VT_CONSOLE=y  
    CONFIG_SERIAL=y  
    CONFIG_PRINTER=y  
    CONFIG_PRINTER_READBACK=y  
    CONFIG_MOUSE=y  
    CONFIG_PSMOUSE=y  
    CONFIG_QIC02_TAPE=y  
    CONFIG_QIC02_DYNCONF=y  
    CONFIG_WATCHDOG=y  
    CONFIG_SOFT_WATCHDOG=y  
    CONFIG_RTC=y  
    CONFIG_NVRAM=y  
    CONFIG_QUOTA=y  
    CONFIG_MINIX_FS=y  
    CONFIG_EXT2_FS=y  
    CONFIG_ISO9660_FS=y  
    CONFIG_JOLIET=y  
    CONFIG_FAT_FS=y  
    CONFIG_MSDOS_FS=y  
    CONFIG_UMSDOS_FS=y  
    CONFIG_PROC_FS=y  
    CONFIG_NFS_FS=y  
    CONFIG_SUNRPC=y  
    CONFIG_LOCKD=y  
    CONFIG_CODA_FS=y  
    CONFIG_SMB_FS=y  
    CONFIG_NCP_FS=y  
    CONFIG_SYSV_FS=y  
    CONFIG_NLS=y  
    CONFIG_VGA_CONSOLE=y  
    CONFIG_MAGIC_SYSRQ=y  
      
    ==> /proc/mca/machine <==  
    Model Id: 0xf8  
    Submodel Id: 0x28  
    BIOS Revision: 0x2  
      
    ==> /proc/mca/pos <==  
    Slot 1: ff 8e f1 fc a0 ff ff ff  IBM SCSI Adapter w/Cache  
    Slot 2: ff ff ff ff ff ff ff ff    
    Slot 3: 1f 0f 01 2b ff b5 ff ff    
    Slot 4: ff ff ff ff ff ff ff ff    
    Slot 5: da 8f 1d 6e fd c0 00 00    
    Slot 6: ff ff ff ff ff ff ff ff    
    Slot 7: ff ff ff ff ff ff ff ff    
    Slot 8: 42 60 99 04 ff ff ff ff  3Com 3c523 Etherlink/MC  
    Video : ff ff ff ff ff ff ff ff    
    SCSI  : ff ff ff ff ff ff ff ff    
      
    ==> /proc/mca/slot1 <==  
    Slot: 1  
    Adapter Name: IBM SCSI Adapter w/Cache  
    Id: 8eff  
    Enabled: Yes  
    POS: Driver Installed: No  
    ff 8e f1 fc a0 ff ff ff   
    Subsystem PUN: 7  
    I/O base address: 0x3540  
      
    ==> /proc/mca/slot3 <==  
    Slot: 3  
    Adapter Name: Unknown  
    Id: 0f1f  
    Enabled: Yes  
    POS: Driver Installed: No  
    1f 0f 01 2b ff b5 ff ff   
      
    ==> /proc/mca/slot5 <==  
    Slot: 5  
    Adapter Name: Unknown  
    Id: 8fda  
    Enabled: Yes  
    POS: Driver Installed: No  
    da 8f 1d 6e fd c0 00 00   
      
    ==> /proc/mca/slot8 <==  
    Slot: 8  
    Adapter Name: 3Com 3c523 Etherlink/MC  
    Id: 6042  
    Enabled: Yes  
    POS: Driver Installed: No  
    42 60 99 04 ff ff ff ff   
    Revision: 0xe  
    IRQ: 3  
    IO Address: 0x300-0x308  
    Memory: 0xc00d8000-0xc00dbfff  
    Transceiver: Internal  
    Device: eth0  
    Hardware Address: 02 60 8c 8c ef bd  
      
    - --   
    Raul  
      
    > On Thu, 3 Dec 1998, Tymm Twillman wrote:  
    >   
    > > ln -s /dev/ttyS0 /dev/cua0  
    >   
    > This is bad!  
    >   
    > A process using /dev/cua0 will create a lockfile named cua0.  Another  
    > process wanting to use /dev/ttyS0, will look for a lockfile named  
    > ttyS0.  When it is not found, that process will go ahead and open  
    > ttyS0 and collide with the data being transferred on cua0.  
    >   
    > A complex locking routine can be used.  See my blurb on lockfiles and  
    > a sample routine to creat either dual lockfiles or single ones.  
    >   
    > This is available from scicom.alphacdc.com via ftp.  The tarball is  
    > pub/linux/serial_suite.tgz.  
    >   
    > vern  
    >   
      
    Yep, I really bumbled this one up.  Apologies for the bad advice.  
      
    - -Tymm  
      
    Thanks to everyone who has been sending me SMP skew-testing results.  
    I have some cleaner V2 code below which tries to reduce some sources  
    of skew in the code by forcing both master and slave to use the  
    same message-seding code, but I have found a smoking gun in a  
    dual PPro 180 MHz that someone sent me the results from:  
      
    >     -8960      9522  
    >     -9098      9393  
    >     -9092      9390  
    >     -9092      9390  
    >     -9098      9393  
    >     -9092      9390  
    >     -9092      9393  
    >     -9092      9390  
    >     -9092      9456  
    >     -9089      9390  
    >     -9092      9390  
    >     -9092      9393  
    >     -9098      9390  
    >     -9092      9390  
    >     -9083      9390  
    >     -9092      9390  
    >     -9092      9456  
    >     -9089      9390  
    >     -9092      9390  
    >     -9092      9393  
    >     -9098      9390  
    >     -9092      9390  
    >     -9089      9390  
    >     -9092      9390  
    >     -9092      9456  
    > min1 = -9098, min2 = 9390, skew = -18488  
      
    These two processors have their TSCs offset by 9244 from each other, a  
    difference of 51 usec.  That is definitely enough to screw up timekeeping.  
    Thus, I think we need to insert some skew-removal code into the SMP  
    boot process.  (Are any SMP wizards interested in helping?)  
    - --   
     -Colin  
      
    /*  
     * Test code - please run this on your SMP PC system.  
     * Thanks to everyone who has sent me results.  (colin@nyx.net)  
     *   
     * This measures the skew between the time stamp counters on  
     * two pentium-type processors.  The purpose is to design kernel  
     * timekeeping code for SMP systems.  If the TSC registers are  
     * reliably in sync, then things can be simplified considerably,  
     * but verifying "reliably" requires testing on a variety of systems.  
     *   
     * This should be run on a mostly idle system, so that the two threads  
     * can run simultaneously on two processors without getting interrupted.  
     * An interrupt is easy to see (it looks like a number > 1000), so you  
     * can just run it and hope before shutting things down.  One or two  
     * intrrupts don't hurt.  
     *   
     * What *does* hurt the results is DMA activity.  If you see significant  
     * skew (+/-10 or more) or "noisy" inconsistent data, please try unplugging  
     * the network briefly.  If that doesn't fix it, please tell me a lot  
     * about your system, so I can try to figure out what's happening.  
     * (Motherboard, processor speed, bus speed, BIOS brand, PCI cards.)  
     * /proc/cpuinfo has lots of useful data.  
     *  
     * NEGATIVE NUMBERS mean that there is definitely significant skew.  
     * If you see any number except the final skew *ever* being negative,   
     * that is a very important piece of data.  
     *   
     * PLEASE COMPILE -O2.  It's simple code which should be all in registers  
     * except for the required memory references.  Too much memory access  
     * screws up the timing.  
     *  
     * LIBC5 instructions: you'll need to include <linux/shed.h>  
     * for the CLONE_* flags, and link -lpthread to get the clone()  
     * function.  
     *  
     *  
     * Typical results look like this:  
     *       50        54  
     *       46        46  
     *       46        46  
     *       46        76  
     *       46        58  
     *       46        46  
     *       46        80  
     *       46        46  
     *       46        46  
     *       46        46  
     *       48        46  
     *       46        46  
     *       48        46  
     *       46        46  
     *       48        46  
     *       46        46  
     *       48        46  
     *       46        46  
     *       48        46  
     *       50        50  
     *       44        58  
     *       46        76  
     *       46        76  
     *       46        84  
     *       46        46  
     * min1 = 44, min2 = 46, skew = -2  
     *   
     * The numbers might vary from 40 to 350.  The larger your bus multiplier,  
     * the larger the numbers.  400 MHz systems with 66 MHz buses will produce  
     * large numbers.  
     */  
    #include <stdio.h>  
    #include <sched.h> /* linux/shed.h on libc5 */  
    #ifndef __OPTIMIZE__  
    #error Please compile with optimization on.  
    #endif  
      
    /*  
     * These are defined at the end of the file to make sure they  
     * don't get inlined.  
     */  
    static unsigned send(void);  
    static unsigned receive(void);  
    #define NSAMPLES 25  
      
    unsigned master_send[NSAMPLES], master_receive[NSAMPLES];  
    unsigned slave_send[NSAMPLES], slave_receive[NSAMPLES];  
      
    /* The master sends first. */  
    static int  
    master(void *arg)  
    {  
     int i;  
     (void)arg;  
      
     for (i = 0; i < NSAMPLES; i++) {  
      master_send[i] = send();  
      master_receive[i] = receive();  
     }  
     /* Wait for slave to store last datum */  
     while (!receive_ready)  
      ;  
     return 0;  
    }  
    /* The slave recived first */  
    static int  
    slave(void *arg)  
    {  
     int i;  
     (void)arg;  
      
     for (i = 0; i < NSAMPLES; i++) {  
      slave_receive[i] = receive();  
      slave_send[i] = send();  
     }  
     /* Tell master we're done */  
     receive_ready = 1;  
     _exit();  
    }  
    int  
    main(void)  
    {  
     int i;  
     unsigned min1, min2, delta;  
     int delta1[NSAMPLES], delta2[NSAMPLES];  
     /* Stack for second process */  
     static char child_stack[100000];  
    #define CLONE_ALL (CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_PID)  
     /*  
      * We want master and slave running simultaneously, each on a  
      * different processor.  Unfortunately, user space offers no  
      * guarantees, but on an idle machine, it should work.  
      */  
     clone(slave, child_stack + sizeof(child_stack), CLONE_ALL, 0);  
     master(0);  
     for (i = 0; i < NSAMPLES; i++) {  
      delta1[i] = min1 = slave_receive[i] - master_send[i];  
      delta2[i] = min2 = master_receive[i] - slave_send[i];  
      printf("%9d %9d\n", min1, min2);  
     }  
     for (i = 1; i < NAMPLES-1; i++) {  
      if (min1 > delta1[i])  
       min1 = delta1[i];  
      if (min2 > delta2[i])  
       min2 = delta2[i];  
     }  
     printf("V2: min1 = %u, min2 = %u, diff = %d\n",  
      min1, min2, (int)min1 - (int)min2);  
     return 0;  
    }  
    /*  
     * Variables for interprocessor communications.   
     * Padded to make sure thre is no cache line interference.  
     */  
    static volatile int pad0[16];  
    static volatile int receive_ready;  
    static volatile int pad1[15];  
    static volatile int signal_sent;  
    static volatile int pad2[15];  
    #define rdtsc(hi,lo) asm volatile("rdtsc" : "=a" (lo), "=d" (hi))  
      
    /* Send a signal, returning the TSC just before it is sent. */  
    static unsigned  
    send(void)  
    {  
     unsigned hi, lo;  
     /* Send to slave */  
     signal_sent = 0;  
     while (!receive_ready)  
      ;  
     rdtsc(hi,lo); /* Waste time */  
     receive_ready = 0;  
     rdtsc(hi,lo);  
     signal_sent = 1;  
     return lo;  
    }  
    /* Receive a signal, returning the TSC just after it is received. */  
    static unsigned  
    receive(void)  
    {  
     unsigned hi, lo;  
     while (signal_sent)  
      ;  
     receive_ready = 1;  
     while (!signal_sent)  
      ;  
     rdtsc(hi,lo);  
     return lo;  
    }  
      
    On Thursday, 03 December 1998 at 08:43, Helge Hafting wrote:  
    >   
    > Roeland Th. Jans wrote:  
    > > On Wed, Dec 02, 1998 at 03:25:24PM -0000, Simon Kenyon wrote:  
    > > > On 02-Dec-98 Alex Buell wrote:  
    > > > > What is the first thing that ceases when you spin down a planet? That's  
    > > > > right, gravity. Everything not tied down would just fly out into space,  
    > > > > and that includes the atmosphere. Simple.   
    > > >   
    > > > i don't see a smiley, but i have to assume that that was a little joke! right?  
    > >   
    > > well, the problem is that... it's true. so don't use ower management on the  
    > > earth spin...  
    >   
    > Where do people get such crazy ideas?  
    > Earth's gravity has nothing to do with spin, but mass.  The mass creates  
    > the gravity.  The spin creates a centrifugal force that's opposed  
    > to gravity, it weakens the effect of gravity slightly.  
    >   
    > Stopping the spin wouldn't mess up gravity at all.  There would  
    > be other unpleasant effects like making a day half a year long,  
    > turning one side of the planet into desert and freezing the other.  
      
    Really? I thought if spin were stopped then days would be eternal on one side of the planet  
    and nights on the other... I guess it depends on whether your frame of reference is the   
    Sun or some grid arbitrarily laid out on the solar system.  
    - --   
    Brendan Cully  
    brendan@kublai.com  
    `cat ~/.signature`  
      
    Hello,  
      
    > I'd suggest, changing the late 2.1.1xx kernels NOW to support up to 2GB as  
    > default. It won't break anything, most probably, but if it will, it's better  
    > done now, too.  
    >   
    > This will not only save bad press for Linux but also a large number of  
    > postings to this list.   
    >   
    > It's trivial, actually.  
      
       No, it isn't. There are lots of people who use 3GB of address space per  
    process on machines with just a few dozen megabytes of RAM.  
      
        Have a nice fortnight  
    - --   
    Martin `MJ' Mares   <mj@ucw.cz>   http://atrey.karlin.mff.cuni.cz/~mj/  
    Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth  
    "System going down at 1:45 for disk crashing."  
      
    It apparently was a bug concerning use of the Ultra2Wide controller. I  
    received a forwarded reply from Doug Ledford and added two lines of code to  
    the driver source that fixed it.  
      
    Timm Gleason  
      
    On Mon, 23 Nov 1998, Neil Conway wrote:  
      
    > Doug Ledford wrote:  
    > >  
    > > That will be fixed in 5.1.5 (a bug introduced by myself accidentally  
    while  
    > > dealing with YANSF (Yet Another New Seeprom Format)).  
    >  
    > I don't suppose it's a quickneasy fix ?  I'm about to bring a production  
    > machine back on-line this evening for a (hopefully) multi-week run and  
    > it'd be nice to get the interface back up to speed, as I'll probably not  
    > get another chance for many weeks...  If it's only a two-liner I could  
    > just patch the kernel.  
    >  
    > sorry to hassle you - the driver is great in all other ways.  
      
    It is quick and easy.  Around line 8352 make the code look like:  
      
        if (p->flags & AHC_NEWEEPROM_FMT)  
        {  
          if (sc->device_flags[i] & CFSYNCHISULTRA)  
          {  
            p->ultraenb |= mask;  
          }  
          else if (sc->device_flags[i] & CFNEWULTRAFORMAT)  
          {  
            if ( ((sc->device_flags[i] & (CFSYNCHISULTRA | CFXFER)) == 0x03)  
    &&  
                 !(p->features & AHC_ULTRA2) )  
            {  
              sc->device_flags[i] &= ~CFXFER;  
              sc->device_flags[i] |= CFSYNCHISULTRA;  
              p->ultraenb |= mask;  
            }  
          }  
        }  
      
      Doug Ledford   <dledford@redhat.com>  
       Opinions expressed are my own, but  
          they should be everybody's.  
      
    > -----Original Message-----  
    > From: Gregory T. Norris [mailto:haphazard@socketis.net]  
    > Sent: Friday, December 04, 1998 12:32 PM  
    > To: Timm Gleason  
    > Cc: linux-kernel  
    > Subject: Re: aic7xxx Driver support faster than 20MB/sec?  
    >  
    >  
    > I'm getting 40MB/sec under version 5.1.4, with a 2940UW and Seagate  
    > ST34501W drives.  
    >  
    > On Thu, Dec 03, 1998 at 04:42:25PM -0800, Timm Gleason wrote:  
    > > Does anyone know if the current version of the aic7xxx  
    > driver(5.1.4) support  
    > > faster than 20MB/sec maximum transfer rate? I compiled a 2.0.36  
    > kernel using  
    > > the pre13 patch and the patch text had references in it to the aic7xxx  
    > > driver being 5.0.20. This kernel did support the higher rates.  
    > However, I  
    > > find that the kernel we compiled using the final release of  
    > 2.0.36 contains  
    > > aic7xxx driver 5.1.4 and does not seem to accept negotiation higher than  
    > > 20MB/sec. Yes, I have checked the SCSI BIOS for the controller  
    > and all ID's  
    > > are set to 80MB/sec rate.  
    >  
      
    >   
    > On Thu, 3 Dec 1998 doctor@fruitbat.org wrote:  
    >   
    > > Did you enable the SMP option?  
    > >   
    > > > make config  
    > > > make dep  
    > > > make bzImage  
    > > > make install  
    > > >   
    > > > Then I rebooted. When it starts, it goes to 40 column mode and  
    > > > says "NO ROM BASIC"  
    > >   
    > > Pardon me, but it sounds like you just booted an Atari 400 (or maybe a  
    > > VIC 20, or possibly a Commodore PET ;-).  
    > >   
    > > Seriously, this almost sounds like a virus has infected your boot block.  
    > > Can you boot off of floppy?  Are you using LILO?  Do you have more than  
    > > one OS on your system?  
    >   
    > I once saw this on my old 386 based linux system.. when the boot record  
    > became corrupt.. it wasnt a virus, for some reason the BIOS just wouldnt  
    > let the hdd boot, also could be related to incorrect drive geometry inthe  
    > BIOS (heads, cylinders, sectors etc)  
    >   
    > havent seen the error for a while but its probably part of the newer  
    > BIOS's too (probably some legacy code) :)  
    >   
    >  
      
    As far as I know, when int 19h is invoked it enters ROM BIOS if it is present.  
    This is true with old 386 BIOSes, I did not experiment with newer ones.  
      
    Seems like some how this interrupt is being invoked.  
      
    Regards  
    Ravi   
      
    End of linux-kernel-digest V1 #2945  
    ***********************************  
    To subscribe to linux-kernel-digest, send the command:  
      
     subscribe linux-kernel-digest  
      
    in the body of a message to "Majordomo@vger.rutgers.edu".  If you want  
    to subscribe something other than the account the mail is coming from,  
    such as a local redistribution list, then append that address to the  
    "subscribe" command; for example, to subscribe "local-linux-kernel":  
      
     subscribe linux-kernel-digest local-linux-kernel@your.domain.net  
      
    A non-digest (direct mail) version of this list is also available; to  
    subscribe to that instead, replace all instances of "linux-kernel-digest"  
    in the commands above with "linux-kernel".  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   !  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   !  
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   !  
      
    -  
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in  
    the body of a message to majordomo@vger.rutgers.edu  
      
  
---