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.
----------------------------------------------------------------------
From: Junio Hamano <junio@twinsun.com>
Date: 04 Dec 1998 14:08:48 -0800
Subject: Re: /proc and /kern
>>>>> "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..
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: =?ISO-8859-1?Q?C=2E_Jasp=E2h_Spaans?= <spaans@vvtp.tn.tudelft.nl>
Date: Fri, 4 Dec 1998 23:09:41 +0100 (CET)
Subject: Gravis Ultrasound [classic] artefacts partly solved on 2.1.131
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Tymm Twillman <tymm@coe.missouri.edu>
Date: Fri, 4 Dec 1998 16:10:18 -0600
Subject: Re: Internationalizing Linux
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
> Please read the FAQ at http://www.tux.org/lkml/
>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Meelis Roos <mroos@tartu.cyber.ee>
Date: Sat, 5 Dec 1998 00:17:33 +0200
Subject: Re: linux-kernel-digest V1 #2839 (writable /proc/<pid>/cmdli
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)
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: marcel@mesa.nl (Marcel J.E. Mol)
Date: Fri, 4 Dec 1998 23:25:47 +0100 (MET)
Subject: Re: disks stats through /proc
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,
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Gregory T. Norris" <haphazard@socketis.net>
Date: Fri, 4 Dec 1998 14:32:22 -0600
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.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
Date: Fri, 4 Dec 1998 23:41:58 +0100 (CET)
Subject: Re: 960MB limitation for 2.2 ?
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: MOLNAR Ingo <mingo@chiara.csoma.elte.hu>
Date: Fri, 4 Dec 1998 23:38:38 +0100 (CET)
Subject: Re: Problem with 1G RAM
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Truxton Fulton <trux@truxton.com>
Date: Fri, 4 Dec 1998 14:39:40 -0800 (PST)
Subject: Re: patch to drivers/char/serial.c to fix kernel lock-up
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Brendan Kehoe <brendan@cygnus.com>
Date: Fri, 4 Dec 1998 14:44:41 -0800 (PST)
Subject: kernel debugging & x86 emulators
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 read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Andries.Brouwer@cwi.nl
Date: Fri, 4 Dec 1998 23:45:45 +0100 (MET)
Subject: Re: IDE disk geometry + patch
From gmack@imag.net Fri Dec 4 21:09:04 1998
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Perry Harrington <pedward@sun4.apsoft.com>
Date: Fri, 4 Dec 1998 14:58:51 -0800 (PST)
Subject: Re: Problem with 1G RAM
> 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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Brandon S. Allbery KF8NH" <allbery@kf8nh.apk.net>
Date: Fri, 04 Dec 1998 18:14:46 -0500
Subject: Re: NO ROM BASIC
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.
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Paul Jakma <paul@clubi.ie>
Date: Fri, 4 Dec 1998 23:13:45 +0000 (GMT)
Subject: Re: Dead Machine & 2.1.131
On Fri, 4 Dec 1998, Michael K Vance wrote:
> 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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Mark Lord <mlord@pobox.com>
Date: Sat, 05 Dec 1998 00:02:46 +0000
Subject: Re: IDE disk geometry + patch
"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)
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: hpa@transmeta.com (H. Peter Anvin)
Date: 5 Dec 1998 00:37:54 GMT
Subject: Re: kerneli blowfish/twofish compromised?
Followup to: <199811260315.WAA26353@dcl.MIT.EDU>
By author: "Theodore Y. Ts'o" <tytso@mit.edu>
In newsgroup: linux.dev.kernel
>
> From: alan@lxorguk.ukuu.org.uk (Alan Cox)
> Date: Wed, 25 Nov 1998 19:25:08 +0000 (GMT)
>
> > 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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: a sun <asun@saul2.u.washington.edu>
Date: Fri, 4 Dec 1998 16:38:56 -0800 (PST)
Subject: Re: kernel knowledge of localtime (user-level implememntation)
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Mark Lord <mlord@pobox.com>
Date: Sat, 05 Dec 1998 00:29:58 +0000
Subject: Re: Absolutely horrid IDE performance...
Gerard Roudier wrote:
>
> 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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Leonard Zhang System Administrator ISD RVIB <leonardz@rvib2.rvib.org.au>
Date: Sat, 5 Dec 1998 11:35:33 +1000 (AEST)
Subject: Re: Dumb question: Which is "better" SCSI or IDE disks?
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
>
>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "H. J. Lu" <hjl@freya.yggdrasil.com>
Date: Fri, 4 Dec 1998 17:48:27 -0800 (PST)
Subject: Re: NIS/RPC Dead on 2.1.130 Alpha
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)
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: jens@pinguin.conetix.de
Date: Sat, 5 Dec 1998 01:07:04 +0100
Subject: Linux/98?!?
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: jens@pinguin.conetix.de
Date: Sat, 5 Dec 1998 00:02:01 +0100
Subject: Re: Internationalizing Linux
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Terry L Ridder <terrylr@tbcnet.com>
Date: Fri, 04 Dec 1998 21:21:08 -0600
Subject: Re: Y2k compliance
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Chris Chiapusio <chipper@llamas.net>
Date: Fri, 4 Dec 1998 22:28:04 -0500 (EST)
Subject: RE: Y2k compliance
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Raul Miller <rdm@test.legislate.com>
Date: Fri, 4 Dec 1998 22:56:55 -0500
Subject: Harmless? "oops" on MCA, 3c523
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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Tymm Twillman <tymm@coe.missouri.edu>
Date: Fri, 4 Dec 1998 23:14:24 -0600
Subject: Re: cua* on kernel 2.1 and beyond
> 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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Colin Plumb <colin@nyx.net>
Date: Fri, 4 Dec 1998 23:18:32 -0700 (MST)
Subject: CAUGHT IN THE ACT: evidence of clock skew on Intel SMP
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;
}
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Brendan Cully <brendan@kublai.com>
Date: Fri, 4 Dec 1998 20:11:46 -0500
Subject: Re: IDE freeze for seconds
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`
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Martin Mares <mj@atrey.karlin.mff.cuni.cz>
Date: Fri, 4 Dec 1998 23:34:44 +0100
Subject: Re: 960MB limitation for 2.2 ?
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."
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: "Timm Gleason" <timm@n2h2.com>
Date: Fri, 4 Dec 1998 14:50:07 -0800
Subject: RE: aic7xxx Driver support faster than 20MB/sec?
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.
>
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
From: Ravi Terala <rterala@qualcomm.com>
Date: Fri, 4 Dec 1998 16:02:47 -0700 (MST)
Subject: Re: NO ROM BASIC
>
> 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
Please read the FAQ at http://www.tux.org/lkml/
------------------------------
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
Please read the FAQ at http://www.tux.org/lkml/