>From linux-kernel@vger.rutgers.edu Thu Aug 13 12:21:08 0400 1998
Received: from listserv.funet.fi (listserv.funet.fi [128.214.248.27]) by hclhprnd.hclt.com (8.8.5/SCO5) with ESMTP
id RAA18415; Thu, 13 Aug 1998 17:53:17 GMT
Return-Path: <owner-linux-kernel-digest-outgoing@vger.rutgers.edu>
Received: from vger.rutgers.edu ([128.6.190.2]:11787 "EHLO vger.rutgers.edu" ident: "root") by listserv.funet.fi with ESMTP id <5960-31831>; Thu, 13 Aug 1998 20:36:33 +0300
Received: by vger.rutgers.edu id <154645-22291>; Thu, 13 Aug 1998 12:21:08 -0400
From: owner-linux-kernel-digest@vger.rutgers.edu
To: linux-kernel-digest@vger.rutgers.edu
Subject: linux-kernel-digest V1 #2384
Reply-To: linux-kernel@vger.rutgers.edu
Errors-To: owner-linux-kernel-digest@vger.rutgers.edu
Precedence: bulk
Message-Id: <19980813164111Z154645-22291+2665@vger.rutgers.edu>
Date: Thu, 13 Aug 1998 12:21:08 -0400
linux-kernel-digest Thursday, 13 August 1998 Volume 01 : Number 2384
In this issue:
Re: kill -9 <pid of X>
Re: kill -9 <pid of X>
Re: kill -9 <pid of X>
Antw: Re: kill -9 <pid of X>
Re: kill -9 <pid of X>
Re: kill -9 <pid of X>
Re: kill -9 <pid of X>
ip forwarding question from /var/log/messages
sorry about the sysctl fowarding message...
Re: bad patches (was: Patches vs complete tarballs....)
Kernel panic after reloading scsi device driver a few times
Re: 2.0.36pre4
Re: SMP
Re: Subject: Re: SMART-ide how???
Re: compile a big-endian kernel on a prep machine
Re: try_to_unuse: entry xxx not in use
Re: NFS hangs on 2.1.115
Re: patch-ikd-arca-2.1.115-1 avaible
PCI NE2000 on Linux SMP box
untrusted advanced graphics: was: kill -9 <pid of X>
Re: kill -9 <pid of X>
IBM & Linux (Re: DEVFSv50 and /dev/fb?)
Re: ENOSYS, CD-ROM, and SMP oopses
Re: kill -9 <pid of X>
Re: CIPE - Encrypted IP Encapsulation
[semi-offtopic] Linux 2.2 Changes ('really final' version)
Re: kill -9 <pid of X>
Re: kill -9 <pid of X>
Re: IRQ trouble
Re: kill -9 <pid of X>
See the end of the digest for information on subscribing to the linux-kernel
or linux-kernel-digest mailing lists.
----------------------------------------------------------------------
From: Olaf Titz <olaf@bigred.inka.de>
Date: Thu, 13 Aug 1998 13:40:00 +0200
Subject: Re: kill -9 <pid of X>
> Before anybody starts trying to convince me that there is kernel help
> needed, they'd better have their facts straight.
To ensure system stability, all hardware access has to be confined to
device drivers which run in the kernel, so that they are
sanity-checked and when a process exits prematurely, it is ensured the
hardware state is not left undefined. That's the traditional reasoning
and I think it is valid even if a heap of video drivers in the kernel
would be as messy as the current heap of network drivers. ;-)
If we wouldn't follow that, we never had a parport driver in the
kernel. That one in the simplest case doesn't need interrupts or DMA
(other reasons for putting stuff in the kernel) and if you only can
access the parport I/O addresses, you can damage much less than with
access to a video card. At worst you wegde the printer[1]. BRSing a
printer is nothing compared to BRSing a computer...
Everything else belongs in user space. Really I think the proper way
to make an X server is to have a framebuffer device spiced with
acceleration ioctls[2], and let the X server use that. But that needs
some kernel support, limited mostly to mode switching and stuffing
commands into the accelerator parts. It would be messy but it wouldn't
necessary _have_ to be as messy as XFree86 is currently.
VGAs which don't support a linear framebuffer are out here (and as a
band-aid can still be used with the old XFree86 servers).
olaf
[1] My BIOS doesn't properly initialize the printer port. The printer
gets wedged by reboot until the parport driver is initialized, which
means I have to build that into the kernel. My old board worked with
that as a module. Oh well.
[2] I don't know what's going on in the video-drivers-in-kernel camp
currently, I'm just stating how _my_ model would look like.
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Olaf Titz <olaf@bigred.inka.de>
Date: Thu, 13 Aug 1998 14:12:45 +0200
Subject: Re: kill -9 <pid of X>
> Why is your X server in a tight loop with signals blocked?
Bacause of a bug in it? ;-)
> For example, it _never_ makes any sense to block SIGSEGV. For all I know,
XFree86 and svgalib apps _must_ block/catch SIGSEGV precisely because
that signal can occur at any time and exiting then leaves the hardware
in an undefined state. Just like with SIGTERM. The fact that SIGSEGV
are usually caused by a bug in the application doesn't change
anything. If the X server unexpectely dumps core without restoring
video mode you're hosed. Especially if it does that while writing a
register set, depending on the hardware the machine may need a power
cycle to ever get a beam out of the monitor again.
I've seen this various times with different graphics boards. Cirrus
and noname chipsets were the worst offenders.
olaf
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Jon Hamilton <hamilton@pobox.com>
Date: Thu, 13 Aug 1998 07:47:58 -0500
Subject: Re: kill -9 <pid of X>
In message <Pine.HPP.3.91.980812193611.21672B-100000@gaia.ecs.csus.edu>, "Jon M
. Taylor" wrote:
} On Wed, 12 Aug 1998, Brandon S. Allbery KF8NH wrote:
}
} > In message <Pine.HPP.3.91.980812140323.6780F-100000@gaia.ecs.csus.edu>, "Jo
} n
} > M.
} > Taylor" writes:
} > +-----
} > | On Wed, 12 Aug 1998, Kragen wrote:
} > | > Remember, we're talking about defending against signals from a hostile
} > | > root who wants to crash the video card.
} > | No we are not. Where did hostility come into this? There are
} > | many legitimate reasons why I might want to kill -9 the X server.
} > +--->8
} >
} > Excuse me? You want to use the explicit kill-without-cleanup, then you
} > complain that it didn't clean up after you and we need to hack the kernel t
} o
} > make up for it? What's wrong with a normal kill?
}
} If X is hosed, a normal kill might not work. Or the kernel might
} need to kill the X server process for OOM reasons or something else. I'd
} still like to make the process go away without trouble in those
} circumstances. If I have to kill -9 a normal process, it doesn't have to
} free its own memory, does it? No, the kernel can do that for me. The
} kernel cannot do that with the X server's video card manipulations.
}
} > If your worry is traceback (which -9 won't help you with either) then edit
} > XF86Config and turn on core dumps, then kill it with -4 or something. It'l
} l
} > fork, the child will dump core, then it cleans up.
}
} Whee. Now I can trace through a 1MB+ core file, most of which is
} not the code I am interested in. I still think debugging a kernel module
} is easier.
Easier isn't always better. You argued in an earlier post several points
about X code being ugly, using Imakefiles, having poor internal interfaces,
etc. None of those are particularly compelling reasons to put things
in the kernel; rather, they're all arguments for cleaning up the X code.
- --
Jon Hamilton
hamilton@pobox.com
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: "Axel Eble" <aeble@controlware.de>
Date: Thu, 13 Aug 1998 14:44:28 +0200
Subject: Antw: Re: kill -9 <pid of X>
>To ensure system stability, all hardware access has to be confined to
>device drivers which run in the kernel, so that they are
>sanity-checked and when a process exits prematurely, it is ensured the
>hardware state is not left undefined. That's the traditional reasoning
>and I think it is valid even if a heap of video drivers in the kernel
>would be as messy as the current heap of network drivers. ;-)
you would need only one driver in the kernel: the text console driver.
That's enough to get the system into a mode where an install program
could load the video drivers for the graphics hardware on the system.
So essentially you would have two video drivers: one for the text mode
and one for the specific type of crappy PC video card :-)
Am I wrongo there?
>Everything else belongs in user space. Really I think the proper way
>to make an X server is to have a framebuffer device spiced with
>acceleration ioctls[2], and let the X server use that. But that needs
>some kernel support, limited mostly to mode switching and stuffing
>commands into the accelerator parts. It would be messy but it wouldn't
>necessary _have_ to be as messy as XFree86 is currently.
Sounds like a sensible concept to me. That way one would have
a common interface, only one X server would be necessary, that one
could be completely revamped etc.
And what's more: one would be reminded of "real" computers booting
like an SGI or a NeXT :-)
Axel
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: "Richard B. Johnson" <root@chaos.analogic.com>
Date: Thu, 13 Aug 1998 08:50:10 -0400 (EDT)
Subject: Re: kill -9 <pid of X>
On Thu, 13 Aug 1998, Alan Cox wrote:
> > I started X. As root I killed X. Keyboard, etc., all locked.
> > I logged in over the network and restarted X. Everything worked,
> > including ctl-alt-backspace which got me out of X with a usable
> > keyboard. `stty sane` and `stty rows 24` fixed up about averything.
>
> For a tiny fraction of cards. On a cirrus you can get into a state where
> even the engineers who designed it couldnt get it back without a power
> down.
>
> Alan
>
Yes. On one of my S3_VERGE machines, I could get X back up and it
worked fine. However, once I normally exited X, I was stuck with
a "strange" screen and no keyboard control.
Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
Penguin : Linux version 2.1.115 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: yodaiken@chelm.cs.nmt.edu
Date: Thu, 13 Aug 1998 05:47:53 -0600
Subject: Re: kill -9 <pid of X>
On Thu, Aug 13, 1998 at 02:12:45PM +0200, Olaf Titz wrote:
> > Why is your X server in a tight loop with signals blocked?
>
> Bacause of a bug in it? ;-)
>
> > For example, it _never_ makes any sense to block SIGSEGV. For all I know,
>
> XFree86 and svgalib apps _must_ block/catch SIGSEGV precisely because
> that signal can occur at any time and exiting then leaves the hardware
> in an undefined state. Just like with SIGTERM. The fact that SIGSEGV
So the isn't the correct approach to _catch_ SIGSEGV and to do a safe exit
or for X to run as the child of a process that knows how to safe exit
when X die?
In fact, wouldn't is be reasonable to have a collection of X parents that
would save video state, fork/exec X and take care of cleanup? These
would be small, easy to debug programs, as far as I can tell.
- ---------------------------------
Victor Yodaiken
Department of Computer Science
New Mexico Institute of Mining and Technology
Socorro NM 87801
Homepage http://www.cs.nmt.edu/~yodaiken
PowerPC Linux page http://linuxppc.cs.nmt.edu
Real-Time Page http://rtlinux.org
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
Date: Thu, 13 Aug 1998 14:52:05 +0200 (CEST)
Subject: Re: kill -9 <pid of X>
On Wed, 12 Aug 1998, Brandon S. Allbery KF8NH wrote:
> In message <Pine.HPP.3.91.980812151305.11627B-100000@gaia.ecs.csus.edu>,
> "Jon M
> . Taylor" writes:
> +-----
> | On Wed, 12 Aug 1998, Brandon S. Allbery KF8NH wrote:
> | > In message <m0z6d1t-000aNFC@the-village.bc.nu>, Alan Cox writes:
> | > | an argument against any specific setup btw - no doubt kernel code would
> | > | have some upset potential too)
> | > "Some"? Is wedging the console less preferable than wedging thwe entire
> | > system? I know where I can get NT4 in that case :-)
> | Suppose the sounds driver locks up and wedges your system that
> | way. Better put in in usersapce too. After all, you aare a lot better
> +--->8
>
> The sound driver doesn't map and copy big chunks of memory around. More to
> the point, compare the number of crashes from Alan's sound driver work to
> those during fbcon development. Likewise, NT stability (granted, always an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which crashes have _you_ seen during fbcon development? I just checked the
Linux/m68k registration database, and either you didn't register, or you
weren't there when fbcon was developed (1994/1995).
I guess you're talking about the optimizations that happened lately to get
better performance out of vgacon after the abstract console merge? That's
something completely different.
Greetings,
Geert
- --
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Mark Lehrer <mark@lehrer.nlcomm.com>
Date: Thu, 13 Aug 1998 10:23:33 -0400
Subject: ip forwarding question from /var/log/messages
Hello. I'm setting up a masquerading system on a PPP link and I have
everything set up right; the right kernel and ipfwadm options. However,
what is stopping me (IMO) is the following boot-time message:
mark> grep sysctl /var/log/messages
...
Aug 12 15:03:54 firewall kernel: sysctl: ip forwarding off
Aug 12 15:08:49 firewall kernel: sysctl: ip forwarding off
Aug 12 15:16:13 firewall kernel: sysctl: ip forwarding off
Aug 13 08:34:47 firewall kernel: sysctl: ip forwarding off
Is the kernel just silent when forwarding is turned back on? This is
a frustrating problem. I looked at the kernel source but it wasn't
too obvious what was going on.
Thanks!
Mark
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Mark Lehrer <mark@lehrer.nlcomm.com>
Date: Thu, 13 Aug 1998 10:30:55 -0400
Subject: sorry about the sysctl fowarding message...
This always happens; right after I post a message, I find the answer
in a rather obvious place... the /etc/rc.d/init.d/network script.
Think: kernel source is a last resort. 8^)
I think I can figure it out from here.
Mark
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Mike Jagdis <mike@roan.co.uk>
Date: Thu, 13 Aug 1998 12:40:42 +0100 (GMT/BST)
Subject: Re: bad patches (was: Patches vs complete tarballs....)
On Thu, 13 Aug 1998, Rogier Wolff wrote:
> Patch might be one of the programs that needs to be "recent".
Nah, I'm still using patch 2.1. All it needs is the right arguments.
Mike
- --
.----------------------------------------------------------------------.
| Mike Jagdis | Internet: mailto:mike@roan.co.uk |
| Roan Technology Ltd. | |
| 54A Peach Street, Wokingham | Telephone: +44 118 989 0403 |
| RG40 1XG, ENGLAND | Fax: +44 118 989 1195 |
`----------------------------------------------------------------------'
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: "Bas Mevissen" <sgm@stack.nl>
Date: Thu, 13 Aug 1998 15:14:34 +0200
Subject: Kernel panic after reloading scsi device driver a few times
Hi all,
On my Linux 2.0.35/SMP driver Dual PPro box I got the following after
loading and unloading the ncr53c8xx device driver a few times:
Aug 13 14:24:45 twin kernel: ncr53c8xx: at PCI bus 0, device 13, function 0
Aug 13 14:24:45 twin kernel: ncr53c8xx: 53c810 detected
Aug 13 14:24:45 twin kernel: ncr53c810-0: rev=0x02, base=0xe0800000,
io_port=0x9800, irq=10
Aug 13 14:24:45 twin kernel: ncr53c810-0: ID 7, Fast-10, Parity Checking
Aug 13 14:24:45 twin kernel: ncr53c810-0: restart (scsi reset).
Aug 13 14:24:45 twin kernel: scsi1 : ncr53c8xx - revision 2.5f.1
Aug 13 14:24:45 twin kernel: scsi : 2 hosts.
Aug 13 14:25:14 twin kernel: ncr53c810-0: releasing host resources
Aug 13 14:25:14 twin kernel: ncr53c810-0: resetting chip
Aug 13 14:25:14 twin kernel: ncr53c810-0: host resources successfully
released
Aug 13 14:25:14 twin kernel: scsi : 1 host.
Aug 13 14:25:22 twin kernel: ncr53c8xx: at PCI bus 0, device 13, function 0
Aug 13 14:25:22 twin kernel: ncr53c8xx: 53c810 detected
Aug 13 14:25:22 twin kernel: ncr53c810-0: rev=0x02, base=0xe0800000,
io_port=0x9800, irq=10
Aug 13 14:25:22 twin kernel: ncr53c810-0: ID 7, Fast-10, Parity Checking
Aug 13 14:25:22 twin kernel: ncr53c810-0: restart (scsi reset).
Aug 13 14:25:22 twin kernel: scsi1 : ncr53c8xx - revision 2.5f.1
Aug 13 14:25:22 twin kernel: scsi : 2 hosts.
Aug 13 14:25:29 twin kernel: Vendor: PHILIPS Model: CDD2600
Rev: 1.07
Aug 13 14:25:29 twin kernel: Type: CD-ROM
ANSI SCSI revision: 02
Aug 13 14:25:34 twin kernel: ncr53c810-0: releasing host resources
Aug 13 14:25:34 twin kernel: ncr53c810-0: the timer seems to be already
stopped
Aug 13 14:25:34 twin kernel: ncr53c810-0: resetting chip
Aug 13 14:25:34 twin kernel: ncr53c810-0: host resources successfully
released
Aug 13 14:25:34 twin kernel: scsi : 1 host.
Aug 13 14:25:34 twin kernel: Unable to handle kernel paging request at
virtual address c4845d2c
Aug 13 14:25:34 twin kernel: current->tss.cr3 = 0309e000, `r3 = 0309e000
Aug 13 14:25:34 twin kernel: *pde = 00003067
Aug 13 14:25:34 twin kernel: *pte = 00000000
Aug 13 14:25:34 twin kernel: Oops: 0000
Aug 13 14:25:34 twin kernel: CPU: 0
Aug 13 14:25:34 twin kernel: EIP: 0010:[<04845d2c>]
Aug 13 14:25:34 twin kernel: EFLAGS: 00010206
Aug 13 14:25:34 twin kernel: eax: 026900d8 ebx: 02690080 ecx: 00000000
edx: 001a0e48
Aug 13 14:25:34 twin kernel: esi: 04845d2c edi: 00000002 ebp: 0309ff50
esp: 0309ff34
Aug 13 14:25:34 twin kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss:
0018
Aug 13 14:25:34 twin kernel: Process xterm (pid: 416, process nr: 35,
stackpage=0309f000)
Aug 13 14:25:34 twin kernel: Stack: 001177ed 02690080 00000001 ffffffff
00000105 00000002 0011e6c2 001b76c0
Aug 13 14:25:34 twin kernel: 0011e6f3 0309ff6c 00000000 08072880
bffff2e8 0010ac47 00001770 00036e0c
Aug 13 14:25:34 twin kernel: 04805000 00000000 08072880 bffff2e8
00000000 03910018 00000018 bfff002b
Aug 13 14:25:34 twin kernel: Call Trace: [timer_bh+749/820]
[do_bottom_half+10/96] [do_bottom_half+59/96] [handle_bottom_half+11/24]
[8390:ei_open+-77828/76] [system_call+125/312]
Aug 13 14:25:34 twin kernel: Code: <1>Unable to handle kernel paging request
at virtual address c4845d2c
Aug 13 14:25:34 twin kernel: current->tss.cr3 = 0309e000, `r3 = 0309e000
Aug 13 14:25:34 twin kernel: *pde = 00003067
Aug 13 14:25:34 twin kernel: *pte = 00000000
Aug 13 14:25:34 twin kernel: Oops: 0000
Aug 13 14:25:34 twin kernel: CPU: 0
Aug 13 14:25:34 twin kernel: EIP: 0010:[die_if_kernel+716/780]
Aug 13 14:25:34 twin kernel: EFLAGS: 00010202
Aug 13 14:25:34 twin kernel: eax: 00000010 ebx: 0000002b ecx: 04845d2c
edx: 0000ea60
Aug 13 14:25:34 twin kernel: esi: 00000000 edi: 030a0000 ebp: 0309fef8
esp: 0309fe94
Aug 13 14:25:34 twin kernel: ds: 0018 es: 0018 fs: 0010 gs: 002b ss:
0018
Aug 13 14:25:34 twin kernel: Process xterm (pid: 416, process nr: 35,
stackpage=0309f000)
Aug 13 14:25:34 twin kernel: Stack: 0018002b 0309fef8 00045000 00000000
00000000 04800000 05000000 04800000
Aug 13 14:25:34 twin kernel: 00000018 001160b7 0018e808 0309fef8
00000000 00115d68 04845d2c 00000002
Aug 13 14:25:34 twin kernel: 0309ff50 04000000 00000246 0308d098
03037414 00115d68 0010b0a5 0309fef8
Aug 13 14:25:34 twin kernel: Call Trace: [tty_wait_until_sent+155/388]
[8390:ei_open+-98308/76] [<05000000>] [8390:ei_open+-98308/76]
[do_page_fault+847/864] [do_page_fault+0/864] [<04845d2c>]
Aug 13 14:25:34 twin PAM_pwdb[427]: (su) session closed for user root
Aug 13 14:25:34 twin kernel: [do_page_fault+0/864]
[error_code+237/248] [<04845d2c>] [<04845d2c>] [timer_bh+749/820]
[do_bottom_half+10/96] [do_bottom_half+59/96] [handle_bottom_half+11/24]
Aug 13 14:25:34 twin kernel: [8390:ei_open+-77828/76]
[system_call+125/312]
Aug 13 14:25:34 twin kernel: Code: 64 8a 04 0e 0f a1 88 c2 81 e2 ff 00 00 00
89 54 24 10 52 68
Aug 13 14:25:34 twin kernel: Aiee, killing interrupt handler
Aug 13 14:25:48 twin PAM_pwdb[798]: (su) session opened for user root by
sgm(uid=0)
Aug 13 14:25:49 twin kernel: Kernel panic: CPU #1:Attempted flush tlb IPI
when not AKP(=255)
There was another scsi driver loaded for the ZIP drive (PPA 1.42) and it was
copying data from the zip disk to the ide harddisk.
Is it such a bad idea to (un)load a driver on a working system (copying
data) ?
In a second try, the machine didn't behave nice after unloading this driver.
I halted it immediately after that to avoid trouble. I can't see what is
really going on because there is no console on the box. I use it remotely.
I hope someone can shine his light on this.
Bas.
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Andy Carlson <andyc@andyc.carenet.org>
Date: Thu, 13 Aug 1998 08:34:09 -0500 (CDT)
Subject: Re: 2.0.36pre4
Hi. I just started watching this group, and was wondering if you could
elaborate on the modular sound comment. I have noticed that sound
modules don't seem to work in 2.1.107 and 2.1.114 (the only two
development kernels I have tried) and wondered if it is tied in with
this. Thanks.
Andy Carlson |\ _,,,---,,_
andyc@andyc.carenet.org ZZZzz /,`.-'`' -. ;-;;,_
BJC Health System |,4- ) )-,_. ,\ ( `'-'
St. Louis, Missouri '---''(_/--' `-'\_)
Cat Pics: http://www.anet-stl.com/~andyc/animal.html
On Wed, 12 Aug 1998, Alan Cox wrote:
>
> ftp://ftp.linux.org.uk/pub/linux/alan/...
>
> This one updates the tulip and 3c509 drivers, so give those a beating. The
> mdelay/udelay problem with the aic7xxx update is fixed. A small root
> permissions bug in /proc is fixed and a few other minor things.
>
> Modular sound isnt in this one. Its about 60/40 in favour but I decided
> the 40% were right. It changes expected behaviour for people which isnt
> good for 2.0
>
> The main thing left to sort now is the final CPU detection. Im still getting
> some reports of misdetections
>
> Alan
>
> -
> 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.altern.org/andrebalsa/doc/lkml-faq.html
>
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Gary White <linux-kernel@netpathway.com>
Date: Thu, 13 Aug 1998 09:00:38 -0500
Subject: Re: SMP
Thanks to all that replied. Someone suggested that I may have
defective memory, but all the simms I have ( 8 - 8x32 60ns)
work fine as long as they are in banks 0 and 1. Tyan suggest
the slowest memory should go in banks 0 and 1 with the
fastest in banks 2 and 3. The only problem is all the simms
I have are identical. Two other suggestions I will try is to
upgrade the bios to 1.2 and buy a better grade of memory
which I will do. I understand that Tyan motherboards are
picky about grades of memory. Thanks again for the help.
I will keep everyone posted on the progress.
- --
Gary White Network Administrator
admin@netpathway.com Internet Pathway
Voice 601-776-3355 Fax 601-776-3817
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Mark Lord <mlord@pobox.com>
Date: Thu, 13 Aug 1998 10:08:08 -0400
Subject: Re: Subject: Re: SMART-ide how???
Ian Stirling wrote:
>
> I mailed quantum in the past, asking about the meanings of the values
> returned by SMART.
> They basically said, piss off, we won't tell you.
And nor should they.
The SMART spec is very specific about requiring OS/application
software to NOT interpret the SMART values, other than notifying
of a possible problem whenever a threshold is exceeded.
That way, each drive vendor can invent unit-specific measures
that are most appropriate for the specific implementation,
without having to maintain or worry about breaking a slew of
software utilities.
Ugly, maybe, but an okay way to do it.
- --
mlord@pobox.com
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: "Mike A. Harris" <mharris@ican.net>
Date: Wed, 12 Aug 1998 01:02:53 -0400 (EDT)
Subject: Re: compile a big-endian kernel on a prep machine
On Tue, 11 Aug 1998, Herve REY wrote:
> i have kernel 2.0.47 for prep powerpc.
> i want to compile the kernel in big-endian orderring.
> i saw : processor.h --> MSR_LE, MSR_ILE
Can you tell me where I can get kernel 2.0.47 from? I can't find
it anywhere. The last kernel I knew about was 2.0.35.
- --
Mike A. Harris - Computer Consultant - Linux advocate
Escape from the confines of Microsoft's operating systems and push your
PC to it's limits with LINUX - a real OS. http://www.redhat.com
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Bill Hawes <whawes@transmeta.com>
Date: Thu, 13 Aug 1998 07:31:16 -0700
Subject: Re: try_to_unuse: entry xxx not in use
Trever Adams wrote:
> printk("try_to_unuse: entry %08lx "
> "not in use\n", entry);
>
> I believe I had the above section of code from swapfile.c (lines 338 and
> 339) show up on shutting down 2.1.115 the other day. I have never had
> it show up before. I am pretty sure that was it. It was after syslog
> had shut down (RedHat standard init pretty much) and I believe after
> disks were unmounted. The error looked very much like that if not that
> (didn't right it down, was in a hurry).
This message indicates that the system might have lost track of a swap page
- -- when it came time to turn swap off, the swap map count indicated that the
page was in use, but no task was found still using it.
The next time you plan to shut down, you might try turning swapoff -a by hand
so that any such messages will get logged.
Regards,
Bill
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Bill Hawes <whawes@transmeta.com>
Date: Thu, 13 Aug 1998 07:34:57 -0700
Subject: Re: NFS hangs on 2.1.115
David Howells wrote:
> I tried running 2.1.115 yesterday, but found that I couldn't NFS mount
> anything - the mount program just hung uninterruptibly, as did the amd
> automounter. I also found I couldn't reboot successfully as the kernel hung in
> the unmounting phase (no suprise there).
Is your NFS modular? If so you might want to try loading the modules ahead of
time -- there seem to be some funny things going on when kmod loads modules.
Regards,
Bill
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Andrea Arcangeli <arcangeli@mbox.queen.it>
Date: Thu, 13 Aug 1998 16:53:26 +0200 (CEST)
Subject: Re: patch-ikd-arca-2.1.115-1 avaible
On Wed, 12 Aug 1998, Andrea Arcangeli wrote:
I merged good stuff from Michael L. Galbraith (thanks Michael), the new
diff is called:
ftp://e-mind.com/pub/linux/kernel-patches/patch-ikd-arca-2-2.1.115.diff.gz
Andrea[s] Arcangeli
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: yosshy@debian.or.jp (Akira YOSHIYAMA)
Date: Thu, 13 Aug 1998 22:40:00 +0900 (JST)
Subject: PCI NE2000 on Linux SMP box
Hi,
I have a PPro x2 SMP box and a PCI NE2000 compatible NIC with VIA
chip. I rebuilt Linux kernel to contain ne2k-pci driver as a module.
I configure as below:
- ---
# ifconfig eth0 192.168.1.1
- ---
result:
- ---
# ifconfig -a
...
eth0 Link encap:Ethernet HWaddr 00:00:05:00:0B:EC
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:1 dropped:0 overruns:0 frame:0
TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
Collisions:0
Interrupt:16 Base address:0x7f20
# cat /proc/interrupts
CPU0 CPU1
0: 23739 70354 IO-APIC-edge timer
1: 742 2076 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
5: 0 1 IO-APIC-edge soundblaster
10: 332 937 IO-APIC-edge aha152x
12: 1000 2625 IO-APIC-edge PS/2 Mouse
13: 1 0 XT-PIC fpu
14: 18178 58411 IO-APIC-edge ide0
15: 7864 16510 IO-APIC-edge ide1
16: 10 11 IO-APIC-level eth0
NMI: 0
IPI: 0
- ---
It looks good. But pings for other hosts on the LAN doesn't
return. In /var/log/syslog:
- ---
Aug 13 22:20:16 localhost kernel: eth0: timeout waiting for Tx RDC.
Aug 13 22:20:30 localhost last message repeated 14 times
Aug 13 22:20:30 localhost kernel: Socket destroy delayed (r=0 w=384)
Aug 13 22:20:31 localhost kernel: eth0: timeout waiting for Tx RDC.
Aug 13 22:21:19 localhost kernel: eth0: timeout waiting for Tx RDC.
Aug 13 22:21:22 localhost last message repeated 3 times
- ---
Why can't? VIA chips doesn't support my SMP mother board? hmm...
In my box, NT can't use the NIC as same. But I don't know it's
because of same problem.
I guess this is because of:
1. BIOS problem
2. NIC problem
3. ne2k-pci problem
4. network code problem
Anyone, advice me, please.
Thanks for any suggestion.
- ---
A. Yoshiyama <yosshy@debian.or.jp>
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: jh99@cts.com
Date: Thu, 13 Aug 1998 08:28:16 -0700
Subject: untrusted advanced graphics: was: kill -9 <pid of X>
The following does not appear to be possible to implement
entirely in user space:
1. Providing a bulletproof mechanism to allow untrusted
processes to access advanced graphics functions without a
task switch to a trusted server process.
All else appears to be possible, however difficult, or
easy, to coordinate, and implement, in user space.
Is the functionality and performance of that kind of a
mechanism required? Some will say yes, some will say no.
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Ian Collier <imc@comlab.ox.ac.uk>
Date: Thu, 13 Aug 1998 16:51:29 +0100 (BST)
Subject: Re: kill -9 <pid of X>
OK, it's obvious what the answer is. [ :-) ]
Collect together a minimal set of display device drivers out of the
X server and put them into a kernel module. Then have the X server
insmod the correct drivers for your graphics card. No one needs to
bother Linus or write kernel patches.
So you end up with a module that creates a /dev/Xgraphics device
[using the gift of dev_fs (-: ] which does all your mode switches.
The X server opens this device and instructs it to change modes,
do some acceleration, whatever. When the device is closed it resets
the graphics mode. This even works if X got killed by an OOM error.
imc
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Ian Collier <imc@comlab.ox.ac.uk>
Date: Thu, 13 Aug 1998 16:55:32 +0100 (BST)
Subject: IBM & Linux (Re: DEVFSv50 and /dev/fb?)
On Tue, 11 Aug 1998 17:39:57 +0100 (BST), Alan Cox said:
> IBM are strange. Bits of IBM are pro or for Linux. I've already been in
> the ridiculous situation of helping one bit of IBM with some Linux driver
> work while not having full documentation because another bit of IBM wouldnt
> give it out.
I can imagine that. Anyway, the day I can phone in to IBM tech support and
say "I'm running Linux on my IBM ThinkPad and the soundcard dies whenever I
suspend the machine" and get a sensible answer is the day I will believe IBM
is actively supporting Linux.
imc
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Meelis Roos <mroos@tartu.cyber.ee>
Date: Thu, 13 Aug 1998 11:09:33 +0300 (EEST)
Subject: Re: ENOSYS, CD-ROM, and SMP oopses
> I had the same problem with 2.1.110 anyway. Something in the dcache
> (lookup_dentry) oops's on the request_module call so I can get ENOSYS on
> basically anything modularized. klogd trying to load Unix sockets causes a
> flood of messages until I hit ALT+SysRQ+E.
Just tried it with non-modularized kernel (no module support at all).
I still see strange ENOSYS errors on mount syscalls.
amd for instance gets 2 ENOSYS errors and then succeeds on mount.
Not sure yet if it succeeds always.
So it _seems_ that the ENOSYS anomaly and my amd hanging problem are two
different things.
- ---
Meelis Roos (mroos@tartu.cyber.ee)
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Matthew Kirkwood <weejock@ferret.lmh.ox.ac.uk>
Date: Thu, 13 Aug 1998 17:11:30 +0100 (GMT)
Subject: Re: kill -9 <pid of X>
On Thu, 13 Aug 1998, Ian Collier wrote:
> So you end up with a module that creates a /dev/Xgraphics device
> [using the gift of dev_fs (-: ] which does all your mode switches.
> The X server opens this device and instructs it to change modes,
> do some acceleration, whatever.
Yes, that's stable[1] and secure, but the overhead of a kernel trap for
each acceleration command would make it very slow compared with the
current XFrees.
And allowing userspace access to mmio registers is not an option, because
for many, if not most, PC (and - thanks to the wonders of PCI - Alpha,
PPC, etc) video cards, unless the kernel traps and emulates all of these
accesses (even worse), there is no way that it can restore a sane state.
Only on low-end (dumb framebuffer) or high-end (context-enabled card)
hardware is this an option, and those cases are the ones which the
current situation works well for...
Matthew.
[1] As stable as the driver is, anyway.
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Scott McDermott <vaxerdec@frontiernet.net>
Date: Thu, 13 Aug 1998 09:37:42 -0400
Subject: Re: CIPE - Encrypted IP Encapsulation
Felix von Leitner on Wed, Aug 12, 1998 at 04:23:19PM +0200:
> I don't think the ruling would hold in court, since the whole operating
> system can be viewed as software with plugins (programs). So PGP could
> be viewed as plugin for the operating system and then every operating
> system would have to be banned.
Additionally, I'm wondering just how exactly a legal system would attack
Linux -- it's not exactly an entity per se that one can point to. There
is really no enterprise at all that can be prosecuted. Who would they
sue/indict? Linus? Maintainer Blah? How ridiculous, they can't possibly
accomplish this. Such crap really gets in the way, I would advocate
just ignoring such preposterous nonsense. I don't know why we are being
obsequious when it's unnecessary and accomplishes nothing.
- --
Scott
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Joseph Pranevich <knight@baltimore.wwaves.com>
Date: Thu, 13 Aug 1998 12:12:19 -0400 (EDT)
Subject: [semi-offtopic] Linux 2.2 Changes ('really final' version)
Hello again,
It's been a couple weeks and I've just finished an update to my changes
document. I hope you are interested. (Yes, I know I said I wouldn't post
to linux-kernel again, but I got a *lot* of requests to do so. Oh well.)
Please note that I don't think I'm fooling anyone by calling this a
'final' version. Linus has listed several big things that may still get in
and I will definately update if any of those things get in. But otherwise,
this should be it. (Unless I missed something important or said something
misleading...)
Happy reading.
Joe Pranevich
- --
The Wonderful World of Linux 2.2
- --------------------------------
As any kernel developer can surely tell you, the advent of Linux 2.2 is
nigh. Linux 2.1 is approaching near astronomical version numbers in its
slow march to completeness, 2.1.115 as of this writing, and all eyes are
looking towards the day when 2.2.0 will ship standard in the various
distributions. Even if you don't actually follow the Linux kernel version
by version, 2.2 is an important milestone to understand. So, submitted for
your approval, here is my take on the Linux Kernel Developments of late,
with some significant bias towards Linux/i386 which is the Linux that I
use most often at home.
Please note that this document does not cover all the new hardware that
Linux supports. Many devices, such as scanners and printers, are handled
exclusively in user space. Other devices, such as video cards and mice,
are handled by a combination of user and kernel drivers. If you don't see
a device class that you are interested in listed in this document, it is
quite likely that Linux 2.2 supports it -- just not necessarily using the
kernel to do so.
1) Chips Galore
The world of Intel chips is a fast and interesting thing to follow, if you
have nothing better to do. Merced, Celeron, MMX... the names of Intel
technologies float past to be replaced by new cutting-edge technology.
(Whether or not these technologies are worthwhile is a matter that I'm not
even going to begin to try and debate.) In addition, AMD, Cyrix, and other
companies have become solid competitors in the market and each have their
own little optimizations, quirks, and bugs. It's a mess, to say the
least.
Linux 2.2 will be the first stable Linux to support processor vendor
selection in the kernel configuration tool for even better fine-tuning.
Perhaps even more importantly, Linux 2.2 (and later revisions of 2.0 for
obvious reasons) supports bugfixes and workarounds for widespread
processor bugs including the infamous F00F Pentium bug. Other bugs that
can't be worked around, such as a couple AMD K6 bugs, are reported during
startup.
Merced hasn't arrived yet and probably isn't immediately forthcoming, but
Linux 2.2 has already been ported to Sparc64, Alpha, and other 64-bit
platforms so the infrastructure for a 64-bit native kernel is already
happily in place. (There are, of course, other obstacles that would have
to be overcome before Linux/Merced could be released but having a 64-bit
ready kernel is an important step.)
Multiple-Processor machines now will operate much more efficiently than
they did in Linux 2.0 with issues such as the global spinlock removed. Up
to 16 processors are supported (the same as with 2.0) but the performance
difference should be amazing. Also, there is now greater support for the
IO-APIC on Intel boards that will make SMP generally better supported.
In terms of other ports, Linux 2.2 will feature improved support for a
large number of 'workstation' machines such as Sparc, Sparc64, and Alpha
machines. As for 'desktop' machines, Linux 2.2 has been ported to
Motorola's m68k and PPC processors and now can be expected to run on many
of these platforms, including the Macintosh. (with varying degrees of
hardware support, of course.) Linux is also moving to processors, such as
ARM that are increasingly popular for embedded systems.
On somewhat of a tangent, there is continuing work to support a subset of
the Linux kernel on 8086, 8088, 80186, and 80286 machines. This project
will never integrate itself with Linux-proper but will provide an
alternative Linux-subset operating system for these machines.
In terms of memory consumption, the average Linux 2.2 setup will require
more memory than Linux 2.0. (Although a larger number of components can
now be modularized or compiled-out to allow a system administrator more
flexibility if memory is tight.) According to many sources, the absolute
least amount of RAM required for 2.2 on text-only systems is 5 megs. (Up
from 4 with Linux 2.0) To get reasonable performance without swapping, 8
megs are still recommended. (There have been reports of savvy linux users
getting running systems with only 3 megs, your mileage may vary.) On the
bright side, Linux 2.2 includes a number of new optimizations that should
actually improve the performance of machines with at least 16 megs of RAM.
The more, the merrier.
2) System Busses and Assorted Ilk
Although somewhat less crucial and cutting edge, Linux 2.2 will support a
larger percent of the existing x86 computers with the addition of complete
support for the Microchannel bus found on some PS/2s and older machines.
In addition to hundreds of minor patches to the bus system (including many
new PCI device names), larger improvements have taken place. The PCI
subsystem, in particular, has undergone several major changes. Firstly,
the PCI device reporting interface has been changed and moved to allow for
easier addition of new information fields. This particular change doesn't
spell much of a difference for an end user but it makes the lives of
developers much easier. Additionally, it is now possible to choose whether
you want to scan your PCI bus using your compatible PCI BIOS or through
direct access. This allows Linux 2.2 to work on a larger set of machines
as several PCI BIOSes were incompatible with the standards and caused
booting problems.
Sadly, there is still little kernel support for Plug-and-Play ISA devices.
While that would be a great addition, there are some problems with the
currently proposed systems that will need to be resolved sometime in 2.3
before inclusion. Fortunately enough, there happens to be a great
user-level utility, isapnp, for setting up PnP devices that requires just
a tad more work than we'd like but gets the job done in true Linux
fashion.
3) IDE, and SCSI, and USB... Oh my!
As far as Linux IDE is concerned, not much obvious has changed for Linux
2.2. The most obvious change is that it is now possible to load and unload
the IDE subsystem as a module, just like SCSI. (This also has the added
bonus of allowing one to use a PnP-based IDE controller.) For less
bleeding-edge machines, the updated IDE driver now supports older MFM and
RLL disks and controllers without having to load an older version of the
driver. Linux 2.2 now also has the ability to detect and configure all
PCI-based IDE cards automatically, including the activation of DMA
bus-mastering to reduce CPU overhead and improve performance. And finally,
more drivers have been developed for controllers that are buggy or simply
different. It's amazing how even excellent things can continue to get
better.
Elsewhere in the IDE world, parallel port IDE devices have become more
common and are now supported by Linux 2.2, for the most part. It is a good
assumption that many devices that are not supported currently will be
added as 2.2 progresses.
The SCSI subsystem's main improvements have been the addition of many new
drivers for many new cards and chipsets. Too many, in fact, to even begin
to name here.
PCMCIA adapters (or PC-card slots, as they are called now) are not
supported in the standard Linux 2.2 but are supported by an external
module provider. Thus, while not in the kernel, PCMCIA support will be
included in most distributions.
IRDA devices will also be supported in a similar manner as PCMCIA devices.
Alas, there is some bad news here. Despite ongoing efforts by several
parties to finish USB support, no support has currently been included in a
Linux 2.1 release. This could change before Linux 2.2 becomes finalized,
but it is unlikely that such a large feature would be included this close
to release. It is more likely that USB support will be provided by an
external source as modules and would therefore still be included in
distributions (see the note on PCMCIA, above.)
4) Ports: Parallel and Serial
Nothing much new on this front, Linux has always had incredible support
for these basic building blocks. The parallel port driver has been
rewritten with cross-platform issues in mind and thus what was once just a
'Parallel Port' is now a 'PC-Style Parallel Port' Functionality-wise, the
only obvious change is that you can now effortlessly share a single
parallel port device with multiple device drivers. (Note however that the
naming convention used to label parallel ports has changed so you may find
that your lp1 has become your lp0. Distributions should allow for this
change automatically however.)
Serial support is chugging along as well as it always has but with one
notable difference. Previously, a serial device such as a modem involved
two devices, one for call-in and one for call-out. (ttyS and cua
respectively) As of Linux 2.2, the two are combined in one device (ttyS)
and accessing the cua devices now prints a warning message to the kernel
log. On the bright side, Linux 2.2 includes support for having more than 4
serial ports, it allows serial devices to share interrupts, and it
includes a number of drivers for non-standard ports and multi-port cards.
My only complaint with serial support is its lack of support for the
standard methods for modules to pass device parameters at module-load time
via the modules.conf file and kmod. (Instead, these parameters are set
using the 'setserial' command. Somewhat yuck.)
It should also be mentioned that Linux 2.2 will support newer UART chips
than 2.0 which may translate into higher transfer rates using newer
modems.
5) CD-ROMs, Floppies, and removable media
Thankfully, the hodge-podge of hundreds of CD-ROM standards has solidified
behind the 'standard' of ATAPI CD-ROMs. This reprieve has given developers
time to completely rewrite the CD-ROM driver system to be more
standardized in terms of support. Small, quirky differences between the
individual drivers have now all been fixed for better support.
Rewritable CD-ROMs aren't supported nearly as well as one would like,
unfortunately. SCSI CD-ROMs are well done (and most IDE drives use
SCSI-over-ATA, the SCSI-emulation driver). With other rewritable CD-ROMs,
your mileage may vary.
Floppies are working as well as ever. There are new developments in terms
of large volume floppies and it remains to be seen whether or not all of
these will be supported. Those devices that communicate using ATAPI (a
large number of them, actually) are already supported to some degree.
IOMEGA's zip drive, an increasingly popular storage solution, is fairly
well supported under Linux 2.2. These beasts come in three versions: SCSI,
ATAPI (IDE), and Parallel. Under SCSI and ATAPI, the Zip drives are
supported just as any other disk would be. The parallel version of these
drives actually use a sort of SCSI-over-parallel protocol that is also
supported in Linux 2.2. (Other IOMEGA solutions such as DITTO drives may
also be supported using the ftape drivers.)
DVD drives are already supported, to some degree, under Linux as they
represent themselves largely as ATAPI drives. (SCSI DVD drives may not,
but they will probably work using the excellent SCSI CD-ROM driver.)
Unfortunately, this does not necessarily mean that all will be rosy in the
Linux/DVD world as Linux does not currently support any DVD-centric
filesystems that have been proposed nor are any user-space tools developed
to display DVD movies and etc. Once the standards stabilize a bit, it is
highly likely that the requisite parts will be added to the Linux kernel
sometime during the 2.2.x cycle, following the initial release.
Other removable media may or may not be supported under Linux 2.2. If the
device connects through the parallel port, it is possible that it is
supported using one of the Parallel Port IDE device protocol modules that
are included in the kernel.
6) Glorious Sounds!
At long last, the sound code has been partially rewritten to be completely
modular from start to finish. Distributions will be able to more easily
include generic sound support out-of-the-box for their users as well as
making it easier for the rest of us to load and configure sound devices.
(Especially pesky Plug-and-Play ones.) Lots of new sound devices are
supported as well and it looks like this is one area where Linux will
really improve in the next year.
One very notable defect here is the remaining lack of support for the PC
internal speaker, if only for completeness. Then again, Windows 95/98
doesn't do it either so who am I to judge?
7) Video4Linux
Linux 2.2 now has amazing support for a growing number of TV and radio
tuner cards and digital cameras. This is a truly bleeding edge addition to
2.1's roster so there may still be some outstanding issues but it is
reasonable to assume that they will be fixed in time. In my humble
opinion, this is just an amazing area for Linux to be in at all.
8) Back me up, Scotty!
Linux 2.2's backup and tape device subsystem has not changed much since
the 2.0 release. More drivers for devices have been written, of course and
substantial improvement has been made for backup devices that work off of
the floppy disk controller (including the IOMEGA DITTO).
Rewritable CD-ROMs have become a popular solution for backing up data and
they are supported under Linux 2.2 (either natively or using the SCSI
emulation driver.) There are still outstanding issues in this regard, see
my note above on CD-ROMs for details.
9) Joysticks, Mouse, and Input Devices
Joysticks are better supported in 2.2 including a large number of new
joysticks and joysticks with an inordinate numbers of buttons. Likely,
your joystick will work under Linux 2.2.
Mice in 2.2 aren't really different from mice in 2.0. (As in 2.0, there
are some inconsistencies regarding mouse support that will be addressed in
the future. For the most part, mouse control is provided through a daemon
external to the kernel. Some mouse drivers however deliberately emulate a
Microsoft standard mouse. The reasoning behind this is obvious but it
would be nice if it was decided on in one way or the other.) It should be
noted that, while not solely a kernel issue, mice with Microsoft's
spinning wheel extension are supported in recent versions of the XFree86,
Linux's most popular GUI. (However many Linux applications have not been
designed to take advantage of this feature.)
Additionally, several other input devices are now supported under Linux
2.2 including some digitizer pads. If your devices emulates a mouse (as
many do) then it is already supported by Linux 2.2 (and, in fact, Linux
2.0).
10) Video
Perhaps the most surprising and cutting-edge addition to the Linux kernel
version 2.2 is what is called the 'frame-buffer console' driver (or
'fbcon', for short.)
Previously, the Linux kernel (for Intel-based machines) only understood
and manipulated the video devices in text mode. Graphical support was to
be provided by two other systems: 'svgalib' for console-based graphics,
and a specialized X Server for window-based graphics. This kludgey system
often required configuration information to be repeated and each system
supported only a limited slice of the myriad of video devices in common
use.
Since this addition is rather new, it remains to be seen whether it will
truly replace the previous and long-standing duality. Unfortunately, it
could be nearly a year after Linux 2.2 ships before this new system could
be robust enough to support the cards and technologies that we already
take for granted as working. My personal opinion is that this is the right
idea, but I'm going to withhold judgment until we see exactly how far
Linus and the developers decide to take this feature.
As an added side-effect of this new feature, primitive multi-heading has
been added into the kernel for some devices. Currently, this is limited to
some text-mode output but it is reasonable to assume that this very new
addition to the Linux kernel will mature somewhat during the 2.2.x and
2.3.x cycles.
It should also be mentioned that it is now possible to remove support for
'virtual' terminals as provided by the kernel. This allows very
memory-conscious people to save just a tad more.
Although unimaginable to the desktop user, Linux can now work even better
on systems that do not actually include any sort of video device. In
addition to being able to log in over serial or networked lines, as Linux
2.0 and previous Linuxes allowed, it is now possible to redirect all the
kernel messages (usually sent to the console directly before any hardware
was initialized) to a serial device.
11) Networking: Ethernet, ISDN, and the lowly modem.
I don't have a huge amount of experience here; I've been using the same
network cards in all my machines for several years. But, it doesn't take
an Alan Cox to see that the number of supported Ethernet and ISDN devices
supported in Linux 2.2 has risen sharply. I have been told that newer
solutions such as cable modems are supported, also.
My only gripe in this regard is the continued non-support of so-called
'Winmodems.' Not that I blame Linux for their absence, making modems that
are 80% software is just a dumb idea anyway, but the idealist in me hopes
that some day these pesky devils will be supported like their less
retarded cousins.
12) Amateur Radio people are Linux people, too.
Since before Linux 2.0, Linux has been one of the few desktop OSes to
include native support for computer-based amateur radio people. (Not that
I actually know what that entails but it seems to be a more popular option
outside the US.) Linux 2.2 adds support for NetROM and ROSE amateur radio
protocols. The basic AX.25 layer has also been materially enhanced.
13) Filesystems for the World
Linux 2.2 has a wide array of new filesystems and partition types for
interconnectivity. In addition, many of Linux's supported filesystems
(including those I haven't listed here) have been updated with a new
caching system to markedly improve performance. (In fact, not updating the
drivers wasn't even an option if one wanted them included in Linux 2.2.)
For the Microsoft nut, Linux will now read (and maybe write) NTFS (Windows
NT) drives and Windows 98's FAT32 drives (also used by some later versions
of Windows 95). Linux 2.2 also understands Microsoft's Joilet system for
long filenames on CD-ROMs. And finally, Linux also understands a new type
of extended partition that Microsoft invented. Drivers to read and write
Microsoft and Stacker compressed drives are being developed but not yet
included in the kernel.
For Mac connectivity, a HFS driver for reading and writing Mac disks has
been included. HFS+ and MFS (ancient floppy format) are not yet supported.
Macintosh partition tables can now also be read by the kernel; this allows
Mac SCSI disks to be mounted natively.
Sadly, OS/2 users will still not be able to write to their HPFS drives.
Some updates have been made to the HPFS driver to support the new 'dcache'
system but not the complete overhaul that some were hoping for.
If there are any Amiga users left, they will be pleased to know that the
FFS driver has undergone some minor updates since 2.0. This is especially
useful as the new generation of PPC Amigas will continue to support this
format.
For connectivity to other UNIXes, Linux 2.2 has come forward in leaps and
bounds. Linux 2.2 still includes the UFS filesystem which is used on BSD
derived systems, including Solaris and the free versions of BSD. Linux 2.2
can now also read the partition table formats used by FreeBSD, SunOS, and
Solaris. For SysV-style UNIXs, Linux 2.2 features a somewhat updated
version of SysVFS. Linux 2.2 can also read the Acorn's RiscOS disks. And
finally, Linux 2.2 features a somewhat updated version of the ever-popular
Minix filesystem, which can be used for small drives and floppies on most
UNIXes. With so many incompatible formats (and Linux 2.2 reading so many
of them), it's amazing anyone ever got any work done.
In other news, support for 'extended' drives (the format used by much
older versions of Linux) has been removed in favor of the 'second
extended' filesystem. (This shouldn't matter to many people, 'ext2' is far
superior to its predecessor.) With the increased support of initial
ramdisks, a 'romfs' has been created which has very minimal overhead.
While not quite a filesystem, Linux 2.2 includes enhanced support for
stretching a filesystem across several disks transparently. At present,
this support can be used in RAID 0, 1, 4, and 5 modes as well as a simple
linear mode.
14) Networking II: Under the Hood
On the protocol front, a lot has happened that I simply don't understand
completely. The next generation Internet protocol, IPv6, has made an
appearance. SPX, a compliment to IPX is new, as well. DDP, the protocol of
choice for AppleTalk networking has also been improved. And, just as you
would come to expect by now, the existing protocols have been improved, as
well. I only wish I had the need to use some of this stuff...
On the low-end front, not much has changed. PPP, SLIP, CSLIP, and PLIP are
all still available for use. I guess some things don't need much
improvement. (Although each of those drivers have been updated in one way
or another.)
The list keeps going, however. Linux 2.2 will have an excellent new
networking core, new tunneling code, a completely new firewalling and
routing system called 'ipchains', support for limiting bandwidth
consumption, and a ton more. It's just amazing. I wish I could keep track
of it all. (But, who am I kidding?)
It should be noted that file and printer sharing protocols have also been
improved and markedly enhanced. SMB, the protocol for accessing
Windows-based shared filesystems has been somewhat improved with bugfixes
and the like. If you are a fan of NetWare (doubtful), you'll be happy to
know that Linux 2.2 supports a large number of improvements in this area,
including access to two different kinds of NCP long file names. Trusty NFS
has also been improved, both at the server level and the client level. And
finally, those eggheads over at CMU have been hard at work developing the
new distributed network filesystem, Coda. This filesystem supports a large
number of highly-requested features including disconnected operations for
laptops, an advanced cache system, and security improvements.
On somewhat of a tangent, Linux 2.2 also includes a driver which will
allow one to share (and remotely mount) whole disk images over a network.
15) Not Everyone Speaks English.
Linux 2.0 is a very international OS with support for international
keyboards and the like. Linux 2.2 adds to this and other
internationalization features the ability to load some UNICODE codepages
for translating filenames into Linux's native system. (Currently, the only
filesystems that use these UNICODE codepages include Microsoft's VFAT and
Microsoft's Joilet ISO 9660 (CD-ROM filesystem) extension.)
16) Unix98: The Next Generation
Linux 2.2 will be a more 'standard' UNIX in a number of ways. The most
pronounced of these ways to the end user will be the addition of
UNIX98-style Pty devices using a new filesystem (devpts) and a cloning
device to provide the functionality.
17) And, finally...
In addition to those noted above, there are a large number of other
drivers and things that just don't fit in anywhere but should still be
noted. So, in no given order, the oddball updates of Linux 2.2:
The loopback driver, which allows disk images to be mounted and
manipulated just like any regular drive, has been improved in a number of
ways. Of these improvements, the most notable difference to users will be
its increased support for encryption and the mounting of encrypted hard
disks and disk images.
A driver for accessing your computer's CMOS memory has also been provided
in Linux 2.2 which may be useful in some applications. (Sadly, a similar
driver to access your BIOS's flashable RAM did not make it, it will still
be necessary to boot from a DOS floppy to flash your computer's BIOS to a
new version.)
And finally, in the past, Linux used a half-user/half-kernel method of
loading in and out drivers (called 'modules') called 'kerneld' This method
was good but inefficient. Linux 2.2 has removed kerneld and replaced it
with a smaller all-kernel solution called 'kmod'.
- ------------
This is the 'really final' version of this document, unless there are
really stupid mistakes or Linux 2.1 gets a really special new feature.
(We're in a feature freeze... again so that is unlikely.) I would however
like to ask for interested people to continue to send me suggestions and
corrections at knight@baltimore.wwaves.com.
Thank you all for your support during the writing of this document.
Unfortunately, in the rush of suggestions and the rash of dozens of people
correcting me on the same items (Alpha as a 64-bit platform, for example),
I completely lost track of contributors. I'm sorry. In particular, I'd
like to thank Alan Cox and Meelis Roos for their contributions, they
really helped out a lot in the preparation of this 'final' draft.
Thank you, and Good Night.
Joseph Pranevich
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
Date: Thu, 13 Aug 1998 18:21:08 +0200 (CEST)
Subject: Re: kill -9 <pid of X>
On Thu, 13 Aug 1998, Ian Collier wrote:
> OK, it's obvious what the answer is. [ :-) ]
>
> Collect together a minimal set of display device drivers out of the
> X server and put them into a kernel module. Then have the X server
> insmod the correct drivers for your graphics card. No one needs to
> bother Linus or write kernel patches.
>
> So you end up with a module that creates a /dev/Xgraphics device
> [using the gift of dev_fs (-: ] which does all your mode switches.
> The X server opens this device and instructs it to change modes,
Hey, this _is_ already present! Please point your editor at drivers/video/.
> do some acceleration, whatever. When the device is closed it resets
> the graphics mode. This even works if X got killed by an OOM error.
Change mode on close isn't implemented yet.
Greetings,
Geert
- --
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: Ian Collier <imc@comlab.ox.ac.uk>
Date: Thu, 13 Aug 1998 17:34:02 +0100 (BST)
Subject: Re: kill -9 <pid of X>
On Thu, 13 Aug 1998 18:21:08 +0200 (CEST), you said:
> On Thu, 13 Aug 1998, Ian Collier wrote:
> > So you end up with a module that creates a /dev/Xgraphics device
> > [using the gift of dev_fs (-: ] which does all your mode switches.
> > The X server opens this device and instructs it to change modes,
> Hey, this _is_ already present! Please point your editor at drivers/video/.
Not for anywhere near all the devices supported by X though, I bet.
> > do some acceleration, whatever. When the device is closed it resets
> > the graphics mode. This even works if X got killed by an OOM error.
> Change mode on close isn't implemented yet.
Well that _was_ the whole point of this thread... :-)
imc
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: "Mike A. Harris" <mharris@ican.net>
Date: Thu, 13 Aug 1998 12:35:23 -0400 (EDT)
Subject: Re: IRQ trouble
On Tue, 11 Aug 1998, Matthew D. Pitts wrote:
> > > Disable the IRQ on your video card. It is unnecessary. Most PC
> > > BIOS's have an "Assign IRQ2 to VGA" enable disable in CMOS setup.
> > > Set it to disable.
> >
> > I can't disable anything on my videocard.
> > Don't we just all love PnP? :-)
> >
> > And I never saw that option in my BIOS.
> > Besides, I thought IRQ9 was (unofficially) reserved for videoboards?
> IRQ 9 is cascaded to IRQ 2, so technically it doesn't exist. ( although my
> sportster winmodem uses IRQ 9 ;()
Yes. My modem is on what I refer to as IRQ 2. In DOS programs,
I set the software to use IRQ 2 and everything works. If I use
"IRQ 9", nothing works.
In Windows 3.1/95 I have to set it to IRQ 9 or nothing works. In
Linux, I set it to IRQ 2 and it works.
PC hardware is braindamaged IMHO. It would be nice to see a new
architecture with a PIC with 256 IRQ's, all non-cascaded in one
chip. Same goes for DMA and any other resources.
- --
Mike A. Harris - Computer Consultant - Linux advocate
Escape from the confines of Microsoft's operating systems and push your
PC to it's limits with LINUX - a real OS. http://www.redhat.com
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
From: "Jon M. Taylor" <taylorj@ecs.csus.edu>
Date: Thu, 13 Aug 1998 09:44:04 -0700 (PDT)
Subject: Re: kill -9 <pid of X>
On Thu, 13 Aug 1998, DAVID BALAZIC wrote:
> >> I regard such as overly simplistic and therefore
> >> strawmen.
> >
> > The situation *is* really quite simple. Video drivers belong in
> >the kernel.
> >
> >Jon
>
> Just for information :
>
> Other unices ( IRIX and Solaris at least ) have gfx drivers.
Yep. When GGI people have spoken to users of other Unices in the
past about the Linux video driver situation, we have gotten a lot of
strange looks (well, the equivalent over e-mail anyway). The idea that
putting video drivers in the OS was _controversial_ *really* blew people's
minds. In the rest of the world, this is not even an issue for debate.
Jon
- ---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
------------------------------
End of linux-kernel-digest V1 #2384
***********************************
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.altern.org/andrebalsa/doc/lkml-faq.html