owner-linux-kernel-digest@vger.rutgers.edu wrote:
>
> linux-kernel-digest Thursday, February 3 2000 Volume 01 : Number 148
>
> In this issue:
>
> Re: /dev/random oddness
> Re: Devices not supporting read-6....
> Re: how does kernel get the "current" task struct?
> devfsd-v1.3.1 available
> Re: Strange problem with 2.3.42
> Re: 2.3.4[12] compile failure sparc64
> IDE performance question
> Re: RAID0 expansion
> Re: [2.3.42] Doesn't compile on Alpha
> Re: RAID0 expansion
> Re: [2.3.42] Doesn't compile on Alpha
> Re: Devices not supporting read-6....
> zillion of oopses on 2.2.15pre4
> Design issues for a kernel-driver
> Lockup with heavy io on a HPT366 controller
> OOPS on Mandrake 6.0 system - buffer activity
> how to do realloc in kernel?
> [PATCH] MTRRs above 4GB (3rd try)
>
> See the end of the digest for information on subscribing to the linux-kernel
> or linux-kernel-digest mailing lists.
>
> ----------------------------------------------------------------------
>
> From: hpa@transmeta.com (H. Peter Anvin)
> Date: 2 Feb 2000 20:08:31 -0800
> Subject: Re: /dev/random oddness
>
> Followup to: <200002012318.XAA01482@raistlin.arm.linux.org.uk>
> By author: Russell King <rmk@arm.linux.org.uk>
> In newsgroup: linux.dev.kernel
> >
> > Hi,
> >
> > I've just had a report that I've confirmed that /dev/random on ARM doesn't
> > behave the same as /dev/random on x86.
> >
> > I've confirmed this by comparing a NetWinder with an IBM thinkpad.
> > Both these have PS/2 mice. The NetWinder is running 2.3.41, which
> > uses the standard random.c and pc_keyb.c sources. The thinkpad is
> > running untouched 2.2.12 at the moment.
> >
> > On the thinkpad, doing an 'od -t x1 -Ax /dev/random' and moving the
> > mouse in a console results in a lot of bytes being generated from
> > the device. However, on a NetWinder, it results in very few, less
> > than 1/10th of what the x86 machine produces.
> >
> > I have also compared it with other ARM architectures (on 2.2.14) use
> > the busmice code (which got added to 2.3 iirc) to add randomness,
> > and that behaves in the same manner as the NetWinder.
> >
> > Does anyone have any clues what might be causing this odd behaviour?
> > I haven't scanned over random.c in any great depth yet.
> >
>
> It depends on the resolution of your timer. Higher resolution = more
> randomness. On IA32 the time stamp counter register is used to get a
> very high resolution timer, which gives you plenty of randomness per
> event.
>
> -hpa
>
> - --
> <hpa@transmeta.com> at work, <hpa@zytor.com> in private!
> "Unix gives you enough rope to shoot yourself in the foot."
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Eric Youngdale" <eric@andante.org>
> Date: Wed, 2 Feb 2000 23:10:08 -0500
> Subject: Re: Devices not supporting read-6....
>
> - ----- Original Message -----
> From: "Rogier Wolff" <R.E.Wolff@BitWizard.nl>
> To: "Drew Eckhardt" <drew@Poohsticks.Org>
> Cc: "Kenneth D. Merry" <ken@kdm.org>; "Jonas Nickel"
> <jonas.nickel@tu-berlin.de>; "Rogier Wolff" <R.E.Wolff@BitWizard.nl>;
> <linux-kernel@vger.rutgers.edu>; <linux-scsi@vger.rutgers.edu>;
> <phoenix@thesindicate.com>
> Sent: Wednesday, February 02, 2000 6:13 PM
> Subject: Re: Devices not supporting read-6....
>
> > Drew Eckhardt wrote:
> >
> > > Under Linux, the CD and disk drivers are completely divorced. When
> > > I wrote the disk driver, I used the smallest command possible for a
> > > given transfer size. The CD driver was cloned from that.
> >
> > This is a bad idea! This "divorce" should be undone whenever someone
> > has a chance!
>
> I am not so sure it is a good idea to merge them. A lot of the
> common/similar code got removed from both sd.c and sr.c when I did the
> rewrite of the queueing code.
>
> > DVD RAM drives currently require a gross hack to allow them to be
> > driven by both the disk driver (to write to the device), and as a
> > CDROM drive (to allow cdrom ioctls like play track).
>
> Is this what that ghost stuff is really for? There is a much easier way
> of doing this, you know. There is no technical reason why the same
> Scsi_Device cannot be driven by both drivers - the only thing you would need
> to do is to teach sd.c that it should also attach to DVD RAM drives.
>
> If I had to guess, all you would need to do is to fix it so that
> scsi_scan() first marked the Scsi_Device as writable, and then a couple of
> minor edits to sd.c so that it treats the combination of TYPE_ROM with the
> writable flag set as equivalent to TYPE_MOD.
>
> - -Eric
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Rik van Riel <riel@nl.linux.org>
> Date: Thu, 3 Feb 2000 05:20:50 +0100 (CET)
> Subject: Re: how does kernel get the "current" task struct?
>
> On Wed, 2 Feb 2000, Jun Sun wrote:
>
> > This question is not related, but if you want to know which process
> > is running on another CPU, which data structure tells you that?
>
> You might want to look into reading kernel/sched.c :)
>
> cheers,
>
> Rik
> - --
> The Internet is not a network of computers. It is a network
> of people. That is its real strength.
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Richard Gooch <rgooch@ras.ucalgary.ca>
> Date: Thu, 3 Feb 2000 15:43:11 +1100
> Subject: devfsd-v1.3.1 available
>
> Hi, all. I've just released version 1.3.1 of my devfsd (devfs
> daemon) at: http://www.atnf.csiro.au/~rgooch/linux/
> This work has been sponsored by SGI.
>
> This works with devfs-patch-v130 and devfs-patch-v99.7 (or later).
>
> NOTE: The new "MODLOAD" action is now the recommended way to load
> modules. Don't use the "EXECUTE" action for this anymore.
>
> The main changes are:
>
> - - added "MODLOAD" action
>
> - - install default configuration file if /etc/devfsd.conf doesn't
> exist.
>
> Regards,
>
> Richard....
> Old: rgooch@atnf.csiro.au
> Current: rgooch@ras.ucalgary.ca
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: "Garst R. Reese" <reese@isn.net>
> Date: Thu, 03 Feb 2000 01:31:35 -0400
> Subject: Re: Strange problem with 2.3.42
>
> From: Daniel.Egger@suse.de
> Date: Wed, 2 Feb 2000 23:36:35 +0100 (CET)
> Subject: Strange problem with 2.3.42
>
> Hiho developers,
>
> I discovered 2 problems with 2.3.42:
>
> 1) When I compile it for a K6 maschine the kernel hangs after "Loading
> ..."
> It's probably a compiler problem, maybe using -march=k6 is no good
> idea.
> Can't help there.
> 2) Using a Pentium version of the kernel works until short before the
> prompt.
> He starts up normally even loads all my daemons and servers and
> shows me
> my login shell, after authentificating myself the mschine just does
> nothing.
> I can logon on all tty's but'll never get a shell; he seems o
> hangs, however
> I can break this by pressing Ctrl-C and get back my login prompt.
>
> Get the latest util-linux pkg. 2.10e. As usual the Changes file is not
> current with the dev. kernels. Configure it to get you a new passwd and
> login.
> Worked for me and I already had 2.10. This showed up in a 2.3.41pre for
> me.
> Garst
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Anton Blanchard <anton@progsoc.uts.edu.au>
> Date: Thu, 3 Feb 2000 18:12:14 +1100
> Subject: Re: 2.3.4[12] compile failure sparc64
>
> > On an E3500, I've been getting the following during make all ........
> > make -C arch/sparc64/kernel
> > make[1]: Entering directory `/usr/src/linux/arch/sparc64/kernel'
> > sparc64-linux-gcc -D__KERNEL__ -I/usr/src/linux/include -D__SMP__ -Wall
> > -Wstrict
> > -prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -m64 -pipe
> > -mno-fpu -m
> > cpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7
> > -Wno-sig
> > n-compare -c -o setup.o setup.c
> > setup.c: In function `setup_arch':
> > setup.c:514: `memory_end_p' undeclared (first use in this function)
> > setup.c:514: (Each undeclared identifier is reported only once
> > setup.c:514: for each function it appears in.)
> > setup.c:522: `memory_start_p' undeclared (first use in this function)
> > make[1]: *** [setup.o] Error 1
> > make[1]: Leaving directory `/usr/src/linux/arch/sparc64/kernel'
> > make: *** [_dir_arch/sparc64/kernel] Error 2
>
> Turn off Initial RAM disk support and it should compile OK. It still needs
> fixing.
>
> Anton
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Ray L <rayl@mail.com>
> Date: Thu, 3 Feb 2000 01:55:09 -0700
> Subject: IDE performance question
>
> hi folks
>
> i have an IDE performance question:
>
> i've just put together an athlon 500 on a MS-6167 motherboard, and
> i'm using an IBM deskstar DPTA-372050 20 Gig drive. i'm running
> 2.2.15pre5 and mandrake 7.0. i've tuned the IDE subsystem using the
> /proc settings, and am getting fairly close to the rated throughput
> (lmbench tells me 20.9/22.3 MB/s on R/W, ibm says 22.9)
>
> however, i do experience system pauses while the disk is in heavy
> use. for example, while a large tar is going on, an 'ls' might take
> up to 2 seconds to return in another xterm. i did not observe this
> behavior on my old system (4 gig barracuda scsi on DPT controller).
>
> is this normal for large IDE drives, or have i missed some config parm?
> in particular, what is up with the write-only pio_mode below? should
> i be setting that to some particular value?
>
> here's my settings at the moment:
>
> root@stingray# cat /proc/ide/hda/settings
> name value min max mode
> - ---- ----- --- --- ----
> bios_cyl 2495 0 65535 rw
> bios_head 255 0 255 rw
> bios_sect 63 0 63 rw
> breada_readahead 4 0 127 rw
> bswap 0 0 1 r
> file_readahead 124 0 2097151 rw
> io_32bit 1 0 3 rw
> keepsettings 1 0 1 rw
> max_kb_per_request 64 1 127 rw
> multcount 8 0 8 rw
> nice1 1 0 1 rw
> nowerr 0 0 1 rw
> pio_mode write-only 0 255 w
> slow 0 0 1 rw
> unmaskirq 1 0 1 rw
> using_dma 1 0 1 rw
>
> any clues appreciated, thanks
>
> - --
> - -----------------------------------------------------------------------------
> Ray Lehtiniemi (rayl@mail.com) (rayl@optitech.com)
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: James Antill <james@and.org>
> Date: 03 Feb 2000 02:48:37 -0500
> Subject: Re: RAID0 expansion
>
> Sasi Peter <sape@iq.rulez.org> writes:
>
> > On Wed, 2 Feb 2000, Stephen C. Tweedie wrote:
> >
> > > On Tue, 1 Feb 2000 22:15:23 +0100 (CET), Sasi Peter <sape@iq.rulez.org>
> > > said:
> > > > A while ago I have seen someone here talk about a tool for
> > > > nondestructively adding a new partition to an existing raid0 set,
> > > > which afterwards seems to have grown in size, but all the contained
> > > > information is still on it, and if using ext2 on it, w/ e2resize it
> > > > also can be expanded.
> > > Look for the logical volume manager (LVM) code, at
> > > http://linux.msede.com/lvm/
> >
> > Unfortunatelly I have an active working raid0 set, and no LVM installed.
> > Somebody once had a program (no I could not find it in the archives), to
> > resize this, and I have got no facility to do a backup, and install LVM.
> > And I guess without a backup LVM will not help me...
> >
> > Anybody, who remembers that?
>
> First off, you probably want to try linux-fs@.
>
> As to your question, I seem to remember someone writing something
> that would add/delete _blocks_ to/from _the end_ of an ext2/raid0[1]
> fs.
> Obviously the marked points are the important ones. Ie. If you have
> been using a drive and want to "resize" it downwards[2], then you had
> to move all of your data to the begining of the disks and then remove
> any completely free blocks from the end.
>
> In short your best bet is still probably:
>
> 1. Buy offline storage.
> 2. tar -c
> 3. fdisk/cfdisk
> 4. tar -x
>
> I'd be happy to be proved wrong though.
>
> [1] The raid0 comprising of ext2 fses.
>
> [2] There's got to be a better way of expressing that, but I hope you
> get the idea (that the fs should get smaller).
>
> - --
> James Antill -- james@and.org
> I am always an optimist, but frankly there is no hope.
> -Hosni Mubarek
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Jakub Jelinek <jakub@redhat.com>
> Date: Thu, 3 Feb 2000 09:05:45 +0100
> Subject: Re: [2.3.42] Doesn't compile on Alpha
>
> - --TB36FDmn/VVEgNH/
> Content-Type: text/plain; charset=us-ascii
>
> On Wed, Feb 02, 2000 at 08:50:29PM -0500, Aaron Tiensivu wrote:
> > [root@multiameal /usr/src/linux-2.3/linux]# make
> > gcc -D__KERNEL__ -I/usr/src/linux-2.3/linux/include -O2 -fomit-frame-pointer -fn
> > o-strict-aliasing -pipe -mno-fp-regs -ffixed-8 -mcpu=ev4 -c -o init/main.o ini
> > t/main.c
> > In file included from init/main.c:33:
> > /usr/src/linux-2.3/linux/include/linux/pci.h:318: parse error before `dma_addr_t
> > '
> > /usr/src/linux-2.3/linux/include/linux/pci.h:318: warning: no semicolon at end o
> > f struct or union
> > /usr/src/linux-2.3/linux/include/linux/pci.h:346: parse error before `}'
> > make: *** [init/main.o] Error 1
> >
> >
> > Rather odd since the same tree will build for i386 ok.
> > I'm guessing the newer PCI code hasn't been synced for Alpha yet?
> > I can provide .config if need be.
>
> Try this.
> It is Richard Henderson's WIP patch for dynamic DMA I've hacked for what
> Linus finally accepted into 2.3.41 and hopefully with all the
> NEW_PCI_DMA_MAP stuff protected by an ifdef of the same name, so if I
> haven't forgotten anything (don't have an Alpha nor cross-compiler set up),
> it should be working for you if you don't have more than 4G (or what was the
> limit on Alpha) of physical memory.
> Please tell me if the patch does not compile.
> Once this Alpha code is finished and NEW_PCI_DMA_MAP enabled and working,
> this will remove physical memory limits on Alpha (like it did on
> UltraSPARC where we don't pose any physical RAM limits in 2.3.42 any more,
> so if you want on sparc64 128GB of RAM, just prepare enough bucks for a big
> machine) without ugly hacks like bigmem/Alpha.
> All drivers you use on such system have to be converted to the new DMA
> mapping API though (in vger CVS we have converted all drivers which are
> available as config options for sparc64 and will be working on merging it to
> Linus' tree through maintainers).
>
> Cheers,
> Jakub
> ___________________________________________________________________
> Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
> Linux version 2.3.41 on a sparc64 machine (1343.49 BogoMips)
> ___________________________________________________________________
>
> - --TB36FDmn/VVEgNH/
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: attachment; filename="dynamic-dma-alpha.patch"
>
> - --- linux/arch/alpha/kernel/Makefile.jj Mon Dec 20 09:09:50 1999
> +++ linux/arch/alpha/kernel/Makefile Thu Feb 3 08:12:24 2000
> @@ -30,7 +30,7 @@ O_OBJS += core_apecs.o core_cia.o core_
> else
>
> ifdef CONFIG_PCI
> - -O_OBJS += pci.o
> +O_OBJS += pci.o pci_iommu.o
> endif
>
> # Core logic support
> - --- linux/arch/alpha/kernel/core_cia.c.jj Mon Dec 20 09:09:54 1999
> +++ linux/arch/alpha/kernel/core_cia.c Thu Feb 3 08:12:24 2000
> @@ -314,12 +314,21 @@ struct pci_ops cia_pci_ops =
> write_dword: cia_write_config_dword
> };
>
> +void
> +cia_pci_tbi(struct pci_controler *hose, dma_addr_t start, dma_addr_t end)
> +{
> + wmb();
> + *(vip)CIA_IOC_PCI_TBIA = 3; /* Flush all locked and unlocked. */
> + mb();
> + *(vip)CIA_IOC_PCI_TBIA; /* Re-read to force write. */
> +}
> +
> void __init
> cia_init_arch(void)
> {
> struct pci_controler *hose;
> struct resource *hae_mem;
> - - unsigned int temp;
> + unsigned int temp;
>
> #if DEBUG_DUMP_REGS
> temp = *(vuip)CIA_IOC_CIA_REV; mb();
> @@ -368,7 +377,7 @@ cia_init_arch(void)
> printk("cia_init: W3_BASE was 0x%x\n", temp);
> #endif /* DEBUG_DUMP_REGS */
>
> - - /*
> + /*
> * Set up error reporting.
> */
> temp = *(vuip)CIA_IOC_CIA_ERR;
> @@ -382,6 +391,55 @@ cia_init_arch(void)
> mb();
>
> /*
> + * Create our single hose.
> + */
> +
> + pci_isa_hose = hose = alloc_pci_controler();
> + hae_mem = alloc_resource();
> +
> + hose->io_space = &ioport_resource;
> + hose->mem_space = hae_mem;
> + hose->config_space = CIA_CONF;
> + hose->index = 0;
> +
> + hae_mem->start = 0;
> + hae_mem->end = CIA_MEM_R1_MASK;
> + hae_mem->name = pci_hae0_name;
> + hae_mem->flags = IORESOURCE_MEM;
> +
> + if (request_resource(&iomem_resource, hae_mem) < 0)
> + printk(KERN_ERR "Failed to request HAE_MEM\n");
> +
> +#ifdef NEW_PCI_DMA_MAP
> + /*
> + * Set up the PCI to main memory translation windows.
> + *
> + * Window 0 is scatter-gather 8MB at 8MB (for isa)
> + * Window 1 is direct access 1GB at 1GB
> + * Window 2 is scatter-gather 128MB at 2GB
> + * ??? We ought to scale this last with memory.
> + */
> + hose->sg_isa = iommu_arena_new(8*1024*1024, 8*1024*1024);
> + hose->sg_pci = iommu_arena_new(2048u*1024*1024, 128*1024*1024);
> +#if 1
> + hose->direct_map_base = 1024*1024*1024;
> + hose->direct_map_size = 1024*1024*1024;
> +#endif
> +
> + *(vuip)CIA_IOC_PCI_W0_BASE = hose->sg_isa->dma_base | 3;
> + *(vuip)CIA_IOC_PCI_W0_MASK = (hose->sg_isa->size - 1) & 0xfff00000;
> + *(vuip)CIA_IOC_PCI_T0_BASE = virt_to_phys(hose->sg_isa->ptes) >> 2;
> + *(vuip)CIA_IOC_PCI_W1_BASE = hose->direct_map_base | 1;
> + *(vuip)CIA_IOC_PCI_W1_MASK = (hose->direct_map_size - 1) & 0xfff00000;
> + *(vuip)CIA_IOC_PCI_T1_BASE = 0;
> +
> + *(vuip)CIA_IOC_PCI_W2_BASE = hose->sg_pci->dma_base | 3;
> + *(vuip)CIA_IOC_PCI_W2_MASK = (hose->sg_pci->size - 1) & 0xfff00000;
> + *(vuip)CIA_IOC_PCI_T2_BASE = virt_to_phys(hose->sg_pci->ptes) >> 2;
> +
> + *(vuip)CIA_IOC_PCI_W3_BASE = 0;
> +#else
> + /*
> * Set up the PCI->physical memory translation windows.
> * For now, windows 2 and 3 are disabled. In the future,
> * we may want to use them to do scatter/gather DMA.
> @@ -402,14 +460,15 @@ cia_init_arch(void)
>
> *(vuip)CIA_IOC_PCI_W2_BASE = 0x0;
> *(vuip)CIA_IOC_PCI_W3_BASE = 0x0;
> +#endif
> mb();
>
> - - /*
> - - * Next, clear the CIA_CFG register, which gets used
> - - * for PCI Config Space accesses. That is the way
> - - * we want to use it, and we do not want to depend on
> - - * what ARC or SRM might have left behind...
> - - */
> + /*
> + * Next, clear the CIA_CFG register, which gets used
> + * for PCI Config Space accesses. That is the way
> + * we want to use it, and we do not want to depend on
> + * what ARC or SRM might have left behind...
> + */
> *((vuip)CIA_IOC_CFG) = 0; mb();
>
> /*
> @@ -419,26 +478,6 @@ cia_init_arch(void)
> *((vuip)CIA_IOC_HAE_MEM); /* read it back. */
> *((vuip)CIA_IOC_HAE_IO) = 0; mb();
> *((vuip)CIA_IOC_HAE_IO); /* read it back. */
> - -
> - - /*
> - - * Create our single hose.
> - - */
> - -
> - - hose = alloc_pci_controler();
> - - hae_mem = alloc_resource();
> - -
> - - hose->io_space = &ioport_resource;
> - - hose->mem_space = hae_mem;
> - - hose->config_space = CIA_CONF;
> - - hose->index = 0;
> - -
> - - hae_mem->start = 0;
> - - hae_mem->end = CIA_MEM_R1_MASK;
> - - hae_mem->name = pci_hae0_name;
> - - hae_mem->flags = IORESOURCE_MEM;
> - -
> - - if (request_resource(&iomem_resource, hae_mem) < 0)
> - - printk(KERN_ERR "Failed to request HAE_MEM\n");
> }
>
> static inline void
> @@ -456,6 +495,8 @@ void
> cia_machine_check(unsigned long vector, unsigned long la_ptr,
> struct pt_regs * regs)
> {
> + int expected;
> +
> /* Clear the error before any reporting. */
> mb();
> mb(); /* magic */
> @@ -464,5 +505,22 @@ cia_machine_check(unsigned long vector,
> wrmces(rdmces()); /* reset machine check pending flag. */
> mb();
>
> - - process_mcheck_info(vector, la_ptr, regs, "CIA", mcheck_expected(0));
> + expected = mcheck_expected(0);
> + process_mcheck_info(vector, la_ptr, regs, "CIA", expected);
> +
> + if (!expected && vector == 0x660) {
> + struct el_common *com;
> + struct el_common_EV5_uncorrectable_mcheck *ev5;
> + struct el_CIA_sysdata_mcheck *cia;
> +
> + com = (void *)la_ptr;
> + ev5 = (void *)(la_ptr + com->proc_offset);
> + cia = (void *)(la_ptr + com->sys_offset);
> +
> + if (com->code == 0x202) {
> + printk(KERN_CRIT "CIA pci err0=%016lx "
> + "err1=%016lx err2=%016lx\n",
> + cia->pci_err0, cia->pci_err1, cia->pci_err2);
> + }
> + }
> }
> - --- linux/arch/alpha/kernel/irq.c.jj Mon Dec 20 09:10:08 1999
> +++ linux/arch/alpha/kernel/irq.c Thu Feb 3 08:12:24 2000
> @@ -897,6 +897,7 @@ process_mcheck_info(unsigned long vector
> case 0x98: reason = "processor detected hard error"; break;
>
> /* System specific (these are for Alcor, at least): */
> + case 0x202: reason = "system detected hard error"; break;
> case 0x203: reason = "system detected uncorrectable ECC error"; break;
> case 0x204: reason = "SIO SERR occurred on PCI bus"; break;
> case 0x205: reason = "parity error detected by CIA"; break;
> - --- linux/arch/alpha/kernel/machvec_impl.h.jj Mon Dec 20 09:10:10 1999
> +++ linux/arch/alpha/kernel/machvec_impl.h Thu Feb 3 08:24:55 2000
> @@ -100,9 +100,16 @@
> #define DO_T2_IO IO(T2,t2)
> #define DO_TSUNAMI_IO IO(TSUNAMI,tsunami)
>
> +#ifdef NEW_PCI_DMA_MAP
> +#define BUS(which) \
> + mv_virt_to_bus: CAT(which,_virt_to_bus), \
> + mv_bus_to_virt: CAT(which,_bus_to_virt), \
> + mv_pci_tbi: CAT(which,_pci_tbi)
> +#else
> #define BUS(which) \
> mv_virt_to_bus: CAT(which,_virt_to_bus), \
> mv_bus_to_virt: CAT(which,_bus_to_virt)
> +#endif
>
> #define DO_APECS_BUS BUS(apecs)
> #define DO_CIA_BUS BUS(cia)
> - --- linux/arch/alpha/kernel/pci.c.jj Fri Jan 14 08:29:40 2000
> +++ linux/arch/alpha/kernel/pci.c Thu Feb 3 08:12:24 2000
> @@ -40,6 +40,7 @@ const char pci_hae0_name[] = "HAE0";
> */
>
> struct pci_controler *hose_head, **hose_tail = &hose_head;
> +struct pci_controler *pci_isa_hose;
>
> /*
> * Quirks.
> @@ -327,7 +328,7 @@ pcibios_fixup_pbus_ranges(struct pci_bus
> int __init
> pcibios_enable_device(struct pci_dev *dev)
> {
> - - /* Not needed, since we enable all devices at startup. */
> + /* What in the world is this supposed to do? */
> return 0;
> }
>
> - --- linux/arch/alpha/kernel/pci_impl.h.jj Thu Dec 16 07:37:57 1999
> +++ linux/arch/alpha/kernel/pci_impl.h Thu Feb 3 08:12:24 2000
> @@ -7,7 +7,7 @@
>
> struct pci_dev;
> struct pci_controler;
> - -
> +struct iommu_arena;
>
> /*
> * We can't just blindly use 64K for machines with EISA busses; they
> @@ -125,11 +125,14 @@ static inline u8 bridge_swizzle(u8 pin,
>
> /* The hose list. */
> extern struct pci_controler *hose_head, **hose_tail;
> +extern struct pci_controler *pci_isa_hose;
>
> extern void common_init_pci(void);
> extern u8 common_swizzle(struct pci_dev *, u8 *);
> extern struct pci_controler *alloc_pci_controler(void);
> extern struct resource *alloc_resource(void);
> +
> +extern struct iommu_arena *iommu_arena_new(dma_addr_t, unsigned long);
>
> extern const char *const pci_io_names[];
> extern const char *const pci_mem_names[];
> - --- linux/arch/alpha/kernel/pci_iommu.c.jj Thu Feb 3 08:12:24 2000
> +++ linux/arch/alpha/kernel/pci_iommu.c Thu Feb 3 08:38:44 2000
> @@ -0,0 +1,479 @@
> +/*
> + * linux/arch/alpha/kernel/pci_iommu.c
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/mm.h>
> +#include <linux/pci.h>
> +#include <linux/slab.h>
> +#include <linux/bootmem.h>
> +
> +#include <asm/io.h>
> +#include <asm/hwrpb.h>
> +
> +#include "pci_impl.h"
> +
> +
> +/* #define DEBUG_ALLOC 1 */
> +
> +#if DEBUG_ALLOC
> +# define DBGA(args) printk args
> +#else
> +# define DBGA(args)
> +#endif
> +
> +
> +static inline unsigned long
> +mk_iommu_pte(unsigned long paddr)
> +{
> + return (paddr >> (PAGE_SHIFT-1)) | 1;
> +}
> +
> +static inline long
> +calc_npages(long bytes)
> +{
> + return (bytes + PAGE_SIZE - 1) >> PAGE_SHIFT;
> +}
> +
> +
> +static inline unsigned long
> +calc_order(unsigned long npages)
> +{
> + unsigned long order;
> +#if defined(__alpha_cix__) && defined(__alpha_fix__)
> + asm("ctlz %1,%0" : "=r"(order) : "r"(npages));
> + order += ((npages & -npages) != npages);
> +#else
> + for (order = 0; 1UL << order < npages; ++order)
> + continue;
> +#endif
> + return order;
> +}
> +
> +
> +struct iommu_arena *
> +iommu_arena_new(dma_addr_t base, unsigned long window_size)
> +{
> + unsigned long entries, mem_size, mem_pages;
> + struct iommu_arena *arena;
> +
> + entries = window_size >> PAGE_SHIFT;
> + mem_size = entries * sizeof(unsigned long);
> + mem_pages = calc_npages(mem_size);
> +
> + arena = alloc_bootmem(sizeof(*arena));
> + arena->ptes = alloc_bootmem_pages(mem_pages * PAGE_SIZE);
> +
> + spin_lock_init(&arena->lock);
> + arena->dma_base = base;
> + arena->size = window_size;
> + arena->alloc_hint = 0;
> +
> + return arena;
> +}
> +
> +
> +static long
> +iommu_arena_alloc(struct iommu_arena *arena, long n)
> +{
> + unsigned long flags;
> + unsigned long *beg, *p, *end;
> + long i;
> +
> + spin_lock_irqsave(&arena->lock, flags);
> +
> + /* Search forward for the first sequence of N empty ptes. */
> + beg = arena->ptes;
> + end = beg + (arena->size >> PAGE_SHIFT);
> + p = beg + arena->alloc_hint;
> + i = 0;
> + while (i < n && p < end)
> + i = (*p++ == 0 ? i + 1 : 0);
> +
> + if (p >= end) {
> + /* Failure. Assume the hint was wrong and go back to
> + search from the beginning. */
> + p = beg;
> + i = 0;
> + while (i < n && p < end)
> + i = (*p++ == 0 ? i + 1 : 0);
> +
> + if (p >= end) {
> + spin_unlock_irqrestore(&arena->lock, flags);
> + return -1;
> + }
> + }
> +
> + /* Success. Mark them all in use, ie not zero. Typically
> + bit zero is the valid bit, so write ~1 into everything.
> + The chip specific bits will fill this in with something
> + kosher when we return. */
> + for (p = p - n, i = 0; i < n; ++i)
> + p[i] = ~1UL;
> +
> + arena->alloc_hint = p - beg + n;
> + spin_unlock_irqrestore(&arena->lock, flags);
> +
> + return p - beg;
> +}
> +
> +
> +static void
> +iommu_arena_free(struct iommu_arena *arena, long ofs, long n)
> +{
> + unsigned long *p;
> + long i;
> +
> + p = arena->ptes + ofs;
> + for (i = 0; i < n; ++i)
> + p[i] = 0;
> + arena->alloc_hint = ofs;
> +}
> +
> +/* Map a single buffer of the indicate size for PCI DMA in streaming
> + mode. The 32-bit PCI bus mastering address to use is returned.
> + Once the device is given the dma address, the device owns this memory
> + until either pci_unmap_single or pci_sync_single is performed. */
> +
> +dma_addr_t
> +pci_map_single(struct pci_dev *pdev, void *cpu_addr, size_t size)
> +{
> +#ifdef NEW_PCI_DMA_MAP
> + struct pci_controler *hose = pdev ? pdev->sysdata : pci_isa_hose;
> + dma_addr_t max_dma = pdev ? pdev->dma_mask : 0x00ffffff;
> + long npages, order;
> + unsigned long paddr;
> + dma_addr_t ret;
> +
> + paddr = virt_to_phys(cpu_addr);
> + npages = calc_npages((paddr & ~PAGE_MASK) + size);
> + order = calc_order(npages);
> +
> + /* First check to see if we can use the direct map window. */
> + if (paddr + size + hose->direct_map_base - 1 <= max_dma
> + && paddr + size <= hose->direct_map_size) {
> + ret = paddr + hose->direct_map_base;
> + DBGA(("dma_map_single: [%p,%lx] -> direct %x from %p\n",
> + cpu_addr, size, ret, __builtin_return_address(0)));
> + } else {
> + struct iommu_arena *arena;
> + long dma_ofs, i;
> +
> + /* If the machine doesn't define a pci_tbi routine,
> + we have to assume it doesn't support sg mapping. */
> + if (! alpha_mv.mv_pci_tbi)
> + return 0;
> +
> + arena = hose->sg_pci;
> + if (!arena
> + || arena->dma_base + arena->size > max_dma)
> + arena = hose->sg_isa;
> +
> + dma_ofs = iommu_arena_alloc(arena, npages);
> + if (dma_ofs < 0)
> + return 0;
> +
> + paddr &= PAGE_MASK;
> + for (i = 0; i < npages; ++i, paddr += PAGE_SIZE) {
> + arena->ptes[i + dma_ofs] = mk_iommu_pte(paddr);
> + DBGA(("DMS: %x -> %lx\n",
> + arena->dma_base + ((dma_ofs + i) << PAGE_SHIFT),
> + arena->ptes[i + dma_ofs]));
> + }
> +
> + ret = arena->dma_base + dma_ofs * PAGE_SIZE;
> + ret += (unsigned long)cpu_addr & ~PAGE_MASK;
> +
> + /* ??? This shouldn't have been needed, since the entries
> + we've just modified were not in the iommu tlb. */
> + alpha_mv.mv_pci_tbi(hose, ret, ret + size - 1);
> +
> + DBGA(("dma_map_single: [%p,%lx] np %ld -> sg %x from %p\n",
> + cpu_addr, size, npages, ret,
> + __builtin_return_address(0)));
> + }
> +
> + return ret;
> +#else
> + return virt_to_bus(cpu_addr);
> +#endif
> +}
> +
> +
> +/* Unmap a single streaming mode DMA translation. The DMA_ADDR and
> + SIZE must match what was provided for in a previous pci_map_single
> + call. All other usages are undefined. After this call, reads by
> + the cpu to the buffer are guarenteed to see whatever the device
> + wrote there. */
> +
> +void
> +pci_unmap_single(struct pci_dev *pdev, dma_addr_t dma_addr, size_t size)
> +{
> +#ifdef NEW_PCI_DMA_MAP
> + struct pci_controler *hose = pdev ? pdev->sysdata : pci_isa_hose;
> + long npages, order;
> +
> + npages = calc_npages((dma_addr & ~PAGE_MASK) + size);
> + order = calc_order(npages);
> +
> + if (dma_addr >= hose->direct_map_base
> + && (dma_addr + size
> + <= hose->direct_map_base + hose->direct_map_size)) {
> + /* Nothing to do. */
> + DBGA(("dma_unmap_single: direct [%x,%lx] from %p\n",
> + dma_addr, size, __builtin_return_address(0)));
> + } else {
> + struct iommu_arena *arena;
> + long dma_ofs;
> +
> + arena = hose->sg_pci;
> + if (!arena || dma_addr < arena->dma_base)
> + arena = hose->sg_isa;
> +
> + dma_ofs = (dma_addr - arena->dma_base) >> PAGE_SHIFT;
> + if (dma_ofs * PAGE_SIZE >= arena->size) {
> + printk(KERN_ERR "Bogus dma_unmap_single: dma_addr %x "
> + " base %x size %x\n", dma_addr, arena->dma_base,
> + arena->size);
> + return;
> + BUG();
> + }
> +
> + iommu_arena_free(arena, dma_ofs, npages);
> + alpha_mv.mv_pci_tbi(hose, dma_addr, dma_addr + size - 1);
> +
> + DBGA(("dma_unmap_single: sg [%x,%lx] np %ld from %p\n",
> + dma_addr, size, npages, __builtin_return_address(0)));
> + }
> +#endif
> +}
> +
> +
> +/* Allocate and map kernel buffer using consistent mode DMA for PCI
> + device. Returns non-NULL cpu-view pointer to the buffer if
> + successful and sets *DMA_ADDRP to the pci side dma address as well,
> + else DMA_ADDRP is undefined. */
> +
> +void *
> +pci_alloc_consistent(struct pci_dev *pdev, size_t size, dma_addr_t *dma_addrp)
> +{
> + void *cpu_addr;
> +
> + cpu_addr = kmalloc(size, GFP_ATOMIC);
> + if (! cpu_addr) {
> + printk("pci_alloc_consistent: kmalloc failed from %p\n",
> + __builtin_return_address(0));
> + /* ??? Really atomic allocation? Otherwise we could play
> + with vmalloc and sg if we can't find contiguous memory. */
> + return NULL;
> + }
> + memset(cpu_addr, 0, size);
> +
> + *dma_addrp = pci_map_single(pdev, cpu_addr, size);
> + if (*dma_addrp == 0) {
> + kfree_s(cpu_addr, size);
> + return NULL;
> + }
> +
> + DBGA(("pci_alloc_consistent: %lx -> [%p,%x] from %p\n",
> + size, cpu_addr, *dma_addrp, __builtin_return_address(0)));
> +
> + return cpu_addr;
> +}
> +
> +
> +/* Free and unmap a consistent DMA buffer. CPU_ADDR and DMA_ADDR must
> + be values that were returned from pci_alloc_consistent. SIZE must
> + be the same as what as passed into pci_alloc_consistent.
> + References to the memory and mappings assosciated with CPU_ADDR or
> + DMA_ADDR past this call are illegal. */
> +
> +void
> +pci_free_consistent(struct pci_dev *pdev, size_t size, void *cpu_addr,
> + dma_addr_t dma_addr)
> +{
> + pci_unmap_single(pdev, dma_addr, size);
> + kfree_s(cpu_addr, size);
> +
> + DBGA(("pci_free_consistent: [%x,%lx] from %p\n",
> + dma_addr, size, __builtin_return_address(0)));
> +}
> +
> +
> +/* Map a set of buffers described by scatterlist in streaming mode for
> + PCI DMA. This is the scather-gather version of the above
> + pci_map_single interface. Here the scatter gather list elements
> + are each tagged with the appropriate PCI dma address and length.
> + They are obtained via sg_dma_{address,length}(SG). */
> +
> +static inline unsigned long
> +sg_prepare(struct scatterlist *sg_orig, int nents, int *pdma_nents)
> +{
> + struct scatterlist *sg, *dma_sg;
> + long next_vaddr;
> + dma_addr_t dent_addr, dent_len;
> +
> + sg = dma_sg = sg_orig;
> +
> + next_vaddr = (unsigned long)sg->address + sg->length;
> + dent_addr = (unsigned long)sg->address & ~PAGE_MASK;
> + dent_len = sg->length;
> +
> + for (sg++; --nents >= 0; ++sg) {
> + unsigned long addr;
> + addr = (unsigned long) sg->address;
> +
> + /* For the purposes of DMA, we can combine if the
> + two addresses are virtually contiguous, or if they
> + both are on a page boundary. */
> + if (! (next_vaddr == addr
> + || ((next_vaddr | addr) & ~PAGE_MASK) == 0)) {
> + /* Can't combine. */
> + dma_sg->dma_address = dent_addr;
> + dma_sg->dma_length = dent_len;
> + dma_sg++;
> +
> + /* Round up the displacement to the next page. */
> + dent_addr = (dent_addr + dent_len + PAGE_SIZE - 1);
> + dent_addr &= PAGE_MASK;
> + dent_len = 0;
> + }
> + dent_len += sg->length;
> + next_vaddr = addr + sg->length;
> + }
> + dma_sg->dma_address = dent_addr;
> + dma_sg->dma_length = dent_len;
> + dma_sg++;
> +
> + *pdma_nents = dma_sg - sg_orig;
> +
> + return (dent_addr + dent_len + PAGE_SIZE - 1) >> PAGE_SHIFT;
> +}
> +
> +static inline unsigned long *
> +sg_fill_span(unsigned long *pte, unsigned long start, unsigned long end)
> +{
> + while (start < end) {
> + *pte++ = mk_iommu_pte(start);
> + start += PAGE_SIZE;
> + }
> +
> + return pte;
> +}
> +
> +static inline unsigned long *
> +sg_fill(unsigned long *pte, struct scatterlist *sg, int nents)
> +{
> + unsigned long paddr, next_paddr;
> +
> + paddr = virt_to_phys(sg->address);
> + next_paddr = paddr + sg->length;
> + paddr &= PAGE_MASK;
> +
> + for (++sg; --nents >= 0; ++sg) {
> + unsigned long addr = virt_to_phys(sg->address);
> +
> + if (next_paddr != addr) {
> + pte = sg_fill_span(pte, paddr, next_paddr);
> + paddr = addr & PAGE_MASK;
> + }
> + next_paddr = addr + sg->length;
> + }
> +
> + return sg_fill_span(pte, paddr, next_paddr);
> +}
> +
> +int
> +pci_map_sg(struct pci_dev *pdev, struct scatterlist *sg, int nents)
> +{
> + struct pci_controler *hose;
> + struct iommu_arena *arena;
> + dma_addr_t max_dma, dma_addr;
> + long npages, dma_ofs, i;
> + unsigned long *end_pte;
> + int dma_nents;
> +
> + if (! alpha_mv.mv_pci_tbi) {
> + for (i = 0; i < nents; ++i) {
> + sg[i].dma_address = virt_to_bus(sg[i].address);
> + sg[i].dma_length = sg[i].length;
> + }
> + return nents;
> + }
> +
> +#ifdef NEW_PCI_DMA_MAP
> + /* Fast path single entry scatterlists. */
> + if (nents == 1) {
> + sg->dma_length = sg->length;
> + sg->dma_address = pci_map_single(pdev, sg->address, sg->length);
> + return sg->dma_address != 0;
> + }
> +
> + /* First, find out how many iommu page table entries we'll
> + consume. Also set up zero-biased offsets into the dma
> + region we'll be allocating. */
> +
> + npages = sg_prepare(sg, nents, &dma_nents);
> +
> + /* Second, allocate the iommu ptes. */
> +
> + hose = pdev ? pdev->sysdata : pci_isa_hose;
> + max_dma = pdev ? pdev->dma_mask : 0x00ffffff;
> +
> + arena = hose->sg_pci;
> + if (!arena || arena->dma_base + arena->size > max_dma)
> + arena = hose->sg_isa;
> +
> + dma_ofs = iommu_arena_alloc(arena, npages);
> + if (dma_ofs < 0)
> + return 0;
> + dma_addr = arena->dma_base + dma_ofs * PAGE_SIZE;
> +
> + /* Third, normalize the sg dma addresses. */
> +
> + for (i = 0; i < dma_nents; ++i)
> + sg[i].dma_address += dma_addr;
> +
> + /* Fourth, fill in the iommu ptes. */
> +
> + end_pte = sg_fill(arena->ptes + dma_ofs, sg, nents);
> + if (end_pte - (arena->ptes - dma_ofs) != npages)
> + BUG();
> +
> + /* ??? This shouldn't have been needed, since the entries
> + we've just modified were not in the iommu tlb. */
> + alpha_mv.mv_pci_tbi(hose, dma_addr, dma_addr + npages*PAGE_SIZE - 1);
> +
> + DBGA(("dma_map_sg: ne %d np %ld -> [%x,%d]\n",
> + nents, npages, dma_addr, dma_nents));
> +
> + return dma_nents;
> +#else
> + BUG();
> +#endif
> +}
> +
> +
> +/* Unmap a set of streaming mode DMA translations. Again, cpu read
> + rules concerning calls here are the same as for pci_unmap_single()
> + above. */
> +
> +void
> +pci_unmap_sg(struct pci_dev *pdev, struct scatterlist *sg, int nents)
> +{
> +#ifdef NEW_PCI_DMA_MAP
> + long size, i;
> +
> + if (! alpha_mv.mv_pci_tbi)
> + return;
> +
> + for (i = size = 0; i < nents; ++i)
> + size += (sg[i].dma_length + PAGE_SIZE - 1) & PAGE_MASK;
> +
> + DBGA(("dma_unmap_sg: [%x,%d] np %ld\n",
> + (dma_addr_t) (sg[0].dma_address & PAGE_MASK),
> + nents, calc_npages(size)));
> +
> + pci_unmap_single(pdev, sg[0].dma_address, size);
> +#endif
> +}
> - --- linux/arch/alpha/kernel/proto.h.jj Mon Dec 20 09:10:16 1999
> +++ linux/arch/alpha/kernel/proto.h Thu Feb 3 08:12:24 2000
> @@ -9,55 +9,65 @@
> struct pt_regs;
> struct task_struct;
> struct pci_dev;
> +struct pci_controler;
>
> /* core_apecs.c */
> extern struct pci_ops apecs_pci_ops;
> extern void apecs_init_arch(void);
> extern void apecs_pci_clr_err(void);
> extern void apecs_machine_check(u64, u64, struct pt_regs *);
> +extern void apecs_pci_tbi(struct pci_controler *, dma_addr_t, dma_addr_t);
>
> /* core_cia.c */
> extern struct pci_ops cia_pci_ops;
> extern void cia_init_arch(void);
> extern void cia_machine_check(u64, u64, struct pt_regs *);
> +extern void cia_pci_tbi(struct pci_controler *, dma_addr_t, dma_addr_t);
>
> /* core_irongate.c */
> extern struct pci_ops irongate_pci_ops;
> extern int irongate_pci_clr_err(void);
> extern void irongate_init_arch(void);
> extern void irongate_machine_check(u64, u64, struct pt_regs *);
> +#define irongate_pci_tbi ((void *)0)
>
> /* core_lca.c */
> extern struct pci_ops lca_pci_ops;
> extern void lca_init_arch(void);
> extern void lca_machine_check(u64, u64, struct pt_regs *);
> +extern void lca_pci_tbi(struct pci_controler *, dma_addr_t, dma_addr_t);
>
> /* core_mcpcia.c */
> extern struct pci_ops mcpcia_pci_ops;
> extern void mcpcia_init_arch(void);
> extern void mcpcia_init_hoses(void);
> extern void mcpcia_machine_check(u64, u64, struct pt_regs *);
> +extern void mcpcia_pci_tbi(struct pci_controler *, dma_addr_t, dma_addr_t);
>
> /* core_polaris.c */
> extern struct pci_ops polaris_pci_ops;
> extern void polaris_init_arch(void);
> extern void polaris_machine_check(u64, u64, struct pt_regs *);
> +extern void polaris_pci_tbi(struct pci_controler *, dma_addr_t, dma_addr_t);
>
> /* core_pyxis.c */
> extern struct pci_ops pyxis_pci_ops;
> extern void pyxis_init_arch(void);
> extern void pyxis_machine_check(u64, u64, struct pt_regs *);
> +extern void pyxis_pci_tbi(struct pci_controler *, dma_addr_t, dma_addr_t);
>
> /* core_t2.c */
> extern struct pci_ops t2_pci_ops;
> extern void t2_init_arch(void);
> extern void t2_machine_check(u64, u64, struct pt_regs *);
> +#define t2_pci_tbi ((void *)0)
>
> /* core_tsunami.c */
> extern struct pci_ops tsunami_pci_ops;
> extern void tsunami_init_arch(void);
> extern void tsunami_kill_arch(int);
> extern void tsunami_machine_check(u64, u64, struct pt_regs *);
> +extern void tsunami_pci_tbi(struct pci_controler *, dma_addr_t, dma_addr_t);
>
> /* setup.c */
> extern unsigned long srm_hae;
> - --- linux/include/asm-alpha/io.h.jj Mon Dec 20 09:28:20 1999
> +++ linux/include/asm-alpha/io.h Thu Feb 3 08:13:49 2000
> @@ -430,7 +430,7 @@ out:
> #endif
> #define RTC_ALWAYS_BCD 0
>
> - -/* Nothing to do */
> +/* DMA Cache coherency. Nothing to do. */
>
> #define dma_cache_inv(_start,_size) do { } while (0)
> #define dma_cache_wback(_start,_size) do { } while (0)
> - --- linux/include/asm-alpha/machvec.h.jj Mon Dec 20 09:28:22 1999
> +++ linux/include/asm-alpha/machvec.h Thu Feb 3 08:12:24 2000
> @@ -21,6 +21,7 @@ struct vm_area_struct;
> struct linux_hose_info;
> struct pci_dev;
> struct pci_ops;
> +struct pci_controler;
>
> struct alpha_machine_vector
> {
> @@ -41,6 +42,8 @@ struct alpha_machine_vector
>
> unsigned long (*mv_virt_to_bus)(void *);
> void * (*mv_bus_to_virt)(unsigned long);
> + void (*mv_pci_tbi)(struct pci_controler *hose,
> + dma_addr_t start, dma_addr_t end);
>
> unsigned int (*mv_inb)(unsigned long);
> unsigned int (*mv_inw)(unsigned long);
> - --- linux/include/asm-alpha/pci.h.jj Fri Jan 14 09:44:35 2000
> +++ linux/include/asm-alpha/pci.h Thu Feb 3 08:41:07 2000
> @@ -1,36 +1,136 @@
> #ifndef __ALPHA_PCI_H
> #define __ALPHA_PCI_H
>
> +#include <linux/spinlock.h>
> +#include <asm/scatterlist.h>
> #include <asm/machvec.h>
>
> - -/*
> - - * The following structure is used to manage multiple PCI busses.
> - - */
> +/* Override the logic in pci_scan_bus for skipping already-configured
> + bus numbers. */
> +
> +#define pcibios_assign_all_busses() 1
> +
> +#define PCIBIOS_MIN_IO alpha_mv.min_io_address
> +#define PCIBIOS_MIN_MEM alpha_mv.min_mem_address
>
> struct pci_bus;
> +struct pci_dev;
> struct resource;
>
> +/* An IOMMU allocation arena. There are typically two of these
> + regions per bus. */
> +/* ??? The 8400 has a 32-byte pte entry, and the entire table apparently
> + lives directly on the host bridge (no tlb?). We don't support this
> + machine, but if we ever did, we'd need to parameterize all this quite
> + a bit further. Probably with per-bus operation tables. */
> +
> +struct iommu_arena
> +{
> + spinlock_t lock;
> + unsigned long *ptes;
> + dma_addr_t dma_base;
> + unsigned int size;
> + unsigned int alloc_hint;
> +};
> +
> +/* A controler. Used to manage multiple PCI busses. */
> +
> struct pci_controler {
> - - /* Mandated. */
> struct pci_controler *next;
> struct pci_bus *bus;
> struct resource *io_space;
> struct resource *mem_space;
>
> - - /* Alpha specific. */
> unsigned long config_space;
> unsigned int index;
> unsigned int first_busno;
> unsigned int last_busno;
> +
> +#ifdef NEW_PCI_DMA_MAP
> + dma_addr_t direct_map_base;
> + unsigned int direct_map_size;
> + struct iommu_arena *sg_pci;
> + struct iommu_arena *sg_isa;
> +#endif
> };
>
> - -/* Override the logic in pci_scan_bus for skipping already-configured
> - - bus numbers. */
> +/* IOMMU controls. */
>
> - -#define pcibios_assign_all_busses() 1
> - -
> - -#define PCIBIOS_MIN_IO alpha_mv.min_io_address
> - -#define PCIBIOS_MIN_MEM alpha_mv.min_mem_address
> +/* Allocate and map kernel buffer using consistent mode DMA for PCI
> + device. Returns non-NULL cpu-view pointer to the buffer if
> + successful and sets *DMA_ADDRP to the pci side dma address as well,
> + else DMA_ADDRP is undefined. */
> +
> +extern void *pci_alloc_consistent(struct pci_dev *, size_t, dma_addr_t *);
> +
> +/* Free and unmap a consistent DMA buffer. CPU_ADDR and DMA_ADDR must
> + be values that were returned from pci_alloc_consistent. SIZE must
> + be the same as what as passed into pci_alloc_consistent.
> + References to the memory and mappings assosciated with CPU_ADDR or
> + DMA_ADDR past this call are illegal. */
> +
> +extern void pci_free_consistent(struct pci_dev *, size_t, void *, dma_addr_t);
> +
> +/* Map a single buffer of the indicate size for PCI DMA in streaming
> + mode. The 32-bit PCI bus mastering address to use is returned.
> + Once the device is given the dma address, the device owns this memory
> + until either pci_unmap_single or pci_sync_single is performed. */
> +
> +extern dma_addr_t pci_map_single(struct pci_dev *, void *, size_t);
> +
> +/* Unmap a single streaming mode DMA translation. The DMA_ADDR and
> + SIZE must match what was provided for in a previous pci_map_single
> + call. All other usages are undefined. After this call, reads by
> + the cpu to the buffer are guarenteed to see whatever the device
> + wrote there. */
> +
> +extern void pci_unmap_single(struct pci_dev *, dma_addr_t, size_t);
> +
> +/* Map a set of buffers described by scatterlist in streaming mode for
> + PCI DMA. This is the scather-gather version of the above
> + pci_map_single interface. Here the scatter gather list elements
> + are each tagged with the appropriate PCI dma address and length.
> + They are obtained via sg_dma_{address,length}(SG).
> +
> + NOTE: An implementation may be able to use a smaller number of DMA
> + address/length pairs than there are SG table elements. (for
> + example via virtual mapping capabilities) The routine returns the
> + number of addr/length pairs actually used, at most nents.
> +
> + Device ownership issues as mentioned above for pci_map_single are
> + the same here. */
> +
> +extern int pci_map_sg(struct pci_dev *, struct scatterlist *, int);
> +
> +/* Unmap a set of streaming mode DMA translations. Again, cpu read
> + rules concerning calls here are the same as for pci_unmap_single()
> + above. */
> +
> +extern void pci_unmap_sg(struct pci_dev *, struct scatterlist *, int);
> +
> +/* Make physical memory consistent for a single streaming mode DMA
> + translation after a transfer.
> +
> + If you perform a pci_map_single() but wish to interrogate the
> + buffer using the cpu, yet do not wish to teardown the PCI dma
> + mapping, you must call this function before doing so. At the next
> + point you give the PCI dma address back to the card, the device
> + again owns the buffer. */
> +
> +extern inline void
> +pci_dma_sync_single(struct pci_dev *dev, dma_addr_t dma_addr, size_t size)
> +{
> + /* Nothing to do. */
> +}
> +
> +/* Make physical memory consistent for a set of streaming mode DMA
> + translations after a transfer. The same as pci_dma_sync_single but
> + for a scatter-gather list, same rules and usage. */
> +
> +extern inline void
> +pci_dma_sync_sg(struct pci_dev *dev, struct scatterlist *sg, int nents)
> +{
> + /* Nothing to do. */
> +}
>
> #endif /* __ALPHA_PCI_H */
> - -
> - --- linux/include/asm-alpha/scatterlist.h.jj Wed Oct 13 08:05:45 1999
> +++ linux/include/asm-alpha/scatterlist.h Thu Feb 3 08:12:24 2000
> @@ -1,12 +1,19 @@
> #ifndef _ALPHA_SCATTERLIST_H
> #define _ALPHA_SCATTERLIST_H
>
> +#include <linux/types.h>
> +
> struct scatterlist {
> - - char * address; /* Location data is to be transferred to */
> - - char * alt_address; /* Location of actual if address is a
> - - * dma indirect buffer. NULL otherwise */
> - - unsigned int length;
> + char *address; /* Source/target vaddr. */
> + char *alt_address; /* Location of actual if address is a
> + dma indirect buffer, else NULL. */
> + dma_addr_t dma_address;
> + unsigned int length;
> + unsigned int dma_length;
> };
> +
> +#define sg_dma_address(sg) ((sg)->dma_address)
> +#define sg_dma_len(sg) ((sg)->dma_length)
>
> #define ISA_DMA_THRESHOLD (~0UL)
>
> - --- linux/include/asm-alpha/types.h.jj Wed Oct 13 08:05:46 1999
> +++ linux/include/asm-alpha/types.h Thu Feb 3 08:12:24 2000
> @@ -56,22 +56,14 @@ typedef unsigned short u16;
> typedef signed int s32;
> typedef unsigned int u32;
>
> - -/*
> - - * There are 32-bit compilers for the alpha out there..
> - - */
> - -#if ((~0UL) == 0xffffffff)
> - -
> - -typedef signed long long s64;
> - -typedef unsigned long long u64;
> - -#define BITS_PER_LONG 32
> - -
> - -#else
> - -
> typedef signed long s64;
> typedef unsigned long u64;
> #define BITS_PER_LONG 64
>
> - -#endif
> +/* PCI dma addresses are 32-bits wide. Ignore PCI64 for now, since
> + we'll typically be sending it all through iommu tables anyway. */
> +
> +typedef u32 dma_addr_t;
>
> #endif /* __KERNEL__ */
> #endif /* _ALPHA_TYPES_H */
>
> - --TB36FDmn/VVEgNH/--
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Martin Bene <mb@sime.com>
> Date: Thu, 03 Feb 2000 09:16:55 +0100
> Subject: Re: RAID0 expansion
>
> At 19:59 02.02.00 +0100, Sasi Peter wrote:
> >Unfortunatelly I have an active working raid0 set, and no LVM installed.
> >Somebody once had a program (no I could not find it in the archives), to
> >resize this, and I have got no facility to do a backup, and install LVM.
> >And I guess without a backup LVM will not help me...
>
> I Guess you're looking for this:
> - ------------------
> Hi all !
>
> There's a new version of the raidreconf utility out. I call it 0.0.2.
>
> You can download a patch against the current raidtools at
> http://ostenfeld.dk/~jakob/Software-RAID.HOWTO/
>
> New features:
> *) Bugfix in RAID-0 growth. It now seems to work in all cases with
> strange disk orderings, different disk sizes etc.
> *) Added shrinking of RAID-0 arrays. This also seems to work in all
> cases I have tested.
> *) Added ``importing'' of devices. You can convert a single block
> device in to a RAID (hopefully) without loosing your data on the
> block device.
> - ------------------
>
> Bye, Martin
>
> "you have moved your mouse, please reboot to make this change take effect"
> - --------------------------------------------------
> Martin Bene vox: +43-316-813824
> simon media fax: +43-316-813824-6
> Andreas-Hofer-Platz 9 e-mail: mb@sime.com
> 8010 Graz, Austria
> - --------------------------------------------------
> finger mb@mail.sime.com for PGP public key
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Richard Henderson <rth@cygnus.com>
> Date: Thu, 3 Feb 2000 00:27:04 -0800
> Subject: Re: [2.3.42] Doesn't compile on Alpha
>
> On Thu, Feb 03, 2000 at 09:05:45AM +0100, Jakub Jelinek wrote:
> > Try this.
> > It is Richard Henderson's WIP patch for dynamic DMA I've hacked for what
> > Linus finally accepted into 2.3.41 and hopefully with all the
> > NEW_PCI_DMA_MAP stuff protected by an ifdef of the same name...
>
> Try instead
>
> ftp://ftp.twiddle.net/pub/rth/d-2341.gz
> ftp://ftp.twiddle.net/pub/rth/d-2341-2.gz
>
> They were posted to axp-list, but not here.
>
> r~
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
> Date: Thu, 3 Feb 2000 09:51:27 +0100 (MET)
> Subject: Re: Devices not supporting read-6....
>
> Eric Youngdale wrote:
>
> > Is this what that ghost stuff is really for? There is a much easier
> > way of doing this, you know. There is no technical reason why the
> > same Scsi_Device cannot be driven by both drivers - the only thing
> > you would need to do is to teach sd.c that it should also attach to
> > DVD RAM drives.
>
> Which is what the ghost stuff does, maybe not in the cleanest way, but
> that is still the only thing that it does.
>
> > If I had to guess, all you would need to do is to fix it so that
> > scsi_scan() first marked the Scsi_Device as writable, and then a
> > couple of minor edits to sd.c so that it treats the combination of
> > TYPE_ROM with the writable flag set as equivalent to TYPE_MOD.
>
> The end result is exactly the same as what the ghost stuff does now.
>
> The common code between sd and sr is "read a block". This is code that
> should be shared. Moreover, that's about the only "real" thing that
> should be in those drivers. Of course "sr" also supports a few ioctls,
> and "sd" also does writing.
>
> Roger.
>
> - --
> ** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> "I didn't say it was your fault. I said I was going to blame it on you."
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Oleg Drokin <green@ccssu.crimea.ua>
> Date: Thu, 3 Feb 2000 10:55:50 +0200
> Subject: zillion of oopses on 2.2.15pre4
>
> Hello!
>
> I finally managed to attach serial console to my server.
> Today I came to it and found that server crashed in the night.
> Looking at the logs I found that oopses produced
> logfile of 2825 lines!
> Here I include first two decoded. Second one repeating several times, anyway
> ( I run squid with AIO threads)
> the far you look - the more strange results you see.
> E.g. there is oops where instead of process name multiline part of
> one of my logs printed.
> Anyway Box is Dual P3-450, 256M RAM.
> Linux ccssu 2.2.15pre4 #3 SMP Tue Jan 25 16:46:10 EET 2000 i686 unknown
> This one is patched with raid-012345-... patch.
> Disk subsystem is mixed SCSI Adaptec AIC-7895 Ultra SCSI host adapter
> (2 SCSI disks) and one big IDE drive.
> There is also Moxa 8 port serial board. I use usual serial driver for it
> (setup with setserial), not new moxa driver, that went in at 2.2.14 time.
>
> BTW, it seems that I hit this problem second time, already. First time
> was with 2.2.14 near a week ago.
> Full oops-dump (not decoded) with appropriate System.map is
> at http://crimea.edu/~green/oops/oops.tgz, for anybody who interested.
> If any other info is needed
>
> Options used: -V (default)
> -o /lib/modules/2.2.15pre4/ (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -m /boot/System.map-2.2.15pre4 (specified)
> -c 1 (default)
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000070
> current->tss.cr3 = 01e03000, %cr3 = 01e03000
> *pde = 0e79a067
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c01acf2d>]
> EFLAGS: 00010282
> eax: 00000070 ebx: 00000039 ecx: 00000019 edx: 00000000
> esi: cf607e49 edi: 0000000c ebp: cf607c00 esp: c31fbe54
> ds: 0018 es: 0018 ss: 0018
> Process squid (pid: 10521, process nr: 50, stackpage=c31fb000)
> Stack: c803b000 00000000 00000000 c8c3e1a0 cf607f2f 0000000c ffff39b0 c01acc6c
> cf607c00 cf607c00 c803b000 00000000 c31fbee0 c01ac883 cf607c00 c803b000
> c023dac4 c01a3ccb c803b000 00000000 c01a3c92 c0005d80 00000001 c011b82d
> Call Trace: [<c01acc6c>] [<c01ac883>] [<c01a3ccb>] [<c01a3c92>] [<c011b82d>] [<c0113805>] [<c01134bc>]
> [<c01130b4>] [<c0133388>] [<c0133751>] [<c010ef51>] [<c0109304>] [<c010002b>]
> Code: f0 ff 4a 70 0f 94 c0 84 c0 74 09 52 e8 22 8d fa ff 83 c4 04
>
> >>EIP: c01acf2d <ppp_async_encode+241/288>
> Trace: c01acc6c <ppp_tty_push+100/180>
> Trace: c01ac883 <ppp_tty_wakeup+5f/74>
> Trace: c01a3ccb <do_softint+2f/44>
> Trace: c01a3c92 <do_serial_bh+56/60>
> Trace: c011b82d <do_bottom_half+85/a8>
> Trace: c0113805 <schedule+2ed/3b0>
> Trace: c01134bc <schedule_timeout+6c/8c>
> Trace: c01130b4 <process_timeout+0/10>
> Code: c01acf2d <ppp_async_encode+241/288> 00000000 <_EIP>: <===
> Code: c01acf2d <ppp_async_encode+241/288> 0: f0 ff 4a 70 lock decl 0x70(%edx) <===
> Code: c01acf31 <ppp_async_encode+245/288> 4: 0f 94 c0 sete %al
> Code: c01acf34 <ppp_async_encode+248/288> 7: 84 c0 testb %al,%al
> Code: c01acf36 <ppp_async_encode+24a/288> 9: 74 09 je c01acf41 <ppp_async_encode+255/288>
> Code: c01acf38 <ppp_async_encode+24c/288> b: 52 pushl %edx
> Code: c01acf39 <ppp_async_encode+24d/288> c: e8 22 8d fa ff call c0155c60 <__kfree_skb+0/ac>
> Code: c01acf3e <ppp_async_encode+252/288> 11: 83 c4 04 addl $0x4,%esp
>
> Aiee, killing interrupt handler
> Scheduling in interrupt
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> current->tss.cr3 = 00101000, %cr3 = 00101000
> *pde = 00000000
> Oops: 0002
> CPU: 0
> EIP: 0010:[<c01138b2>]
> EFLAGS: 00010282
> eax: 00000018 ebx: c31fa000 ecx: 000002fd edx: cf4fe000
> esi: c31fa000 edi: cdd34000 ebp: c31fbdb8 esp: c31fbda0
> ds: 0018 es: 0018 ss: 0018
> Process squid (pid: 10521, process nr: 50, stackpage=c31fb000)
> Stack: c31fa000 cdd34000 c011a3b0 c31fa000 00000000 00000246 00000000 c011a7c5
> c31fbe18 c31fa000 c31fbe18 00000000 c0109892 c31fa000 c0109897 0000000b
> 00000000 c011127e c01d87b5 c31fbe18 00000002 c31fa000 cf607e49 0000000c
> Call Trace: [<c011a3b0>] [<c011a7c5>] [<c0109892>] [<c0109897>] [<c011127e>] [<c01d87b5>] [<c010943d>]
> [<c01acf2d>] [<c01acc6c>] [<c01ac883>] [<c01a3ccb>] [<c01a3c92>] [<c011b82d>] [<c0113805>] [<c01134bc>]
> [<c01130b4>] [<c0133388>] [<c0133751>] [<c010ef51>] [<c0109304>] [<c010002b>]
> Code: c7 05 00 00 00 00 00 00 00 00 8d 65 e4 5b 5e 5f 89 ec 5d c3
>
> >>EIP: c01138b2 <schedule+39a/3b0>
> Trace: c011a3b0 <exit_notify+150/29c>
> Trace: c011a7c5 <do_exit+2c9/2d0>
> Trace: c0109892 <die+4e/54>
> Trace: c0109897 <die+53/54>
> Trace: c011127e <do_page_fault+2fa/3d0>
> Trace: c01d87b5 <lk_lockmsg+124b/1306>
> Trace: c010943d <error_code+2d/40>
> Trace: c01acf2d <ppp_async_encode+241/288>
> Trace: c01130b4 <process_timeout+0/10>
> Code: c01138b2 <schedule+39a/3b0> 00000000 <_EIP>: <===
> Code: c01138b2 <schedule+39a/3b0> 0: c7 05 00 00 00 movl $0x0,0x0 <===
> Code: c01138b7 <schedule+39f/3b0> 5: 00 00 00 00 00
> Code: c01138bc <schedule+3a4/3b0> a: 8d 65 e4 leal 0xffffffe4(%ebp),%esp
> Code: c01138bf <schedule+3a7/3b0> d: 5b popl %ebx
> Code: c01138c0 <schedule+3a8/3b0> e: 5e popl %esi
> Code: c01138c1 <schedule+3a9/3b0> f: 5f popl %edi
> Code: c01138c2 <schedule+3aa/3b0> 10: 89 ec movl %ebp,%esp
> Code: c01138c4 <schedule+3ac/3b0> 12: 5d popl %ebp
> Code: c01138c5 <schedule+3ad/3b0> 13: c3 ret
>
> Aiee, killing interrupt handler
> Scheduling in interrupt
>
> 768 warnings issued. Results may not be reliable.
>
> Boot sequence is:
>
> Linux version 2.2.15pre4 (root@ccssu) (gcc version 2.7.2.3) #3 SMP Tue Jan 25 16:46:10 EET 2000
> Intel MultiProcessor Specification v1.1
> Virtual Wire compatibility mode.
> OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
> Processor #0 Pentium(tm) Pro APIC version 17
> Processor #1 Pentium(tm) Pro APIC version 17
> I/O APIC #2 Version 17 at 0xFEC00000.
> Processors: 2
> mapped APIC to ffffe000 (fee00000)
> mapped IOAPIC to ffffd000 (fec00000)
> Detected 451030504 Hz processor.
> Console: colour VGA+ 80x25
> Calibrating delay loop... 448.92 BogoMIPS
> Memory: 257836k/262144k available (996k kernel code, 420k reserved, 2840k data, 52k init)
> Dentry hash table entries: 32768 (order 6, 256k)
> Buffer cache hash table entries: 262144 (order 8, 1024k)
> Page cache hash table entries: 65536 (order 6, 256k)
> VFS: Diskquotas version dquot_6.4.0 initialized
> Checking 386/387 coupling... OK, FPU using exception 16 error reporting.
> Checking 'hlt' instruction... OK.
> POSIX conformance testing by UNIFIX
> mtrr: v1.35a (19990819) Richard Gooch (rgooch@atnf.csiro.au)
> per-CPU timeslice cutoff: 100.00 usecs.
> CPU0: Intel Pentium III (Katmai) stepping 03
> calibrating APIC timer ...
> ..... CPU clock speed is 451.0418 MHz.
> ..... system bus clock speed is 100.2312 MHz.
> Booting processor 1 eip 2000
> Calibrating delay loop... 450.56 BogoMIPS
> OK.
> CPU1: Intel Pentium III (Katmai) stepping 03
> Total of 2 processors activated (899.48 BogoMIPS).
> enabling symmetric IO mode... ...done.
> ENABLING IO-APIC IRQs
> init IO_APIC IRQs
> IO-APIC (apicid-pin) 2-0, 2-20, 2-21, 2-22, 2-23 not connected.
> number of MP IRQ sources: 23.
> number of IO-APIC #2 registers: 24.
> testing the IO APIC.......................
> IO APIC #2......
> .... register #00: 02000000
> ....... : physical APIC id: 02
> .... register #01: 00170011
> ....... : max redirection entries: 0017
> ....... : IO APIC version: 0011
> .... register #02: 00000000
> ....... : arbitration: 00
> .... IRQ redirection table:
> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
> 00 000 00 1 0 0 0 0 0 0 00
> 01 000 00 0 0 0 0 0 1 1 59
> 02 0FF 0F 0 0 0 0 0 1 1 51
> 03 000 00 0 0 0 0 0 1 1 61
> 04 000 00 0 0 0 0 0 1 1 69
> 05 000 00 0 0 0 0 0 1 1 71
> 06 000 00 0 0 0 0 0 1 1 79
> 07 000 00 0 0 0 0 0 1 1 81
> 08 000 00 0 0 0 0 0 1 1 89
> 09 000 00 0 0 0 0 0 1 1 91
> 0a 000 00 0 0 0 0 0 1 1 99
> 0b 000 00 0 0 0 0 0 1 1 A1
> 0c 000 00 0 0 0 0 0 1 1 A9
> 0d 000 00 1 0 0 0 0 0 0 00
> 0e 000 00 0 0 0 0 0 1 1 B1
> 0f 000 00 0 0 0 0 0 1 1 B9
> 10 0FF 0F 1 1 0 1 0 1 1 C1
> 11 0FF 0F 1 1 0 1 0 1 1 C9
> 12 0FF 0F 1 1 0 1 0 1 1 D1
> 13 0FF 0F 1 1 0 1 0 1 1 D9
> 14 000 00 1 0 0 0 0 0 0 00
> 15 000 00 1 0 0 0 0 0 0 00
> 16 000 00 1 0 0 0 0 0 0 00
> 17 000 00 1 0 0 0 0 0 0 00
> .................................... done.
> checking TSC synchronization across CPUs: passed.
> mtrr: your CPUs had inconsistent fixed MTRR settings
> mtrr: probably your BIOS does not setup all CPUs
> PCI: PCI BIOS revision 2.10 entry at 0xfb370
> PCI: Using configuration type 1
> PCI: Probing PCI hardware
> PCI->APIC IRQ transform: (B0,I8,P0) -> 16
> PCI->APIC IRQ transform: (B0,I9,P0) -> 17
> PCI->APIC IRQ transform: (B0,I10,P0) -> 18
> PCI->APIC IRQ transform: (B0,I11,P0) -> 19
> PCI->APIC IRQ transform: (B0,I11,P1) -> 16
> PCI->APIC IRQ transform: (B0,I12,P0) -> 16
> Linux NET4.0 for Linux 2.2
> Based upon Swansea University Computer Society NET3.039
> NET4: Unix domain sockets 1.0 for Linux NET4.0.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP
> TCP: Hash tables configured (ehash 262144 bhash 65536)
> NET4: Linux IPX 0.38 for NET4.0
> IPX Portions Copyright (c) 1995 Caldera, Inc.
> Initializing RT netlink socket
> Starting kswapd v 1.5
> Detected PS/2 Mouse Port.
> Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled
> ttyS00 at 0x03f8 (irq = 4) is a 16550A
> ttyS01 at 0x02f8 (irq = 3) is a 16550A
> Real Time Clock Driver v1.09
> PIIX4: IDE controller on PCI bus 00 dev 39
> PIIX4: not 100% native mode: will probe irqs later
> ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:DMA
> ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:pio
> hdb: QUANTUM FIREBALLlct08 17, ATA DISK drive
> hdc: CD-ROM CDU4011, ATAPI CDROM drive
> hdd: IOMEGA ZIP 100 ATAPI Floppy, ATAPI FLOPPY drive
> ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
> ide1 at 0x170-0x177,0x376 on irq 15
> hdb: QUANTUM FIREBALLlct08 17, 16555MB w/418kB Cache, CHS=20510/81/32, UDMA
> md driver 0.90.0 MAX_MD_DEVS=256, MAX_REAL=12
> raid1 personality registered
> (scsi0) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 11/0
> (scsi0) Wide Channel A, SCSI ID=0, 32/255 SCBs
> (scsi0) Warning - detected auto-termination
> (scsi0) Please verify driver detected settings are correct.
> (scsi0) If not, then please properly set the device termination
> (scsi0) in the Adaptec SCSI BIOS by hitting CTRL-A when prompted
> (scsi0) during machine bootup.
> (scsi0) Cables present (Int-50 NO, Int-68 YES, Ext-68 NO)
> (scsi0) Downloading sequencer code... 374 instructions downloaded
> (scsi1) <Adaptec AIC-7895 Ultra SCSI host adapter> found at PCI 11/1
> (scsi1) Wide Channel B, SCSI ID=0, 32/255 SCBs
> (scsi1) Warning - detected auto-termination
> (scsi1) Please verify driver detected settings are correct.
> (scsi1) If not, then please properly set the device termination
> (scsi1) in the Adaptec SCSI BIOS by hitting CTRL-A when prompted
> (scsi1) during machine bootup.
> (scsi1) Cables present (Int-50 NO, Int-68 NO, Ext-68 NO)
> (scsi1) Downloading sequencer code... 374 instructions downloaded
> scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.23/3.2.4
> <Adaptec AIC-7895 Ultra SCSI host adapter>
> scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.23/3.2.4
> <Adaptec AIC-7895 Ultra SCSI host adapter>
> scsi : 2 hosts.
> (scsi0:0:5:0) Synchronous at 40.0 Mbyte/sec, offset 8.
> Vendor: IBM Model: DNES-309170W Rev: SA30
> Type: Direct-Access ANSI SCSI revision: 03
> Detected scsi disk sda at scsi0, channel 0, id 5, lun 0
> (scsi0:0:6:0) Synchronous at 40.0 Mbyte/sec, offset 8.
> Vendor: IBM Model: DNES-309170W Rev: SA30
> Type: Direct-Access ANSI SCSI revision: 03
> Detected scsi disk sdb at scsi0, channel 0, id 6, lun 0
> scsi : detected 2 SCSI disks total.
> SCSI device sda: hdwr sector= 512 bytes. Sectors= 17916240 [8748 MB] [8.7 GB]
> SCSI device sdb: hdwr sector= 512 bytes. Sectors= 17916240 [8748 MB] [8.7 GB]
> PPP: version 2.3.7 (demand dialling)
> TCP compression code copyright 1989 Regents of the University of California
> PPP line discipline registered.
> ne2k-pci.c:vpre-1.00e 5/27/99 D. Becker/P. Gortmaker http://cesdis.gsfc.nasa.gov/linux/drivers/ne2k-pci.html
> ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xd400, IRQ 16.
> eth0: RealTek RTL-8029 found at 0xd400, IRQ 16, 00:00:01:00:A2:35.
> ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xd800, IRQ 17.
> eth1: RealTek RTL-8029 found at 0xd800, IRQ 17, 00:60:52:07:86:F0.
> ne2k-pci.c: PCI NE2000 clone 'RealTek RTL-8029' at I/O 0xdc00, IRQ 18.
> eth2: RealTek RTL-8029 found at 0xdc00, IRQ 18, 00:00:01:00:91:31.
> rtl8139.c:v1.07 5/6/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html
> eth3: SMC1211TX EZCard 10/100 (RealTek RTL8139) at 0xe800, IRQ 16, 00:e0:29:33:f1:97.
> Partition check:
> sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
> sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 sdb8 >
> md.c: sizeof(mdp_super_t) = 4096
> hdb: [PTBL] [3309/255/63] hdb1 hdb2
> autodetecting RAID arrays
> (read) sda6's sb offset: 1574272 [events: 0000005d]
> (read) sdb6's sb offset: 1574272 [events: 0000005d]
> autorun ...
> considering sdb6 ...
> adding sdb6 ...
> adding sda6 ...
> created md0
> bind<sda6,1>
> bind<sdb6,2>
> running: <sdb6><sda6>
> now!
> sdb6's event counter: 0000005d
> sda6's event counter: 0000005d
> md: md0: raid array is not clean -- starting background reconstruction
> md0: max total readahead window set to 128k
> md0: 1 data-disks, max readahead per data-disk: 128k
> raid1: device sdb6 operational as mirror 1
> raid1: device sda6 operational as mirror 0
> raid1: raid set md0 not clean; reconstructing mirrors
> raid1: raid set md0 active with 2 out of 2 mirrors
> md: updating md0 RAID superblock on device
> sdb6 [events: 0000005e](write) sdb6's sb offset: 1574272
> md: syncing RAID array md0
> md: minimum _guaranteed_ reconstruction speed: 100 KB/sec.
> md: using maximum available idle IO bandwith for reconstruction.
> md: using 128k window.
> sda6 [events: 0000005e](write) sda6's sb offset: 1574272
> .
> ... autorun DONE.
> VFS: Mounted root (ext2 filesystem) readonly.
> Freeing unused kernel memory: 52k freed
> Adding Swap: 104384k swap-space (priority 1)
> Adding Swap: 104384k swap-space (priority 1)
> md0: blocksize changed
> nr_blocks changed to 32 (blocksize 4096, j 6880, max_blocks 393568)
> registered device ppp0
> hdc: ATAPI 40X CD-ROM drive, 120kB Cache
>
> Bye,
> Oleg
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: M.Hunold@t-online.de (Michael Hunold)
> Date: Thu, 03 Feb 2000 09:59:25 +0100
> Subject: Design issues for a kernel-driver
>
> Hello,
>
> I have some questions concerning the design of a
> kernel-driver.
>
> First of all the background of the story:
>
> I have written a driver-package for video-hardware
> that is based on the SAA7146-chipset by
> Philips Semiconductors. The driver can
> be found at http://www.mihu.de/linux/
>
> The package includes a driver for a tv-card
> called "MXB", too.
>
> There is something special about the SAA7146 that
> cleary separates it from chipsets like the BT848:
>
> The SAA7146 can be used in a more generic fashion.
> It features input- and output-ports rather than
> simple connectors for external video-sources. It
> features two busses (i2c and DEBI) that can be
> used to control external hardware. Because of that,
> SAA7146-based hardware can differ very much and
> it is impossible to write a generic driver for
> all the hardware out there.
>
> Until now, the driver can only be compiled as a
> module. I'd like to incorporate it in the kernel
> and so it must become very more -- well -- suitable.
> Please donīt get me wrong: the driver itself is
> very stable and useful, but the integration into
> the kernel-environment is quite terrible at the
> moment.
>
> There is a "saa7146-core"-module, which works like
> this:
>
> When the module is inserted, it scans the pci-bus
> for any available SAA7146 and allocates various
> things like irqs, memory for grabbing-buffers, etc.
> for all of the SAA7146 in the system.
>
> The module then exports some functions to provide
> the functionality to any "real" hardware-specific
> device-driver:
>
> EXPORT_SYMBOL(saa7146_get_handle);
> EXPORT_SYMBOL(saa7146_command);
>
> All "real" functionality lies under the "saa7146_command",
> which can be called with a handle obtained by "saa7146_get_handle".
>
> An example: lets assume that I have inserted the
> "saa7146-core.o"-module and then insert my "mxb.o"-module.
>
> The "init_function" of the module then calls "saa7146_get_handle"
> as often as it returns different handles and then checks
> if a MXB is present. Of course this does not work very well, when
> I have different SAA7146-based hardware in my system and I want
> to insert different drivers.
>
> You should get the idea of how it works.
>
> The good thing of this architecture is, that the real
> hardware-driver does not have to worry about stuff like
> irq-allocation, memory-allocation and similar at all.
> It can implement an interface to a higher API like
> video4linux and use the functions exported by the core-driver.
> So the drivers for different hardwares do not have to
> include the same code over and over again.
>
> Ok, now I'd like to integrate the driver properly into the
> kernel and I can think of only one real solution of the problem:
>
> The core-modules gets some real locking/unlocking mechanisms with
> real handle-handling. External drivers must attach and detach to
> the core in order to be able to call the functions. If they want
> to probe for a specific hardware for example, they have to attach,
> then call some probing-functions and have to detach if the hardware
> does not fit.
>
> There is a second way in my mind, but I don't think that it is
> as stable as the above one:
>
> The core-module "knows" about all SAA7146-based hardware out there.
> I think any hardware can be determined by a specific combination
> of helper-chipsets sitting on the two busses, but I am not completely
> sure about that. Then the core-driver can probe for the devices and
> select the one that fits best...
>
> I had a look through various kernel-drivers, but I did not find
> anything that uses a mechanism like a described above. So I
> am a little confused on how to actually design my driver.
>
> I would really appreciate it, if you comment on my design I
> suggested above. I am interested in any other documents dealing
> withthis issue, too.
>
> Thanks,
> Michael.
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Boszormenyi Zoltan <zboszor@externet.hu>
> Date: Thu, 3 Feb 2000 10:11:10 +0100 (CET)
> Subject: Lockup with heavy io on a HPT366 controller
>
> Hi!
>
> With 2.3.4[12] I get hard lockup during heavy i/o.
> I have a BP6 with two 400 MHz not overclocked Celerons,
> the kernel is compiled SMP. I have these IDE devices:
>
> hda: TOSHIBA CD-ROM XM-6002B, ATAPI CDROM drive
> hdc: QUANTUM FIREBALL_TM2110A, ATA DISK drive
> hde: QUANTUM FIREBALL CX13.0A, ATA DISK drive
>
> The boot disk is hde on the UDMA66 controller,
> hdc is a mobile rack. BTW, is there a way to
> hot-swap the rack?
>
> I can reproduce the lockup by doing
>
> while true ; do dd if=/dev/hde of=/dev/null ; done
> while true ; do tar xzvf linux-2.3.41.tar.gz ; done
> while true ; do tar xzvf linux-2.3.41.tar.gz ; done
>
> on three consoles. The two tar are done in the same
> directory on /dev/hde8. Instantly before the lockup
> I get a "hde: timeout waiting for DMA" message. I tried
> with and without HPT366_FAST_IRQ_PREDICTION, it locks up
> in both cases. With this option the machine seems to stand
> the stress a little longer but sometimes tar (actually its
> gzip child) complains about data corruption. The lockup
> happens in 2 minutes.
>
> I checked it with 2.3.40 and it does not lock up with
> the same procedure though it complains about data corruption
> without HPT366_FAST_IRQ_PREDICTION.
>
> Regards,
> Zoltan Boszormenyi
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: =?iso-8859-1?q?Etienne=20LORRAIN?= <etienne_lorrain@yahoo.fr>
> Date: Thu, 3 Feb 2000 10:22:25 +0100 (CET)
> Subject: OOPS on Mandrake 6.0 system - buffer activity
>
> Hi,
>
> Sorry, the OOPS I reported yesterday was not on Mandrake
> but on RedHat 6.0 - standart install... too many distribution
> installed on my PC.
>
> Etienne.
> ___________________________________________________________
> Do You Yahoo!?
> Achetez, vendez! Ā votre prix! Sur http://encheres.yahoo.fr
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Hari Krishna <hari@iitg.ernet.in>
> Date: Thu, 3 Feb 2000 14:42:18 +0530 (IST)
> Subject: how to do realloc in kernel?
>
> hi,
> is there any kernel function to do realloc for the pointers assigned by
> vmalloc or kmalloc?
>
> thanx in advance
>
> HARI.
>
> =============================================================================
> S.Harikrishna,
> #115, IIT Hostel -6,
> IIT Guwahati -781009.
> Assam.
> India.
> ph: +91-0361-548604
> e-mail : hari_krishna.s@mailcity.com
> hari@iitg.ernet.in
> ==============================================================================
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> From: Boszormenyi Zoltan <zboszor@externet.hu>
> Date: Thu, 3 Feb 2000 10:15:39 +0100 (CET)
> Subject: [PATCH] MTRRs above 4GB (3rd try)
>
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
> Send mail to mime@docserver.cac.washington.edu for more info.
>
> - --685023584-920054653-949569339=:15719
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Hi!
>
> This is the third (I don't expect to be final :-)) attempt, the news:
> - - Avoid some more 64 bit computations. There won't be more
> to remain easily readable.
> - - One fix in cyrix_get_free_region().
> - - Compute only once whether "000" has to be appended
> to the string form of base and size in mtrr_add(),
> - - simple_strtoll() was the copy of simple_strtol(), now calls
> simple_strtoull().
> - - Most drivers that use mtrr_add()/mtrr_del() (except vesafb) are updated
> in a simple way.
> Vesafb is corrected to work on non power of two framebuffer sizes.
> I suppose in the implementation that there is a large area that
> can be write-combined and a smaller area at the end that should be
> uncached. The size reported by the VESA BIOS is the size of the large
> area minus the size of the small area. This works on my videocard
> that reports 32704kB. :-)
>
> I am still waiting for AMD K6-II/K6-III/Athlon and Centaur CPU reports.
>
> Regards,
> Zoltan Boszormenyi
>
> - --685023584-920054653-949569339=:15719
> Content-Type: APPLICATION/octet-stream; name="mtrrpage.gz"
> Content-Transfer-Encoding: BASE64
> Content-ID: <Pine.LNX.4.02.10002031015390.15719@prins.externet.hu>
> Content-Description:
> Content-Disposition: attachment; filename="mtrrpage.gz"
>
> H4sICJBfmDgAA210cnJwYWdlAOxcWXPbuJZ+ln8F2rfiJk1JIbXbsp3YjpzW
> tJeUl15uOqWiJUpmWSJ1ScpLJ+n/Oo/zB+7znHMAkOAi2e6kaqamJtVtSQRw
> cHDW7wCQKpUKm7re4uG1HQxvXrv1Tuv1rRN4zvT1LAqC6rDqB+7E9exp6Vdn
> xI6ca8ZqzGpsw3+NFquZprlmGMZqGqmhzW3T3G40+dC3b1mlVmuWW8zAl5rJ
> 3r5dY5l/4WI4dMKwyhusra0tyzQ78PbE9sYBkL6YB/ZiynZm/HP4duhP/WC8
> mE7dsVMd+rM9PrQkCAbOfGoPYWA4d73B1B/eDgInHN44o8XU0XR270Y3zGae
> H8zsKQudmT2/8QOnumbgaGTctOomvP2nP43+02MH/w7//Hcw+y/v0WU7f177
> 4Z9+8HZmu9Oq8xChIKLqzWKPj1b+nfgjd+wCG9GNw0aBe+cELPLZInTY3J44
> bBLY3mJqB270yFwvjBx7xPxxjsz1Y5Tu6wChx/sbBzhmp/49ke97kTNlHz4E
> vsFsj6bMEdo/ecf2o5up77Gh7cG6I3ZyeX4eMvvav3NY4/1BNTcG6Ab+aIHC
> bDLPuWeuP4ymIQtpHUE4BzkTNVwVMgJ9ckTGC28YuT4YGbBPc9xZ1XorJW7r
> m8V95D6AUgPQpuu53oStu2PQ9cQHkVer1XUQMUNzHdAKoMUeA7EclcCxA5D1
> xJk5XqRaRM2sfTOL+3e+O2KtBrt2IwZ2O19ENgqGkTbZ3A9D93rqrFRD6M7m
> U2cQRkHkf1x8muJSYGl34TxwvWhcHZZJF26Up3Lhzxx2+BiAoMbug4Met/l6
> jf3D9YbTxchhO9zLo8c5tN3s5VucIPB8bCG/blnlNvh1uwkv6NZJbzucvb6x
> g5Eb/KuQjny+VvnHyBm7nkOGOPild37RPztVWV4HQ2kyDYOC2bRq+vqa8Zwh
> LaZJN4YhDDgQgy7Pr3oQY5IHR/vHFz0mItUWLsWom1tla0tGKrDtDukLXHk6
> 2iaJoYRgPFt0uEnh5666nOP+aW9w0f9nj7PUgSD6epP17PCR2RTsMBBMwXfR
> V2/cyQ1EhCAKwf3BhMFBJ/wPzBUv9/hMe9BLm5q28EJ34oEl8C66tgENup70
> /Km/sqdhQV/i58gPwHQgcAwmTjTAlWj6a/4gFA8GiznYl8pH//Sydzw4Ox+c
> 7F/8XNLMhzH/Z14d69le+6fvRLe/UsN0Pn3/t5PeNuuHjLwhCJxh9IadBRRH
> MLqzD/0+uQk4ybWLwYOhV4LDwJpcT7VvHCJi28gfLrAbeVYII2z4CxYBOgzf
> pJYCATG3EDCa1EKwj7IMZQhJcYnCt1qJhf1H/+io3xtc9k96Z1eXDHIbGaQ7
> RgsaDC5OPgwGZH6NdrtsmcxomnV8RfsLcRVDRmEjrSmWaBcaIGxNwO/T+r62
> Q6e8xkolyouZxtD90ykn1ss28a++xj6vVfK9R4vZ7BF62+EtpNMyQ8rwpss1
> kO5Lf7BnmU2xH/kFRdbRLAS20W3nN4/hCRI7uTjXgHVdoU1z6V0+xh0zTRNN
> bIOZDx3T1NnuLoO/n/nsq8mC1+BweAdeQe90wXVMOk+XlcA6+94d5KsR09wq
> 5FnAHY7OKDFUKQSUSLwMRnTxA4qTfyBNdjqIdYym1SjXmqTJUuBEi8DrcqTy
> NSWUmPkDlGvCvBCzIhM+CLj7FSL8BAAMT7qQdAKb2aNRgKEFDZ1p9Vql3tSr
> rD+GZD1zwGfYve1FGHk4FZx94bGHTosdY1Rm4Ds26GF4g1ZLGGkPMAE40MwP
> QPvRjRvCY3DLa5o1pjJ17DDC0AUP3YDNAx9y2CwkORlPLhI0RHbCVcTf6mg0
> TCz1EOgDvphLE0HsAQFjAngqpNVDyp7Gi8dONDNxJ4fsspQVKZ4urEHaCdvY
> TbWL5hDEMbxhGrv2/WgwnC8GIzuyqyC7wZ3jjSCO6rwjGGVpiIbxGzT90jt9
> B8GCQt82NGAHaYbsy246lHZFh2tYzm23gAyEniIiSkTKkhCWJuR4Sfrzg9tQ
> BtvpI3oBmS402YA/7gGioiLvwejI7u0YrQ99iLyThb8IFTcgIUvj/yuWcYVZ
> UrDpRmphe3vsw/57iJc/9Y8u4/ggHUoTZp/XFO9G4SrXLZ5PUCFDys5kqARi
> wxMUgJGvXFKsB1n5SIDWbNwl709H5iFCKuphvyAwY6Bo1lplqw6BotnGV1kc
> IVbwbPAimjwIFnPwW1AVmP29HTKH2kbgac6dCwoBPSJT+G+AlU4EcWEwntoT
> CAP0oouwE9644whll/A4BJwG0IBijf7R+kTCMMddVSfFPrEpJLybUaZcwYeU
> NdmRiBONnzHQ7J+fmxX40yqzWrMlH7WFtW1CXRM525zf3V2YXKTxxnsRh+A/
> WMJiPveDyBlV5bjXSdqgsboMUtIMMeiwHdZmb3jQvzpm2/COwCLYGNvZ4ZMq
> SUJITZdwo5CUJQg1JBU+v/AEGudMQ0d6k5IvGDeEFkHP5lZLgGkhRHY1n4MU
> R+C3I1w0zIk2aZURPUJD8shksREg18gc5DPwNoSZuwQyuwnZS4ibpD/0SsSd
> Y1QBRVPoGDFIfRMPUVQi1NizgB4aydHRUQ/FlnE8Ldue93fVC81uwjMfCSzL
> RoL4l79/6A2uTg/3D3/aPzju5frXivr/en54dnLAs3Fzy0TZtmqWIlu2Wdq0
> ap2fS1AbJtbD8xkJTPsLXnlssGAph910sKPJDdYgZVvNTLRLtdYFyzECKAwz
> 9myUDTLIfAvAYAeYrzfgJQsJhwhzFwEfN3w5JnwhKJQqltPClB9hkk9VqmDU
> cJ0V1l9abow0EzkEC5OMKRXPUxjT5UTPnWm1UebsCAEhIikIwC6BjgDkxD/c
> B27kVKBKuebbDqS6Qg1ntaUoudbALbJWU5bS2PJZxOwoWAwjFhdkmIcB77Fh
> 9BCtBuBxMEZfGfmD0B5DsosJQfaAotNh2gaS0hW/4sJEMMy5I9szWi3IVYkD
> fc1GNTCS0n2QAuMS6jEF0LIvVD6XgXo3P0LCdzniL84MwYYvPGTzkUaJ8ATq
> PL98nQaB66UMJR6hYBF8LMHdMmxHpQb4y/Nw3cZupvjNAbs8pSJot7Gbqj1x
> 4Ff4/wkJEyra2UnWrcfyxpa9PawLlFYSwBM6iLFxrAClllJtodjORlh6JEa2
> AmMpmw7kHGR8jS0K3hTDpe0hzNplhyhBQA2Dg/2LHkRbnpB30FQMDH5dnMem
> QDlbTCN3PnWHfLvt+pHVBY4TCXHoLyBijvx7D0o9f8bqtROmxSBFZ4Dw6Xnt
> PT1u63FaJFNDFKTgAasGYMDqSExa1MWEHq0Yl2EHQlltCFHE98y+dVi4AP+E
> xQ64PUM6b8RZauwHWtyEeZSodOPuhlFOJiYQwuXZ2sJQ07ZMkU+YqkGsS4ll
> 8tSdnTS2M14eTqD5EDwJOS3j5wLkucGhZ/1TwRgDgM6KMTUcg6tqQ5bEVTVa
> yqoyoQyqdJL/G7ZBeWSbbVCGTzAIxTKjVLz2kogpGbiLmeHCiUQhOnHDiO/y
> RxJgafYUHH/0yGEkrAEUxxahXqYams4sKOtoiMHAMMFbdNoWtNEt7hzEt1jS
> U8jiRTbplQ+9FJ9EWoLRUAz4IxpRxV0CVMkYt43tR9a0aj9zcdVRTka7Yyni
> Kgrowjr4FuUuX1Aqz6Op0lNeWIJvAb7H040QcFXsIwqq0nhEr1i6vqGk5G6y
> mafOlQ7hT05m5CfT8qlAp8ivpzFBNzmWwsFf0BmtcRdxEsxKYhXlRjbji7lV
> GRYDFwnCUQOWWSNcZ5mtjtBBDO0Qu00czwncIWEF3HsaCJSfSXYE5zL5HxcM
> 1o4x9uPF1cnJ/vnvn9h7MFGbdrEI3FS5XnYoJ3AjiuwgQvyi8ZpY7qcIi+PT
> y2E4xV5ie5rr0SlVqGe7GytnKePBBelv6XzGsvnEsEx3kv7H897l1fnpxSca
> 4Xoj5yHdDy1HHDqWyd5BH/gMKm0/qEr0xdXUEGrqFKopqfy/s5L2/19Hz9dR
> s1au1VBJW23l4EapY6bigAb/ZdAiX+OUcqfcicLd3zG758ETYjmelAIksSVr
> e4gOgFUPaPi3uLWBkIC5s5kzcm1AMo/pnQjKwnKXge8zIFjObBu1y5CQODsb
> U16JbRDjhJOp3uWxDAEOryVZuxtzTDKKgsdka4WN3SCMYla+8i5i2/zb11iO
> w+2qqY2UFHZ2hRi4DFgJk6HmcvziIjSCF8PAZP2ZJ7js5pq7Qkp8AG3su5j0
> 6xDjNxAQ1QGd+JEzhFSq841Mb+Go/fOSdbH5KwgeBJUsyw29HyPy0LJccJtd
> L6AQjEJu97MFrPvaSfa7aHsLdZDV96qVcH2rbMFChCHt0jYT1bEqszz9SN1e
> vow5o0DSq+wxOUFZwaKuminxJz5WeqdnFx8OlxUDxUE1qZYts92moGxZWyIo
> Yywmd4cQ9dzwqzzD4VQkrck7JAQ0XW8Y0D2AXKTeHxE+w1TKoD14/D8drHdQ
> Nrw7hVPRB6+DpPvFAtvD4BIFC0deRpFhRYJh5wGQckgYGMAw3obhFZg4XxIA
> XpLDHV6u+S2Ta75eK1tWgvRhpItniA/dvxf64QXcQdg16Z5OF8LFeOw+fGx8
> ggC1Dh63zkuq/PPUVgv7oWArYWjPbXGGvUGl/1FvHzJgb4A2pDNd9Y13vV8U
> F/uB24/KkPmJVy1JH8ITKeZkH2LryS0OifhFRC/coCANWFBpbaEGGp0yVKN0
> tFnyk83+GrvGC1f8KYH1cOFG9jXkRNpTxutQvDqi0ybhcBQf+VJIa3u5LTj2
> 5QsToUazqMqHGvzLF9o1ecmwJo2Sbs7j1QZLipIKPYFRmih24hY9HhWrqn/6
> y/5xN+ZBU+ujONUjLTFNqkGncZ/Fvg9jdH/nlmnraLzbXHaQHWV1NwHHodry
> BgJPvUanvH9463o3JlDE1ldiWmw9QUKLkcLYBkeLbgJ/AZWJLF+W7nFx1Vt1
> OtW2rBa84TiL8tTSQ1HIwVlaPO3zqI/3T5KLaxDLnPkcYxmgBEg+Mlk12Il7
> EBsPP3wXjpafGads8VSU52rmj2AufiqysUEWx62goCtW28gHpyUrX01YUa1G
> RSRDx9VjBfwNQpaZJbTSIDTz4dX04RXEabAIz4/SwgFzKIt0p0SLJy3ESMSZ
> 2C+HqjnrlY+5M3yOZbiU1yc4VZh7kf23FPtf5pZM2P9XvkvDjlSTX2Hzh7+f
> 93/bXtraO73cvzrfFhgtJbRx3tu5WmH6M49CIG4ucO9l63T7cl1c/rPntD+J
> 1/8Ikb3EswRPMh6y5dcUMuNwpRxsc0VmdEALwQzOjwqFQ4rNVIewRYPdugdc
> D0tJbDMwBL6nSG9J+zztChvgQ4vM8+9HVu5KpW8Iq6VihoRNyX8v1xOXOI+p
> 9Rbd+QIo25SXvvLzMmXeSoniN82KazFkfjMfLO6cwOaqLiv0PbQ9dFWsBQVe
> u3bQYC3yXe7QZe7WqEMgwq2NQg5BECmjv0H4VViW0Y2IGypxJZ5J01HAThwE
> 8oKTzn944wxvocLF03S6IAW2S8JB80bwR4Ww868F3iXCRwRoqCc2mEJdjS3C
> nzVTbgfx2DPN3jqxOKLER/iCT4hJKjap0w+8aYU2CoKozIJ0VQsFINuvAT2P
> 7ODxZWopTClL5sAeqVm+n34EPOES7tS4hBtWWYEYwpJ3mLiyEwM0Ydt7QvQG
> x/M8QckthMVc28Bb4fRVgGWBSjFu5t85wdSeh7xMQUiitBaLuJyqJ5YJPGPo
> yyZKeuQlzdKyFpOr0o4HSI5IMm94pcK22fp6UvWQ8NSmZ7jSaVz3ock43nDq
> h3hG8YglcbwQpWznit2yuGKbsWKlfmL8vlt85SO/Z7Nao0xIm2jO3HBmY/GD
> W02oRFIw3uQG+UMJi6+qSlM6taMocK8HkY/37cFzafsj95iespzOl7ORM4MC
> dowUO6v9K+n9QoZXqRq1kuyAMMOgOn2AtZzz0f0k/LUGdWAb1IqX5juJv/KD
> TvPFXuj5fFNFVdYYo46CbVc5mDo+K+WYjhiaCV8pN2CqlF/gIDxPk2Tq9XbZ
> wm3p+taWvNwnjg5C0p3YsqLjJAAy/J7H2J06bBP/ltHqIXfwM8/rxVioHPfu
> vPgOz9Qfj+HR5nzuh2Kb6gi/10QXctFtAn+K395ytvlW0zoudRfFisToDVrD
> 7isAovjvDJCtoXQ8lh2PCzrSm/WRG6JN7L4aradurohdGScIukWXyul6UqLR
> wrsseIq/9I6LOpZDdZLUPArUz7j2j/H1/E/yHByAVws3MAyrUduKL2nnrekP
> Loc/6PtDJEd4BC66TgaJD8ggcsbADaEiTQyAgPrFncUUfBOvWRusWWYbwLK4
> 1bK0/5IBNA9tonchGPOvY2koAr0LHkuvysYU0PKGsznTaPw6KRZW0aR0yRFz
> sQyo57fIQNxSyMoA+CgUQWH3Ff2fXYnxRRrZRb6s0CkcTsn9OC5z6EO+0DHy
> NQWXkrKMn/qaei9ZHFDTeqCJw5t00xMLk+XOPQhxhAtD95E1T6ORqnmWsPdN
> dkZxI2Nn3Ac7dOvVajS3ysm5XfZMiCDB6dUJwYILnM9VzFVOmMxHURWeAAoJ
> IVHh1kqCH6B8ostDyWmBmu8hXPE7YYV3m8UdkPzjLMnjM018pQHekcJi0pxh
> HIDpUSYRipGxB0F876ZSScNslesInhqAjlsN5d7OyBnbYKXbqvudnvXPDi+P
> D0/edVObGChHaBnsv3s3gEL0/PdteYKXar7oXa5qftc7XtX8c/84bhfK+SHE
> r4oyLbXL/aF3fiKlAeqZPw7wftWA99wI6VClzDS6vbWpQw024ToCT+SNcg9K
> ScRH+1fHlxkVYyblSuHDqkLd/IPI8fwDvyYHlRuOiQ/hClVliKJEoZkJPAn9
> 9E7Q52Lc8tIAtISEqDCUICR3WwrWm9p/y2914Magur4Cb1AWmfsegKzqKi83
> MTRQovWElT7VB031qT5kr2qn/yGjNUrqt3YyTL5fLa/3WVksYXCyisFJzKCx
> hEEiyrtVAZh5ixme9OI5Lbwd3NnBgL4YFGaEFhuUtinvt+tMS9GBfD5RvVN+
> EqfO8tC5lP5ik5H+btZwNkry4MvDXs7ovlMUMVZFkRU6f8JHsvbPcknomZya
> TyUleXi0OhdUnnSbyre5TaXYKp/h9iynSTwGWiEfobm/KxU1Bf4vEktBpFPk
> QiKpWKnkkBLLNwhECV/LVvvM0FS82so3hqbKdwhNSqeCu8PKoHzrMyI6kxTE
> F1TEpQZFmJEvRJkRYSzZnCzF1nVWmAQ4m2aTX6lrme3UUW9y2ye9GyS/CM1v
> D8c72soQ9XiiqEkyhJgetxmtkwN+1lsa28MIj1LYj7c/orISFG6ZdEwTi7Wm
> HpXgq2AnppuQOsmQqimk8HMnIcWXIn5fAwdpdjh03cH1Yjx2sB6NPw7o0g7f
> SlwH+3ll1ly+y74LUMzsADLTXjWm7smBXhbbKvDp1fAAd/3K/ArM7qtRvB3p
> qse5e3s1U9YpfB28U9HeXjmjnhjmkcHkDtMo6adWCR+fXiZ2WrJOJKq96qSW
> 2lm2VKKTWWsnu1Tq9KK1iuv8329dTbmuZ6rwu6+LW2SGX2bsYv0LRSN7YmV6
> apOyEv80lPh1ltd2OKvQrzvRzzrdLP1pqOa22c7+NNQSGqmh1nazvm2ZyU9D
> Nei7KPBX3OVSf9olhS9EVmGD/tmv9D2lAZW49M2fMtAuy6/J8dqfx7g8vTgR
> qfTO8wTraXqTZfSSTL+av0Yxf0aWXhqDLqfXfCa9NEhcTq/1THppZLWcXvuZ
> 9N4X8Vegj06xPnL0MhBnKX9bS+xlTX43OhT3opOLi/SjSPzWSOoHiDJHVcws
> 8Cv+if9k2kq3qlvL3CpNYrVXNU30qqb8gldp//LyvH8wOD0772Fhzn+hKnch
> Vt1p1dSThzJ/2Syr12X1hFBu/POGG4V8FDDzMnLFVJ5JRC4JTy7+u72ja0oc
> CT5zvyLl1S5gAEmABaOw5bpgebdind7uPVxdpSIEjWdMjgTEB//7TXfPJJOP
> QfRej0JiSE/PR/d0z0x/wDVGjUA1tL/IOLSFHzcgs1iu3DpbsFCuoa0d+8GL
> 8vXBAjQIwQGal9yP4DATHu2H1LyUsyibXHQAkOzGP2DVRKpkfj3LOLS6BdZS
> 4MgVNQ1WOuWtAeb8SuLGeBaj08vp5PwMXVlhlQWLDN8JmyNh1LW/Xl3Yk6uT
> i7H95ftkMkYokJdwVIaQlK3iI0H+cXX++9gG983z6fn0rE7hEpUKQmJ8fLrP
> peLBYhG5MXgAsxvUr6hXXyswGqULcSrBzagJniyElkLkHU3F6S7o15/dx7m3
> 2EauW8f3HXu+XMs0u2Bi5hfwQjI045PVYe/OqzSTEOUJZ1qmnIWxBx4rOl3I
> y0giFI7RKEl/hM8wg0A8C+a404AXv5W2jGlpXIuK4ZFpUvg+Md+WgZdRJFtU
> hqiLlgHXfB1/+X5Gh6G4mx1qtAwTvRDAOxEoni82efoUxrd3+Cp9Ujz54l2r
> 3ZXIY2CMPV3+J4+CPJ4ZwJ8dzjw1YTptphBVhMlgyBc0rI6ZksTo99E4hRdy
> 9aJsiSUib9Yc3ayiFmDFDmL2FQ3GNhE7DMR3fRsC7MUWoFyG6OWFMkOvFWST
> SiDxsWRLm8q5eWmfX/1G4rVj1mYNTNKCr1LtsvbmbnDgxM+GOVjcbJkKh1av
> qxrxPJIitUxJvxjdvkkmQbwqdYy3qNFpDc6Hk9PT8fW1PWH6YnKJD1rrpePX
> tSHpDTGc2BYbfWmIDtmC+LjFNlJ1rj4U5bIDr8JRojqUSqOsA5B9zubd0AwE
> I4tP7dfx1dQGSG1PjKtFbi/gYBkH2uWUe+QqSOo78TLYZEla0D7F9L8qJHl2
> 6LO1rLQchZQRkNuIriTcFINmr9CVBHp8w6YUG3A2AZzN3IvCB+cZHh0pGUJL
> OKK5jSO0d3CDeqa+o553cI96taGo30bu2cY4gnrEONVIg1NA9PoUTvUvPDVN
> r0/Zk3qJHKww+W3Hnu8uax+zDZitllGwbOEzzA6iXiBub3k9nbigx1TDXD5+
> 3PauGlqu3f4L8rfTUJbFrO5bx/aC1SNTm/nqfS9orbESorAalCpKYFWTPbr1
> 1k/ZuT5Zeto0WEOeEjjMOWTTHfNuK+d6giM/1QeWIanMw14XeIUu5KTwIiU7
> lbmgqaUTJBuwWeeV2ZK6lL7Zqjp3R5pTp7kK3qhaMUvTLHyuMRTe4yJoQaTR
> o+O7KWa420IkWCduVbEDq2tul8cCRVE5Z/YB7Q4m1OFXymhQNkv5C6MLH4NU
> tNJXyTCLHrPNoyRJ898S0ZJIo62ls2NfhikLIfaSik3ZaJiYFrgU3JOkXkHs
> 8deLklJrN3Je0Zwd5b4giyJDqb5ldqxOX9KbPVKbvXZCJ/EijbLmjoJeAEnP
> Q0nPNDiEsNsxshU1ALXC0hZM1rn8yNiJ0WdkhTvpkGI12Rch94P9MP+bH2y/
> Cd3mFXRJ4v5iD9b57hwYbbOLklHdBJh94Jr+Yb7BN/koMol8G98N4RZjncUp
> fa72J28e34ka71zIhijubsJQ/JsiZH2ZLV22dEE2pSjqI566CrfccDFNsYPI
> B0LXMAt2nUxdS/eflRvFPOS91t50Zu2G1jEbom97nJrJaiezxShnAPXqRV4z
> 6bSlTNzg7tFx18BPExUmJJzifpkycnDUA0894WtpUB7lI75FGTIUkNFhG4p7
> dt8xjiR3zUFbBBqmuI6PAdd9s0m40D0dHt/XVYv1rJxIa9xFujOUIl1GJdPw
> NrWXNepeO9a8I+GrWqM2YvIxaKfoM5kUdVyJwS2MavnqMNusWtpeHefxjq0W
> NnoDBB9vPlRqypVKteqSqNh9j5meeKcVi5pNcg9I1lfER0nevgp6luEHmGnZ
> W6k8936Mr0+0H2cntCIVALM7MOavHTjWm37/9k1Wqw/ezUH6Wwhbztq7hR1r
> tmhOOHfhxEeyXA3QcjUAt0wpvXfhHD1ssEVC2OCudpRf7Y0n3gwHPxBGVJmk
> FYj3Jx2oXIJ16Uarhxh5lq2qwftV57Oe5xRA7uBahNvS4SmrEiZWtV0VDMRh
> BkS/WajrKa8l4Jsqxjh7Eduv3Xox6/yfxl/1hAfTUkmVnwr8oFee7iACopZg
> YdgpdBq7AOoukh58hvFpspZqFpTBqD18wm3An5nKwaA/ArcAvN6snlR1iLw+
> 1qRxSEaL/tnn8WRi5NIOvAifLkYOlD1IGBABPD3dLJQ8qQkb+wId1nYyT+xI
> cW8BnRoOq81qXY5WLTBTqBsZNtTLubXArthkMIk9ufz3XTz85Zf4jin2J/rd
> l3mAqeKDFaXAm1HSDe9m6SyfM9YyL7I5W9QrNfYB55lANyAtuztmd4dVsMH9
> C4DHdDKzaAAA
> - --685023584-920054653-949569339=:15719--
>
> Please read the FAQ at http://www.tux.org/lkml/
>
> ------------------------------
>
> End of linux-kernel-digest V1 #148
> **********************************
>
> To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
> in the body of a message to "Majordomo@vger.rutgers.edu". If you want
> to subscribe something other than the account the mail is coming from,
> such as a local redistribution list, then append that address to the
> "subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-linux-kernel@your.domain.net
>
> A non-digest (direct mail) version of this list is also available; to
> subscribe to that instead, replace all instances of "linux-kernel-digest"
> in the commands above with "linux-kernel".
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Feb 07 2000 - 21:00:09 EST