lkml.org 
[lkml]   [1998]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
From
SubjectRe:linux-kernel-digest V1 #2943
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 13:57 >>>


linux-kernel-digest Saturday, 5 December 1998 Volume 01 : Number 2943

In this issue:

Re: cua* on kernel 2.1 and beyond
Re: IDE disk geometry + patch
Re: Problem with 1G RAM
Re: IDE freeze for seconds
Re: Patch to loop device (loop.c)
Re: Y2k compliance
Re: [BUG] arp replies with BOOTP [more info]
Re: win chip???
Re: Limit of 256 NFS Mounted Filesystems
Re: IDE freeze for seconds
AXP user's gripe about v2.[1-2] messages.
mediumraw keyboard mode?
Re: Internationalizing Linux
Re: Looking for SMP-capable tester
Re: Problem with 1G RAM
[PATCH] Compilation errors in netsyms.c
Re: patch to drivers/char/serial.c to fix kernel lock-up
Re: Network block device... some questions
Re: kernel-2.1.126 booting problem
Re: your mail
Re: NO ROM BASIC
Linux 2.1.131ac3
Re: Bugfix for drivers/scsi/sd.c
keyboard.h
Re: Machine Dead on 2.1.131
Re: NO ROM BASIC
Re: LM sensors in kernel --- why not?
Re: Dumb question: Which is "better" SCSI or IDE disks?
Re: Dead Machine & 2.1.131
Re: Patch to loop device (loop.c)
Re: SWAP: Linux far behind Solaris or I missed something (fwd)
Re: NO ROM BASIC
Re: Dumb question: Which is "better" SCSI or IDE disks?
RE: Linux 2.1.131ac2 is up
Re: IDE disk geometry + patch
Noisy hard drives
Re: LM sensors in kernel --- why not?
Re: Modular SysV IPC, testers wanted [patch]
Re: Patch to loop device (loop.c)
Re: NTFS partitions show up as OS/2 partitions.
Re: Internationalizing Linux

See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.

----------------------------------------------------------------------

From: Vern Hoxie <vern@zebra.alphacdc.com>
Date: Fri, 4 Dec 1998 08:13:25 -0700
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

- --
Vernon C. Hoxie vern@zebra.alphacdc.com
3975 W. 29th Ave. uucp: 303-455-2670
Denver, Colo., 80212 voice: 303-477-1780
Nothing but the heart can change the heart.

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Mark Lord <mlord@pobox.com>
Date: Fri, 04 Dec 1998 15:13:44 +0000
Subject: Re: IDE disk geometry + patch

Andries.Brouwer@cwi.nl wrote:
>
> The sooner this is corrected, the better.

Go for it.
- --
mlord@pobox.com

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Jamie Lokier <lkd@tantalophile.demon.co.uk>
Date: Fri, 4 Dec 1998 15:24:26 +0000
Subject: Re: Problem with 1G RAM

On Thu, Dec 03, 1998 at 01:19:03PM +0100, Rik van Riel wrote:
> With the standard Linux kernel, you can only use 1G-64M
> since the system uses a bit of 'extra' address space for
> administration.

As a matter of stability, the kernel should be modified to ignore any
extra memory it can't handle.

Right now, it will simply go horribly wrong with 1G RAM and default
options, am I right?

It'd be nice if someone would fix the memory map setup so the system at
least works!

- -- Jamie

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Mark Lord <mlord@pobox.com>
Date: Fri, 04 Dec 1998 15:20:28 +0000
Subject: Re: IDE freeze for seconds

Johnny Teveßen wrote:
>
> Quoting Pavel Machek (pavel@atrey.karlin.mff.cuni.cz):
>
> > Get bdflush-1.6 from sunsite, there's way to postpone writes until
> > disk is spinned up again. I believe this is what you want.
>
> That's interesting. I was told that there's no way to find out whether
> an IDE drive is spinning or not. At least not without spinning it up.

There is no guaranteed way, but most newer drives
should now support "hdparm -C"
- --
mlord@pobox.com

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Andi Kleen <ak@muc.de>
Date: Fri, 4 Dec 1998 16:25:21 +0100
Subject: Re: Patch to loop device (loop.c)

In muc.lists.linux-kernel, you wrote:
>On Thu, Dec 03, 1998 at 05:24:12PM +0100, Andi Kleen wrote:
>
>> >First of all, I found out that the "create_missing_block" function
>> >doesn't seem to work, at least it didn't work on my system.
>> >(If you tried to create a file system with 1024 blocks (1meg) on
>> > a file which was only 1 Byte long it didn't work...)
>>
>> That is because it is not supposed to extend the file length, but
>> to fill in holes in the file (unallocated blocks in the middle of a
>> file)
>>
>> I don't think the loop device should try to extend the file, a block
>> device with varying length does not look like a good idea for me.
>
>Ahh, so I misunderstood the comment, because I didn't know that
>this would be possible (that a backing file containged blocks
>which are not mapped to the block device). Just out of interest,
>how can such a situation happen ?
>
>(Do you open a file and then write to position 100000 for example? )

Yes.

fd = creat(file, mode);
lseek(fd, 100000, SEEK_SET);
write(fd, "x", 1);
close(fd);

now you have a file with a hole. For some databases that use the file offset
as hash key it is very useful. When the kernel sees a hole it simply returns
zeros.

- -Andi

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: robbie@scot-mur.demon.co.uk
Date: Fri, 4 Dec 1998 15:47:07 +0000
Subject: Re: Y2k compliance

I think there is another exeption for years divisible by 400, so 2000 is
a leap year. try

cal 2 1900
cal 2 2000

I guess cal could be wrong, but I doubt it.

Regards

Rob

On Fri, Dec 04, 1998 at 09:12:47AM -0600, S. Shore wrote:
> In fact, the year 2000 isn't a leap year. A little-known rule of leapyears
> (iirc) is that any year divisible by 100 (i think) can't be a leapyear.
>
> Scott.
>
> On Fri, 4 Dec 1998 robbie@scot-mur.demon.co.uk wrote:
>
> > Date: Fri, 4 Dec 1998 01:03:30 +0000
> > From: robbie@scot-mur.demon.co.uk
> > To: Linux Kernel List <linux-kernel@vger.rutgers.edu>
> > Subject: Re: Y2k compliance
> >
> > On Thu, Dec 03, 1998 at 10:30:44AM -0500, Gregory Maxwell wrote:
> > > On Thu, 3 Dec 1998, Chris Wedgwood wrote:
> > >
> > > > On Wed, Dec 02, 1998 at 11:53:57AM +1030, Alan Modra wrote:
> > > >
> > > > > Linux ignores the RTC century byte (for good reason). Before I put
> > > > > this fix in, when the year wrapped to 00 Linux would read the RTC
> > > > > year as 1900. So a reboot (who does that anyway?) would give a
> > > > > classic Y2K time warp.
> > > >
> > > > So how does it know what century it is?
> > >
> > > If the right part of the year is less then z it's 20xx if it's greater
> > > it's 19xx
> > So how does it cope with 2000 being a leep year? In the small ammount of
> > experimenting I have done, the year goes back to 1980, not 1900. I think
> > linux needs some way of dealing with these buggy machines, probably in
> > user space.
> > >
> > >
> > > -
> > > 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/
> >
> > --
> >
> > Robbie Murray
> >
> > -
> > 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/
> >
>

- --

Robbie Murray

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Martin Mares <mj@ucw.cz>
Date: Fri, 4 Dec 1998 16:52:33 +0100
Subject: Re: [BUG] arp replies with BOOTP [more info]

Hello,

> A quick test showed that this problem does not occur on 2.0.X kernels.
> I'm not sure where exactly within 2.1.X history it appeared.

I already know what's happening there, but it isn't easy to find
a clean solution... Expect patch within few days.

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
"To be or not to be? It's simple: $2b or (not $2b) = $ff"

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "Henning P. Schmiedehausen" <hps@tanstaafl.de>
Date: 4 Dec 1998 16:56:58 +0100
Subject: Re: win chip???

hpa@transmeta.com (H. Peter Anvin) writes:

>Anyone working on RockWell or Lucent support? I have a laptop with a

I tried calling Lucent Germany but they have the most sucking
telephone recipist that I ever had the misfortune to deal with. I gave
up after she put me on hold for the fourth time in a row without even
asking why I called. Maybe she was just busy talking gossip with her
SO or something. I wonder whether Lucent knows what kind of idiots
they employ.

>Lucent-based internal LoseModem[TM]... maybe I should give it a shot.

Acer Notebook by accident? ;-) I have a 710TE which is a wonderful
machine besides of the integrated WinModem (which seems to be some
sort of soft-WinModem).

Kind regards
Henning

- --
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- hps@tanstaafl.de
TANSTAAFL! Consulting - Unix, Internet, Security

Hutweide 15 Fon.: 09131 / 50654-0 "There ain't no such
D-91054 Buckenhof Fax.: 09131 / 50654-20 thing as a free Linux"

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Richard Kaszeta <kaszeta@me.umn.edu>
Date: Fri, 4 Dec 1998 10:07:55 -0600 (CST)
Subject: Re: Limit of 256 NFS Mounted Filesystems

Michel LESPINASSE writes ("Re: Limit of 64 Mounted Filesystems"):
>I also had this problem because I am mounting a lot of clearcase views at
>my job - I can hardly work with less than 30 mounted filesystems, and the
>64 limit is easy to reach.
>
>You can change your NR_SUPER in include/linux/fs.h .... I upped it to 256
>and am running without problems with a 2.0.36 kernel

Unfortunately, I've discovered that 256 is as high as one can reasonly
put this limit, even with the 2.1.x kernel, as each nfs (or other
'nodev' type of mount) requires a device of major number 0 and a
different minor number, so there can only be 255 nodev filesystems at
any given time.

Thus, my automounter map with more than 1000 entries for user home
directories will break the linux machines which I am attempting to use
a web servers and samba servers, because in practice they have been
hitting this 256 limit rather frequently. I certainly couldn't use
linux for my mail server.

Anyone have ideas for workarounds? I have a *huge* amount of storage
here for each user, which is why I starting using autofs to start
with---it was the only efficient way of serving home directories
(which are spread over a couple dozen servers and devices anyways, so
most alternative schemes still would run into some of these limits).

IMHO, this is a serious limitation, since for my environment (and for
quite a few other locations I know of with many users) this means my
plans of replacing some of my solaris boxes with linux boxes.

We need to fix this if we are to claim that linux is a serious
candidate for server use.

- --
Richard W Kaszeta Graduate Student/Sysadmin
bofh@me.umn.edu University of MN, ME Dept
http://www.menet.umn.edu/~kaszeta

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: =?iso-8859-1?Q?Johnny_Teve=DFen?= <j.tevessen@gmx.net>
Date: Fri, 4 Dec 1998 17:17:13 +0100
Subject: Re: IDE freeze for seconds

Quoting Mark Lord (mlord@pobox.com):

> There is no guaranteed way, but most newer drives
> should now support "hdparm -C"

Good hint, thanks. Three of my four drives seem to support this.

johnny
- --
Trust no-one.

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: "Barrett G. Lyon" <blyon@netpr.com>
Date: Fri, 04 Dec 1998 10:05:55 -0600
Subject: AXP user's gripe about v2.[1-2] messages.

This is a bit off topic, but I have a small gripe, and I am not sure if it
is an AXP specific gripe or not.

On 2.1.131 I notice in dmesg a repetitive message as of:

myprogram: Exception at [<fffffc0000316948>] (fffffc000031694c)

Many times over. The problem is that 'myprogram' is not a single process,
but there are about 200 of the same processes running all compiled by
different users, yet using the same name. How is one to know what process
is actually causing this exception? It would be optimum if it displayed a
PID, or some way to track down the exact process.

Anyway that is just my gripe ;)

- -Barrett



- --
Barrett G. Lyon PGP: www.netpr.com/pgpkeys
Data & Network Security Consultant Fax: 310-737-0196
Network Presence, LLC Email: blyon@netpr.com
- --

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Frank da Cruz <fdc@watsun.cc.columbia.edu>
Date: Fri, 4 Dec 1998 11:17:41 -0500 (EST)
Subject: mediumraw keyboard mode?

In the quest to win the hearts and minds of the PC-using public, Linux
and other forms of UNIX suffer from certain limitations that tend to put
people off right away. One of the most obvious is that keys often don't
do what their labels say they do. This is because applications don't
have a reasonable form of access to the keyboard.

Let us consider only the case where the user is using the actual keyboard
of the PC, and not coming into the PC via Telnet, rlogin, getty, etc.

The normal level of reading keystrokes is read(0,&c,1), but this does not
let us see the F-keys, arrow keys, editing keys, etc, nor distinguish the
numeric keypad digits from the top-rank digits. (Well, it lets us "see"
these keys, but only through the keymap, in which a single key press might
emit in a string of several characters.) The point is, the application
has no way of knowing the user pressed (say) the F7 key, Alt-x, Shift-Insert,
Ctrl-Page-Up, etc.

I understand it is possible to put the keyboard in "raw" mode and sense
key up/down events and scan codes, but I think this interface is way too
difficult (and dangerous) to expect the average application developer to
cope with. Plus it doesn't work on xterms.

What is needed is an API to read keycodes, similar to read(), but which
returns a unique code for each key and key combination, and does so both
for the console and xterms, and yet returns a sensible error when attempted
from a remote terminal.

I heard a rumor that such a "mediumraw" API exists but is not documented.
If so, I'd like to find out about it and use it to add a "friendlier"
and more intuitive user interface to the Linux version of C-Kermit, and,
in the process, maybe write the needed documentation.

Can somebody tell me where to start looking?

Thanks!

Frank da Cruz
The Kermit Project
Columbia University

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Bruce Korb <korb@datadesign.com>
Date: Fri, 04 Dec 1998 08:22:49 -0800
Subject: Re: Internationalizing Linux

Jes Sorensen wrote:
> Oh and everybody should have a 2000 page translation table on paper?

Well, actually, if I ever get my proposal completed, then
the system events are stored as data without formatting strings
at all. The console display program does the formatting.
Your console display program will, presumably, contain the
format strings of your favorite language. See? Simple. ;-)
Panics, excepted, of course. I must keep saying that.

> Drago> I think having messages appear in the sysadmin's native
> Drago> language has merit. The front line for Linux support is moving
> Drago> 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.

Or administer them. I think one of the goals is to have Linux
ultimately be "everyman's" desktop os. Or, of being capable of
being such. For it to ever be so, the system messages about the
status of hardware and software need to be in native tongue so
the user can talk intelligently to the administrator without
requiring the services of a translator. I think, anyway.

> Drago> Once messages permeate back to this list, they can be converted
> Drago> back to English just as the original message was converted
> Drago> 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.

No. But if a tarball of the syslog came back and your console display
program could format it in English, would that be better?
The encoded tarball would be far smaller than the text, anyway.

Besides all that, the strings get removed from the kernel,
making it smaller and more suited to embedded applications :)

- --
Bruce Korb | Data Design Systems, Inc.
Korb at DataDesign dot com | 45 Cabot Dr., Suite 110
Voice: 408-260-0280 | Santa Clara, CA 95051
Fax: 408-260-0281 | USA

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Colin Plumb <colin@nyx.net>
Date: Fri, 4 Dec 1998 09:37:41 -0700 (MST)
Subject: Re: Looking for SMP-capable tester

Thanks, folks! I've already got a pile of replies!
I'm getting on towards enough, but if you're curious
about your machine, here's a bug-fixed version that
actually computes the skew properly.

Two things of note:
- - If you see a skew greater than 10, I'd be interested in
lots of details about your system, including particularly
the BIOS. (AMI, Phoenix, Award, ...) Running it
repeatedly, does the skew ever reverse?
- - If the numbers in columns printed aren't nearly identical,
are you sure your machine is entirely idle? Do you have any
network interfaces running in promiscuous mode competing for
memory bandwidth?

I've got a lot of "good" figures (lots of identical numbers), and
a few "bad" ones (lots of noise). I'm curious what makes the
numbers noisy.

Again, thanks for everyone's help. Run the following harmless
little thing on an SMP system to measure the TSC difference
between two processors.
- --
-Colin


#include <stdio.h>

#include <sched.h>

static volatile int receive_ready;
static volatile int pad1[15];
static volatile int signal_sent;
static volatile int pad2[15];

static char child_stack[100000];

#define NSAMPLES 25

unsigned master_send[NSAMPLES], master_receive[NSAMPLES];
unsigned slave_send[NSAMPLES], slave_receive[NSAMPLES];

#define rdtsc(hi,lo) asm volatile("rdtsc" : "=a" (lo), "=d" (hi))

static int
master(void *arg)
{
unsigned hi, lo;
int i;

(void)arg;

for (i = 0; i < NSAMPLES; i++) {
/* Send to slave */
signal_sent = 0;
while (!receive_ready)
;
rdtsc(hi,lo); /* Waste time */
receive_ready = 0;
rdtsc(hi,lo);
signal_sent = 1;
master_send[i] = lo;

/* Receive from slave */
while (signal_sent)
;
receive_ready = 1;
while (!signal_sent)
;
rdtsc(hi,lo);
master_receive[i] = lo;
}

/* Wait for slave to store last datum */
while (!receive_ready)
;

return 0;
}


static int
slave(void *arg)
{
unsigned hi, lo;
int i;

(void)arg;

for (i = 0; i < NSAMPLES; i++) {
/* Receive from master */
while (signal_sent)
;
receive_ready = 1;
while (!signal_sent)
;
rdtsc(hi,lo);
slave_receive[i] = lo;

/* Send to master */
signal_sent = 0;
while (!receive_ready)
;
rdtsc(hi,lo); /* Waste time */
receive_ready = 0;
rdtsc(hi,lo);
signal_sent = 1;
slave_send[i] = lo;
}

/* Tell master we're done */
receive_ready = 1;
_exit();
}

int
main(void)
{
int i;
int min1, min2, delta;
#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);

min1 = min2 = 0x7fffffff;
for (i = 1; i < NSAMPLES; i++) {
delta = slave_receive[i] - master_send[i];
if (min1 > delta)
min1 = delta;
printf("%9d ", delta);
delta = master_receive[i] - slave_send[i];
if (min2 > delta)
min2 = delta;
printf("%9d\n", delta);
}
printf("min1 = %d, min2 = %d, skew = %d\n", min1, min2, min1 - min2);

return 0;
}

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Perry Harrington <pedward@sun4.apsoft.com>
Date: Fri, 4 Dec 1998 11:25:49 -0800 (PST)
Subject: Re: Problem with 1G RAM

Perusing setup.c in the i386 directory yields:

#define MAXMEM ((unsigned long)(-PAGE_OFFSET-VMALLOC_RESERVE))

if (memory_end > MAXMEM)
memory_end = MAXMEM;

If this doesn't truncate the mem=XXXM command supplied maximum, then I'm
at a loss.

- --Perry

>
> 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.
>
> This seems to have bitten quite a few people, and we *do* want to help
> people who run Linux on big machines, don't we? They don't always get a
> second chance to explain to their bosses why the machine won't boot...
>
> Neil
>
> -
> 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/
>


- --
Perry Harrington Linux rules all OSes. APSoft ()
email: perry@apsoft.com Think Blue. /\

Please read the FAQ at http://www.tux.org/lkml/

------------------------------

From: Arjan van de Ven <arjan@stack.nl>
Date: Fri, 4 Dec 1998 20:28:47 +0100 (CET)
Subject: [PATCH] Compilation errors in netsyms.c

Kernel Compilation Project bugreport + fix
- -------------------------------------------
Kernel : 2.1.131-ac2
Architecture : i386/gcc
Affected files : net/netsyms.c

Description of the problem
- --------------------------
If ATALK is the only selected network-protocol, things will not compile
(netsyms.c aborts the compile because of incorrect include-files). Also,
arp_find, arp_rcv, arp_tbl, ip_rcv are for TCP/IP only!


Proposed solution
- -----------------

diff -r -u linux/net/netsyms.c /usr/src/linux/net/netsyms.c
- --- linux/net/netsyms.c Fri Dec 4 20:18:22 1998
+++ /usr/src/linux/net/netsyms.c Fri Dec 4 20:14:03 1998
@@ -16,6 +16,11 @@
#include <linux/ioport.h>
#include <net/neighbour.h>
#include <net/snmp.h>
+#include <net/sock.h>
+#include <net/dst.h>
+#include <net/checksum.h>
+#include <net/pkt_sched.h>
+#include <linux/etherdevice.h>

#ifdef CONFIG_BRIDGE
#include <net/br.h>
@@ -439,13 +444,15 @@
EXPORT_SYMBOL(dev_mc_add);
EXPORT_SYMBOL(dev_mc_delete);
EXPORT_SYMBOL(dev_mc_upload);
- -EXPORT_SYMBOL(arp_find);
EXPORT_SYMBOL(n_tty_ioctl);
EXPORT_SYMBOL(tty_register_ldisc);
EXPORT_SYMBOL(kill_fasync);
+#ifdef CONFIG_INET
EXPORT_SYMBOL(ip_rcv);
EXPORT_SYMBOL(arp_rcv);
EXPORT_SYMBOL(arp_tbl);
+EXPORT_SYMBOL(arp_find);
+#endif

EXPORT_SYMBOL(if_port_text);


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Theodore Y. Ts'o" <tytso@mit.edu>
Date: Fri, 4 Dec 1998 16:02:21 -0500
Subject: Re: patch to drivers/char/serial.c to fix kernel lock-up

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: Pavel Machek <pavel@bug.ucw.cz>
Date: Fri, 4 Dec 1998 22:05:49 +0100
Subject: Re: Network block device... some questions

Hi!

> Furtheron we intended to use Your NBD to create a distributed Raid 5
> system over several cluster nodes (a crazy idea but why not
> using the clusternodes also for a "distributed, reliable, high
> perfomance and fault tolerant" filesystem. (by the way saving the
> investments for
> expensive Raid-Hardware).
> OK, this idea based on a discussion in the Linux-Raid newsgroup with
> serveral coments sounding like: "it should work"...

Ook, try this patch. With it, I was able to create and run raid5 for a
short while (then it deadlocked - it is bad idea to write to
loopback-mounted device). Please test.
Pavel

PS: See my prev. mails into linux-raid for small oops-fix and why
raidtools need fixing a bit.

- --- clean//drivers/block/nbd.c Fri Sep 11 20:54:23 1998
+++ linux/drivers/block/nbd.c Fri Dec 4 21:22:28 1998
@@ -44,8 +44,9 @@

#define LO_MAGIC 0x68797548

- -static int nbd_blksizes[MAX_NBD] = {1024, 1024,};
- -static int nbd_sizes[MAX_NBD] = {0x7fffffff, 0x7fffffff,};
+static int nbd_blksizes[MAX_NBD];
+static int nbd_sizes[MAX_NBD];
+static int nbd_bytesizes[MAX_NBD];

static struct nbd_device nbd_dev[MAX_NBD];

@@ -382,9 +383,11 @@
if ((arg & 511) || (arg > PAGE_SIZE))
return -EINVAL;
nbd_blksizes[dev] = arg;
+ nbd_sizes[dev] = arg/nbd_blksizes[dev];
return 0;
case NBD_SET_SIZE:
- - nbd_sizes[dev] = arg;
+ nbd_bytesizes[dev] = arg;
+ nbd_sizes[dev] = arg/nbd_blksizes[dev];
return 0;
case NBD_DO_IT:
if (!lo->file)
@@ -400,6 +403,8 @@
dev, (long) lo->head, (long) lo->tail, requests_in, requests_out);
return 0;
#endif
+ case BLKGETSIZE:
+ return put_user(nbd_bytesizes[dev]/512, (long *) arg);
}
return -EINVAL;
}
@@ -472,6 +477,9 @@
nbd_dev[i].file = NULL;
nbd_dev[i].magic = LO_MAGIC;
nbd_dev[i].flags = 0;
+ nbd_blksizes[i] = 1024;
+ nbd_bytesizes[i] = 0x7fffffff;
+ nbd_sizes[i] = nbd_bytesizes[i]/nbd_blksizes[i];
}
return 0;
}


- --
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Pavel Machek <pavel@bug.ucw.cz>
Date: Fri, 4 Dec 1998 22:10:25 +0100
Subject: Re: kernel-2.1.126 booting problem

Hi!

> I need to use the kernel which allow
> to use "big sawp" (above 1GB) and "big RAM" (greater 512MB)
> but I cannot it working under Debian2.0, Pentium II.

Go for 2.1.131, 512 M ram should not be problem, still you might want
to try with mem=64M.

Pavel
- --
I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel
Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-).

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Kurt Garloff <garloff@kg1.ping.de>
Date: Fri, 4 Dec 1998 21:23:56 +0100
Subject: Re: your mail

On Thu, Dec 03, 1998 at 08:00:11PM -0800, Tim Thompson wrote:
> but i need to be able to eather call an
> 'int 15' or directly call the address in BIOS of the lcd handaler.
> Will the kernel allow a module to do eather? If so anyone got an example
> of this? I'm relitivly new to linux kernel modules.

AFAIK, there's no way to call a routine in your BIOS, if it was designed for
real-mode, which most routines are designed for.
If you think your BIOS routine is PM clean, find out a way to figure out the
address (intvektor 15 in DOS ...). This might include hacking setup.S or
LILO to read the intvektor, before we switch to PM.
Look into APM code or vesafb code how to call such a routine. You don't
expect the machine insn int 15 to work!

BTW: You really mean int 0x15? Wasn't this the int BIOSes used to use for
tapes and now use for joystick access and some extended memory reporting and
copying funcs. You won't be lucky calling it.

- --
Kurt Garloff <K.Garloff@ping.de> (Dortmund, FRG)
PGP key on http://student.physik.uni-dortmund.de/homepages/garloff

>There is something frustrating about the quality and speed of Linux
>development. I.e. the quality is too high and the speed is too high, in
>other words, I can implement this XXXX feature, but I bet someone else
>has already done it and is just about to release his patch to Linus soon...
[From a posting of Tigran Aivazian to linux-kernel, XXXX = disk stat]

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: weirdow <WeiRdoW@dma.be>
Date: Fri, 04 Dec 1998 22:15:41 +0100
Subject: Re: NO ROM BASIC

Ok just my 0.02 euro

I saw this recently on new hard drives which worked perfectly on one
machine but when transfered to another they gave the NO ROM BASIC msg.
sometimes i could fix it by repartitioning the drive on the new machine
and installing everything again other times it just would let me
partition the drive install dos from disk and try to boot -> NO ROM
BASIC .. this is/was really frustrating. maybe some freak combination of
drive/host adapter.

Other thing that might cause this was the following. I forgot to
activate the partition from which it needed to boot. maybe something
screws up the partition table code on some machines..


Hope you'll get it working.

greets

Jim

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Dec 98 22:15 GMT
Subject: Linux 2.1.131ac3

ftp://ftp.linux.org.uk/pub/linux/alan/2.1/...

Changes this time:


Differences between 2.1.131ac2 and 2.1.131ac3

o There is a boot option "noapic" for booting SMP machines that
the IO APIC code doesnt work on. All IRQ's end up on CPU0 ala 2.0
if this is set (Tigran Aivazian)
o COSA bug fix (Yenya)
o IDE drivers in ide-scsi have but one LUN (Dave Woodhouse)
o Multisound updates (Andrew Veliath)
o 8390 deadlock fix (me)
o Updated bttv documentation slightly (me)
o Unixware disk slices (Krzysztof G. Baranowski)
o ARM merge (Russ King)
o Kernel NFSD fixes (assorted)
o Big file handle sets done right (Bill Hawes, Stephen Tweedie)
o Updated DECnet project URL (Steve Whitehouse)
o Fix for MTU problems in the z85230 driver. (me)
o Sound could blow up when fed negative sizes. (Oleg Drokin


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Jirka Hanika" <HANIKA@ksvi.mff.cuni.cz>
Date: Fri, 4 Dec 1998 22:24:30 +0200 (METDST)
Subject: Re: Bugfix for drivers/scsi/sd.c

> The patch fixes:
>
> 1. registration 1 scsi major too much

With 0, 16, 32... disks, yes

> 2. getting stuck with _zero_ scsi disks recognized in case
> of having "12 + n * 16" disks (n = 0 to 7).

Getting stuck with only n * 16 disks recognized in that case. Yes.
Your patch is correct, however, it is a bit too cautious.

> --- linux-2.1.130.orig/drivers/scsi/sd.c Thu Nov 19 01:42:44 1998
> +++ linux-2.1.130/drivers/scsi/sd.c Wed Dec 2 01:03:16 1998
> @@ -1487,7 +1487,7 @@
> sd_template.dev_max = 128;
>
> if(!sd_registered) {
> - for (i=0; i <= sd_template.dev_max / SCSI_DISKS_PER_MAJOR; i++) {
> + for (i=0; i <= ( sd_template.dev_max - 1) / SCSI_DISKS_PER_MAJOR; i++) {
> if (register_blkdev(SD_MAJOR(i),"sd",&sd_fops)) {
> printk("Unable to get major %d for SCSI disk\n", SD_MAJOR(i));
> return 1;
> @@ -1540,8 +1540,12 @@
> sd_gendisks[i].real_devices =
> (void *) (rscsi_disks + i * SCSI_DISKS_PER_MAJOR);
> }
> - LAST_SD_GENDISK.max_nr =
> - sd_template.dev_max % SCSI_DISKS_PER_MAJOR;
> + if ( sd_template.dev_max == 0)
> + LAST_SD_GENDISK.max_nr = 0;

We're talking the sd_init() function which doesn't execute at all
if no disks are detected. Moreover, unless SD_EXTRA_DEVS is set to
zero, dev_max is never zero. This check is not necessary.

> + else if ( sd_template.dev_max % SCSI_DISKS_PER_MAJOR == 0)
> + LAST_SD_GENDISK.max_nr = SCSI_DISKS_PER_MAJOR;
> + else
> + LAST_SD_GENDISK.max_nr = sd_template.dev_max % SCSI_DISKS_PER_MAJOR;
> LAST_SD_GENDISK.next = NULL;
> return 0;
> }

What about optimizing away the if's by

LAST_SD_GENDISK.max_nr =
(sd_template.dev_max - 1) % SCSI_DISKS_PER_MAJOR + 1;

I'm not sure which one is nicer

Jirka


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Paul Barton-Davis <pbd@Op.Net>
Date: Fri, 4 Dec 1998 16:16:07 -0500
Subject: keyboard.h

1) Why does keyboard.h define NR_KEYS to be 128 ? Is it just so that
its the the nearest power of 2 to a likely limit ?

2) Why does keyboard.h stick the macros for K_FIND thru K_PAUSE right
in the middle of those for K_Fnn, thus preventing a nice simple
macro like:

#define K_FNUM(k) KVAL(k)+1

and requires instead:

#define K_FNUM(k) k <= K_F20 ? KVAL(k)+1 : \
k > K_PAUSE(k) ? : KVAL(k)-9 : -1
3) Whats the rationale for the keycodes assigned to various escaped
scancodes (E0_KPENTER etc.) ? I.e why is E0_KPENTER assigned keycode
96, instead of, say, 102 or 83. The comments say:

* The keycodes 1-88,96-111,119 are fairly standard, and
* should probably not be changed - changing might confuse X.
* X also interprets scancode 0x5d (KEY_Begin).

is this the only reason ?

4) Why do the Focus and RC930 keyboards get special treatment,
instead of labelling the scancodes they use generically ?

I have a new Logitech Internet keyboard, with 18 new function keys
that generate various e0-prefixed scancodes. I can get Linux to work
with them using setkeycodes(1), and I hacked X to work with them by
tweaking the XFree-3.3.3 code. But these two sets of keymaps are
nowadays designed to work together, and right now, thats hard to do
because of the wierd and sparse-filling of the e0_keys and high_keys arrays in
pc_keyb.c. X needs to know the special names/values in use
in the kernel (like FOCUS_PF11)

I have already hacked pc_keyb.c to avoid all this, and use generic
names for the scancodes, ie.

change E0_MSLW to SC_E0_5B (scancode: 0xe0 0x5b)
and FOCUS_PF11 to SC_73 (scancode: 0x73)

but I got nervous that there is some rationale for the way things are
being done right now.

My plan is to completely fill all the relevant arrays, increase
NR_KEYS, and thus allow any new keyboard with new keys to work
with X without further kernel/X hacking.

- --p



Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Michael K Vance <mkv102@psu.edu>
Date: Fri, 04 Dec 1998 16:30:48 -0500
Subject: Re: Machine Dead on 2.1.131

Rik van Riel wrote:

> hardware access. You're not using XFree 3.3.3 are you?

I am, in fact. Pre-compiled glibc binaries.

m.

- --
"Up above aliens hover making home movies for the folks back home, of all
these weird creatures who lock up their spirits, drill holes in themselves
and live for their secrets. They're all uptight." -Thom Yorke, Radiohead

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Josh Newton <jnewto4@umbc.edu>
Date: Fri, 4 Dec 1998 13:13:03 -0500 (EST)
Subject: Re: NO ROM BASIC

On Thu, 3 Dec 1998, Konstantyn Prokopenko wrote:

> Hi!
>
> I'm new in Linux and I've got a problem compiling a kernel.
> I have dual PENTIUM II motherboard with 128 Mb memory runing Red Hat
> Linux. I compiled the 2.1.128 Linux kernel using:
>
> 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"

This is evidence of a _really_ serious crash; the last time I saw
this error message was about 6 years ago on a 386 when a DOS program
crashed hard. All I can tell you is to try make config; make dep; make
clean; make zImage. Then install the new kernel by hand (if you're using a
boot loader).
Make sure you do a make clean in there; this may be the result of
a previous incomplete compile.

- -========================================================-
Some people have mood swings; I have an entire playground.
- -========================================================-

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Paul Jakma <paul@clubi.ie>
Date: Fri, 4 Dec 1998 18:15:12 +0000 (GMT)
Subject: Re: LM sensors in kernel --- why not?
On Fri, 4 Dec 1998 robbie@scot-mur.demon.co.uk wrote:

> Hi
>
> Is there any chance of it supporting the via chipset any time soon?
>

They're working on it. This is only needed for SMBus support. So if your
hardware monitor chip can be accessed directly (eg via the ISA bus) and is
supported by lm_sensors, then you can use lm_sensors on a Via board. The
Winbond and (AFAIK) some of the more advanced LM chips support ISA bus
access.

I've been using lm_sensors on my TMC TI5VG+ motherboard, Via MVP3+
chipset, with Winbond monitor chip for months.

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: alan@lxorguk.ukuu.org.uk (Alan Cox)
Date: Fri, 4 Dec 1998 19:16:28 +0000 (GMT)
Subject: Re: Dumb question: Which is "better" SCSI or IDE disks?
> 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: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 16:30:01 +0100 (CET)
Subject: Re: Dead Machine & 2.1.131

On Fri, 4 Dec 1998, Michael K Vance wrote:

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

What exactly is xfstt and what is it doing to your machine?

If we get this info out maybe it'll ring a bell with some folks
who don't know X really well but do know the kernel.

OTOH, if xfstt runs as root and directly accesses I/O ports,
then there isn't much we can do... (a usermode device driver
can generally be considered a Bad Thing, what about MatroxFB
with XF86_fbcon?).

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Alexander Kjeldaas <astor@guardian.no>
Date: Fri, 4 Dec 1998 17:55:08 +0100
Subject: Re: Patch to loop device (loop.c)

On Fri, Dec 04, 1998 at 03:50:47AM +0000, rohloff@informatik.tu-muenchen.de wrote:
> Ahh, so I misunderstood the comment, because I didn't know that
> this would be possible (that a backing file containged blocks
> which are not mapped to the block device). Just out of interest,
> how can such a situation happen ?
>
> (Do you open a file and then write to position 100000 for example? )
>
> so long
>

One nice thing about the patch is that it seems like the loop-device
might be useable over NFS with the patch. This opens up some new
possibilities.

astor

- --
Alexander Kjeldaas, Guardian Networks AS, Trondheim, Norway
http://www.guardian.no/

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Rik van Riel <H.H.vanRiel@phys.uu.nl>
Date: Fri, 4 Dec 1998 16:23:44 +0100 (CET)
Subject: Re: SWAP: Linux far behind Solaris or I missed something (fwd)

On Fri, 4 Dec 1998, Stephen C. Tweedie wrote:
> On Fri, 4 Dec 1998 10:41:15 +0000, Neil Conway
> <nconway.list@ukaea.org.uk> said:
>
> >> (although the 2.1.130+my patch seems to work very well
> >> with extremely high swap throughput)
>
> > Since the poster didn't say otherwise, perhaps this test was performed
> > with buffermem/pagecache.min_percent set to their default values, which
> > IIRC add up to 13% of physical RAM (in fact that's PHYSICAL ram, not 13%
>
> I know. That's why relying on fixed margins to ensure good
> performance is wrong: the system really ought to be self-tuning.
> We may yet get it right for 2.2: there are people working on this.

It appears that 2.1.130 + my little patches only needs the
borrow percentage (otherwise kswapd doesn't have enough
reason to switch from the always-succesful swap_out()),
and that only needs to be set to a high value...
(ie. /not/ the braindead values that went into 2.1.131)

cheers,

Rik -- the flu hits, the flu hits, the flu hits -- MORE
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Nicholas J. Leon" <nicholas@binary9.net>
Date: Fri, 4 Dec 1998 12:10:15 -0500 (EST)
Subject: Re: NO ROM BASIC

On Thu, 3 Dec 1998 doctor@fruitbat.org wrote:

# Seriously, this almost sounds like a virus has infected your boot block.

Do you perchance work for Compaq support? They always claim "its a virus"
if they don't really understand what is happening[1].


<vent>
[1] My friend who had a Compaq called one day when his built-in cdrom
drive stopped responding. Their answer "its a virus. Reinstal Windows". So
he did (?) and it still didn't work. He called them and they said "its a
virus, reinstall." "But I just installed. If there is a virus, it came
from YOUR quick restore disk." "No, no virus there, but you DO have a
virus. My paper in front of me says so."

He took it back and bought a Gateway.

This is one of my major problems with compaq. They apprently have "Its a
virus" on the support help form. If they don't understand what the problem
is they blame it on virii. I cant' wait until Y2k so that all the problems
with Compaq machines can be blamed on THAT.


[ps: if there are any compaq support people reading: burn in hell and die]
</vent>


G'day!

- -- n i c h o l a s j l e o n
/ elegance through simplicity /
/ good fortune through truth / http://mrnick.binary9.net
/ not all questions have answers / mailto:nicholas@binary9.net



Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: menion <menion@mindless.com>
Date: Fri, 04 Dec 1998 17:12:05 +0000
Subject: Re: Dumb question: Which is "better" SCSI or IDE disks?
Russell Leighton wrote:
>
> What are good rules of "thumb" for
> choosing IDE vs SCSI when building
> a Linux system?
>
> Both are fast these days...I always
> thought that IDE==cheap, but loaded
> the CPU, so you didn't want that in
> a server or high performance machine
> that might be busy with other things
> besides waiting for the current disk
> transfer...is that fair? just basically
> wrong?
>
> Thanks in advance!

If you have the money, I would go SCSI. I use an old Seagate Barracuda
2 gig, and a BusLogic 948, and I have a lot better over all performance
on that SCSI disk. (On my home machine). At work, there is no
compirison. I have a IDE + SCSI Linux Box, and 2 SCSI Linux box's. The
100% SCSI have big speed difference. Esp The P-II. =). However, IDe,
SCSI, if you are not doing anything but piddling, or compiling, or
something like that, I would not worry about it. If it is a server, I
say, Go for it. SCSI all the way.

js

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Ken Clark" <ken@gesn.com>
Date: Fri, 4 Dec 1998 11:13:12 -0600
Subject: RE: Linux 2.1.131ac2 is up

> Differences between 2.1.131 and 2.1.131ac2
>
> o AVL tree for programs with large numbers of VMAs (eg netscape/X)
>

Honestly not trying to troll here, but do you have any idea what the 2.2
solution to lots of VMAs is going to be? There was lots of talk about fuzzy
hashes and such a while back, but I haven't heard anything since.

Ken


Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Andries.Brouwer@cwi.nl
Date: Fri, 4 Dec 1998 18:24:47 +0100 (MET)
Subject: Re: IDE disk geometry + patch

From ptb@it.uc3m.es Fri Dec 4 14:43:19 1998

I saw this recently on new fujitsus.
Reported 1023,255,63 after selecting LBA.
Result complete muddle until I realized that _smart IDE disk_
(or somesuch) had been enabled in the bios. Turned it off and all OK.

But LBA has _always_ been the preferred access mode for linux.
Are you saying that it is not? Please explain!

Peter

No. This has nothing to do with disk access.
It only concerns the geometry returned by the
HDIO_GETGEO ioctl (as used by fdisk and LILO).

Note that all these numbers are fake and have
no relation to any hardware parameters.

The rules of the game are:
(i) C*H*S is total disk capacity
(ii) Only change H and S in emergency cases because
it may confuse other operating systems on the same disk:
H and S are used in conversions of LBA addresses to 3D addresses.

The conclusion is that one should always put
C := capacity/(H*S).

Andries


[If you still have these Fujitsus you can check whether
the change I suggested avoids your complete muddle in
all cases, regardless of BIOS settings.]

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Hirsim{ki Mika <mhi@alpha.cc.tut.fi>
Date: Fri, 4 Dec 1998 19:28:11 +0200
Subject: Noisy hard drives
>> [hard disk noise]
> Anyone know of sound proof cases?

I'd like some info on this as well... I've got two
external UW-drives (10000 & 7200 rpm) and earache. ;-)

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Harald Milz <hm@seneca.muc.de>
Date: 4 Dec 1998 16:04:15 GMT
Subject: Re: LM sensors in kernel --- why not?

robbie@scot-mur.demon.co.uk wrote:

> Is there any chance of it supporting the via chipset any time soon?

It is already supported in lm_sensors-1.4.11. 2.0 should be out before
end-98 as I'm told, and the Genesys GL518SM found e.g. on Tyan Trinity boards
may be supported then too. :-))

- --
A recent study has found that concentrating on difficult off-screen
objects, such as the faces of loved ones, causes eye strain in computer
scientists. Researchers into the phenomenon cite the added
concentration needed to "make sense" of such unnatural three
dimensional objects ...

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Lenart Gabor <lgb@hal2000.hal.vein.hu>
Date: Fri, 4 Dec 1998 18:39:38 +0100
Subject: Re: Modular SysV IPC, testers wanted [patch]

On Fri, Dec 04, 1998 at 10:47:11AM +0200, Dragos Acostachioaie wrote:
> It works for me. Applied against 2.1.131, tested with postgresql,
> dosemu and IPC utilities (ipcs, ipcrm). Both as module and monolithic.
> Nice work, you should send it to Linus.

I read that the patch uses a layer to detect IPC usage request or something
similar. In this case it will slow IPC calls, won't it ?

- ---[ LGB/DC ]------------------[ root@hal2000 ]-----------------[ LINUX ]---
"The truth is out there" "We're living together" "The future is dark."
- ---[ 88/422022-4602 ]--[ http://www.hal.vein.hu/~lgb ]------[ 87/477074 ]---
Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: rhp@draper.net
Date: Fri, 4 Dec 1998 11:41:14 -0600
Subject: Re: Patch to loop device (loop.c)

On Fri, Dec 04, 1998 at 03:47:39AM +0000, rohloff@informatik.tu-muenchen.de wrote:
> >
> > In the case of writes, loop.c always receives a complete block by definition.
>
> By which definition ? There is code in the loop device to handle
> partial writes, and the requests are done in sector counts, not
> in block counts. The loop device itself accesses the real (backing) device
> only with complete block reads/writes. But what guarantees that
> the request TO the loop device is aligned to block boundaries.

Ah! (the lightbulb illuminates over my head). Now I understand why you
are concerned with unaligned requests.

My thinking was that the purpose of the loop device is to support
***filesystems*** having special data transformation needs. As observed in
my own testing, filesystems mounted over a loop device request only aligned
sectors/block... hence the selection of block as the unit of CBC crypting.

It makes no conceptual difference whether block level CBC IV's are seeded
with block numbers or sector numbers. Assuming the world concurs, I will
revise my loop transfer API changes introduced in 2.1.130 to pass sector
rather than block.

Btw, carrying this thinking to the next logical level, developing transfer
module logic that CBC crypts individual sectors only to have them aggregated
into fixed filesystem blocks seems like a wasted effort. I wish we could
assume aligned sectors/block requestors in all cases.
>
> >
> > In the case of reads, should the real (backing) request (which plays prior
> > to the loop.c request) fail to return all of the required sectors then
> > end_that_request_first() invokes printk() advising that an error has
> > occurred. Thus loop.c is assured never to see incomplete blocks. Correct?
>
> Yes, the backing device (be it file or block device) is able (and does)
> return complete blocks, but how do you know that the request to
> the loop device asks for complete blocks...
>
<snip>
>
> It is of course possible to handle requests to the loop device, which
> start in the middle of a block gracefully, but it makes things even
> more complicated than they are at the moment. (Because to write
> to the middle of a block you would first need to decrypt the whole block,
> then update the second part of the block, then crypt it again and put
> it back to disk (or the buffer cache)).

Ack!

>
> so long
> Ingo
>

Thank you Ingo for mentoring with me. This type of exchange makes Linux
wonderful environment.

Best Regards,
Reed "Think Unaligned Sectors" Petty <rhp@draper.net>

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: Meelis Roos <mroos@tartu.cyber.ee>
Date: Fri, 4 Dec 1998 19:45:50 +0200
Subject: Re: NTFS partitions show up as OS/2 partitions.

TS> NTFS and HPFS are completely different designs, and I've seen no evidence
TS> they share any code. Do you have a reference for that claim?

NTFS is based on HPFS. I don't know if there's some code left from
original HPFS but they are similar. Do you know how NT converts (at
least used to convert) FAT partitions into NTFS? Simple - first convert
it into HPFS and then modify the HPFS to be NTFS.

- --
Meelis Roos (mroos@tartu.cyber.ee)

Please read the FAQ at http://www.tux.org/lkml/

------------------------------
From: "Adam D. Bradley" <artdodge@cs.bu.edu>
Date: Fri, 4 Dec 1998 12:55:22 -0500 (EST)
Subject: Re: Internationalizing Linux

On Fri, 4 Dec 1998, Drago Goricanec wrote:

> On 03 Dec 1998 16:25:16 +0100, Jes Sorensen writes:
>
> > 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.

This subject has been beaten to death on this list, several times. All of
the kernelspace solutions proposed are bloaty and exceptionally
inefficient to keep consistent. And there is effectively _ZERO_ desire by
the core developers to try to maintain such a beast.

If you really want kernel messages translated, hack dmesg and syslogd to
do the translation. The set of kernel messages is finite, and userspace
translation bloat is much more bearable than kernelspace. If that's just
not good enough and you really really really really really really want all
the printk()'s in your native language, create and maintain your own
patch, just don't expect it to get into the mainstream kernel.

Once the system has booted, the kernel shouldn't normally have much to say
anyway, and if it does, it is much more useful to this list in its present
form. Concentrate on internationalizing userspace (glibc, gnome, etc),
it's much more useful.

Adam
- --
Your lives aren't small, but \\ Adam Davenport Bradley, Grad Student
you're living them in a small \\ Boston University Computer Science
way. Live openly and expansively! \\ artdodge@cs.bu.edu 353-8921/MCS211
II Cor 6:11-13 (The Message) <>< \\ http://www.netwinder.org/~artdodge



Please read the FAQ at http://www.tux.org/lkml/

------------------------------
End of linux-kernel-digest V1 #2943
***********************************
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.057 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site