This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun May 5 20:21:57 2024 Received: from lml.valinux.com (postfix@lml.valinux.com [198.186.203.19]) by herbie.ucs.indiana.edu (8.9.3/8.9.3) with ESMTP id GAA04052 for ; Thu, 3 Feb 2000 06:46:19 -0500 (EST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by lml.valinux.com (Postfix) with ESMTP id D90725924E; Thu, 3 Feb 2000 03:48:54 -0800 (PST) Received: by vger.rutgers.edu via listexpand id ; Thu, 3 Feb 2000 02:26:59 -0500 Received: by vger.rutgers.edu id ; Thu, 3 Feb 2000 02:25:18 -0500 Received: from pbox.rz.RWTH-Aachen.DE ([137.226.144.252]:2288 "EHLO pbox.rz.rwth-aachen.de") by vger.rutgers.edu with ESMTP id ; Thu, 3 Feb 2000 02:23:58 -0500 Received: from deselaers.de (IDENT:thomasd@phelps.Informatik.RWTH-Aachen.DE [137.226.116.15]) by pbox.rz.rwth-aachen.de (8.9.3/8.9.3) with ESMTP id MAA20523 for ; Thu, 3 Feb 2000 12:37:09 +0100 Message-Id: <38996857.62C2F7DA@deselaers.de> Date: Thu, 03 Feb 2000 12:36:55 +0100 From: Thomas Deselaers Reply-To: Thomas@deselaers.de Organization: GELB X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.12 i686) X-Accept-Language: de, en Mime-Version: 1.0 To: linux-kernel@vger.rutgers.edu Subject: Re: linux-kernel-digest V1 #148 References: <20000203055543Z153898-17760+54@vger.rutgers.edu> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel-outgoing-dig 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 > 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 > > - -- > at work, 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" > Date: Wed, 2 Feb 2000 23:10:08 -0500 > Subject: Re: Devices not supporting read-6.... > > - ----- Original Message ----- > From: "Rogier Wolff" > To: "Drew Eckhardt" > Cc: "Kenneth D. Merry" ; "Jonas Nickel" > ; "Rogier Wolff" ; > ; ; > > 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 > 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 > 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" > 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 > 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 > 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 > Date: 03 Feb 2000 02:48:37 -0500 > Subject: Re: RAID0 expansion > > Sasi Peter writes: > > > On Wed, 2 Feb 2000, Stephen C. Tweedie wrote: > > > > > On Tue, 1 Feb 2000 22:15:23 +0100 (CET), Sasi Peter > > > 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 > 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 > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +#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 > +#include > #include > > - -/* > - - * 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 > + > 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 > 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 > 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 > 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:[] > 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: [] [] [] [] [] [] [] > [] [] [] [] [] [] > Code: f0 ff 4a 70 0f 94 c0 84 c0 74 09 52 e8 22 8d fa ff 83 c4 04 > > >>EIP: c01acf2d > Trace: c01acc6c > Trace: c01ac883 > Trace: c01a3ccb > Trace: c01a3c92 > Trace: c011b82d > Trace: c0113805 > Trace: c01134bc > Trace: c01130b4 > Code: c01acf2d 00000000 <_EIP>: <=== > Code: c01acf2d 0: f0 ff 4a 70 lock decl 0x70(%edx) <=== > Code: c01acf31 4: 0f 94 c0 sete %al > Code: c01acf34 7: 84 c0 testb %al,%al > Code: c01acf36 9: 74 09 je c01acf41 > Code: c01acf38 b: 52 pushl %edx > Code: c01acf39 c: e8 22 8d fa ff call c0155c60 <__kfree_skb+0/ac> > Code: c01acf3e 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:[] > 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: [] [] [] [] [] [] [] > [] [] [] [] [] [] [] [] > [] [] [] [] [] [] > Code: c7 05 00 00 00 00 00 00 00 00 8d 65 e4 5b 5e 5f 89 ec 5d c3 > > >>EIP: c01138b2 > Trace: c011a3b0 > Trace: c011a7c5 > Trace: c0109892 > Trace: c0109897 > Trace: c011127e > Trace: c01d87b5 > Trace: c010943d > Trace: c01acf2d > Trace: c01130b4 > Code: c01138b2 00000000 <_EIP>: <=== > Code: c01138b2 0: c7 05 00 00 00 movl $0x0,0x0 <=== > Code: c01138b7 5: 00 00 00 00 00 > Code: c01138bc a: 8d 65 e4 leal 0xffffffe4(%ebp),%esp > Code: c01138bf d: 5b popl %ebx > Code: c01138c0 e: 5e popl %esi > Code: c01138c1 f: 5f popl %edi > Code: c01138c2 10: 89 ec movl %ebp,%esp > Code: c01138c4 12: 5d popl %ebp > Code: c01138c5 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) 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) 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 > > scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.1.23/3.2.4 > > 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 > bind > running: > 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 > 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?= > 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 > 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 > 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: > 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/