owner-linux-kernel-digest@vger.rutgers.edu wrote:
> linux-kernel-digest Tuesday, 7 October 1997 Volume 01 : Number 1211
>
> In this issue:
>
> Re: ULTRA DMA HDD
> Re: Repeatable kernel crash [2.1.55, Wine, Control Panel]
> Re: suidpid( UID, credential? ) ? secure IPC? (fwd)
> Re: linux 2.0.31 problem
> dev_alloc doesn't (didn't) clear the new device.
> Re: Strange file system problem with 2.0.31pre10
> Re: linux 2.0.31 problem
> CONFIG_PROFILE
> Re:
> Re: CONFIG_PROFILE
> Directory slowness
> Spontaneous watchdog reboots with 2.1.57?
> Interrupt Latency.
> Bug in internal_add_timer()?
> Re: Interrupt Latency.
> Re: your mail
> Re: Bug in smbfs 2.0.30 pre9 ?
> Re: Repeatable kernel crash [2.1.55, Wine, Control Panel]
> Another one?
> Re: Directory slowness
> disk reporting in /proc/stat
> 2.0.30 Kernel Panic
> cyrix patch: where???
> Re: Q' about 'securelevel' for SA Magazine (LONG!)
> Re: Interrupt Latency.
> Security hole in linux-2.0.31-pre9 (NFS related)
> Re: Strange file system problem with 2.0.31pre10
> Re: suidpid( UID, credential? ) ? secure IPC?
> patch for CLONE_PID enhancements to clone()
> Re: Security hole in linux-2.0.31-pre9 (NFS related)
> Re: suidpid( UID, credential? ) ? secure IPC?
> Re: Another one?
> Re: Security hole in linux-2.0.31-pre9 (NFS related)
> Re: cyrix patch: where???
>
> See the end of the digest for information on subscribing to the linux-kernel
> or linux-kernel-digest mailing lists.
>
> ----------------------------------------------------------------------
>
> From: Kostas Liakakis <kostas@rincewind.techpath.gr>
> Date: Tue, 7 Oct 1997 09:47:47 +0200 (EET)
> Subject: Re: ULTRA DMA HDD
>
> On Oct 03, Phil Brutsche wrote:
>
> > > > AFAIK DOS can't handle more that one Primary Partition, so
> > > > you should create Extended one, and some Logical inside of it.
>
> wrong! DOS happily handles more than one primary DOS partition --
> I've been using this setup for many years with various *DOS versions
> from 5.0 to 6.22 and NovelDOS 7.0 etc.
>
> Really? Go and boot from the second dos primary partition in a
> hard disk. Do the same on win95... They 'll both hang. Or I did
> something terribly wrong with my lilo setup.
>
> -K.
>
> ------------------------------
>
> From: Gabriel Paubert <paubert@iram.es>
> Date: Tue, 7 Oct 1997 08:58:26 +0100 (MET)
> Subject: Re: Repeatable kernel crash [2.1.55, Wine, Control Panel]
>
> > Modify_ldt should check that it does not try to invalidate one of the
> > selectors in CS, DS, ES, FS, GS and SS. You'll find CS, DS, ES and SS on
> > the stack, GS in its register. For FS it depends on kernel version:
> > on the stack for 2.0, in its register for 2.1.
>
> Sorry I was partially wrong, at least in my 2.0.30 tree there is a check for
> fs and gs, but not in 2.1.5x. And it seems the registers are not where
> I claimed they were on (2.0.x gs is on the stack).:-(. I've been playing
> with task switching recently (Ingo's soft task switch) and I did not
> correctly remember differences between 2.0.xx and 2.1.xx.
>
> Gabriel.
>
> ------------------------------
>
> From: alan@lxorguk.ukuu.org.uk (Alan Cox)
> Date: Tue, 7 Oct 1997 08:01:43 +0100 (BST)
> Subject: Re: suidpid( UID, credential? ) ? secure IPC? (fwd)
>
> > Mainframe's (i.e. IBM MVS, OS/390, et. al.) have a special facility for
> > performance cross-address space procedure calls. You can think of them
>
> So does the 80x86 with its call gates.
>
> > MVS programmers have been using this facility for decades to isolate
> > highly privileged, or extrememly important code, from other address spaces.
> > The facility is there for good reason... Why not go study it, or talk
> > to you nearby MVS guru - and try to implement such a facility in Linux.
>
> For users in general its too slow and too expensive to work with. You can
> sort of do it in userspace however using modify_ldt and mmap/mprotect in
> your own program space if you want.
>
> > Like Durable Queues (essentially SysV message queues that are ACID
> > consistent and persist across reboots). I've been finding it a chore to
>
> Ok thats a fun one. A persistent queue - definitely a user space problem
> from the unix viewpoint.
>
> > write business-grade applications on Unix without things like cross-address
> > space calls, durable queues, etc. Generally, one has to resort to an
>
> "Business Grade" here meaning giant data processing apps ?
>
> Alan
>
> ------------------------------
>
> From: Kurt Garloff <garloff@kg1.ping.de>
> Date: Tue, 7 Oct 1997 10:07:30 +0200 (CEST)
> Subject: Re: linux 2.0.31 problem
>
> On Tue, 7 Oct 1997, Francesco Faenzi wrote:
>
> > Hi, I,ve got the following problem with linux-2.0.31-pre10
> >
> > Oct 6 23:26:31 bob kernel: hda: write_intr: status=0x51
> > { DriveReady SeekComplete Error }
> > Oct 6 23:26:31 bob kernel: hda: write_intr: error=0x18
> > { SectorIdNotFound }, LBAsect=1718312, sector=328159
> > Oct 6 23:26:31 bob kernel: hda: status error: status=0x59 { DriveReady
> > SeekComplete DataRequest Error }
> > Oct 6 23:26:31 bob kernel: hda: status error: error=0x18
> > { SectorIdNotFound }, LBAsect=1718319, sector=328159
> > Oct 6 23:26:31 bob kernel: hda: no DRQ after issuing WRITE
> > Oct 6 23:26:31 bob kernel: ide0: reset: success
> >
> > hdparm -g /dev/hda:
> >
> > /dev/hda:
> > geometry = 1654/16/63, sectors = 1667232, start = 0
>
> Hmm, the log looks more like a (temporary ?) HD failure than like a kernel
> bug. Test with badblocks (readonly) or write a little testprogram for
> (permamnent) HD errors.
> But: The sector the kernel looks for might be illegal. Maybe somebody
> familiar with LBA can comment on this.
>
> Kurt Garloff, Dortmund
> <K.Garloff@ping.de>
>
> ------------------------------
>
> From: David Woodhouse <D.W.Woodhouse@nortel.co.uk>
> Date: Tue, 07 Oct 1997 09:34:05 +0100
> Subject: dev_alloc doesn't (didn't) clear the new device.
>
> This is a multipart MIME message.
>
> - --===_0_Tue_Oct__7_09:29:22_BST_1997
> Content-Type: text/plain; charset=us-ascii
>
> Patch against 2.1.57-vger-971005
>
> Given that the only place dev_alloc seems to be used in the entire kernel
> source is in net/tunnel.c, which is what I'm working on, I feel justified in
> changing the semantics a bit.
> OK?
>
> - --===_0_Tue_Oct__7_09:29:22_BST_1997
> Content-Type: application/octet-stream
> Content-Description: dev_alloc-clear-vger57
>
> - --- linux/net/core/dev.c.orig Tue Oct 7 09:21:22 1997
> +++ linux/net/core/dev.c Tue Oct 7 09:27:07 1997
> @@ -277,6 +277,7 @@
> *err=-ENOBUFS;
> return NULL;
> }
> + memset(dev, 0, sizeof(struct device)+16);
> dev->name=(char *)(dev+1); /* Name string space */
> *err=dev_alloc_name(dev,name);
> if(*err<0)
>
> - --===_0_Tue_Oct__7_09:29:22_BST_1997
> Content-Type: text/plain; charset=us-ascii
>
> David Woodhouse, CB3 9AN http://dwmw2.robinson.cam.ac.uk/
> dwmw2@cam.ac.uk Tel: 0976 658355
> ( D.W.Woodhouse@nortel.co.uk Tel: 01279 402332 )
>
> (Use the former; I'm going back to College tomorrow.)
>
> - --===_0_Tue_Oct__7_09:29:22_BST_1997--
>
> ------------------------------
>
> From: Kurt Huwig <kurt@huwig.de>
> Date: Tue, 7 Oct 1997 11:32:45 +0200 (CEST)
> Subject: Re: Strange file system problem with 2.0.31pre10
>
> On Mon, 6 Oct 1997, Jonathan Stanton wrote:
> > [After a crash, the Netscape binary seems to differ; after a reboot, it
> > is ok again]
> [...]
>
> >From a fast look at your diff-file, there are two blocks of 4096 Bytes
> that differ. This rings a bell?! You should check your RAM, disable caches
> and look if the error remains.
>
> Kurt
>
> - -------------------------------------------------------------
> If you put a PC-formatted disk into a Macintosh, you can read it.
> If you put a Mac-formatted disk into a Win95-PC, it asks you
> whether it should format it.
>
> ------------------------------
>
> From: Francesco Faenzi <1993s000@educ.disi.unige.it>
> Date: Tue, 7 Oct 1997 11:31:33 +0100 (MET)
> Subject: Re: linux 2.0.31 problem
>
> Thank you for your answer.
> I'll try with badblocks (ro).
> I hope the failure is only temporary.
> Francesco Faenzi
>
> Francesco Faenzi | Disclaimer :=> Everything above is a true statement,
> Student in Computer Science | for sufficiently false values of true.
>
> ------------------------------
>
> From: Martin Mares <mj@mj.gts.cz>
> Date: Tue, 7 Oct 1997 11:45:44 +0200
> Subject: CONFIG_PROFILE
>
> Hi,
>
> Does anybody know why the profiling code is compiled in even if it isn't
> configured by CONFIG_PROFILE? (The config switch now controls only whether
> it's turned on by default or not.)
>
> Have a nice fortnight
> - --
> Martin `MJ' Mares <mj@gts.cz> http://atrey.karlin.mff.cuni.cz/~mj/
> Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
> "I love complete delivery - with the screwdriver."
>
> ------------------------------
>
> From: "Iba\qez Palomar Juan David" <al004151@llevant.uji.es>
> Date: Tue, 7 Oct 1997 12:09:24 +0200 (METDST)
> Subject: Re:
>
> >Hi All,
> > I am new to Linux kernel.Will be thankfull if someone helps.
> >
> > What is SEGMENTATION FAULT? In which conditions does it occur?
> > Why did the following program receive the above error?
> >
> >#include<unistd.h>
> >#include<errno.h>
> >#include<stdlib.h>
> >void main()
> >{
> > char *ptr="error",ptr1,ptr2; // The error is here
> you declare ptr1 and ptr2 as char
> it must be:
>
> char *ptr="error",*ptr1,*ptr2;
> > int filedes[2];
> > pipe(filedes);
> > perror(ptr);
> > ptr1=malloc(1024);
> > scanf("%s",ptr1);
> > write(filedes[1],ptr1,1024);
> > ptr2=malloc(1024);
> > read(filedes[1],ptr2,1024);
> > printf("\n%s",ptr2);
> > free(ptr1);
> > free(ptr2);
> >
> >}
> >
> > Thanks in advance.
> > Avijit Lahiri
> >
>
> ------------------------------
>
> From: Marcin Dalecki <dalecki@sub994.sub.uni-goettingen.de>
> Date: Tue, 7 Oct 1997 10:55:34 +0100 (MET)
> Subject: Re: CONFIG_PROFILE
>
> On Tue, 7 Oct 1997, Martin Mares wrote:
>
> > Hi,
> >
> > Does anybody know why the profiling code is compiled in even if it isn't
> > configured by CONFIG_PROFILE? (The config switch now controls only whether
> > it's turned on by default or not.)
> I suppose that this is mainly due to the fact that the profiling infects
> crucial kernel structures. I have tried to make it an real option A LONG
> time ago and failed :-(.
>
> Marcin
>
> ------------------------------
>
> From: "Steven N. Hirsch" <shirsch@ibm.net>
> Date: Tue, 7 Oct 1997 07:15:33 -0400 (EDT)
> Subject: Directory slowness
>
> Bill,
>
> I chased down the dcache shrink patch and rebuilt 2.1.57 with:
>
> bad_inode57-patch
> file_table57-patch
> nfs_57-patch
> procfs_57-patch
> remount_57-patch
> shrink_dcache_sb-57.patch
> smbfs_57-patch
> sunrpc_57-patch (with one-line fixup per your posting)
>
> Everything seems to work fine, but I've noticed that my file manager
> (Midnight Commander) is taking about 6-8x longer to stat a large directory
> (approx. 2200 files) than usual. Before I ifdef'ed the printk's out, the
> dcache code reported a large amount of activity at this point. I'm
> guessing that this slowdown is due to the shrinking algorithm?
>
> Steve
>
>
>
> ------------------------------
>
> From: Chris Ricker <gt1355b@prism.gatech.edu>
> Date: Tue, 7 Oct 1997 07:25:37 +0000 (GMT)
> Subject: Spontaneous watchdog reboots with 2.1.57?
>
> Anyone else having problems with the software watchdogd randomly
> rebooting stock 2.1.57? I have a box here that will do so randomly
> after someone telnets in. The only message that appears in the logs is:
>
> watchdog[253]: process table is full!
>
> The problem is, the process table shouldn't be full. This has happened
> on a freshly booted system with one user logged in at the console and
> with no user processes besides login and bash going. Immediately after
> a remote login, the watchdog message appears and the system reboots.
> It doesn't occur every time someone telnets in, but appears to require
> a local user and telnet user to occur.
>
> thanks,
> chris
>
> - --
> Chris Ricker gt1355b@prism.gatech.edu
>
> ------------------------------
>
> From: David Woodhouse <D.W.Woodhouse@nortel.co.uk>
> Date: Tue, 07 Oct 1997 12:20:55 +0100
> Subject: Interrupt Latency.
>
> Could anyone give me a clue what the normal interrupt latency is under Linux
> 2.0 or 2.1 on a Pentium.
>
> That is, if I put in a driver which responds to an interrupt simply by
> waggling an output bit on the parallel port or something similar, what kind of
> time delay will I see if I put a scope on it?
>
> Thanks.
>
> - --
> David Woodhouse, CB3 9AN http://dwmw2.robinson.cam.ac.uk/
> dwmw2@cam.ac.uk Tel: 0976 658355
> ( D.W.Woodhouse@nortel.co.uk Tel: 01279 402332 )
>
> (Use the former; I'm going back to College tomorrow.)
>
> ------------------------------
>
> From: Jan Echternach <jec@DInet.de>
> Date: Tue, 7 Oct 1997 13:31:16 +0200
> Subject: Bug in internal_add_timer()?
>
> Hi,
>
> I think the test whether the timer value is in the past doesn't work
> when jiffies overflow (i.e. expires = ULONG_MAX - 5, jiffies = expires
> + 10), but I'm not sure if I really understood what the code is
> expected to do.
>
> > ...
> > } else if (expires < timer_jiffies) {
> > /* can happen if you add a timer with expires == jiffies,
> > * or you set a timer to go off in the past
> > */
> > insert_timer(timer, tv1.vec, tv1.index);
> > } ...
>
> - --
> Jan Echternach
>
> ------------------------------
>
> From: Harald Koenig <koenig@tat.physik.uni-tuebingen.de>
> Date: Tue, 7 Oct 1997 13:46:43 +0200
> Subject: Re: Interrupt Latency.
>
> On Oct 07, David Woodhouse wrote:
>
> > Could anyone give me a clue what the normal interrupt latency is under Linux
> > 2.0 or 2.1 on a Pentium.
> >
> > That is, if I put in a driver which responds to an interrupt simply by
> > waggling an output bit on the parallel port or something similar, what kind of
> > time delay will I see if I put a scope on it?
>
> I've tested this long time ago with Linux-1.0...1.3 with my 486DX2/66.
> there I got ~11-12 usec interrupt latency (I just read the timer latch
> in the clock timer ISR, then you exactly know how many usec it took
> from timer countdown to get into the ISR...)
>
> Harald
> - --
> All SCSI disks will from now on ___ _____
> be required to send an email notice 0--,| /OOOOOOO\
> 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
> \ \/OOOOOOOOOOOOOOO\
> \ OOOOOOOOOOOOOOOOO|//
> Harald Koenig, \/\/\/\/\/\/\/\/\/
> Inst.f.Theoret.Astrophysik // / \\ \
> koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
>
> ------------------------------
>
> From: "Richard B. Johnson" <root@chaos.analogic.com>
> Date: Tue, 7 Oct 1997 08:02:47 -0400 (EDT)
> Subject: Re: your mail
>
> On Mon, 6 Oct 1997, Abhijit Lahiri wrote:
>
> > Hi All,
> > I am new to Linux kernel.Will be thankfull if someone helps.
> >
> > What is SEGMENTATION FAULT? In which conditions does it occur?
>
> Segmentation faults usually occur when you access memory you don't
> own.
>
> >
> > #include<unistd.h>
> > #include<errno.h>
> > #include<stdlib.h>
> > void main()
> > {
> > char *ptr="error",ptr1,ptr2;
> |____|__________ Not pointers
> *ptr1, *ptr2;
> |______|________ Need the splat
> >
>
> Cheers,
> DJ
> Richard B. Johnson
> Analogic Corporation
> Penguin : Linux version 2.1.55 on an i586 machine (66.15 BogoMips).
> Warning : It's hard to stay on the trailing edge of technology.
> Linux : Engineering tool
> Spam : sync@localhost, daemon@loghost
>
>
> ------------------------------
>
> From: Bill Hawes <whawes@star.net>
> Date: Tue, 07 Oct 1997 08:15:47 -0400
> Subject: Re: Bug in smbfs 2.0.30 pre9 ?
>
> Dietmar Kling wrote:
>
> > I've mounted a dir with smbfs (Share from Windows NT)
> > //tiger/d$ 1148608 1131136 17472 98% /dos/smb
> >
> > when i do a
> > minitiger:/dos/smb/backup # ls -l |wc
> > 93 830 6697
> >
> > You see 93 Lines (dirs + files)
> >
> > When I do a strg + a in Windows NT Explorer in the same directory i have
> > 186 objects!
> >
> > 186/2 = 93 -> I can see only 93 files on linux side!!!!
> >
> > Something is wrong here.
>
> I've run into this problem in 2.1.57 smbfs, and have fixed it in the
> latest snapshot, though the fix introduced some other problems to be
> resolved. Once the code has stabilized it should be possible to back
> port a fix to 2.0.31.
>
> Regards,
> Bill
>
> ------------------------------
>
> From: Gabriel Paubert <paubert@iram.es>
> Date: Tue, 7 Oct 1997 08:15:08 +0100 (MET)
> Subject: Re: Repeatable kernel crash [2.1.55, Wine, Control Panel]
>
> On Tue, 7 Oct 1997, Morten Welinder wrote:
>
> >
> > Thanks to Marcus Meissner for pointing out the culprit: modify_ldt
> > (and not old_select as I suspected as it was the last thing I saw).
> >
> > The following program locks up Linux for me. Don't run this unless
> > you have mounted your disks read-only. Note that without the final
> > sleep(1), the crash doesn't seem to happen.
> >
>
> That's a simple problem, I found it a few weeks ago by inspection of the
> source code just for curiosity, but did not have a time to make patch for
> it. And I was not worried since I don't use DOSEMU or WINE (yet).
>
> Modify_ldt should check that it does not try to invalidate one of the
> selectors in CS, DS, ES, FS, GS and SS. You'll find CS, DS, ES and SS on
> the stack, GS in its register. For FS it depends on kernel version:
> on the stack for 2.0, in its register for 2.1.
>
> The error to return in this case is probably EBUSY, otherwise you will run
> into very nasty things during task switches. I first thought possible to
> simply clear the corresponding registers, but it won't work for CS or SS,
> and trigger segment related exceptions that Linux probably does not handle
> very well, hence the lockup (the middle ground would be to return EBUSY
> for CS and SS but silently clear DS, ES, FS and GS).
>
> I can help in writing the patch (which kernel version), but I don't have much
> time right now.
>
> Gabriel
>
> ------------------------------
>
> From: Cristian Candet <ccris@romus.ro>
> Date: Tue, 7 Oct 1997 15:14:55 +0300 (EET DST)
> Subject: Another one?
>
> Hi guys.
>
> On my P166 machine running 2.0.30, I started a flood ping to one of
> the workstations on my net. When I launched a second flood ping on another
> workstation I got the following error:
>
> general protection: 0000
> CPU: 0
> EIP: 0010:[<0014b522>]
> EFLAGS: 00010206
> eax: 827d07c2 ebx: 02d06be8 ecx: 02d06be0 edx: 037cd188
> esi: 02276018 edi: 2b49e6c1 ebp: 02276018 esp: 03028f28
> ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> Process ping (pid: 12791, process nr: 45, stackpage=03028000)
> Stack: 00d17c0c 02be2e1c 02be2e7c 00140c4d 02276018 02d06be8 001e9160
> 2b49e6c1
> 0149e6c1 00000000 02be2e7c 001dfd60 00200008 02d06be8 00000001
> 00000000
> 00000000 00000001 ffffff00 00000001 0149e6c1 0805ba40 00000246
> 0013994c
> Call Trace: [<00140c4d>] [<0013994c>] [<001178af>] [<0010a57b>]
> Code: 66 8b 40 02 86 c4 25 ff ff 00 00 50 57 8b 42 24 0f b7 40 0c
> Aiee, killing interrupt handler
>
> The machine did not freeze and apparently everything seemed to be normal
> after this message. Anyway it's the second time when under this
> circumstances (2 flood pings) I get an error message. Do you find any
> meaning for this?
>
> - ----------------------------------------------
> Cristian Candet
> Network Administrator
> - ----------------------------------------------
> E-mail: ccris@romus.ro
> Alternate e-mail: ccris@lbi.ro
> Ripe Handle: CC58-RIPE
> Internic Handle: CC2501
> - ----------------------------------------------
> "If you want to call yourself a good shooter,
> first shoot and then call whatever you hit
> the TARGET..."
> - ----------------------------------------------
>
> ------------------------------
>
> From: Bill Hawes <whawes@star.net>
> Date: Tue, 07 Oct 1997 08:29:44 -0400
> Subject: Re: Directory slowness
>
> Steven N. Hirsch wrote:
>
> > Everything seems to work fine, but I've noticed that my file manager
> > (Midnight Commander) is taking about 6-8x longer to stat a large directory
> > (approx. 2200 files) than usual. Before I ifdef'ed the printk's out, the
> > dcache code reported a large amount of activity at this point. I'm
> > guessing that this slowdown is due to the shrinking algorithm?
>
> Hi Steve,
> Probably so, and we may have to back that out. Linus's comment in
> d_invalidate made it clear that he intended to do a shrink, but the
> invalidations happen very frequently, so it's wasting time. But I have
> come up with a good way to renew dentries following a successful
> operation, and this greatly lessens the number of invalidates. So the
> next patch for nfs client should be much faster in this respect.
>
> This seems to be one area where we'll need to do a lot of tuning and
> reworking ..
>
> BTW, I just got a message from someone saying nfs client didn't work on
> big directories. Have you run into any problems in this area?
>
> Regards,
> Bill
>
> ------------------------------
>
> From: Terje Malmedal <tm@odin.funcom.com>
> Date: Tue, 7 Oct 1997 14:16:50 +0200
> Subject: disk reporting in /proc/stat
>
> Linux will by default not report statistics for more than the four
> first disks in the system. This patch increases that to eight. Which
> is what I need. If anybody needs more all they need to do is to change
> DK_NDRIVE in kernel_stat.h
>
> I'm also including a patch against ftp.feral.com:/pub/linux/iostat.c
> to make it understand the new format.
>
> diff -ur linux-2.1.57/drivers/block/ll_rw_blk.c linux/drivers/block/ll_rw_blk.c
> - --- linux-2.1.57/drivers/block/ll_rw_blk.c Sat Aug 16 18:53:08 1997
> +++ linux/drivers/block/ll_rw_blk.c Sun Oct 5 16:57:33 1997
> @@ -252,7 +252,7 @@
> switch (MAJOR(req->rq_dev)) {
> case SCSI_DISK_MAJOR:
> disk_index = (MINOR(req->rq_dev) & 0x0070) >> 4;
> - - if (disk_index < 4)
> + if (disk_index < DK_NDRIVE)
> drive_stat_acct(req->cmd, req->nr_sectors, disk_index);
> break;
> case IDE0_MAJOR: /* same as HD_MAJOR */
> diff -ur linux-2.1.57/fs/proc/array.c linux/fs/proc/array.c
> - --- linux-2.1.57/fs/proc/array.c Sun Sep 21 19:50:01 1997
> +++ linux/fs/proc/array.c Tue Oct 7 13:48:20 1997
> @@ -28,6 +28,11 @@
> *
> * Yves Arrouye : remove removal of trailing spaces in get_array.
> * <Yves.Arrouye@marin.fdn.fr>
> + *
> + * Terje Malmedal : Increased number of disks reported on in /proc/stat
> + * to eight. To increase it further change DK_NDRIVE
> + * in kernel_stat.h.
> + * <tm@funcom.com>
> */
>
> #include <linux/types.h>
> @@ -210,7 +215,17 @@
>
> static int get_kstat(char * buffer)
> {
> - - int i, len;
> + static char* disk_params[] = {
> + "disk",
> + "disk_rio","disk_wio",
> + "disk_rblk","disk_wblk"
> + };
> + int* disk_info[] = {
> + kstat.dk_drive,
> + kstat.dk_drive_rio,kstat.dk_drive_wio,
> + kstat.dk_drive_rblk,kstat.dk_drive_wblk
> + };
> + int i, j, len;
> unsigned sum = 0;
> extern unsigned long total_forks;
> unsigned long ticks;
> @@ -219,29 +234,21 @@
> for (i = 0 ; i < NR_IRQS ; i++)
> sum += kstat.interrupts[i];
> len = sprintf(buffer,
> - - "cpu %u %u %u %lu\n"
> - - "disk %u %u %u %u\n"
> - - "disk_rio %u %u %u %u\n"
> - - "disk_wio %u %u %u %u\n"
> - - "disk_rblk %u %u %u %u\n"
> - - "disk_wblk %u %u %u %u\n"
> - - "page %u %u\n"
> - - "swap %u %u\n"
> - - "intr %u",
> + "cpu %u %u %u %lu\n",
> kstat.cpu_user,
> kstat.cpu_nice,
> kstat.cpu_system,
> - - ticks - (kstat.cpu_user + kstat.cpu_nice + kstat.cpu_system),
> - - kstat.dk_drive[0], kstat.dk_drive[1],
> - - kstat.dk_drive[2], kstat.dk_drive[3],
> - - kstat.dk_drive_rio[0], kstat.dk_drive_rio[1],
> - - kstat.dk_drive_rio[2], kstat.dk_drive_rio[3],
> - - kstat.dk_drive_wio[0], kstat.dk_drive_wio[1],
> - - kstat.dk_drive_wio[2], kstat.dk_drive_wio[3],
> - - kstat.dk_drive_rblk[0], kstat.dk_drive_rblk[1],
> - - kstat.dk_drive_rblk[2], kstat.dk_drive_rblk[3],
> - - kstat.dk_drive_wblk[0], kstat.dk_drive_wblk[1],
> - - kstat.dk_drive_wblk[2], kstat.dk_drive_wblk[3],
> + ticks - (kstat.cpu_user + kstat.cpu_nice + kstat.cpu_system));
> + for (j = 0; j < 5; j++) {
> + len += sprintf(buffer + len , disk_params[j] );
> + for (i = 0; i < DK_NDRIVE; i++)
> + len += sprintf(buffer + len," %u",disk_info[j][i]);
> + len += sprintf(buffer + len , "\n" );
> + }
> + len += sprintf(buffer + len,
> + "page %u %u\n"
> + "swap %u %u\n"
> + "intr %u",
> kstat.pgpgin,
> kstat.pgpgout,
> kstat.pswpin,
> diff -ur linux-2.1.57/include/linux/kernel_stat.h linux/include/linux/kernel_stat.h
> - --- linux-2.1.57/include/linux/kernel_stat.h Tue Jul 1 00:23:12 1997
> +++ linux/include/linux/kernel_stat.h Sun Oct 5 17:29:10 1997
> @@ -9,7 +9,7 @@
> * used by rstatd/perfmeter
> */
>
> - -#define DK_NDRIVE 4
> +#define DK_NDRIVE 8
>
> struct kernel_stat {
> unsigned int cpu_user, cpu_nice, cpu_system;
>
> - ----------------------------------------------------------------------------
> And now the patch against iostat.c
>
> - --- iostat.c.org Tue Oct 7 12:46:17 1997
> +++ iostat.c Tue Oct 7 13:28:25 1997
> @@ -60,15 +60,17 @@
> #define STATFILE "/proc/stat"
> #endif
>
> - -#define DK_NDRIVE 4
> +#define DK_NDRIVE 64
> #define CPU_USER 0
> #define CPU_NICE 1
> #define CPU_SYSTEM 2
> #define CPU_IDLE 3
>
> - -static int get_stats(unsigned int cpu[4], unsigned int dk[4]);
> +static int get_stats(unsigned int cpu[4], unsigned int dk[DK_NDRIVE]);
> static void print_hdr(void);
>
> +static int num_drives;
> +
> static inline double
> totcpu(unsigned int c[4])
> {
> @@ -100,7 +102,7 @@
> return (1);
> }
> print_hdr();
> - - for (i = 0; i < DK_NDRIVE; i++)
> + for (i = 0; i < num_drives; i++)
> fprintf(stdout, "% 8d", odk_drive[i]);
> lctime = ctime = totcpu(ocpu_times);
> fprintf(stdout, " %2.0f %2.0f %2.0f %2.0f\n",
> @@ -114,9 +116,9 @@
> sleep(sleepincr);
> if (get_stats(cpu_times, dk_drive))
> break;
> - - for (i = 0; i < DK_NDRIVE; i++)
> + for (i = 0; i < num_drives; i++)
> odk_drive[i] = dk_drive[i] - odk_drive[i];
> - - for (i = 0; i < DK_NDRIVE; i++) {
> + for (i = 0; i < num_drives; i++) {
> fprintf(stdout, "%8.0f",
> (double) odk_drive[i] / (double) sleepincr);
> odk_drive[i] = dk_drive[i];
> @@ -147,6 +149,8 @@
> int gotcpu, gotdk;
> char lbuf[132];
> FILE *statfp;
> + int i;
> + char *num;
>
> statfp = fopen(STATFILE, "r");
> if (statfp == NULL) {
> @@ -168,9 +172,13 @@
> continue;
> }
> if (strncmp(lbuf, "disk", 4) == 0) {
> - - if (sscanf(lbuf+5, "%u %u %u %u\n",
> - - &dk[0], &dk[1], &dk[2], &dk[3]) != 4) {
> - - fprintf(stderr, "bad disk line in %s\n", STATFILE);
> + i = 0;
> + num = strtok(lbuf," ");
> + while((num = strtok(NULL," ")) && i < DK_NDRIVE) {
> + dk[i] = atoi(num);
> + if(dk[i] > 0)
> + num_drives = i+1;
> + i++;
> }
> gotdk++;
> continue;
> @@ -184,7 +192,7 @@
> print_hdr(void)
> {
> int i;
> - - for (i = 0; i < DK_NDRIVE; i++) {
> + for (i = 0; i < num_drives; i++) {
> (void) fprintf(stdout, " dk%d", i);
> }
> fprintf(stdout, " us ni sy id\n");
>
> - --
> - Terje
> tm@funcom.com
>
> ------------------------------
>
> From: Stefan Mars <mars@lysator.liu.se>
> Date: Tue, 7 Oct 1997 13:47:25 +0200 (MET DST)
> Subject: 2.0.30 Kernel Panic
>
> I am trying to fix a problem with boot/root disks that I am experiencing.
> When I boot from the bootdisk I am asked to insert the root disk, which I
> do, and then everything bangs out with a VFS Kernel panic: Unable to mount
> virtual filesystem.
>
> I would suspect that it is a kernel problem, that's why I am asking here.
>
> How can I fix it?
>
> - -Stefan
>
> ------------------------------
>
> From: Shaleh <shaleh@livenet.net>
> Date: Tue, 07 Oct 1997 09:34:50 -0400
> Subject: cyrix patch: where???
>
> I am looking for the cyrix patch for 2.0.29. The only one I can find
> for 2.0.x is for .31-pre_something. Thanks for the assistance. The
> cyrix page posted a few days ago was fabulous, I love set6x86. My
> machine runs so much cooler!! However it had a patch for pre.
>
> ------------------------------
>
> From: Chris Evans <chris@ferret.lmh.ox.ac.uk>
> Date: Tue, 7 Oct 1997 14:53:57 +0100 (BST)
> Subject: Re: Q' about 'securelevel' for SA Magazine (LONG!)
>
> On Sun, 5 Oct 1997, Jim Dennis wrote:
>
> > Hi all,
> >
> > I'm writing another article for SysAdmin Magazine -- and I need
> > some answers to some questions:
> >
> > I'll be talking about the Linux ext2fs "immutable" and
> > "append-only" attributes (as set by 'chattr' and viewed
> > with 'lsattr') and the kernel 'securelevel' feature
> > (visible under /proc/sys/kernel/ and settable by 'sysctl')
> >
> > What is the current state of the securelevel feature?
> > (it seems to be "read-only" in the 2.0.30 kernels --
> > is it "stable" in the 2.1.5x betas?)
> >
> > What restrictions, precisely, are imposed at each
> > securelevel? (below are my impressions -- please correct
> > as necessary or confirm):
>
> Hi,
>
> Please see:
>
> http://parc.power.net/morgan/
>
> (or some similar address), and search though Orange-Linux -> Linux-privs.
>
> There is a patch there that extends the concept of securelevel to be a
> bitmap, and actually makes things like immutable etc. genuinely secure.
>
> > 0 -- none
> >
> > 1 -- disable chattr's (only on clearing -i and -a?)
> > disable writes to kmem
> > disable writes to raw block devices
> > disable loadable modules (except for kerneld?)
> > mount restricted to exact options/records
> > specified in /etc/fstab ?
> > clock/time settings can't be changed?
> > mark stack segments as noexec? (vmm)
>
> The combined patches cater for most of the important ones of these, and
> also take care of other "root ways to batter at the disk" such as
> ioperm()/iopl() etc., and some raw drive commands.
>
> > Can anyone here provide a summary of how that worked?
>
> I think the tradition is that only init (pid 1) may change the securelevel
> value to a less secure one than it currently is at. Unfortunately, it was
> possible to fiddle with the init process's image in memory via /proc/1/mem
> or something similar like that. This is taken care of in the Linux
> patches.
>
> > Where can I find the 'sysctl' command?
>
> It is a kernel function. RTM; man sysctl
>
> > What would a sample 'sysctl' command to increase securelevel
> > look like?
>
> It is most conveniently done via the /proc interface (enabled once more
> in the latest patches on the above site),
>
> ie. echo "some new value" > /proc/sys/kernel/securelevel
>
> > What other features will be accessible via the sysctl(8)
> > command?
>
> Anything under /proc/sys/
>
> > I've heard that a write() to /proc/sys/kernel/securevel
> > should allow one to increase the 'securelevel' setting.
> > Would a shell command such as 'echo 1 > ....' work for
> > that? If not, why not?
>
> securelevel is fine to be written to this way. /proc/sys entries
> containing multiple values to be written may cause problems unless your
> shell issues all the numbers with a single write() call.
>
> > Reducing 'securelevel' is supposed to require a
> > shutdown? Would this necessarily close all remote
> > connections to all network and other non-console devices?
>
> A shutdown or a hacked-up init. Shutdowns do indeed tend to close network
> connections ;-)
>
> > How do the current securelevel features affect
> > X Windows? SVGAlib? IPFW? Other "stuff"?
>
> Some of these things stop working in high security mode; it is necessary
> to deny X write access to /dev/kmem and iopl(). It tries to use both. I
> hope GGI will one day provide a solution for this problem! :)
>
> > Would it be fair to say that the Linux-Privs (Orange Linux)
> > work is not likely to be in the 2.2 kernel?
>
> ACL's for ext2 are partially written it would seem. They might well make
> 2.2 (drool). Don't hold your breath for the auditing stuff, but the
> splitting of root privs into capabilities could well be on target. (more
> drooling -- good security stuff this)
>
> Chris
>
> ------------------------------
>
> From: Ingo Molnar <mingo@pc7537.hil.siemens.at>
> Date: Tue, 7 Oct 1997 17:12:05 +0100 (MET)
> Subject: Re: Interrupt Latency.
>
> On Tue, 7 Oct 1997, Harald Koenig wrote:
>
> > > That is, if I put in a driver which responds to an interrupt simply by
> > > waggling an output bit on the parallel port or something similar, what kind of
> > > time delay will I see if I put a scope on it?
> >
> > I've tested this long time ago with Linux-1.0...1.3 with my 486DX2/66.
> > there I got ~11-12 usec interrupt latency (I just read the timer latch
> > in the clock timer ISR, then you exactly know how many usec it took
> > from timer countdown to get into the ISR...)
>
> i found this to be constant across CPUs (ie. 10 usecs on a pentium as
> well), this is probably due to the fact that PC compatible x86 irq
> handling does quite a few ISA cycles. Linux itself adds almost zero to
> this latency. (1-2 usecs, mainly due to setting the PIC which is in ISA
> space as well)
>
> APIC interrupts are much faster, i measured 4-5 usecs CPU-to-CPU IPI
> latencies, and under 1 usecs local APIC interrupts. (like the local APIC
> timer interrupt on SMP Linux). So if you want very good interrupt
> latencies, add a device to the local IRQ pin of the pentium processor.
> (there are 1 or 2 lines, but i've never done this).
>
> - -- mingo
>
> ------------------------------
>
> From: Hubert Mantel <mantel@suse.de>
> Date: Tue, 7 Oct 1997 16:18:25 +0200 (MEST)
> Subject: Security hole in linux-2.0.31-pre9 (NFS related)
>
> Hello,
>
> I just discovered the following behaviour:
>
> Given the following file:
>
> Mandelbrot:/home/alex/mantel/Kernel # l test
> - -rw------- 1 mantel suse 149 Oct 7 16:09 test
>
> The file is on a NFS-mounted filesystem with root_squash, so root cannot
> read the file:
>
> Mandelbrot:/home/alex/mantel/Kernel # cat test
> cat: test: I/O error
> Mandelbrot:/home/alex/mantel/Kernel # cat test
> cat: test: Permission denied
>
> Now, after the owner has read the file on the same machine, it is readable
> by root afterwards:
>
> Mandelbrot:/home/alex/mantel/Kernel # cat test
> blabla
>
> Seems like some problem with the NFS caching code?
> The server is running linux-2.0.31-pre2(DaveM), the client is running
> linux-2.0.31-pre9(Linus).
>
> Hubert
>
> ------------------------------
>
> From: "Michael K. Johnson" <johnsonm@redhat.com>
> Date: Tue, 07 Oct 1997 14:53:28 +0000
> Subject: Re: Strange file system problem with 2.0.31pre10
>
> Jonathan Stanton writes:
> > It seems that somehow one of the caches (page, buffer, ??) is
> >getting corrupted and I can't seem to force it to reread the reality on
> >the disk without a reboot. If I do a copy of the 'corrupted' binary to
> >another location (like /var/tmp/ ) I get a copy of the binary that stays
> >corrupted upon reboot (which is how I generated the attached 'cmp' file).
>
> Hmm. I'm guessing hardware problems. Here's why:
>
> The corruption occurs on 8-byte boundaries, and the corruption involves
> setting the first four bits -- notice that the broken characters always
> end in {1,3,5,7}7? The offsets are mostly 8 bytes apart, but some are
> 16 apart -- presumably the missing character in the middle already had
> those bits set. Also, the first corrupted section is 4088 bytes, 8
> less than 4096, and 1245189 is almost exactly page-aligned; the whole
> section fits in one page. The second block is also approximately one
> page, 4040 bytes, and is page-aligned.
>
> And since this problem is, relatively speaking, very rare and hard for
> you to trigger, I can easily believe that it would simply not have been
> triggered under a different kernel.
>
> > I don't know if this could have anything to do with this, but I
> >have also been testing devel kernels, and all of them from 2.1.51 to the
> >current 57 have had severe file system corruption--not of the above kind,
> >but the 'EXT2-FS Error' type and hundreds of inodes corrupted and
> >direcotries attached to the wrong place /usr/man/man1/ps.1.gz is really a
> >direcotory holding the linux/drivers/net subdirectory of my kernel tree
> >for example.
>
> This makes it even more likely that it is hardware -- the same problem
> could have wildly different results if it happens while reading an inode
> in.
>
> Doug Ledford recently posted about problems with SDRAM in PPros. Any
> chance that's what you've got?
>
> Also, try turning off DMA in the ide driver and see if that fixes the
> problem. But Mark Lord would know far more about that than I would.
>
> michaelkjohnson
>
> "Magazines all too frequently lead to books and should be regarded by the
> prudent as the heavy petting of literature." -- Fran Lebowitz
>
> ------------------------------
>
> From: Jim Dennis <jimd@starshine.org>
> Date: Tue, 07 Oct 1997 07:59:58 -0700
> Subject: Re: suidpid( UID, credential? ) ? secure IPC?
>
>
> > Instead of a suidpid() call, a more general, and much more interesting
> > mechanism to think about creating would be a "protected shared library"
> > mechanism.
>
> With all due respect I don't want "more interesting" --
> I want "more secure" and "more confidence inspiring."
>
> sendmail is "interesting"
> tcp_wrappers is closer to what I want.
>
>
> > The basic idea is that while code in a protected shared library is
> > executing, it has some level of privileges which is different from when
> > the normal program is running. Jumps into protected shared library from
> > the normal program is only allowed at certain "call gates", to programs
> > from trying to spoof the library by jumping into the middle of the
> > routine. Naturally, any data pages used by the protected shared library
> > would be read protected against the unprivileged portion of the program
> > unless the PSL is itself actually running.
> >
> > This allows you to do all sorts of very interesting things all in
> > userspace, without needing extra special-purpose system calls and
> > without requiring an IPC mechanism. It does require a kernel
> > context-switch to enter and leave a PSL, but if it's done properly, that
> > should be the only overhead.
> >
> > - Ted
>
> But it's still SUID. Now you'd have SUID shared libraries
> -- yuck! What's wrong with a client/server model? Define
> protocols and implement some means of passing resources
> (such as open file handles) and delegating privileges
> (such as access to a given "privileged" TCP port).
>
> The more I think about it the more I see why KeyKOS, EROS,
> Hydra and other "research" OS' espouse "capabilities."
> I just wonder how a "capabilities" subsystem could be
> implemented in Linux -- with some hope of applications
> transparency.
>
> - --
> Jim Dennis (800) 938-4078 consulting@starshine.org
> Proprietor, Starshine Technical Services: http://www.starshine.org
> PGP 1024/2ABF03B1 Jim Dennis <jim@starshine.org>
> Key fingerprint = 2524E3FEF0922A84 A27BDEDB38EBB95A
>
> ------------------------------
>
> From: Peeter Joot <peeter@accessv.com>
> Date: Tue, 07 Oct 1997 11:33:20 -0400
> Subject: patch for CLONE_PID enhancements to clone()
>
> Hello Everybody,
>
> I have made a patch against 2.1.57 that introduces the start of some
> extra
> functionality for clone() called with CLONE_PID.
>
> I have put it at http://www.accessv.com/~peeter/patch-tid.2.1.57-2.gz
> for reference for anybody who wants to examine what I am doing and
> comment
> on it. I could also post it to this list but the size (about 30K) may
> be too
> big for that. It is not advisable to use it as it is now, as I found
> after
> trying it that it breaks shutdown (but nothing else that I noticed :).
> I have probably messed up kill_proc() wrt init, but I haven't looked
> into it yet.
>
> The idea is to allow the CLONE_PID flag to have cloned tasks (not just
> init
> on SMP) be able to share PIDs, and this patch makes some of the changes
> that
> I thought were neccessary for this. Note that nothing has been done
> with
> proc yet, as I don't know exactly how to handle hashing the pid/tids
> into
> the proc inode space.
>
> Most of the changes in this patch are simple changes due to the
> following change in sched.h. I have taken a number of fields out of
> struct task struct and placed them into a separate structure called
> struct process_struct, along with the addition of a 'struct
> process_struct * ps' in struct task struct. When thinking about
> processes that shared pids it didn't seem right that things like the
> uid, gid, groups, ... were different. So, if CLONE_PID is specified in
> the clone flags then threads created reference the same struct
> process_struct. I have put anything that seemed like it should go into
> this structure into this structure, but I would like comments about
> the appropriateness of my choices and whether I have missed anything
> (like
> rlim ?).
>
> As to the other changes, things like do_fork() have been modified to
> set the tid field, and some of the system calls that had pid arguments
> have new varients that take both a pid, and a tid (sys_kill,
> sys_wait4, ...), but these have not been exposed to the user yet via the
>
> syscall mechanisms.
>
> Here is the new structure in question:
>
> struct process_struct {
> /* new fields:
> */
> int last_tid, next_safe;
> int count;
> spinlock_t pslock;
> /* things that were in task_struct:
> */
> int pgrp;
> int tty_old_pgrp;
> int session;
> /* boolean value for session group leader */
> int leader;
> int ngroups;
> gid_t groups[NGROUPS];
> unsigned short uid,euid,suid,fsuid;
> unsigned short gid,egid,sgid,fsgid;
> struct tty_struct *tty; /* NULL if no tty */
> };
>
> I have also added an 'int tid' field to task_struct for holding the
> thread id. This seemed much simpler than encoding the tid in the upper
> pid bits, and doesn't break any experimental code that is currently
> using those bits for other stuff. Within process_struct are also a few
> new fields that weren't in task_struct: last_tid, next_safe, count,
> and pslock.
>
> o last_tid, and next_safe are comparable to the global next_safe
>
> and last_pid variables in fork.c for the do_fork() pid
> allocation.
> o count is a for a reference count on the process struct so that
> it
> doesn't get deleted while some other task is referencing it.
> o pslock is for SMP locking of this structure. Note that I have
> only started putting locks in a few places so far. However if
> this patch was integrated into the kernel nothing should break
>
> SMP-wise because nothing should be using the CLONE_PID clone()
>
> flag.
>
> I would appreciate any comments and suggestions. Thank you,
>
> Peeter
>
> ------------------------------
>
> From: Pavel Machek <pavel@atrey.karlin.mff.cuni.cz>
> Date: Tue, 7 Oct 1997 18:12:03 +0200
> Subject: Re: Security hole in linux-2.0.31-pre9 (NFS related)
>
> Hi!
>
> > The file is on a NFS-mounted filesystem with root_squash, so root cannot
> > read the file:
> >
> > Mandelbrot:/home/alex/mantel/Kernel # cat test
> > cat: test: I/O error
> > Mandelbrot:/home/alex/mantel/Kernel # cat test
> > cat: test: Permission denied
> >
> > Now, after the owner has read the file on the same machine, it is readable
> > by root afterwards:
> >
> > Mandelbrot:/home/alex/mantel/Kernel # cat test
> > blabla
>
> This _has_ to be this way. Imagine root su-ing to given user (he can
> do that). Nono. You'll need all-squash.
>
> Pavel
>
> - --
> - --
> This is my little buggy signature... Pavel
> GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+
>
> ------------------------------
>
> From: "Michael K. Johnson" <johnsonm@redhat.com>
> Date: Tue, 07 Oct 1997 16:24:32 +0000
> Subject: Re: suidpid( UID, credential? ) ? secure IPC?
>
> Jim Dennis writes:
> > The more I think about it the more I see why KeyKOS, EROS,
> > Hydra and other "research" OS' espouse "capabilities."
> > I just wonder how a "capabilities" subsystem could be
> > implemented in Linux -- with some hope of applications
> > transparency.
>
> So why not join the linux-privs list that has been announced several
> times on this list? (Ted started the list; he's not unaware of
> capabilities... :-) They are working on an implementation of POSIX.1e
> capabilities for Linux.
>
> See
> http://parc.power.net/morgan/Orange-Linux/linux-privs/sampler/index.html
> for more information.
>
> michaelkjohnson
>
> "Magazines all too frequently lead to books and should be regarded by the
> prudent as the heavy petting of literature." -- Fran Lebowitz
>
> ------------------------------
>
> From: Cristian Candet <ccris@romus.ro>
> Date: Tue, 7 Oct 1997 20:09:47 +0300 (EET DST)
> Subject: Re: Another one?
>
> On Tue, 7 Oct 1997, Pavel Machek wrote:
>
> > >
> > > Hi guys.
> > >
> > > On my P166 machine running 2.0.30, I started a flood ping to one of
> > > the workstations on my net. When I launched a second flood ping on another
> > > workstation I got the following error:
> >
> > Translate numbers, tell us type of your netcard and say _which_
> > machine dies.
> As I said, none of the machines dies, I only get this message on
> my linux (the workstations have Win95 installed on them). All machines
> are equipped with Novell NE2000 Plus network cards.
> >
> > > general protection: 0000
> > > CPU: 0
> > > EIP: 0010:[<0014b522>]
> > > EFLAGS: 00010206
> > > eax: 827d07c2 ebx: 02d06be8 ecx: 02d06be0 edx: 037cd188
> > > esi: 02276018 edi: 2b49e6c1 ebp: 02276018 esp: 03028f28
> > > ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018
> > > Process ping (pid: 12791, process nr: 45, stackpage=03028000)
> > > Stack: 00d17c0c 02be2e1c 02be2e7c 00140c4d 02276018 02d06be8 001e9160
> > > 2b49e6c1
> > > 0149e6c1 00000000 02be2e7c 001dfd60 00200008 02d06be8 00000001
> > > 00000000
> > > 00000000 00000001 ffffff00 00000001 0149e6c1 0805ba40 00000246
> > > 0013994c
> > > Call Trace: [<00140c4d>] [<0013994c>] [<001178af>] [<0010a57b>]
> > > Code: 66 8b 40 02 86 c4 25 ff ff 00 00 50 57 8b 42 24 0f b7 40 0c
> > > Aiee, killing interrupt handler
> > >
> > > The machine (linux box) did not freeze and apparently everything
> > > seemed to be normal
> > > after this message. Anyway it's the second time when under this
> > > circumstances (2 flood pings) I get an error message. Do you find any
> > > meaning for this?
>
> - ----------------------------------------------
> Cristian Candet
> Network Administrator
> - ----------------------------------------------
> E-mail: ccris@romus.ro
> Alternate e-mail: ccris@lbi.ro
> Ripe Handle: CC58-RIPE
> Internic Handle: CC2501
> - ----------------------------------------------
> "If you want to call yourself a good shooter,
> first shoot and then call whatever you hit
> the TARGET..."
> - ----------------------------------------------
>
> ------------------------------
>
> From: Hubert Mantel <mantel@suse.de>
> Date: Tue, 7 Oct 1997 19:50:07 +0200 (MEST)
> Subject: Re: Security hole in linux-2.0.31-pre9 (NFS related)
>
> Hi,
>
> On Tue, 7 Oct 1997, Pavel Machek wrote:
>
> > > The file is on a NFS-mounted filesystem with root_squash, so root cannot
> > > read the file:
> > >
> > > Mandelbrot:/home/alex/mantel/Kernel # cat test
> > > cat: test: I/O error
> > > Mandelbrot:/home/alex/mantel/Kernel # cat test
> > > cat: test: Permission denied
> > >
> > > Now, after the owner has read the file on the same machine, it is readable
> > > by root afterwards:
> > >
> > > Mandelbrot:/home/alex/mantel/Kernel # cat test
> > > blabla
> >
> > This _has_ to be this way. Imagine root su-ing to given user (he can
> > do that). Nono. You'll need all-squash.
>
> You're right. This bug doesn't open any new security hole. So it's simply
> ugly ;-)
>
> > Pavel
>
> Hubert
>
> ------------------------------
>
> From: Thorsten Kalkbrenner <tk@wh36-b404.stud.uni-karlsruhe.de>
> Date: Tue, 7 Oct 1997 19:14:49 +0200
> Subject: Re: cyrix patch: where???
>
> In article <343A3A7A.BB52D90D@livenet.net> you wrote:
> : I am looking for the cyrix patch for 2.0.29. The only one I can find
> : for 2.0.x is for .31-pre_something. Thanks for the assistance. The
> : cyrix page posted a few days ago was fabulous, I love set6x86. My
> : machine runs so much cooler!! However it had a patch for pre.
>
> hi it is called: 20-cyrix-2.patch
>
> sorry, not more time :)
>
> Thorsten
>
> - --- linux/Documentation/Configure.help.noCyrix Mon Jun 16 09:39:26 1997
> +++ linux/Documentation/Configure.help Tue Jun 17 22:06:26 1997
> @@ -690,18 +690,112 @@
> later load the module when you install the JDK or find an interesting
> Java program that you can't live without.
>
> - -Processor type
> +Processor family
> CONFIG_M386
> This is the processor type of your CPU. It is used for optimizing
> - - purposes. In order to compile a kernel that can run on all CPU types
> - - (albeit not optimally fast), you can specify "386" here. If you
> - - specify "486" or "Pentium" or "PPro", then the kernel will run on
> - - 486 and Pentium (=586) and Pentium Pro (=686) CPUs. In rare cases,
> - - it can make sense to specify "Pentium" even if running a 486: the
> - - kernel will be smaller but slower. On the other hand, if you use a
> - - compiler before gcc 2.7 (say "gcc -v" to find out), then you have to
> - - say "386" or "486" here even if running on a Pentium or PPro
> + purposes. In order to compile a kernel that can run on all ix86 CPU
> + types (albeit not optimally fast), you can specify "386" here. If
> + you specify "486" or "Pentium" or "PPro", then the kernel will run
> + on 486 and Pentium (=586) and Pentium Pro (=686) CPUs. In rare
> + cases, it can make sense to specify "Pentium" even if running a 486:
> + the kernel will be smaller but slower. On the other hand, if you use
> + a compiler before gcc 2.7 (say "gcc -v" to find out), then you have
> + to say "386" or "486" here even if running on a Pentium or PPro
> machine. If you don't know what to do, say "386".
> +
> +Support for Cyrix processors
> +CONFIG_CYRIX
> + This enables recognition of Cyrix processors. Without it
> + /proc/cpuinfo will list your processor as an unknown model
> + of Cyrix. With it it will list the correct details. It should
> + be safe to say Y here regardless of what processor you are
> + actually using. If this option is not enabled none of the
> + Cyrix feature options are available.
> +
> +Enable suspend on halt power saving feature
> +CONFIG_CYRIX_SUSP_HLT
> + Suspend on halt causes the processor to enter a low power state
> + when the "hlt" instruction is executed. This is disabled at
> + power up and many BIOSs leave it that way. You probably want it
> + enabled since it dramatically reduces the operating temperature
> + of the processor. In a few rare cases there may be problems
> + with some bus master DMA cards if this is enabled.
> +
> +No I/O recovery delays
> +CONFIG_CYRIX_FAST_IO
> + Historically programmers used "jmp $+2" instructions to create
> + delays between I/O instructions. The branch prediction of 5x86
> + and higher processors renders this ineffective and so a selectable
> + delay is implemented for I/O instructions in the processor. Linux
> + uses dummy I/O instructions where necessary rather than jumps
> + and so the extra processor imposed delay should not be necessary.
> + Enabling this option removes this delay.
> +
> +5x86 performance features
> +CONFIG_CYRIX_5X86
> + The Cyrix 5x86 has several performance feature which are enabled
> + using on-chip registers. This code attempts to ensure that the
> + useful features are set to suit Linux. Read Documentation/Cyrix
> + before enabling this.
> + WARNING: If this is enabled you may find that the only way to
> + reboot is to power cycle the machine. Even a hard reboot seems
> + to fail on some systems.
> +
> +6x86 performance features
> +CONFIG_CYRIX_6X86
> + The Cyrix 6x86 has several performance feature which are enabled
> + using on-chip registers. Most are normally enabled by the BIOS
> + however this code ensures that all the useful ones are set to
> + suit Linux. Read Documentation/Cyrix before enabling this.
> +
> +Avoid unnecessary locked cycles
> +CONFIG_CYRIX_6X86_NOLOCK
> + Enabling this option causes the 6x86 not to use locked bus cycles
> + except for page table access and interrupt acknowledge cycles.
> + This allows the data used by descriptor tables, xchg instructions
> + and instructions preceeded by the LOCK prefix to be cached leading
> + to improved performance. Enabling this option has no effect if
> + an SMP kernel is being built - SMP requires locked cycles to
> + guarantee processor synchronization.
> +
> +Allocate L1 cache lines on write misses
> +CONFIG_CYRIX_6X86_WTALLOC
> + If this is enabled L1 cache write misses will cause a cache line
> + to be allocated. This may result in increased performance. On the
> + other hand it may cause excessive trashing of the L1 cache when
> + copying or zeroing pages.
> +
> +Branch Target Buffer features
> +CONFIG_CYRIX_6X86_BTB
> + The Cyrix 6x86 has branch prediction logic.
> + Enabling this option resets BTB configuration to reasonable values.
> +
> +BTB risky features
> +CONFIG_CYRIX_6X86_BTB_RISKY
> + Sets Bit 4 of BTB register 5. This results in better performance
> + (context switching) but sometimes causes problems, e.g. when
> + running X.
> +
> +Variable sized paging mechanism (VSPM)
> +CONFIG_CYRIX_6X86_VSPM
> + Variable sized paging mechanism (VSPM) is a feature of the Cyrix
> + 6x86 family of processors that allows large regions of memory
> + to be mapped in one go, significantly reducing the amount of work
> + the MMU has to do compared with traditional paging. However VSPM
> + is known to be buggy in many 6x86 chip revisions. Please read
> + Documentation/Cyrix before enabling this.
> + WARNING: If this is enabled you may find that the only way to
> + reboot is to power cycle the machine. Even a hard reboot seems
> + to fail on some systems.
> +
> +VSPM No traditional pages
> +CONFIG_CYRIX_6X86_VSPM_NOTRADPAGE
> + When you enable VSPM, normally traditional page table entries are
> + created (but not used by the 6x86). These PTEs enable the kernel
> + to unset VSPM (on 1rev7 or better) before rebooting, thus enabling
> + other Protected Mode OSes to be warm booted.
> + Enabling this option disables the creation of traditional page
> + table entries and thus unsetting of VSPM on (warm) reboot.
>
> Compile the kernel into the ELF object format
> CONFIG_ELF_KERNEL
> - --- /dev/null Mon Aug 26 02:21:17 1996
> +++ linux/Documentation/Cyrix Tue Jun 17 22:37:38 1997
> @@ -0,0 +1,189 @@
> + Cyrix Processor Support
> + -----------------------
> +
> +Processor Recognition
> +---------------------
> +
> +Cyrix processors prior to the M2 power up in a default mode which
> +is designed to avoid compatibility problems with software that
> +makes assumptions about processor capabilities based solely on
> +the apparent family of processor. Unless special handling is
> +provided Cyrix chips will be identified as some unknown model
> +of 486.
> +
> + The Cyrix processor recognition kernel build option compiles
> +in code that enables the CPUID instruction on Cyrix processors
> +and that uses the Cyrix specific DEVID feature to identify the
> +particular type of Cyrix chip present.
> +
> + The M2 and later processors have CPUID enabled by default
> +however special handling is still required to read the specific
> +processor type using DEVID since the CPUID information gives
> +family 6, model 0 - i.e. an A step PPro.
> +
> + The combination of CPUID and DEVID allows all current Cyrix
> +processors to be recognised and listed correctly in /proc/cpuinfo.
> +This includes Cx486, 5x86, 6x86, Gx86 (aka MediaGx) and M2.
> +
> + Processor recognition is required for all other Cyrix specific
> +options.
> +
> +
> +Suspend on Halt Power Saving
> +----------------------------
> +
> +The suspend on halt power saving feature allows the processor to
> +enter a low power mode when the "hlt" instruction is executed. This
> +results in dramatically reduced operating temperatures if you do
> +not spend long periods of time running processor intensive tasks.
> +Cyrix processors allow this feature to be enabled an disabled
> +through their configuration registers. The default state on reset
> +is disabled and many (most?) BIOSs leave it disabled hence a
> +kernel configuration option is provided that adds code to explicitly
> +enabled suspend on halt when Linux boots.
> +
> + However there appear to be a few rare cases in which the
> +combination of suspend on halt and some bus master DMA cards can
> +cause the system to lock up. If this appears to happen you may
> +need to leave suspend on halt in its default state. (Note that
> +an option to _disable_ suspend on halt is not provided. If your
> +BIOS enables it you have to live with it)
> +
> +
> +5x86 Performance Features
> +-------------------------
> +
> +The 5x86 contains a performance control register that allows
> +several performance enhancing features to be turned on. Unfortunately
> +many of these features do not appear to work correctly. The 5x86
> +performance features kernel build option will attempt to set
> +the performance control register appropriately but it is
> +impossible to guarantee that even these conservative settings
> +will work on all chips.
> +
> + WARNING: If this is enabled you may find that the only way to
> +reboot is to power cycle the machine. Even a hard reboot seems
> +to fail on some systems.
> +
> +
> +6x86 Performance Features
> +-------------------------
> +
> +Like the 5x86 the 6x86 has several Cyrix specific performance
> +features. Normally a 6x86 aware BIOS will set these to reasonable,
> +if not fully optimal, settings. The 6x86 performance features
> +kernel build option mostly just fine tunes them.
> +
> +
> +6x86 Branch Prediction
> +----------------------
> +
> +The 6x86 uses speculative execution coupled with several levels
> +of branch prediction to maximise processing speed. While the
> +default power up state is reasonable the branch prediction logic
> +is configurable and there may be some benefit in fine tuning it.
> +
> + Unfortunately Cyrix offer no documentation on how to configure
> +branch prediction and IBM have only partial documentation available.
> +Further detail and speculation is available from the 6x86opt package
> +by Mikael Johansson <Mikael.Johansson@helsinki.fi>.
> +
> + The initial power up state of the 6x86 configures the branch
> +prediction logic to handle short branches. The 6x86 branch target
> +buffer features kernel build option enables code that sets the
> +BTB configuration to reasonable values, if BIOS or power on state
> +are not satisfactory.
> +There is also a risky option, which sets an additional BTB config
> +bit. It's risky, because it can cause system hangs, esp. when
> +running X, but you gain some speed (context switching).
> +
> +
> +6x86 Variable Sized Paging Mechanism
> +------------------------------------
> +
> +The variable sized paging mechanism (VSPM) is a feature of the Cyrix
> +6x86 family of processors that allows large regions of memory
> +to be mapped using a single MMU entry rather than many individual
> +page sized entries. This significantly reduces the overhead in
> +accessing such regions. It is also ideally suited to use for the
> +linear mapping of physical memory to kernel memory used by Linux.
> +
> + The Cyrix documenation offers only a brief paragraph of explanation.
> +Unfortunately the observed behaviour of VSPM suggests that even
> +this little information is not entirely correct. Worse still, no one
> +at Cyrix is able to answer questions concerning VSPM. Given that
> +every revision of 6x86 has *different* VSPM bugs this is not entirely
> +surprising! Work arounds are in place for the known bugs in step 1,
> +revisions 4, 5 and 6 chips. Revision 7 is also believed to work.
> +
> + WARNING: There appears to be no way to disable a VSPM entry once
> +it has been created short of a hard reset (which may mean a power
> +cycle). Failure to clear the VSPM entries means that programs that
> +use virtual memory layouts different from Linux will crash unexpectedly
> +after Linux has been running. This includes Windows NT/95, programs
> +that use DOS extenders etc.
> +
> + By experiment:
> +
> + * VSPM pages must be power of two sizes. A single 24MB page fails.
> + This is not entirely surprising but the documentation could give
> + the impression that VSPM supports arbitrary sizes.
> +
> + * Documentation suggests there are 8 VSPM slots (3 bit index) but
> + tests show the upper four slots mirror the lower four.
> +
> + * VSPM entries appear to override traditional page table entries
> + so we must not overlap the start of the vmalloc region.
> +
> + The following only apply to 6x86 1 rev 6 or lower, 1 rev 7 and up
> +seem not to have these restrictions.
> +
> + * With a 16MB page followed by an 8MB page I always get a write
> + fault on the last 4k of the 8MB page. With 8MB plus 4MB I can't
> + even boot.
> + If we have such a memory size we map the first power of two
> + with a VSPM entry and use traditional paging for the rest.
> +
> + * Do not try and create a mapping with dirty and accessed flags
> + clear - a step 1 rev 5 chip will crash.
> +
> + * The valid bit in a VSPM entry is non-functional. There is no way
> + to invalidate a VSPM entry once it has been written
> +
> + * Attempting to replace a VSPM entry with one that maps a zero
> + sized region from 0 to 0 crashes the CPU.
> +
> +
> +What more could be done
> +-----------------------
> +
> + The 6x86 allows Address regions to be set up and en/disabling
> +certain features for these regions. In order to optimize, we could
> +analyse the setup done (or not done) by the BIOS and optimize it.
> +
> + * Setting up regions fo the main memory: RCE, WWO, WL(?), WG
> +
> + * Setting up VGA text (0x000a0000) and graphics memory (PCI:
> + e.g. 0xe0000000) to RCD, WG
> +
> + * Setting up BIOS regions to RCD or RCE, WT
> +
> + * Not touching SMM space (ARR3)
> +
> + * Disabling WG for Memory Mapped IO
> +
> +(RCE/D = Region cache enable/disable, WWO = Weak Write Ordering,
> +WL = Weak Locking, WG = Write Gathering, WT = Write Through.)
> +
> +
> +Where to get information
> +------------------------
> +
> + There is a databook in PDF format (6X-DBOOK.PDF), which can be down-
> +loaded from Cyrix' WWW server, which contains a description of the
> +Configuration Registers CCR0 - CCR5, the Device Identification Registers
> +DIR0 + DIR1 and the Address Region ARRx and Region Control
> +RCRx registers and an incomplete description of the VSPM mechanism.
> +More about CPU detection, VSPM and more undocumented features can be
> +found on the Pentium Compiler Group homepage (http://www.goof.com/pcg)
> +and by following the links found in the docs.
> - --- linux/arch/i386/config.in.noCyrix Mon Jun 16 09:40:34 1997
> +++ linux/arch/i386/config.in Tue Jun 17 21:59:59 1997
> @@ -37,13 +37,42 @@
> if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
> tristate 'Kernel support for JAVA binaries' CONFIG_BINFMT_JAVA
> fi
> +
> bool 'Compile kernel as ELF - if your GCC is ELF-GCC' CONFIG_KERNEL_ELF
>
> - -choice 'Processor type' \
> +choice 'Processor family' \
> "386 CONFIG_M386 \
> 486 CONFIG_M486 \
> Pentium CONFIG_M586 \
> PPro CONFIG_M686" Pentium
> +endmenu
> +
> +mainmenu_option next_comment
> +comment 'Processor features'
> +
> +comment 'Some or all of the following may cause problems'
> +comment 'with some drivers or hardware. Please read the'
> +comment 'help text and Documentation/Cyrix before enabling'
> +comment 'any of these options.'
> +bool 'Cyrix processor recognition' CONFIG_CYRIX
> +if [ "$CONFIG_CYRIX" = "y" ]; then
> + bool 'Enable suspend on halt power saving' CONFIG_CYRIX_SUSP_HLT
> + bool 'No I/O recovery delays' CONFIG_CYRIX_FAST_IO
> + bool '5x86 performance features' CONFIG_CYRIX_5X86
> + bool '6x86 performance features' CONFIG_CYRIX_6X86
> + if [ "$CONFIG_CYRIX_6X86" = "y" ]; then
> + bool ' Avoid unnecessary locked cycles' CONFIG_CYRIX_6X86_NOLOCK
> + bool ' Allocate L1 cache lines on write misses' CONFIG_CYRIX_6X86_WTALLOC
> + bool ' Branch Target Buffer features' CONFIG_CYRIX_6X86_BTB
> + if [ "$CONFIG_CYRIX_6X86_BTB" = "y" ]; then
> + bool ' BTB risky features' CONFIG_CYRIX_6X86_BTB_RISKY
> + fi
> + bool ' Variable sized paging mechanism (VSPM)' CONFIG_CYRIX_6X86_VSPM
> + if [ "$CONFIG_CYRIX_6X86_VSPM" = "y" ]; then
> + bool ' VSPM disable traditional pages' CONFIG_CYRIX_6X86_VSPM_NOTRADPAGE
> + fi
> + fi
> +fi
> endmenu
>
> source drivers/block/Config.in
> - --- linux/arch/i386/defconfig.noCyrix Mon Jun 16 09:45:16 1997
> +++ linux/arch/i386/defconfig Tue Jun 17 22:00:15 1997
> @@ -27,8 +27,19 @@
> CONFIG_KERNEL_ELF=y
> # CONFIG_M386 is not set
> # CONFIG_M486 is not set
> - -CONFIG_M586=y
> - -# CONFIG_M686 is not set
> +# CONFIG_M586 is not set
> +CONFIG_M686=y
> +CONFIG_CYRIX=y
> +CONFIG_CYRIX_SUSP_HLT=y
> +# CONFIG_CYRIX_FAST_IO is not set
> +# CONFIG_CYRIX_5X86 is not set
> +# CONFIG_CYRIX_6X86 is not set
> +# CONFIG_CYRIX_6X86_NOLOCK is not set
> +# CONFIG_CYRIX_6X86_WTALLOC is not set
> +# CONFIG_CYRIX_6X86_BTB is not set
> +# CONFIG_CYRIX_6X86_BTB_RISKY is not set
> +# CONFIG_CYRIX_6X86_VSPM is not set
> +# CONFIG_CYRIX_6X86_VSPM_NOTRADPAGE is not set
>
> #
> # Floppy, IDE, and other block devices
> - --- linux/include/asm-i386/processor.h.noCyrix Mon Jan 20 14:45:06 1997
> +++ linux/include/asm-i386/processor.h Tue Jun 17 00:19:47 1997
> @@ -16,7 +16,7 @@
> */
>
> extern char hard_math;
> - -extern char x86; /* lower 4 bits */
> +extern char x86; /* upper 4 bits=vendor, lower 4 bits=family */
> extern char x86_vendor_id[13];
> extern char x86_model; /* lower 4 bits */
> extern char x86_mask; /* lower 4 bits */
> @@ -148,6 +148,22 @@
> extern inline unsigned long thread_saved_pc(struct thread_struct *t)
> {
> return ((unsigned long *)t->esp)[3];
> +}
> +
> +extern inline void cpuid(int op, int *eax, int *ebx, int *ecx, int *edx)
> +{
> + __asm__("movl %4,%%eax\n\t"
> + ".byte 0x0f, 0xa2\n\t"
> + "movl %%eax,%0\n\t"
> + "movl %%ebx,%1\n\t"
> + "movl %%ecx,%2\n\t"
> + "movl %%edx,%3\n\t"
> + : "=m" (*eax),
> + "=m" (*ebx),
> + "=m" (*ecx),
> + "=m" (*edx)
> + : "g" (op)
> + : "eax", "ebx", "ecx", "edx", "cc");
> }
>
> #endif /* __ASM_I386_PROCESSOR_H */
> - --- linux/include/asm-i386/bugs.h.noCyrix Mon Jun 16 23:22:16 1997
> +++ linux/include/asm-i386/bugs.h Tue Jun 17 15:44:06 1997
> @@ -130,5 +130,5 @@
> check_tlb();
> check_fpu();
> check_hlt();
> - - system_utsname.machine[1] = '0' + x86;
> + system_utsname.machine[1] = '0' + (x86 & 0x0f);
> }
> - --- linux/arch/i386/kernel/head.S.noCyrix Mon Jun 23 15:13:14 1997
> +++ linux/arch/i386/kernel/head.S Mon Jun 23 15:23:12 1997
> @@ -103,13 +103,80 @@
> checkCPUtype:
> #endif
>
> + movl $-1,SYMBOL_NAME(have_cpuid) # -1 for no CPUID initially
> +
> /* check if it is 486 or 386. */
> /*
> * XXX - this does a lot of unnecessary setup. Alignment checks don't
> * apply at our cpl of 0 and the stack ought to be aligned already, and
> * we don't need to preserve eflags.
> */
> - - movl $3, SYMBOL_NAME(x86)
> + /*
> + * A Cyrix preserves flags in cases where other CPUs change
> + * them in undefined ways. We need to know this since we may
> + * need to enable the CPUID instruction at least. (Cyrix chips
> + * prior to M2 have CPUID disabled by default, the Cx486s
> + * didn't have it at all.)
> + */
> + xor %ax,%ax
> + sahf
> + movb $5,%ax
> + movb $2,%bx
> + div %bl
> + lahf
> + cmpb $2,%ah
> + jne ncyrix
> +
> + /*
> + * It behaves like a Cyrix so put "Cyrix" in the vendor id
> + * field. It may be overwritten later with the real thing
> + * if CPUID works.
> + */
> + movl $0x69727943,SYMBOL_NAME(x86_vendor_id) # low 4 chars
> + movl $0x00000078,SYMBOL_NAME(x86_vendor_id)+4 # next 4 chars
> +
> +#ifdef CONFIG_CYRIX
> + /*
> + * N.B. The pattern of accesses to 0x22 and 0x23 is *important*
> + * so do not try and "optimise" it! For the same reason we
> + * do all this with interrupts off just to be sure.
> + */
> +#define setCx86(reg, val) \
> + movb reg,%ax; \
> + outb %ax,$0x22; \
> + movb val,%ax; \
> + outb %ax,$0x23
> +
> +#define getCx86(reg) \
> + movb reg,%ax; \
> + outb %ax,$0x22; \
> + inb $0x23,%ax
> +
> + cli
> + getCx86($0xc3) # get CCR3
> + movb %ax,%cx # Save old value
> + movb %ax,%bx
> + andb $0x0f,%bx # Enable all config registers (for CCR4 access)
> + orb $0x10,%bx
> + setCx86($0xc3,%bx)
> +
> +#ifdef CONFIG_CYRIX_SUSP_HLT
> + getCx86($0xc2) # CCR2 |= SUSP_HLT
> + orb $8,%ax
> + movb %ax,%bx
> + setCx86($0xc2,%bx)
> +#endif
> +
> + getCx86($0xe8) # CCR4 |= CPUID | DTE_EN
> + orb $0x90,%ax
> + movb %ax,%bx
> + setCx86($0xe8,%bx)
> +
> + setCx86($0xc3,%cx) # Restore old CCR3
> + sti
> +#endif /* CONFIG_CYRIX */
> +
> +ncyrix: movl $3, SYMBOL_NAME(x86)# at least 386
> pushfl # push EFLAGS
> popl %eax # get EFLAGS
> movl %eax,%ecx # save original EFLAGS
> @@ -121,6 +188,7 @@
> xorl %ecx,%eax # change in flags
> andl $0x40000,%eax # check if AC bit changed
> je is386
> +
> movl $4,SYMBOL_NAME(x86)
> movl %ecx,%eax
> xorl $0x200000,%eax # check ID flag
> @@ -129,11 +197,22 @@
> pushfl # 487SX we can't change it
> popl %eax
> xorl %ecx,%eax
> - - andl $0x200000,%eax
> - - je is486
> - -isnew: pushl %ecx # restore original EFLAGS
> + pushl %ecx # restore original EFLAGS
> popfl
> - - incl SYMBOL_NAME(have_cpuid) # we have CPUID
> + andl $0x200000,%eax
> + je nocpuid
> +
> + /* get vendor info */
> + xorl %eax, %eax # call CPUID with 0 -> return vendor ID
> + .byte 0x0f, 0xa2 # CPUID
> + movl %eax,SYMBOL_NAME(have_cpuid) # save CPUID level
> + movl %ebx,SYMBOL_NAME(x86_vendor_id) # lo 4 chars
> + movl %edx,SYMBOL_NAME(x86_vendor_id)+4 # next 4 chars
> + movl %ecx,SYMBOL_NAME(x86_vendor_id)+8 # last 4 chars
> +
> + cmpl $0,%eax # do we have processor info as well?
> + je nocpuid
> +
> /* get processor type */
> movl $1, %eax # Use the CPUID instruction to
> .byte 0x0f, 0xa2 # check the processor type
> @@ -146,20 +225,159 @@
> andb $0x0f, %cl # mask mask revision
> movb %cl,SYMBOL_NAME(x86_mask)
> movl %edx,SYMBOL_NAME(x86_capability)
> - - /* get vendor info */
> - - xorl %eax, %eax # call CPUID with 0 -> return vendor ID
> - - .byte 0x0f, 0xa2 # CPUID
> - - movl %ebx,SYMBOL_NAME(x86_vendor_id) # lo 4 chars
> - - movl %edx,SYMBOL_NAME(x86_vendor_id)+4 # next 4 chars
> - - movl %ecx,SYMBOL_NAME(x86_vendor_id)+8 # last 4 chars
>
> - - movl %cr0,%eax # 486+
> - - andl $0x80000011,%eax # Save PG,PE,ET
> - - orl $0x50022,%eax # set AM, WP, NE and MP
> - - jmp 2f
> - -is486: pushl %ecx # restore original EFLAGS
> - - popfl
> - - movl %cr0,%eax # 486
> + cmpl $0x444d4163,SYMBOL_NAME(x86_vendor_id)+8 # "[Authenti]cAMD"?
> + jne nocpuid
> +
> + orb $0x20,SYMBOL_NAME(x86) # Flag as AMD
> + cmpb $0x25,SYMBOL_NAME(x86) # K5 model 0 has swapped
> + jne is486 # feature flags
> + andl $0x00000200,%edx # move bit 9 to bit 13
> + roll $4,%edx # and clear bit 9
> + orl %edx,SYMBOL_NAME(x86_capability)
> + andl $0xfffffdff,SYMBOL_NAME(x86_capability)
> + jmp is486
> +
> +nocpuid:
> + /*
> + * Even if we had CPUID Cyrix tries to look compatible with
> + * Intel so we have to go elsewhere for the nitty gritty.
> + */
> + cmpl $0x69727943,SYMBOL_NAME(x86_vendor_id) # "Cyri[x.*]"?
> + jne is486 # maybe ...
> +
> +chkdevid:
> + orb $0x10,SYMBOL_NAME(x86) # Flag as Cyrix
> + movb $0xfe,SYMBOL_NAME(x86_model) # Generic Cx486?
> + movb $0,SYMBOL_NAME(x86_mask)
> +
> +#ifdef CONFIG_CYRIX
> + cli # Test for DEVID
> + getCx86($0xc3) # by writing CCR3
> + movb %ax,%cx
> + movb %ax,%bx
> + orb $0x80,%bx
> + setCx86($0xc3,%bx)
> + getCx86($0xc0) # dummy to change bus
> + getCx86($0xc3)
> + sti
> + cmp %ax,%cx
> + je is486 # not writable == no DEVID
> +
> + cli
> + setCx86($0xc3,%cx) # restore CCR3
> +
> + getCx86($0xff) # get DEVID in preference to any CPUID
> + movb %al,SYMBOL_NAME(x86_mask)
> + getCx86($0xfe)
> + movb %al,SYMBOL_NAME(x86_model)
> + sti
> +
> +#if defined(CONFIG_CYRIX_5X86) || defined(CONFIG_CYRIX_6X86)
> + andb $0xf0,%al
> +#ifdef CONFIG_CYRIX_6X86
> + cmpb $0x30,%al
> + je is6x86
> +#endif
> +#ifdef CONFIG_CYRIX_5X86
> + cmpb $0x20,%al
> + je is5x86
> +#endif
> + /* Cx486 or something beyond a 6x86 (M2 or better). Note that
> + * the Cx486 also have performance features we could tweak
> + * but given the problems with [56]x86, the number of Cx486
> + * variants, the fact that the Cx486 is pretty well dead
> + * now and the fact that I have no Cx486 myself I haven't
> + * risked it. Nor have I looked at the M2 in any detail yet.
> + */
> + jmp is486
> +#endif
> +
> +#ifdef CONFIG_CYRIX_5X86
> + /* Special set up for 5x86 */
> +is5x86:
> + cli
> + movb %cx,%bx
> + andb $0x0f,%bx # Enable all config registers
> + orb $0x10,%bx
> + setCx86($0xc3,%bx)
> +
> + getCx86($0x20) # PCR0 |= LSSER | BTB_EN
> + orb $0x82,%ax # LOOP_EN is broken, RSTK_EN shows no benefi
> +
> + movb %ax,%bx # and LSSER=0 could break memory mapped
> + setCx86($0x20,%bx) # devices - we have no way of knowing)
> +
> +#ifdef CONFIG_CYRIX_FAST_IO
> + getCx86($0xe8) # CCR4: IORT=0 (nodelay)
> + andb $0xf1,%ax
> + movb %ax,%bx
> + setCx86($0xe8,%bx)
> +#endif
> +
> + setCx86($0xc3,%cx) # restore CCR3
> + sti
> + jmp is486
> +#endif
> +
> +#if defined(CONFIG_CYRIX_6X86) || defined(CONFIG_CYRIX_FAST_IO)
> + /* Special set up for 6x86 */
> +is6x86:
> + cli
> + movb %cx,%bx
> + andb $0x0f,%bx # Enable all config registers
> + orb $0x10,%bx
> + setCx86($0xc3,%bx)
> +
> +#if !defined(__SMP__) && defined(CONFIG_CYRIX_6X86_NOLOCK)
> + getCx86($0xc1) # CCR1 |= NO_LOCK
> + orb $0x10,%ax
> + movb %ax,%bx
> + setCx86($0xe8,%bx)
> +#endif
> +
> +#ifdef CONFIG_CYRIX_FAST_IO
> + getCx86($0xe8) # CCR4: IORT=7 (nodelay)
> + orb $0x97,%ax
> + movb %ax,%bx
> + setCx86($0xe8,%bx)
> +#endif
> +
> + getCx86($0xe9) # CCR5 &= ~SLOP
> + andb $0xfd,%ax
> +#ifdef CONFIG_CYRIX_6X86_WTALLOC
> + orb $0x01,%ax # CCR5 |= WT_ALLOC
> +#endif
> + movb %ax,%bx
> + setCx86($0xe9,%bx)
> +
> +#ifdef CONFIG_CYRIX_6X86_BTB # IBM documentation, no Cyrix docs
> + getCx86($0x30)
> + orb $020,%ax # Enable data bypassing/forwarding
> + movb %ax,%dx
> + orb $0x40,%ax # Enable test register opcodes
> + movb %ax,%bx
> + setCx86($0x30,%bx)
> + mov $0x28,%ebx # BTB index 5
> + .byte 0x0f,0x26,0xcb # mov %ebx,%tr1
> + .byte 0x0f,0x24,0xd0 # mov %tr2,%eax
> +
> + and $0xffffffe2,%eax # FAR COF doesn't make any diff
> +
> +#ifdef CONFIG_CYRIX_6X86_BTB_RISKY # Bit 4 is somewhat risky
> + or $0x00000010,%eax # but accelerates context switching
> +#endif
> + .byte 0x0f,0x26,0xd0 # mov %eax,%tr2
> +
> + setCx86($0x30,%dx) # Disable test register opcodes
> +#endif /* CONFIG_CYRIX_6X86_BTB */
> +
> + setCx86($0xc3,%cx) # restore CCR3
> + sti
> +#endif /* CONFIG_CYRIX_6X86 */
> +#endif /* CONFIG_CYRIX */
> +
> +is486: movl %cr0,%eax # 486 or better
> andl $0x80000011,%eax # Save PG,PE,ET
> orl $0x50022,%eax # set AM, WP, NE and MP
> jmp 2f
> - --- linux/arch/i386/kernel/setup.c.noCyrix Tue Jun 17 22:42:48 1997
> +++ linux/arch/i386/kernel/setup.c Tue Jun 17 16:03:01 1997
> @@ -42,8 +42,8 @@
> char x86_mask = 0; /* set by kernel/head.S */
> int x86_capability = 0; /* set by kernel/head.S */
> int fdiv_bug = 0; /* set if Pentium(TM) with FP bug */
> - -int have_cpuid = 0; /* set if CPUID instruction works */
> - -
> +int have_cpuid = -1; /* CPUID level (-1 if no CPUID) */
> +
> char x86_vendor_id[13] = "unknown";
>
> char ignore_irq13 = 0; /* set if exception 16 works */
> @@ -235,11 +235,86 @@
> return NULL;
> }
>
> +static const char * cyrixmodel(unsigned int nr)
> +{
> + static char nbuf[32];
> +
> +
> + /* Note that some of the possibilities this decoding allows
> + * have never actually been manufactured - but those that
> + * do actually exist are correctly decoded.
> + */
> + if (nr < 0x20) {
> + strcpy(nbuf, "Cx486");
> + if (!(nr & 0x10)) {
> + sprintf(nbuf+5, "%c%s%c",
> + (nr & 0x01) ? 'D' : 'S',
> + (nr & 0x04) ? "Rx" : "LC",
> + (nr & 0x02) ? '2' : '\000');
> + } else if (!(nr & 0x08)) {
> + sprintf(nbuf+5, "S%s%c",
> + (nr & 0x01) ? "2" : "",
> + (nr & 0x02) ? 'e' : '\000');
> + } else {
> + sprintf(nbuf+5, "DX%c",
> + nr == 0x1b ? '2'
> + : (nr == 0x1f ? '4' : '\000'));
> + }
> + return nbuf;
> + } else if (nr >= 0x20 && nr <= 0x4f) { /* 5x86, 6x86 or Gx86 */
> + sprintf(nbuf, "%cx86 %cx Core/Bus Clock",
> + "??56G"[nr>>4],
> + "12??43"[nr & 0x05]);
> + return nbuf;
> + } else if (nr >= 0x50 && nr <= 0x5f) { /* Cyrix M2 */
> + sprintf(nbuf, "M2 %c%sx Core/Bus Clock",
> + "12233445"[nr & 0x07],
> + (nr && !(nr&1)) ? ".5" : "");
> + return nbuf;
> + }
> +
> + /* Probably 0xfd (Cx486[SD]LC with no ID register)
> + * or 0xfe (Cx486 A step with no ID register).
> + */
> + return "Cx486";
> +}
> +
> static const char * getmodel(int x86, int model)
> {
> - - const char *p = NULL;
> - - static char nbuf[12];
> - - switch (x86) {
> + const char *p = NULL;
> + static char nbuf[49];
> +
> + if ((x86 & 0xf0) == 0x10) { /* Cyrix */
> + p = cyrixmodel(model);
> + } else if ((x86 & 0xf0) == 0x20) { /* AMD */
> + /* Actually we must have cpuid or we could never have
> + * figured out that this was AMD from the vendor info :-).
> + */
> + if (have_cpuid < 0)
> + p = "Am486";
> + else {
> + int n, dummy;
> + cpuid(0x80000000, &n, &dummy, &dummy, &dummy);
> + if (!n) {
> + if ((x86 & 0x0f) == 4)
> + p = i486model(model);
> + else if ((x86 & 0x0f) == 5)
> + p = "AMD-K5 (Model 0)";
> + else if ((x86 & 0x0f) == 6)
> + p = "AMD-K6";
> + } else {
> + int *v = (int *)nbuf;
> + cpuid(0x80000002, &v[0], &v[1], &v[2], &v[3]);
> + cpuid(0x80000003, &v[4], &v[5], &v[6], &v[7]);
> + cpuid(0x80000004, &v[8], &v[9], &v[10], &v[11]);
> + nbuf[48] = '\0';
> + p = nbuf;
> + }
> + }
> + } else switch (x86) { /* Intel */
> + case 0:
> + p = "unknown";
> + break;
> case 4:
> p = i486model(model);
> break;
> @@ -250,8 +325,8 @@
> p = i686model(model);
> break;
> }
> - - if (p)
> - - return p;
> + if (p)
> + return p;
>
> sprintf(nbuf, "%d", model);
> return nbuf;
> @@ -260,6 +335,7 @@
> int get_cpuinfo(char * buffer)
> {
> int i, len = 0;
> + int sep_bug;
> static const char *x86_cap_flags[] = {
> "fpu", "vme", "de", "pse", "tsc", "msr", "pae", "mce",
> "cx8", "apic", "10", "11", "mtrr", "pge", "mca", "cmov",
> @@ -284,39 +360,51 @@
> #define CPUN 0
> #endif
>
> - - len += sprintf(buffer+len,"processor\t: %d\n"
> - - "cpu\t\t: %c86\n"
> - - "model\t\t: %s\n"
> - - "vendor_id\t: %s\n",
> - - CPUN,
> - - CD(x86)+'0',
> - - CD(have_cpuid) ?
> - - getmodel(CD(x86), CD(x86_model)) :
> - - "unknown",
> - - CD(x86_vendor_id));
> + len += sprintf(buffer+len,"processor\t: %d\n"
> + "cpu family\t: %c\n"
> + "model\t\t: %s\n"
> + "vendor_id\t: %s\n",
> + CPUN,
> + (CD(x86) & 0x0f)+'0',
> + getmodel(CD(x86), CD(x86_model)),
> + CD(x86_vendor_id));
>
> - - if (CD(x86_mask))
> - - len += sprintf(buffer+len,
> - - "stepping\t: %d\n",
> - - CD(x86_mask));
> - - else
> + if (CD(x86_mask)) {
> + if ((CD(x86) & 0xf0) == 0x10)
> + len += sprintf(buffer+len,
> + "stepping\t: %d rev %d\n",
> + CD(x86_mask) >> 4,
> + CD(x86_mask) & 0x0f);
> + else
> + len += sprintf(buffer+len,
> + "stepping\t: %d\n",
> + CD(x86_mask));
> + } else
> len += sprintf(buffer+len,
> "stepping\t: unknown\n");
>
> - - len += sprintf(buffer+len,
> + sep_bug = CD(x86) == 0x06 && /* Intel family 6 */
> + CD(have_cpuid) >= 0 &&
> + (CD(x86_capability) & 0x800) &&
> + CD(x86_model) < 3 &&
> + CD(x86_mask) < 3;
> +
> + len += sprintf(buffer+len,
> "fdiv_bug\t: %s\n"
> "hlt_bug\t\t: %s\n"
> + "sep_bug\t\t: %s\n"
> "fpu\t\t: %s\n"
> "fpu_exception\t: %s\n"
> - - "cpuid\t\t: %s\n"
> + "cpuid level\t: %d\n"
> "wp\t\t: %s\n"
> "flags\t\t:",
> CD(fdiv_bug) ? "yes" : "no",
> CD(hlt_works_ok) ? "no" : "yes",
> + CD(sep_bug) ? "yes" : "no",
> CD(hard_math) ? "yes" : "no",
> (CD(hard_math) && ignore_irq13)
> ? "yes" : "no",
> - - CD(have_cpuid) ? "yes" : "no",
> + CD(have_cpuid),
> CD(wp_works_ok) ? "yes" : "no");
>
> for ( i = 0 ; i < 32 ; i++ ) {
> - --- linux/arch/i386/kernel/process.c.noCyrix Wed Oct 30 15:31:46 1996
> +++ linux/arch/i386/kernel/process.c Tue Jun 17 16:02:45 1997
> @@ -30,6 +30,7 @@
> #include <asm/segment.h>
> #include <asm/pgtable.h>
> #include <asm/system.h>
> +#include <asm/processor.h>
> #include <asm/io.h>
> #include <linux/smp.h>
>
> @@ -278,7 +279,28 @@
>
> void hard_reset_now (void)
> {
> - -
> +#if defined(CONFIG_CYRIX) && defined(CONFIG_CYRIX_6X86_VSPM) && !defined(__SMP__) && !defined(CONFIG_CYRIX_6X86_VSPM_NOTRADPAGE)
> + /* disable VSPM in order to make it possible to boot other OS */
> + /* check for stepping, only >= 1rev7 allows disabling of VSPM */
> + if ((x86 & 0xf0) == 0x10 && (x86_model & 0xf0) == 0x30
> + && ((x86_mask & 0x0f) > 6 || (x86_mask >> 4) > 1)) {
> + int vspm_idx;
> + for (vspm_idx = 3; vspm_idx >=0; vspm_idx--) {
> + asm( "movl %0,%%eax\n"
> + "movl %%eax,%%tr7\n"
> + "movl $0x00000004,%%eax\n"
> + "movl %%eax,%%tr6\n"
> + "movl %0,%%eax\n"
> + "movl %%eax,%%tr7\n"
> + "movl $0x000004ce,%%eax\n"
> + "movl %%eax,%%tr6\n"
> + : /* no outputs */
> + : "g" (vspm_idx << 7)
> + : "eax", "cc"
> + );
> + }
> + }
> +#endif
> if(!reboot_thru_bios) {
> sti();
> /* rebooting needs to touch the page at absolute addr 0 */
> - --- linux/arch/i386/mm/init.c.noCyrix Mon Jun 16 21:41:27 1997
> +++ linux/arch/i386/mm/init.c Tue Jun 17 11:32:57 1997
> @@ -119,6 +119,82 @@
> unsigned long tmp;
> unsigned long address;
>
> +#ifdef TEST_VERIFY_AREA
> + wp_works_ok = 0;
> +#endif
> +
> +#if defined(CONFIG_CYRIX) && defined(CONFIG_CYRIX_6X86_VSPM) && !defined(__SMP__)
> + unsigned long vspm_max = 0;
> +
> + /* If this is a Cyrix 6x86 we use the variable size paging
> + * mechanism (VSPM) to map physical memory at 0xc0000000.
> + * Note that VSPM pages are stored on the CPU only so this
> + * needs to be done for each processor in a multi-processor
> + * system. If we have a mixture of processors we would also
> + * need to set up the traditional page tables for them.
> + * Note also that VSPM pages will be global to all memory
> + * spaces since they are not stored in the normal page
> + * directories.
> + *
> + * By experiment:
> + * VSPM pages must be power of two sizes. A single 24MB
> + * page fails.
> + * Documentation suggests there are 8 VSPM slots (3 bit
> + * index) but tests show the upper four slots mirror the
> + * lower four.
> + * With a 16MB page followed by an 8MB page I always get
> + * a write fault on the last 4k of the 8MB page. With 8MB
> + * plus 4MB I can't even boot. If we have such a memory
> + * size we map the first power of two with VSPM and use
> + * traditional paging for the rest.
> + * VSPM pages override traditional pages so we cannot
> + * overlap the start of the vmalloc region.
> + * Do not try and create a mapping with dirty and accessed
> + * flags clear - a step 1 rev 5 chip will crash and burn.
> + */
> + if ((x86 & 0xf0) == 0x10 || (x86_model & 0xf0) == 0x30) {
> + int vspm_index = 0;
> + int max_vspm_pages = 1;
> + if ((x86_mask & 0x0f) > 6 || (x86_mask >> 4) > 1) max_vspm_pages = 4;
> +
> + do {
> + unsigned long mem_size;
> +
> + mem_size = 4096;
> + while (vspm_max+mem_size < end_mem)
> + mem_size <<= 1;
> + if (vspm_max+mem_size > end_mem)
> + if ((mem_size >>= 1) < 4096)
> + break;
> +
> + asm( "movl %0,%%eax\n"
> + "movl %%eax,%%tr7\n"
> + "movl $0x00000004,%%eax\n"
> + "movl %%eax,%%tr6\n"
> + "movl %1,%%eax\n"
> + "movl %%eax,%%tr7\n"
> + "movl %2,%%eax\n"
> + "movl %%eax,%%tr6\n"
> + : /* no outputs */
> + : "g" ((((mem_size-1) & 0xfffff000)) | (vspm_index<<7)),
> + "g" ((vspm_max & 0xfffff000) | (vspm_index<<7)),
> + "g" (vspm_max | 0xc0000cd6)
> + : "eax", "cc"
> + );
> +
> + vspm_max += mem_size;
> +
> + } while (vspm_max < end_mem && vspm_index++ < max_vspm_pages);
> +
> + /* Write protect does work correctly but the test
> + * will fail because we can't map just page 0 read
> + * only from under the VSPM big page. If we didn't
> + * know before we do now.
> + */
> + wp_works_ok = 1;
> + }
> +#endif
> +
> /*
> * Physical page 0 is special; it's not touched by Linux since BIOS
> * and SMM (for laptops with [34]86/SL chips) may need it. It is read
> @@ -147,9 +223,6 @@
> */
> /* smp_alloc_memory(8192); */
> #endif
> - -#ifdef TEST_VERIFY_AREA
> - - wp_works_ok = 0;
> - -#endif
> start_mem = PAGE_ALIGN(start_mem);
> address = 0;
> pg_dir = swapper_pg_dir;
> @@ -181,6 +254,16 @@
> continue;
> }
> #endif
> +#if defined(CONFIG_CYRIX) && defined(CONFIG_CYRIX_6X86_VSPM) && !defined(__SMP__) && defined(CONFIG_CYRIX_6X86_VSPM_NOTRADPAGE)
> + if ((x86 & 0xf0) == 0x10 /* Cyrix */
> + && (x86_model & 0xf0) == 0x30 /* 6x86 */
> + && (address + PAGE_SIZE*PTRS_PER_PTE) < vspm_max) { /* within VSPM mappings */
> + pg_dir++;
> + address += PAGE_SIZE * PTRS_PER_PTE;
> + continue;
> + }
> +#endif
> +
> /* map the memory at virtual addr 0xC0000000 */
> pg_table = (pte_t *) (PAGE_MASK & pgd_val(pg_dir[768]));
> if (!pg_table) {
> @@ -192,11 +275,17 @@
> pgd_val(pg_dir[0]) = _PAGE_TABLE | (unsigned long) pg_table;
> pgd_val(pg_dir[768]) = _PAGE_TABLE | (unsigned long) pg_table;
> pg_dir++;
> +
> for (tmp = 0 ; tmp < PTRS_PER_PTE ; tmp++,pg_table++) {
> - - if (address < end_mem)
> - - set_pte(pg_table, mk_pte(address, PAGE_SHARED));
> - - else
> +#if defined(CONFIG_CYRIX) && defined(CONFIG_CYRIX_6X86_VSPM) && !defined(__SMP__) && defined(CONFIG_CYRIX_6X86_VSPM_NOTRADPAGE)
> + if (address < vspm_max || address >= end_mem)
> + pte_clear(pg_table);
> +#else
> + if (address >= end_mem)
> pte_clear(pg_table);
> +#endif
> + else
> + set_pte(pg_table, mk_pte(address, PAGE_SHARED));
> address += PAGE_SIZE;
> }
> }
>
> - --
> cu,
>
> Thorsten
>
> ___
> | h o r s t e n K a l k b r e n n e r tk@wh36-b404.stud.uni-karlsruhe.de
>
> ------------------------------
>
> End of linux-kernel-digest V1 #1211
> ***********************************
>
> To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
> in the body of a message to "Majordomo@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".