Re: 2T for i386
On Thu, Aug 31, 2000 at 07:46:49PM +0100, Alan Cox wrote: > > >You might be able to do that with hardware IDE raid controllers and the like > > >such as the 3ware 8 port cards, or scsi raid controllers and then run ext3 > > >or reiserfs. > > > > If you're building a 2TB array, you're not gonna do it with bloody IDE > > hardware. (I hope you're joking.) > > I used to think that. Im planning on deploying a 1Tb IDE raid using 3ware kit > for an ftp site very soon. Its very cheap and its very fast. UDMA with > one disk per channel and the controller doing some of the work. > > All it lacks is hot swap. I think that may be in the works... -dg -- David Gould [EMAIL PROTECTED] SuSE, Inc., 580 2cd St. #210, Oakland, CA 94607 510.628.3380 No team manager will tell you this; but they all want to see you come walking back into the pits sometimes, carrying the steering wheel.-- Mario Andretti - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: failed to exec /sbin/modprob -s -k binfmt-0000,errno=2
On Fri, 1 Sep 2000 [EMAIL PROTECTED] wrote: > After i compiled kernel,i get these messages at boot time > I got the kernel linux-2.4.0-test7.tar.gz,after i complied the kernel,i > modified my /etc/lilo.conf, that is > _ > boot=/dev/sda > map=/boot/map > install=/boot/boot.b > prompt > timeout=50 > default=linux > image=/boot/vmlinuz-2.4.0-test7 >label=linux-2.4.0 >initrd=/boot/initrd-2.4.0.img >read-only >root=/dev/sda6 Hi BMECMAIL, 1. are you actually using initrd or are you just cut-and-pasting entries in /etc/lilo.conf without having any clue what you are doing (since you provided PCI config info as relevant to this problem, the latter is quite likely) 2. did you compile ELF support statically into the kernel? 3. did you compile ext2 support statically into the kernel? 4. did you forget to upgrade modutils as documented in Documentation/Changes? Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
failed to exec /sbin/modprob -s -k binfmt-0000,errno=2
After i compiled kernel,i get these messages at boot time I got the kernel linux-2.4.0-test7.tar.gz,after i complied the kernel,i modified my /etc/lilo.conf, that is _ boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 default=linux image=/boot/vmlinuz-2.4.0-test7 label=linux-2.4.0 initrd=/boot/initrd-2.4.0.img read-only root=/dev/sda6 image=/boot/vmlinuz-2.3.99-pre9 label=linux-2.3.99 initrd=/boot/initrd-2.3.99-pre9.img read-only root=/dev/sda6 image=/boot/vmlinuz-2.2.14-2.0smp label=linux initrd=/boot/initrd-2.2.14-2.0smp.img read-only root=/dev/sda6 _ when lilo appeared,i choose linux-2.4.0 and i got the following messages: kmod:failed to exec /sbin/modprobe -s -k binfmt-,errno=2 (the message appeared 4 times) kmod:failed to exec /sbin/modprobe -s -k block-major-8,errno=2 VFS:cannot open root device "806" or 08:06 kernel panic:VFS:unable to mount root fs on 08:06 (1) my processor informations processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 499.151528 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 498.07 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 2 cpu MHz : 499.151528 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 498.07 (2) my modules information nfsd 144604 8 (autoclean) nfs28600 1 (autoclean) lockd 31144 1 (autoclean) [nfsd nfs] sunrpc 54116 1 (autoclean) [nfsd nfs lockd] eepro100 12304 1 (autoclean) raid5 18280 1 (autoclean) aic7xxx 112848 11 (3) loaded driver -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 02f8-02ff : serial(auto) 0376-0376 : ide1 03c0-03df : vga+ 03f8-03ff : serial(auto) 70e0-70ff : Intel Speedo3 Ethernet 7400-74be : aic7xxx 7800-78be : aic7xxx fff8- : ide1 (4) PCI information 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03 ) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Step ping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B+ 00:02.0 Ethernet controller: Intel Corporation 82557 (rev 05) Subsystem: Unknown device 1014:00d7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
failed to exec /sbin/modprob -s -k binfmt-0000,errno=2
After i compiled kernel,i get these messages at boot time I got the kernel linux-2.4.0-test7.tar.gz,after i complied the kernel,i modified my /etc/lilo.conf, that is _ boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 default=linux image=/boot/vmlinuz-2.4.0-test7 label=linux-2.4.0 initrd=/boot/initrd-2.4.0.img read-only root=/dev/sda6 image=/boot/vmlinuz-2.3.99-pre9 label=linux-2.3.99 initrd=/boot/initrd-2.3.99-pre9.img read-only root=/dev/sda6 image=/boot/vmlinuz-2.2.14-2.0smp label=linux initrd=/boot/initrd-2.2.14-2.0smp.img read-only root=/dev/sda6 _ when lilo appeared,i choose linux-2.4.0 and i got the following messages: kmod:failed to exec /sbin/modprobe -s -k binfmt-,errno=2 (the message appeared 4 times) kmod:failed to exec /sbin/modprobe -s -k block-major-8,errno=2 VFS:cannot open root device "806" or 08:06 kernel panic:VFS:unable to mount root fs on 08:06 (1) my processor informations processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 499.151528 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 498.07 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 2 cpu MHz : 499.151528 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 498.07 (2) my modules information nfsd 144604 8 (autoclean) nfs28600 1 (autoclean) lockd 31144 1 (autoclean) [nfsd nfs] sunrpc 54116 1 (autoclean) [nfsd nfs lockd] eepro100 12304 1 (autoclean) raid5 18280 1 (autoclean) aic7xxx 112848 11 (3) loaded driver -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 02f8-02ff : serial(auto) 0376-0376 : ide1 03c0-03df : vga+ 03f8-03ff : serial(auto) 70e0-70ff : Intel Speedo3 Ethernet 7400-74be : aic7xxx 7800-78be : aic7xxx fff8- : ide1 (4) PCI information 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03 ) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Step ping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B+ 00:02.0 Ethernet controller: Intel Corporation 82557 (rev 05) Subsystem: Unknown device 1014:00d7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
failed to exec /sbin/modprob -s -k binfmt-0000,errno=2
After i compiled kernel,i get these messages at boot time I got the kernel linux-2.4.0-test7.tar.gz,after i complied the kernel,i modified my /etc/lilo.conf, that is _ boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 default=linux image=/boot/vmlinuz-2.4.0-test7 label=linux-2.4.0 initrd=/boot/initrd-2.4.0.img read-only root=/dev/sda6 image=/boot/vmlinuz-2.3.99-pre9 label=linux-2.3.99 initrd=/boot/initrd-2.3.99-pre9.img read-only root=/dev/sda6 image=/boot/vmlinuz-2.2.14-2.0smp label=linux initrd=/boot/initrd-2.2.14-2.0smp.img read-only root=/dev/sda6 _ when lilo appeared,i choose linux-2.4.0 and i got the following messages: kmod:failed to exec /sbin/modprobe -s -k binfmt-,errno=2 (the message appeared 4 times) kmod:failed to exec /sbin/modprobe -s -k block-major-8,errno=2 VFS:cannot open root device "806" or 08:06 kernel panic:VFS:unable to mount root fs on 08:06 (1) my processor informations processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 499.151528 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 498.07 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 2 cpu MHz : 499.151528 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr xmm bogomips: 498.07 (2) my modules information nfsd 144604 8 (autoclean) nfs28600 1 (autoclean) lockd 31144 1 (autoclean) [nfsd nfs] sunrpc 54116 1 (autoclean) [nfsd nfs lockd] eepro100 12304 1 (autoclean) raid5 18280 1 (autoclean) aic7xxx 112848 11 (3) loaded driver -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 02f8-02ff : serial(auto) 0376-0376 : ide1 03c0-03df : vga+ 03f8-03ff : serial(auto) 70e0-70ff : Intel Speedo3 Ethernet 7400-74be : aic7xxx 7800-78be : aic7xxx fff8- : ide1 (4) PCI information 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03 ) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Step ping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- FastB2B+ 00:02.0 Ethernet controller: Intel Corporation 82557 (rev 05) Subsystem: Unknown device 1014:00d7 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR+ FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- http://www.tux.org/lkml/
Re: Bug: remounting CD-ROM drives does not lock/unlock drive
Jens Axboe wrote: > > On Mon, Aug 28 2000, Rene Mayrhofer wrote: > > I already tried to do so, but I could not find a way.to lock the CD-ROM > > tray on my (SCSI DVD) CD-ROM drive after it has been mounted with the door > > not being lock. How can this be done ? > > > > 'setcd -l1' does not work > > I don't know setcd, but issuing a CDROM_LOCKDOOR ioctl with arg 1 > will lock the door. Unmounting is a different issue, because currently > you can't do that if the drive is opened more than once (which it will > be, mount + locking program). I guess we could work around this by allowing > root to unlock a busy drive, or some other hack like that. Ok, now I think to know what you are meaning: The program locking the door should stay active until the CD-ROM should be unlocked, right ? I always though about issuing some single call to lock or unlock the drive (e.g. setcd), but I never thought about this. What do I have to do to make this possible ? Could you give me some hint on how to allow root to unlock it in a clean way ? I wouldn't be very happy to apply special 'CD-ROM bootable interim hack' patches to each kernel I build for the project. Is there a way to do this general enough so that it can go into the main kernel (maybe another config option in /proc/sys/dev/cdrom if root should be allowed to unlock under all conditions) ? Thanks for your help, Rene - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: pcmcia-cd-3.1.19
Thanks for your reply. > On Thu, 31 Aug 2000, Ibrahim El-Shafei wrote: > > > Hi, > > When I tried to install the pcmcia-cs-3.1.19, I got a message that I > > attached it with this E-Mail, so I stopped the installation until I find the > > answer. > > Date doesn't like that no timezone is set. Try setting one. > > man date might be helpful. but the time and date are set correctly and I don't know why I get this message. can I ignore the message? > > > > This may help you: > > I live in Egypt/CAIRO > > > > thanks for help. > > > Igmar > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test7 spurious '##' patches
On Fri, Sep 01, 2000 at 03:56:40PM +1100, Keith Owens wrote: > On Thu, 31 Aug 2000 21:44:16 -0700, > Richard Henderson <[EMAIL PROTECTED]> wrote: > >On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote: > >> Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version > >> 2.96-ia64-000717 snap 000828. It complained about various include > >> files, "pasting would not give a valid preprocessing token", this > >> version of gcc is a bit more paranoid about the use of '##'. > > > >> -#define dprintk(args...) dfprintk(FACILITY, ## args) > >> +#define dprintk(args...) dfprintk(FACILITY, args) > > > >This one isn't. This is a gcc extension to remove the previous token > >if "args" is empty. So you'd get > > > > dfprintk(FACILITY); > >instead of > > dfprintk(FACILITY, ); > > I know about that extension and I originally tried > dfprintk(FACILITY , ##args) which is what gcc info recommends, but that > still gave a warning message. With a snapshot that recent, (FACILITY , ## args) and (FACILITY, ##args) are equivalent. Older gcc (including 2.95 and all 2.96 up through May or so) would delete too much if you used the second form. The 'pasting would not give ...' warning is supposed to be suppressed in this context, but obviously it isn't working. I'll look into it. zw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test7 spurious '##' patches
On Thu, 31 Aug 2000 21:44:16 -0700, Richard Henderson <[EMAIL PROTECTED]> wrote: >On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote: >> Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version >> 2.96-ia64-000717 snap 000828. It complained about various include >> files, "pasting would not give a valid preprocessing token", this >> version of gcc is a bit more paranoid about the use of '##'. > >> -#define dprintk(args...)dfprintk(FACILITY, ## args) >> +#define dprintk(args...)dfprintk(FACILITY, args) > >This one isn't. This is a gcc extension to remove the previous token >if "args" is empty. So you'd get > > dfprintk(FACILITY); >instead of > dfprintk(FACILITY, ); I know about that extension and I originally tried dfprintk(FACILITY , ##args) which is what gcc info recommends, but that still gave a warning message. Since this particular macro requires at least one argument (dprintk() and dfprintk(FACILITY) are meaningless), it was easier to remove the '##'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
On Fri, Sep 01, 2000 at 12:16:38AM +0300, Matti Aarnio wrote: > Also (I recall) because GCC's 'long long' related operations > and optimizations have been buggy in past, and there is no > sufficient experience to convince him that they work now better > with the recommended kernel compiling GCC version (egcs-1.1.2). To my knowlege it's only been speed related issues, not correctness issues, that have been the cause for the fear and loathing of long long. r~ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test7 spurious '##' patches
On Thu, Aug 31, 2000 at 07:09:00PM +1100, Keith Owens wrote:
> Compiling 2.4.0-test7 with the latest IA64 toolchain, gcc version
> 2.96-ia64-000717 snap 000828. It complained about various include
> files, "pasting would not give a valid preprocessing token", this
> version of gcc is a bit more paranoid about the use of '##'.
It's also lying sometimes. For instance.
> -#define SOCK_DEBUG(sk, msg...) do { if((sk) && ((sk)->debug)) printk(KERN_DEBUG ##
>msg); } while (0)
> +#define SOCK_DEBUG(sk, msg...) do { if((sk) && ((sk)->debug)) printk(KERN_DEBUG
>msg); } while (0)
This change is correct.
> -#define dprintk(args...) dfprintk(FACILITY, ## args)
> +#define dprintk(args...) dfprintk(FACILITY, args)
This one isn't. This is a gcc extension to remove the previous token
if "args" is empty. So you'd get
dfprintk(FACILITY);
instead of
dfprintk(FACILITY, );
r~
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
Paul Jakma <[EMAIL PROTECTED]> writes: > will old tools work with kernel+nfs patches? i think the fear and > main argument against updating NFS in linux 2.2 is that people will > be forced to update their tools. You'd need a pretty recent util-linux package (mount in particular) to actually take use of it, an old 2.9f will not suffice. Check http://nfs.sourceforge.net/ -- Matthias Andree Where do you think you're going today? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Hello! This is one of my first posts here, so try to be gentle, please ;) Seems like if a thread which shares a VM with all the other threads of the same family does an execve, the following would be likely to occurr, using the standard definition of execve. The vm would be overwriteen with the new image, but this would have to wwipe out all the other threads in the process, 'cuz otherwise everything they refer to has just been overwritten by the results of the execve. However, if the execve'ing thread was allowed to spawn off intop a new address space before the execve, it would then become a new process, and leave the parent procvess with one less thread to worry about. Or am I being very stupid and overlooking something critical here? Have a nice day ;) Erik McKee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tracing in the presence of forks.
> Is there any mechanism to automatically stop a process created > by a traced parent preventing this race condition from occurring ? Yeah, use ptrace to stop on every child system call. When the child calls fork(), then change its memory at the return instruction to "jmp ." instruction. Then the grandchild will be born into slavery and you can attach to it before it runs away. Works for me. You could do the same thing without stopping on every system call by assuming that "fork" is the only function that actually calls the kernel to fork, and setting breakpoints in there and then doing the "jmp ." trick. That doesn't protect against children that are actively seeking to evade control but it ought to work on all well behaved citizens. Gosh, I feel like Big Brother now. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: UDMA/66
Thanks for the help i was running at 3.4 MB/sec now it's as high as 27 MB/sec >for starters any other suggestions? shouldn't DMA be enabled upon bootup? Mike Sklar wrote: > > hdparm /dev/hda (or whatever your drive is called) > > Want to see transfer speeds? > > hdparm -t /dev/hda > > A ATA/66 drive @ 7200 RPM should be doing 30MB/s. ATA/33 drive should be > doing 15MB/s. Are you getting 4MB/s? Try just turning on generic dma for > starters. > > hdparm -d1 /dev/hda > > ...g'luck. > > On Thu, 31 Aug 2000, Jonathan Stanford wrote: > > > This is just my lack of experiance talking, but here's the deal... > > > > I have a VIA chipset that supports UDMA66. > > the HD also supports it > > bla bla bla.. > > > > how do i know that linux is using the drive in UDMA66 mode? > > > > I do get the message at bootup: > > ide0: VIA Bus-Master (U)DMA Timing Config Success > > > > But that could be UDMA16 for all i know > > > > How do i know what mode it's in? > > > > -- > > Jonathan Stanford <[EMAIL PROTECTED]> > > "Stand on your own head for a change" - TMBG > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
Keith Owens writes: > Having one directory per installed kernel containing vmlinux, map, > config, build symlink, modules and any future kernel related data makes > sense. Hear, hear. I'm in this camp. I think there should be one build target: "make linux" and one install target: "make install". If you want to get the bzImage file out of the installed place and stick it wherever your personal peccadillo says it should go, there will be documentation revealing where you can pick it up. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: processes hung
On Thu, 31 Aug 2000 [EMAIL PROTECTED] wrote: > I am testing my scsi driver. I started the test, and down > the line, the I/O processes (cp/rm) are hung. It looks > like they are hung on completion of some I/O. How do I > find out, for which I/O they are waiting ? Is there any > way to look at the kernel data structures ? Albert Cahalan sent this one to me when I was having scsi troubles. ps -eo fname,tty,pid,stat,pcpu,nwchan,wchan ps -eo pid,stat,pcpu,nwchan,wchan=WIDE-WCHAN-COLUMN -o args dave -- David Weis| 10520 New York Ave, Des Moines, IA 50322 [EMAIL PROTECTED] | Voice 515-278-0133 Ext 231 | http://www.perfectionlearning.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
UDMA/66
This is just my lack of experiance talking, but here's the deal... I have a VIA chipset that supports UDMA66. the HD also supports it bla bla bla.. how do i know that linux is using the drive in UDMA66 mode? I do get the message at bootup: ide0: VIA Bus-Master (U)DMA Timing Config Success But that could be UDMA16 for all i know How do i know what mode it's in? -- Jonathan Stanford <[EMAIL PROTECTED]> "Stand on your own head for a change" - TMBG - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/net/sys900.c: bugfix and cleanups
Hi,
Please consider applying, comments are on the patch.
- Arnaldo
--- linux-2.4.0-test8-pre1/drivers/net/sis900.c Thu Aug 10 10:14:32 2000
+++ linux-2.4.0-test8-pre1.acme/drivers/net/sis900.cThu Aug 31 23:17:10 2000
@@ -18,6 +18,12 @@
preliminary Rev. 1.0 Jan. 18, 1998
http://www.sis.com.tw/support/databook.htm
+ Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> - 2000/08/31
+ - get rid of check_region (possible race in 2.4)
+ - release the net_dev returned by init_etherdev after unregister_netdevice on
+failure
+ - no need to allocate and zeroing of net_dev->priv, init_etherdev does this for us
+ - small cleanups
+
Rev 1.07.01 Aug. 08 2000 Ollie Lho minor update fro SiS 630E and SiS 630E A1
Rev 1.07 Mar. 07 2000 Ollie Lho bug fix in Rx buffer ring
Rev 1.06.04 Feb. 11 2000 Jeff Garzik <[EMAIL PROTECTED]> softnet and init
for kernel 2.4
@@ -179,7 +185,8 @@
}
pci_io_base = pci_resource_start(pci_dev, 0);
- if (check_region(pci_io_base, SIS900_TOTAL_SIZE)) {
+ /* We do a request_region() to register /proc/ioports info. */
+ if (!request_region(pci_io_base, SIS900_TOTAL_SIZE, "sis900")) {
printk(KERN_ERR "sis900.c: can't allocate I/O space at 0x%08x\n",
pci_io_base);
return -ENODEV;
@@ -187,14 +194,18 @@
/* setup various bits in PCI command register */
if (pci_enable_device (pci_dev))
- return -ENODEV;
+ goto cleanup_region;
+
pci_set_master(pci_dev);
/* do the real low level jobs */
if (sis900_mac_probe(pci_dev, card_names[pci_id->driver_data]) == NULL)
- return -ENODEV;
+ goto cleanup_region;
return 0;
+cleanup_region:
+ release_region(pci_io_base, SIS900_TOTAL_SIZE);
+ return -ENODEV;
}
/* older SiS900 and friends, use EEPROM to store MAC address */
@@ -274,7 +285,8 @@
int i, ret = 0;
u8 revision;
- if ((net_dev = init_etherdev(net_dev, 0)) == NULL)
+ net_dev = init_etherdev(NULL, sizeof(struct sis900_private));
+ if (!net_dev)
return NULL;
pci_read_config_byte(pci_dev, PCI_CLASS_REVISION, &revision);
@@ -285,10 +297,8 @@
else
ret = sis900_get_mac_addr(pci_dev, net_dev);
- if (ret == 0) {
- unregister_netdevice(net_dev);
- return NULL;
- }
+ if (ret == 0)
+ goto cleanup_netdev;
/* print some information about our NIC */
printk(KERN_INFO "%s: %s at %#lx, IRQ %d, ", net_dev->name,
@@ -297,28 +307,15 @@
printk("%2.2x:", (u8)net_dev->dev_addr[i]);
printk("%2.2x.\n", net_dev->dev_addr[i]);
- if ((net_dev->priv = kmalloc(sizeof(struct sis900_private), GFP_KERNEL)) ==
NULL) {
- unregister_netdevice(net_dev);
- return NULL;
- }
-
sis_priv = net_dev->priv;
- memset(sis_priv, 0, sizeof(struct sis900_private));
-
- /* We do a request_region() to register /proc/ioports info. */
- request_region(ioaddr, SIS900_TOTAL_SIZE, net_dev->name);
net_dev->base_addr = ioaddr;
net_dev->irq = irq;
sis_priv->pci_dev = pci_dev;
spin_lock_init(&sis_priv->lock);
/* probe for mii transciver */
- if (sis900_mii_probe(net_dev) == 0) {
- unregister_netdev(net_dev);
- kfree(sis_priv);
- release_region(ioaddr, SIS900_TOTAL_SIZE);
- return NULL;
- }
+ if (sis900_mii_probe(net_dev) == 0)
+ goto cleanup_netdev;
pci_dev->driver_data = net_dev;
pci_dev->dma_mask = SIS900_DMA_MASK;
@@ -334,6 +331,10 @@
net_dev->watchdog_timeo = TX_TIMEOUT;
return net_dev;
+cleanup_netdev:
+ unregister_netdevice(net_dev);
+ kfree(net_dev);
+ return NULL;
}
static int __init sis900_mii_probe (struct net_device * net_dev)
@@ -655,7 +656,7 @@
net_dev->name, inl(ioaddr + txdp));
}
-/* Initialize the Rx descriptor ring, pre-allocate recevie buffers */
+/* Initialize the Rx descriptor ring, pre-allocate receive buffers */
static void
sis900_init_rx_ring(struct net_device *net_dev)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
[snip the plans for AFFS] You know what? Try it. If your scheme is doable at all (I _very_ seriously doubt it, since I've seen similar attempts on FAT-derived filesystems and I remember very well what horror it was) it is doable with private locks. Just take your locks always after the VFS is done with getting its locks and you can forget about the locking done in VFS - the only effect will be that you will see (possibly) fewer simultaneous calls. Which should reduce the pressure on your mechanisms, so if they can work by theselves - they will work. Go ahead, write it. IMNSHO it's going to be much more complicated and race-prone, but code talks. If you will manage to write it in clear and race-free way - fine. Frankly, I don't believe that it's doable. Several things to watch for: * opened unlinked files should remain available until the last process closes the file. * if foo and bar exist there should be no interval during the rename(foo, bar) when open(bar,...) would fail. * busy directories can be removed. * ... and that includes rename() over them. * large intervals when power-off would lead to unrecoverable fs are bad. I'm not talking about full protection, but several seconds of inactivity (i.e. no new requests being submitted) should be enough even on floppies. You will get dirty fs, indeed, but it shouldn't be in catastrophically bad state. BTW, I really wonder what kind of locks are you going to have on _blocks_ (you've mentioned that, unless I've misparsed what you've said). IMO that way lies the horror, but hey, code talks. Right now the thing doesn't even work reliably. If you claim that your design will reduce the contention if VFS will get out of the way - better yet, but let's see first if it will work and will be readable. Allocation problems are not going to enter the game - on AFFS you've got no sparse files and thus all allocation is process-synchronous. Moreover, you can count on the fact that truncate and allocation attempts on a file are not going to clash (that includes the lack of clashes between allocations). You claim that it's doable. I seriously doubt it. Nobody knows your ideas better than you do, so... come on, demonstrate the patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Tracing in the presence of forks.
When a process (traced using the ptrace call) forks, the tracing process cannot keep track of the first few system calls executed by the child process as the child may be scheduled to run before it can be safely attached. Is there any mechanism to automatically stop a process created by a traced parent preventing this race condition from occurring ? If not, what are the implications of adding this functionality to the kernel via say a /proc interface ? Regards Timothy Muir - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test7 lockup - fixed
On Wed, Aug 30, 2000 at 08:24:00PM -0500, Gregory T. Norris wrote: > I'm seeing a hard lockup under 2.4.0-test7. The good news is that it's > 100% reproducible... all I have to do is attempt to install > gpm_1.19.3-3.deb from Debian unstable (interestingly, no other package > seems to trigger the problem). The bad news is that I have no idea > what the problem is. > > The kernel is just a stock 2.4.0-test7 (i.e. no patches have been > applied). I've attached the output from ksymoops, as well as the > config. System information: > > Motherboard: Supermicro PIIIDME (i840 based) > CPU: Dual PIII 600MHz > RAM: 512MB SDRAM > SCSI:Adaptec 2940UW > D'oh! It looks like this was already fixed in 2.4.0-test8-pre1. Sorry for the bogus bugreport... > If there are any missing details I need to fill in, please let me know. > Thanx! PGP signature
RE: Large File support and blocks.
> And the below is what percentage of time doing disk i/o? but most file operations don't do physical IO. > > it again! It doesn't scale well. The long long code is nearly 10 times > > slower! You can do `gcc -S -o xxx name.c` and see why. it's silly to talk about unoptimized code. and to spuriously inflate the memory traffic in this femto-benchmark. measured sanely, optimized with 2.95.2 on a celeron/450, long long costs ~2-3x as much. regards, mark hahn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arch/i386/kernel/acpi.c: get rid of check_region and other small fixes/cleanups
Hi,
Please consider applying.
- Arnaldo
--- linux-2.4.0-test8-pre1/arch/i386/kernel/acpi.c Fri Jul 28 06:34:22 2000
+++ linux-2.4.0-test8-pre1.acme/arch/i386/kernel/acpi.c Thu Aug 31 15:57:57 2000
@@ -21,6 +21,12 @@
/*
* See http://www.geocities.com/SiliconValley/Hardware/3165/
* for the user-level ACPI stuff
+ *
+ * Changes:
+ * Arnaldo Carvalho de Melo <[EMAIL PROTECTED]> - 2000/08/31
+ * - check copy*user return
+ * - get rid of check_region
+ * - get rid of verify_area
*/
#include
@@ -135,8 +141,7 @@
*len = 0;
return 0;
}
- copy_to_user(buffer, str, size);
- return 0;
+ return copy_to_user(buffer, str, size) ? -EFAULT : 0;
}
static void cx_statistics(unsigned int x, unsigned long time)
@@ -1283,11 +1288,9 @@
*/
static int acpi_claim(unsigned long start, unsigned long size)
{
- if (start && size) {
- if (check_region(start, size))
+ if (start && size)
+ if (!request_region(start, size, "acpi"))
return -EBUSY;
- request_region(start, size, "acpi");
- }
return 0;
}
@@ -1391,7 +1394,8 @@
val = *(unsigned long*) ctl->data;
size = sprintf(str, "0x%08lx\n", val);
if (*len >= size) {
- copy_to_user(buffer, str, size);
+ if (copy_to_user(buffer, str, size))
+ return -EFAULT;
*len = size;
}
else
@@ -1404,7 +1408,8 @@
size = sizeof(str) - 1;
if (size > *len)
size = *len;
- copy_from_user(str, buffer, size);
+ if (copy_from_user(str, buffer, size))
+ return -EFAULT;
str[size] = '\0';
val = simple_strtoul(str, &strend, 0);
if (strend == str)
@@ -1423,22 +1428,22 @@
size_t size,
struct acpi_table_info *info)
{
+ struct acpi_table hdr;
+ size_t table_size;
+
if (size < sizeof(struct acpi_table))
return -EINVAL;
- else if (verify_area(VERIFY_READ, buffer, size))
+
+ if (copy_from_user(&hdr, buffer, sizeof(hdr)))
return -EFAULT;
- else {
- struct acpi_table hdr;
- size_t table_size;
- copy_from_user(&hdr, buffer, sizeof(hdr));
- table_size = (size_t) hdr.length;
- if (hdr.signature != info->expected_signature
- || table_size < size
- || (info->expected_size
- && table_size != info->expected_size))
- return -EINVAL;
- }
+ table_size = (size_t) hdr.length;
+ if (hdr.signature != info->expected_signature
+ || table_size < size
+ || (info->expected_size
+ && table_size != info->expected_size))
+ return -EINVAL;
+
return 0;
}
@@ -1496,7 +1501,8 @@
error = acpi_verify_table(buffer, *len, info);
if (error)
return error;
- copy_from_user(&hdr, buffer, sizeof(hdr));
+ if (copy_from_user(&hdr, buffer, sizeof(hdr)))
+ return -EFAULT;
table_size = (size_t) hdr.length;
write_lock(&acpi_do_table_lock);
@@ -1517,7 +1523,8 @@
error = -ENOMEM;
}
if (data)
- copy_from_user(data, buffer, size);
+ if (copy_from_user(data, buffer, size))
+ error = -EFAULT;
write_unlock(&acpi_do_table_lock);
}
@@ -1565,7 +1572,8 @@
size = sprintf(str, "0x%08x\n", val);
if (*len >= size) {
- copy_to_user(buffer, str, size);
+ if (copy_to_user(buffer, str, size))
+ return -EFAULT;
*len = size;
}
else
@@ -1580,7 +1588,8 @@
size = sizeof(str) - 1;
if (size > *len)
size = *len;
- copy_from_user(str, buffer, size);
+ if (copy_from_user(str, buffer, size))
+ return -EFAULT;
str[size] = '\0';
val = (u32) simple_strtoul(str, &strend, 0);
if (strend == str)
@@ -1682,7 +1691,8 @@
pm1_status,
gpe_status,
event_state);
- copy_to_user(buffer, str, size);
+ if (copy_to_user(buffer, str, size))
+ return -EFAULT;
*len = size;
Re: Linux 2.2.18pre1
On Fri, 1 Sep 2000, Neil Brown wrote: > What incompatible tools??? > > Any nfs-utils that work with vanilla 2.2.16 will work just fine with > patched 2.2.16. They may not access any new functionality, but there > ARE NO INCOMPATIBILITIES (that I know of, and I am quute close to the > game). > i meant old tools. sorry. will old tools work with kernel+nfs patches? i think the fear and main argument against updating NFS in linux 2.2 is that people will be forced to update their tools. (however to that arg i say: anybody who uses NFS for any half serious purpose will already have patched up, or is using a dist kernel with patches). > Note that this is in contrast to the changes that went into 2.2.14, > which DID break compatability - all of a sudden you needed to run > lockd from user space, where as before you didn't. (with the patches > you don't any more, so they actaully improve compatability). > cool. another reason to include the patches. > NeilBrown > > -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: I try to keep an open mind, but not so open that my brains fall out. -- Judge Harold T. Stone - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
processes hung
Hi All, I am testing my scsi driver. I started the test, and down the line, the I/O processes (cp/rm) are hung. It looks like they are hung on completion of some I/O. How do I find out, for which I/O they are waiting ? Is there any way to look at the kernel data structures ? Thanks and regards, -hiren - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On Friday September 1, [EMAIL PROTECTED] wrote: > > 2: incompatible tools: those who follow a dist are already using > incompatible tools anyway, and can either stay with their dist or get > the neccessary tools themselves (nfs-utils is available in RPM and > deb anyway!). those who follow the stock kernel can read the changes > file. What incompatible tools??? Any nfs-utils that work with vanilla 2.2.16 will work just fine with patched 2.2.16. They may not access any new functionality, but there ARE NO INCOMPATIBILITIES (that I know of, and I am quute close to the game). Note that this is in contrast to the changes that went into 2.2.14, which DID break compatability - all of a sudden you needed to run lockd from user space, where as before you didn't. (with the patches you don't any more, so they actaully improve compatability). NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
clocks out of sync even after running xntpd on Alpha
On UP2000, time gets lagging behind, while on LX164 with AlphaBIOS, time gets faster about a minute a day compared to two other Linux boxes with Intel CPUs. On both Alpha machines with SuSE-6.4, I started /etc/rc.d/xntpd at boot time. Had checked the time right after boot, both clocks were reset correctly to clock of the xntp server as expected. What is responsible for this error? The real-time clock of each machine or the kernel? RTC support has been enabled on the kernel config on every machine. Best regards, G. Hugh Song - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
kqueue
I haven't been keeping up with the planned changes in 2.4 and beyond. Are there any plans to include something like kevent/kqueue in future kernels? Has someone already implemented something like this and have patches available? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On 1 Sep 2000, Matthias Andree wrote: > Alan Cox <[EMAIL PROTECTED]> writes: > Well, I'm asking again, as usual, are you planning to integrate > kernel-space NFSv3? I'd appreciate if you did. yes please. 0: The new NFS patches work so so much better than vanilla linux nfs. 1: due to (0) most dists have actually been distributing the patches and updated userland for a v. long time now! 2: incompatible tools: those who follow a dist are already using incompatible tools anyway, and can either stay with their dist or get the neccessary tools themselves (nfs-utils is available in RPM and deb anyway!). those who follow the stock kernel can read the changes file. please please lets sort out NFS in 2.2! (cause it's going to be around for a good while yet). Any pain it may cause in tool updates is completely mitigated by the stability, performance and interoperability benefits of the the patches. regards, -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: "Are you sure you're not an encyclopedia salesman?" No, Ma'am. Just a burglar, come to ransack the flat." -- Monty Python - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
Hi, > > - get dentry foo > > - get dentry baz > > How? OK, you've found block of baz. You know the name, all right. Links are chained together and all point back to the original, so if you remove the original, you have quite something to do with lots of links. > Now > you've got to do the full tracing all the way back to root. All file header have a pointer to the dir header, so it's not that difficult, but that makes links to directories so interesting. :) Anyway, I'll better try to describe the idea more generally: The basic idea is to introduce transient states to vfs and to move the locking into the fs, which probably knows better what needs to be protected. This would avoid the current locking overkill. Let's take a rename, first we mark the object as to be moved, no need to keep it locked after this. An open on this object would either fail or had to wait (on a seperate queue). Next we mark the destination dir as not removable. This is basically the job of vfs so far, the next steps happen in the fs. (I use affs here as an example.) First we lock the source dir and remove the object from the chain and unlock the dir. Now I can lock the destination, insert the object here and unlock the dir. (back to vfs) All we have to do now is to restore now the state of destination dir and the object and we have to wakeup anyone who's waiting. Back to the original example of removing a file with links. I have to get the dentry of baz as I have to prevent a lookup of that link, while I'm modifying its block. But I think it's enough to lock that block and check only the cached aliases. Then I can modify that block and unlock it again. > > - update file header baz from file header foo > > If it would be that simple... Extent blocks refer to foo, unfortunately. > Yes, copying the thing would be easier. Too bad, data structure prohibits > that. Which data structure prohibits that? Updating the extent blocks isn't that difficult as the back links are not needed for general operation, it's just wasting I/O. A bit more problematic are concurrent readers of foo, so I can't simply trash the buffer of foo's file header, but I can simply keep it allocated till the file is closed (keeps also the inode number constant and unique). > Well, consider rename over the primary link and there you go... Keep in > mind that extent blocks contain the reference to header block, so unless > you want to update them all you've got to move the header into donor's > chain ;-/ Oops, I just read rename(2) and notice that I forgot about a small detail. Ok, above rename operation get's slightly more difficult. Basically it's only a variation of the unlink problem, I first unlink the old file and then insert the new file. As I do less locking, I shouldn't have a locking problem or what do I miss? I just might have to update lots of back links, but that is not a critical part. [I can skip the affs history part, I just see you already got a better answer than I could give.] bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
Alan Cox <[EMAIL PROTECTED]> writes: > Since 2.2.17 isnt out yet I've released 2.2.18pre1 versus 2.2.17pre20. So > you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre > patch of choice. Well, I'm asking again, as usual, are you planning to integrate kernel-space NFSv3? I'd appreciate if you did. -- Matthias Andree Where do you think you're going today? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On Thu, Aug 31, 2000 at 11:54:06PM +0100, Alan Cox wrote: > o Merge the microcode driver from 2.4 into 2.2(Tigran Aivazian) Just to let people know: This doesn't compile as it has devfs stuff left in it. Fix is in the works... Best regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, 31 Aug 2000 15:08:49 -0400 (EDT), Chris Meadors <[EMAIL PROTECTED]> wrote: >What about those of us who don't have modules enabled. "make >modules_install" complains. > >I'm still like the idea of /lib/kernel or /lib/linux. Keep /lib/modules >for modules. Or on my machines I won't even have to create /lib/modules. The directory name is irrelevant, we just want one place to store information for a specific kernel. Right now we have /boot/vmlinuz, /boot/System.map with symlinks to the real vmlinuz and map, /lib/modules/ contains modules and the symlink to the kernel source tree, nothing contains .config. Is it just me or does this design make no sense? Having one directory per installed kernel containing vmlinuz, map, config, build symlink, modules and any future kernel related data makes sense. Whether you call it /lib/modules/ or /lib/kernel/ is irrelevant. The fact that "make modules_install" complains without modules configured in is also irrelevant, that little bit of the Makefile is easily fixed, but there is no point in changing the Makefile until we agree on a design change. The only problem I can see with the single directory model is on disks where /lib/module//vmlinuz is past cylinder 1024, although that restriction is fast disappearing. Even this problem can be easily fixed by a new Makefile target (make install_low) which copies vmlinuz to /boot as well as /lib/module/. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any good _online_ kernel BSD sockets reference out there??
On Thu, 31 Aug 2000, Andi Kleen wrote: > > Most of your questions should be answered in packet(7) You mean packet(4)?? BTW, very nice piece of documentation!! > In future please try to consult the available documentation before asking > user questions on the kernel list. Actually my question was whether I should change the _kernel_ device driver in order to support that. I guess this _is_ a kernel question ... In the end, it was solved from userspace, but I didn't know that was possible. But ok, your advice was taken (believe me, I'm serious). I'll try and look for docs more thoroughly before dropping a note here. Thanks. Later, Ivan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH] Re: grow_inodes: inode-max limit reached - how to find/fix the inode leak?
On Fri, Sep 01, 2000 at 12:37:21AM +0200, Trond Myklebust wrote: > > " " == Michael Riepe <[EMAIL PROTECTED]> writes: > > > On Thu, Aug 31, 2000 at 03:23:43PM +0200, Trond Myklebust > > wrote: > >> Your patch does not seem correct to me. IMO you should rather > >> be calling nlm_release_file() in both cases where you applied > >> 'put_file()'. > > > No. In the first of two cases, lockd will call > > nlm_release_file() on its own when the function returns. In > > The call in nlmsvc_unshare_file() is in order to clear the f_count > from nlmsvc_share_file(). Yes. That one was missing. > That in nlmsvc_proc_unshare() clears the f_count from > nlmsvc_retrieve_args(). Correct. The calling sequence is nlmsvc_retrieve_args() /* increments */ nlmsvc_unshare_file() /* decrements if share is removed */ nlm_release_file() /* decrements */ so f_count will be at least 2 when nlmsvc_unshare_file() finds a share to remove. In nlmsvc_traverse_shares(), the surrounding retrieve/release calls are missing, so the minimum f_count is 1. > > the second case, we're being called from inside > > nlm_traverse_files(), which holds a lock on the file table -- > > nlm_release_file() would wait forever. > > Ugh. In that case, my personal preference would be to make > nlm_release_file() grab the semaphore, then call another routine to do > f_count-- and possible file cleanup which could also be called by > nlmsvc_traverse_shares(). Call it nlm_put_file() if you like 8-). nlm_release_file() *does* grab the semaphore. That's the problem. > However, the test for min_count is wrong. In both cases you are trying > to clear the f_count that was incremented in > nlmsvc_share_file(). Since shares and locks are invisible to one > another, I'm quite free to have an ordinary block on the same file > thus screwing up your f_count test. Adding or removing blocks or locks does not affect f_count at all. There ist one function that changes f_count when it removes a block, but it is never called, at least not in 2.2.x. The min_count test is irrelevant (TM) anyway. In fact, I could have used a simple `file->f_count--;' instead of `put_file();' (feel free to do that yourself), but I'm paranoid and wanted lockd to complain if something goes wrong. The min_count values are correct, however. -- Michael "Tired" Riepe <[EMAIL PROTECTED]> "All I wanna do is have a little fun before I die" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
[EMAIL PROTECTED] (Linus Torvalds) wrote on 27.08.00 in <[EMAIL PROTECTED]>: > On Sun, 27 Aug 2000, Alexander Viro wrote: > > > > Linus, there is no need in new mask for execve(). > > What you're saying is "there are other ways to accomplish this". And I > kind of agree. I still think the dynamic mask is the preferable option. > > > We have two actions: > > 1. create a VM set up according to the contents of binary > > Sure. Another ELF marker, whatever. It would work, and probably cover the > needs. Especially as "the needs" aren't that big, as this has actually > never come up except as a theoretical discussion ;). Just don't forget that some of this unsharing may be necessary for security reasons. Specifically, when you execve() a suid program, you probably should automatically unshare everything. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Linux 2.2.18pre1
Since 2.2.17 isnt out yet I've released 2.2.18pre1 versus 2.2.17pre20. So you need to grab 2.2.16 then apply the 2.2.17pre20 patch then the 2.2.18pre patch of choice. 2.2.18pre1 (versus 2.2.17pre20) o Update symbios/ncr driver to 1.7.0/3.4.0(Gerhard Roudier) o Updated ATP870U driver (ACard) o Avoid running tq_scheduler stuff sometimes with (Andrea Arcangeli) interrupts off o Futher cpu setup updates(me) o IBM MCA scsi driver updates (Michael Lang) o Fix incorrect out of memory handling in bttv(Dawson Engler) o Fix incorrect out of memory handling in buz (Dawson Engler) o Fix incorrect out of memory handling in qpmouse (Dawson Engler) o Fix error handling memory leak in ipddp (Dawson Engler) o Fix error handling memory leak in sdla (Dawson Engler) o Fix error handling memory leak in softoss (Dawson Engler) o Fix error handling memory leak in ixj (Dawson Engler) o Fix error handling memory leak in ax25 (Dawson Engler) o Merge the microcode driver from 2.4 into 2.2(Tigran Aivazian) o Fix skbuff handling bug in the smc9194 driver (Arnaldo Melo) o Fix problems with SIS900 driver on some 630E(Lei-Chun Chang) boards o Make vfat use the same generation rules as (H. Kawaguchi, in windows 9xChip Salzenberg) o Fix oops in the CPQ array driver(Arnaldo Melo) o Fix ac97 codec not setting the id field (Bill Nottingham) o Further work on the cs46xx/CD power bits(me) o Synclink updates(Paul Fulgham) o Synclink init bug fix (Arnaldo Melo) o Handle odd interrupts from toshiba floppies (Alain Knaff) o Fix trident driver build on nautilus Alpha (Peter Petrakis) o Add later sb16 imix support tot he sb driver(Massimo Dal Zotto) o Ignore luns that report can be connected, but (Matt Domsch) not currently o Fix dereference after kfree in uart401.c(Dawson Engler) o Return correct SuS error code for an unknown(Herbert Xu) socket family o Add sub window clipping to the bttv driver (Thomas Jacob) o Fix nfs cache locked messages (Trond Myklebust) o Fix the modutils misdocumentation (Martin Douda) o Remove bogus biosparm code from seagate.c (Andries Brouwer) o Return correct error code on failed fasync set (Chip Salzenberg) o Handle dcc resume with newer irc clients when (Scottie Shore) doing an irq masq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Tue, 29 Aug 2000, Pavel Machek wrote: > What does this have to do with private namespaces? Albert asked what to do if /var/spool/mail dies and every user has his own namespace. Well, don't let him play with /var/spool/mail directly... > mailfsd /dev/coda0 --enable-imap & > mount /dev/coda0 /var/spool/mail > > It looks easy to me, today and without private namespaces. > [Shall I hack podfuk into providing imap? Okay, it would not be easy > because > * /var/spool/mail/xxx is _writable_, so your imap dream is probably > dream. What does your mailfs do when someone does cat /bin/bash > > $MYMAIL Commit-on-close is one of the obvious variants... > * podfuk is has file granularity > > I could see it working with some kind of directory format, however.] Yep. And quite a few mailreaders can work with that. I'm less than sure that CODA's local caching is appropriate, though. More RPC-oriented stub in the kernel might augment it quite fine and in that case it would probably work better. Or not... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2T for i386
In article <[EMAIL PROTECTED]>, Ricky Beam <[EMAIL PROTECTED]> wrote: > If you're building a 2TB array, you're not gonna do it with bloody IDE > hardware. (I hope you're joking.) The big problem with IDE is trying to find raid 5 that works with 8 or more disks, raid 5 with 4 disks wastes too much. And the 18 inch cable lengths make it hard to house the disks. At least with LVD you can have long cables. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
According to Paul Gortmaker: > (things marked as not set or modular aren't relevant to the zImage) True, but reconstructing the (b)zImage isn't the only purpose of keeping a config file around. So I'd rather keep the modular settings. But maybe that's just me. -- Chip Salzenberg - a.k.a. - <[EMAIL PROTECTED]> "I wanted to play hopscotch with the impenetrable mystery of existence, but he stepped in a wormhole and had to go in early." // MST3K - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH] Re: grow_inodes: inode-max limit reached - how to find/fix the inode leak?
> " " == Michael Riepe <[EMAIL PROTECTED]> writes: > On Thu, Aug 31, 2000 at 03:23:43PM +0200, Trond Myklebust > wrote: >> Your patch does not seem correct to me. IMO you should rather >> be calling nlm_release_file() in both cases where you applied >> 'put_file()'. > No. In the first of two cases, lockd will call > nlm_release_file() on its own when the function returns. In The call in nlmsvc_unshare_file() is in order to clear the f_count from nlmsvc_share_file(). That in nlmsvc_proc_unshare() clears the f_count from nlmsvc_retrieve_args(). > the second case, we're being called from inside > nlm_traverse_files(), which holds a lock on the file table -- > nlm_release_file() would wait forever. Ugh. In that case, my personal preference would be to make nlm_release_file() grab the semaphore, then call another routine to do f_count-- and possible file cleanup which could also be called by nlmsvc_traverse_shares(). Call it nlm_put_file() if you like 8-). However, the test for min_count is wrong. In both cases you are trying to clear the f_count that was incremented in nlmsvc_share_file(). Since shares and locks are invisible to one another, I'm quite free to have an ordinary block on the same file thus screwing up your f_count test. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
Alexander wrote vs I wrote vs he wrote etc.
> > > And let's not go into the links to directories, implemented well
> > > after it became painfully obvious that they were an invitation for
> > > troubles (from looking into Amiga newsgroups it seems that miracle
> > > didn't happen - I've seen quite a few complaints about fs breakage
> > > answered with "don't use links to directories, they are broken").
> >
> > They MAY be fixed in the OS3.5 BoingBag 2 (service pack 2 with a
> > cutsiepie name.) Heinz has committed yet another rewrite.
>
> Ouch... Why did he do them (links to directories, that is), in the
> first place?
Since you asked, but I am warning you that you don't want to know
Well, maybe you do - there is a project to port UNIXy tools to every
platform in existance. While I like some of the people involved just
a whole lot I dislike the way they have done it. They attempt to pervert
other filesystems into UNIX lookalikes. They needed links. They
pestered the Commodore people until in desperation to shut them
up Randall made an effort. As you note, as a filesystem AFFS is not
well suited to links. (But then a lightweight threaded OS is not well
suited to several popular GCCisms such as huge amounts of data
on the stack. It takes programmer discipline to write threaded programs
properly. But the results are, in my experience, very well worth it. And
avoiding stack overflow on small stack spaces is one of the keys
unless the OS has done what BeOS did by assigning absurd default
stack spaces to accommodate GeekGadgets.)
> > > Anyway, it's all history. We can't unroll the kludge, no matter
> > > what we do. We've got what we've got. And I'm not too interested in
> > > distribution of the blame between the people in team that seems to be
> > > dissolved years ago. I consider AFFS we have to deal with as a poor
excuse
> > > of design and I think that it gives more than enough reasons for that.
> > > In alternative history it might be better. So might many other things.
> >
> > Indeed, poor or not it exists and we live with it in the Amiga
community.
> > (Um, I wonder if I could talk Hendrix into a copy of the source for SFS
so
> > it could be ported to Linux These days I prefer it to FFS. {^_-})
>
> Hmm... What, format description is not available?
SFS is a private effort on Hendrix's part. It is wholely unrelated to FFS.
But it does work on the Amiga, fairly nicely. I'm not sure how much of
his structures he has released publicly. (It is also in perpetual beta.)
> > If you want I can bend your ear on things Amiga for longer than your
> > patience stretches, I suspect. (I've been following the threads
discussions
>
> alt.folklore.computers is -> that way ;-) Let's take it there...
Private email is easier. I've had my Use(less)Net aversion therapy. (I
got well and good spoiled by BIX in its prime. It had the highest signal
to noise ratio I have experienced yet.)
Er, and if you want info about the latest changes to the RDB spec to
incorporate into the kernel attempts to read the AFFS boot sectors
"I can help you." Er, I am the person guilty for the
latest perversions. {^_-}
> ObWTF: WTF did these guys drop QNX when they clearly wanted RTOS? Do they
> have somebody who
> a) knew the difference between RT and TS and
> b) knew that Linux is TS?
Um, it would not be either polite or politic to say what I "really" think
here or
anywhere else. I am reserving judgement until I have had a chance to test
what a full up "elate" can do. I am willing to be (very) surprised.
The interesting thing is that we need an OS somewhere between QNX and
Linux. Sadly it appears that NT is about what fits in the niche and is well
enough
known to sell to our customers, theme parks, theaters, cruise ships, and
other
venues. It's a small niche. We have fun doing it. And we make enough money
to finance doing more of it. (And so far the customers are more than passing
honest, which is amazingly refreshing. And it's amazing fun to walk into a
place
like Wonderland in the Toronto area and see their volcano really work
knowing
that it is our tool making it go. The looks on the other people's faces are
VERY
rewarding.)
(Er, by day Loren, my partner, is a mild mannered (hah) OS hacker for
UniSys. Lately he's been "doing" specialty HALs for their BIG machines.
He has some interesting opinions about the various OSs out there and
how people are relearning what he and his buddies learned, often the
hard way, 20 years ago. He nearly single handedly built some of the
Burroughs OSs. Chuckle - he was hired to write documentation. They
discovered he was fixing bugs he found while testing his documentation.
Suddenly he was tossed into the OS group as a programmer.)
{^_^}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Large File support and blocks.
And the below is what percentage of time doing disk i/o?
> Just put this in a loop and time it. Change SIZE to long long, and do
> it again! It doesn't scale well. The long long code is nearly 10 times
> slower! You can do `gcc -S -o xxx name.c` and see why.
>
>
> #define SIZE long
>
> SIZE *foo()
> {
> SIZE one;
> SIZE two;
> static SIZE answer[8];
>
> one = 1;
> two = 2;
> answer[0] = one - two;
> answer[1] = two - one;
> answer[2] = one + two;
> answer[3] = two + one;
> answer[4] = two / one;
> answer[5] = one / two;
> answer[6] = one * two;
> answer[7] = two * one;
> return answer;
> }
>
>
> Long long things, even it they work well, are not very nice on 32 bit
> machines. For the time being, I'd advise increasing cluster size rather
> than using 64 bit values.
>
> In a few years, even Intel machines will be 64 bits. Int will still be
> long, but it will be 64 bits. ---and they will autoscale for backwards
> compatibility (one new instruction, used once, for oprand size).
>
> Cheers,
> Dick Johnson
>
> Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
>
> "Memory is like gasoline. You use it up when you are running. Of
> course you get it all back when you reboot..."; Actual explanation
> obtained from the Micro$oft help desk.
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: Large File support and blocks.
On Thu, 31 Aug 2000, Linda Walsh wrote:
> > It is propably from reasoning of:
> >
> > "there is really no point in it, as at 32bit systems
> > int and long are same size, thus same limit comes
> > with both types."
> >
> > At 64-bit machines there is, of course, definite difference.
> ---
> There ya go again -- confusing the issue with facts. Compare
> and contrast the appropriate 32 and 64 bit values. Using a 'long long'
> on ia32 for comparison vs. an int.
Just put this in a loop and time it. Change SIZE to long long, and do
it again! It doesn't scale well. The long long code is nearly 10 times
slower! You can do `gcc -S -o xxx name.c` and see why.
#define SIZE long
SIZE *foo()
{
SIZE one;
SIZE two;
static SIZE answer[8];
one = 1;
two = 2;
answer[0] = one - two;
answer[1] = two - one;
answer[2] = one + two;
answer[3] = two + one;
answer[4] = two / one;
answer[5] = one / two;
answer[6] = one * two;
answer[7] = two * one;
return answer;
}
Long long things, even it they work well, are not very nice on 32 bit
machines. For the time being, I'd advise increasing cluster size rather
than using 64 bit values.
In a few years, even Intel machines will be 64 bits. Int will still be
long, but it will be 64 bits. ---and they will autoscale for backwards
compatibility (one new instruction, used once, for oprand size).
Cheers,
Dick Johnson
Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] [PATCH] Re: grow_inodes: inode-max limit reached - how to find/fix the inode leak?
On Thu, Aug 31, 2000 at 03:23:43PM +0200, Trond Myklebust wrote: > Your patch does not seem correct to me. IMO you should rather be > calling nlm_release_file() in both cases where you applied > 'put_file()'. No. In the first of two cases, lockd will call nlm_release_file() on its own when the function returns. In the second case, we're being called from inside nlm_traverse_files(), which holds a lock on the file table -- nlm_release_file() would wait forever. -- Michael "Tired" Riepe <[EMAIL PROTECTED]> "All I wanna do is have a little fun before I die" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2T for i386
The latest firmware for the 3ware 5000 family of controllers - Escalade 5.1 - allows for hotswap using standard ide removable drive bays. I was already using ide removable drive bays to reduce downtime in case i needed to do maintenance, but now the worry is gone if it works as they advertise. Check the pdf included with the drivers for Linux for more information. Pedro Pedro On 31 Aug 2000, at 16:16, Stephen Lee wrote: > Alan Cox <[EMAIL PROTECTED]> wrote: > > I used to think that. Im planning on deploying a 1Tb IDE raid using 3ware kit > > for an ftp site very soon. Its very cheap and its very fast. UDMA with > > one disk per channel and the controller doing some of the work. > > > > All it lacks is hot swap. > > I wonder if it is possible to have the manufacturers agree on a common >electrical/physical standa rd for IDE hot-swap connector, like SCA for SCSI. > Say, being able to use standard enclosures that is compatible with different >manufacturer's disks , instead of those 5 inch bay tray hacks that are big and not compatible to each other. > > Stephen > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: TLAN EISA support + PCI fixes
This patch (against 2.4.0-test7 and later) take the tlan driver to v1.10
and has the following fixes/enhancements:
Support for EISA controllers
New PCI probe layout
Other fixes (see patch).
Currently only the Compaq NetFlex-3/E controller is supported, and as I
only had access to one, it might not find your controller. If it dosen't
please load the driver with "insmod tlan debug=0x10" and send me the output.
You'll be able to check if you EISA board was found by watching "dmesg" output.
The driver should report something similar to this:
ThunderLAN driver v1.10
TLAN: eth0 irq=11, io=70a0, Compaq Netelligent 10/100 TX PCI UTP, Rev. 16
TLAN: eth1 irq= 9, io=3000, Compaq NetFlex-3/E, Rev. 0
TLAN: 2 devices installed, PCI: 1 EISA: 1
Please note this driver version is experimental. Some issues are
still left (timers on SMP, revision, etc.).
Have fun.
--
Torben Mathiasen
Linux ThunderLAN maintainer
http://tlan.kernel.dk
diff -ur linux-2.4.0-test7/drivers/net/tlan.c linux/drivers/net/tlan.c
--- linux-2.4.0-test7/drivers/net/tlan.cThu Aug 31 13:48:07 2000
+++ linux/drivers/net/tlan.cThu Aug 31 14:26:43 2000
@@ -98,10 +98,28 @@
* v1.8a May 28, 2000 - Minor updates.
*
* v1.9 July 25, 2000 - Fixed a few remaining Full-Duplex issues.
- * - Updated with timer fixes from Andrew Morton.
- * - Fixed module race in TLan_Open.
- * - Added routine to monitor PHY status.
- * - Added activity led support for Proliant devices.
+ * - Updated with timer fixes from Andrew Morton.
+ * - Fixed module race in TLan_Open.
+ * - Added routine to monitor PHY status.
+ * - Added activity led support for Proliant devices.
+ *
+ * v1.10 Aug 30, 2000 - Added support for EISA based tlan controllers
+ *like the Compaq NetFlex3/E.
+ * - Rewrote tlan_probe to better handle multiple
+ *bus probes. Probing and device setup is now
+ *done through TLan_Probe and TLan_init_one. Actual
+ *hardware probe is done with kernel API and
+ *TLan_EisaProbe.
+ * - Adjusted debug information for probing.
+ * - Fixed bug that would cause general debug information
+ *to be printed after driver removal.
+ * - Added transmit timeout handling.
+ * - Fixed OOM return values in tlan_probe.
+ * - Fixed possible mem leak in tlan_exit
+ *(now tlan_remove_one).
+ * - Fixed timer bug in TLan_PhyMonitor.
+ * - This driver version is alpha quality, please
+ *send me any bug issues you may encounter.
*
***/
@@ -121,8 +139,9 @@
typedef u32 (TLanIntVectorFunc)( struct net_device *, u16 );
+/* For removing EISA devices */
+static struct net_device *TLan_Eisa_Devices = NULL;
-static struct net_device *TLanDevices = NULL;
static int TLanDevicesInstalled = 0;
/* Force speed, duplex and aui settings */
@@ -144,7 +163,10 @@
static int bbuf = 0;
static u8 *TLanPadBuffer;
static charTLanSignature[] = "TLAN";
-static const char *tlan_banner = "ThunderLAN driver v1.9\n";
+static const char *tlan_banner = "ThunderLAN driver v1.10\n";
+static int tlan_have_pci = 0;
+static int tlan_have_eisa = 0;
+static int manual_priv = 0;
const char *media[] = {
"10BaseT-HD ", "10BaseT-FD ","100baseTx-HD ",
@@ -153,103 +175,72 @@
int media_map[] = { 0x0020, 0x0040, 0x0080, 0x0100, 0x0200,};
-static TLanAdapterEntry TLanAdapterList[] __initdata = {
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETELLIGENT_10,
- "Compaq Netelligent 10 T PCI UTP",
- TLAN_ADAPTER_ACTIVITY_LED,
- 0x83
- },
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETELLIGENT_10_100,
- "Compaq Netelligent 10/100 TX PCI UTP",
- TLAN_ADAPTER_ACTIVITY_LED,
- 0x83
- },
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETFLEX_3P_INTEGRATED,
- "Compaq Integrated NetFlex-3/P",
- TLAN_ADAPTER_NONE,
- 0x83
- },
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETFLEX_3P,
- "Compaq NetFlex-3/P",
- TLAN_ADAPTER_UNMANAGED_PHY | TLAN_ADAPTER_BIT_RATE_PHY,
- 0x83
- },
- { PCI_VENDOR_ID_COMPAQ,
- PCI_DEVICE_ID_NETFLEX_3P_BNC,
- "Compaq NetFlex-3/P",
- TLAN_ADAPTER_NONE,
- 0x83
-
Re: Large File support and blocks.
On Thu, Aug 31, 2000 at 01:46:36PM -0700, Linda Walsh wrote: > > It is propably from reasoning of: > > > > "there is really no point in it, as at 32bit systems > > int and long are same size, thus same limit comes > > with both types." > > > > At 64-bit machines there is, of course, definite difference. > --- > There ya go again -- confusing the issue with facts. Compare > and contrast the appropriate 32 and 64 bit values. Using a 'long long' > on ia32 for comparison vs. an int. No, I don't confuse those details, I am just leaving couple of fundamental environmental assumptions unstated. (this is long..) Linus seem to have (rightly) abhorrence of allowing 'long long' in fastpath core operations, because i386 is register poor, and thus handling such variables is tedious. Also (I recall) because GCC's 'long long' related operations and optimizations have been buggy in past, and there is no sufficient experience to convince him that they work now better with the recommended kernel compiling GCC version (egcs-1.1.2). On the other hand, I think FreeBSD kernel is littered with 'long long' typed variables (loff_t), and thus the gcc/egcs versions compiling it at i386 can't be all bad... So, most people seem to be happy to take a bit of breath as filesizes at 32 bit machines got jumped up by 3-4 orders of magnitude. Punching thru 1TB isn't far away ( this week we have talked at the office of constructing some 1TB+ filesystems at Linux just because it is a) cool, b) reasonably cheap :) ) Propably I have to (nee.. "can") spend couple of weeks at abolishing these limit barriers when those guys want some help. (That is roughly how the LFS changes for 2.4 came to be. Same internal group wanted to process data masses exceeding 2G at intel boxes -- I was happy camper with my Alpha ...) .. and who knows, maybe newest GCC can be proven to be smarter with 'long long', and foremost: produce correct code. > -l /Matti Aarnio <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH *] VM patch w/ drop behind for 2.4.0-test8-pre1
Hi, today I released a new version of my VM patch for 2.4.0-test. This patch should mostly fix streaming IO performance, due to the following two features: - drop_behind(), when we do a readahead, move the pages 'behind' us to the inactive list .. this way we can do streaming IO without putting pressure on the working set - deactivate pages in generic_file_write(), this does basically the same ... by moving the pages we write to to the inactive_dirty list, a big download, etc.. doesn't impact the working set of the system I'm particularly interested in the impact of streaming IO on the performance of the rest of the system with this patch, but of course also in the performance of the streaming IO itself. The patch is available from: http://www.surriel.com/patches/ http://www.surriel.com/patches/2.4.0-t8p1-vmpatch2 regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2T for i386
> > >such as the 3ware 8 port cards, or scsi raid controllers and then run ext3 > > >or reiserfs. > > If you're building a 2TB array, you're not gonna do it with bloody IDE > > hardware. (I hope you're joking.) On Thu, Aug 31, 2000 at 07:46:49PM +0100, Alan Cox wrote: > I used to think that. Im planning on deploying a 1Tb IDE raid using 3ware kit > for an ftp site very soon. Its very cheap and its very fast. UDMA with > one disk per channel and the controller doing some of the work. > > All it lacks is hot swap. 3ware Escalade 6400/6800 have a hot swap capability. My experience with 3ware controllers has been very good. The company has been very responsive to bugs in the linux driver. RAID10 is cool. striping and then mirroring. They are definitely fast and cheap. Though don't tell anyone about them. If the demand goes up much more, they'll start raising the price. 8-) -- Brian Litzinger <[EMAIL PROTECTED]> Copyright (c) 2000 By Brian Litzinger, All Rights Reserved - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
On Thu, 31 Aug 2000, J. Dow wrote:
> > being a jaded bastard I suspect that Commodore PHBs decided to save a
> > bit on floppy controller price and did it well after the initial design
>
> Comododo PHBs had nothing to do with it. And the Commododo floppy
> disk format is quite literally unreadable with a PC style controller. It was
> not an economic decision. If you are going to carp please do so from a
> basis of real knowledge Alexander. (The REAL blame for the disk fiasco
> goes to the people at Metacrap^H^H^H^HComCo.)
Hey, I've clearly said that I don't know which idiot was responsible for
that fsckup.
> > was done and so close to release that redesign was impossible for
> > schedule reasons, but it might be something else. We'll probably never
> > know unless somebody who had been in the original design team will leak
> > it. But whatever reasons were behind that decision, OFS was either blindly
> > copied without a single thought about very serious design factor _or_
> > had been crippled at some point before the release. If it's the latter - I
> > commiserate with their fs folks. If it's the former... well, I think that
> > it says quite a few things about their clue level.
>
> Metacomco designed it based on their TripOS. OFS is very good for
> repairing the filesystem in the event of a problem, although the so called
> DiskDoctor they provided quickly earned the name DiskDestroyer.
> Metacomco and BSTRINGS and BPOINTERS and all that nonsense
> entered the picture when it was decided the originally planned OS was
> would take too long to develop. So what Metacomco had was grafted
> onto what the old Amiga Inc had done resulting in a hodgepodge
> mess.
Umm... Interesting. Could somebody familiar with TripOS tell what
size sectors had there? IOW, did it keep the metadata out-of-band or not?
[snip]
> old cruft is preserved for reading old disks. Later on DirCache was added
> principly for floppy disks. About that time Randall added both so called
> soft links and hard links. For what it is worth it took a long long time and
> series of modifications before either of them worked adequately.
Egads... Please, pass him my compliments - one has to be _really_
perverted to do the hardlinks that way. Even QNX way of handling that
(move them into magical place after the first rename()/link() and leave
the dud in the old place) is much saner.
> > And let's not go into the links to directories, implemented well
> > after it became painfully obvious that they were an invitation for
> > troubles (from looking into Amiga newsgroups it seems that miracle
> > didn't happen - I've seen quite a few complaints about fs breakage
> > answered with "don't use links to directories, they are broken").
>
> They MAY be fixed in the OS3.5 BoingBag 2 (service pack 2 with a
> cutsiepie name.) Heinz has committed yet another rewrite.
Ouch... Why did he do them (links to directories, that is), in the
first place?
> > Anyway, it's all history. We can't unroll the kludge, no matter
> > what we do. We've got what we've got. And I'm not too interested in
> > distribution of the blame between the people in team that seems to be
> > dissolved years ago. I consider AFFS we have to deal with as a poor excuse
> > of design and I think that it gives more than enough reasons for that.
> > In alternative history it might be better. So might many other things.
>
> Indeed, poor or not it exists and we live with it in the Amiga community.
> (Um, I wonder if I could talk Hendrix into a copy of the source for SFS so
> it could be ported to Linux These days I prefer it to FFS. {^_-})
Hmm... What, format description is not available?
> If you want I can bend your ear on things Amiga for longer than your
> patience stretches, I suspect. (I've been following the threads discussions
alt.folklore.computers is -> that way ;-) Let's take it there...
> because there is a project I'd like to port from NT to Linux that just ain't
> gonna make it until some nice threads are added and latencies drop
> dramatically. RT_Linux may be overkill. But as it sits today Linux is
> underkill when you need 1/4 frame and less timing latencies on Show
> Control operations. )
ObWTF: WTF did these guys drop QNX when they clearly wanted RTOS? Do they
have somebody who
a) knew the difference between RT and TS and
b) knew that Linux is TS?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patchlet] current->state=XX -> __set_task_state in mm/highmem.c
Hi.
In mm/highmem.c:map_new_virtual (in a 2.4.0-t8p1 kernel) we set
current's state directly. I believe that using __set_task_state
is nicer. The following patch acts out this belief :) Please
comment.
--- linux-240test8-pre1/mm/highmem.cThu Aug 24 09:43:36 2000
+++ linux/mm/highmem.c Thu Aug 31 22:39:36 2000
@@ -165,7 +165,7 @@
{
DECLARE_WAITQUEUE(wait, current);
- current->state = TASK_UNINTERRUPTIBLE;
+ __set_task_state(current, TASK_UNINTERRUPTIBLE);
add_wait_queue(&pkmap_map_wait, &wait);
spin_unlock(&kmap_lock);
schedule();
--
Regards,
Rasmus([EMAIL PROTECTED])
Outside of the killings, Washington has one of the lowest crime rates in
the country. -Mayor Marion Barry, Washington, DC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[patch] Returning value from void function (kernel/signal.c) (240t8p1)
Hi. I guess the threads stuff introduced this minor compile warning: signal.c: In function `handle_stop_signal': signal.c:367: warning: `return' with a value, in function returning void The following small patch fixes this: --- linux-240test8-pre1/kernel/signal.c Tue Aug 29 22:20:51 2000 +++ linux/kernel/signal.c Thu Aug 31 22:38:48 2000 @@ -364,7 +364,7 @@ recalc_sigpending(t); break; } - return 0; + return; } static int deliver_signal(int sig, struct siginfo *info, struct task_struct *t) -- Regards, Rasmus([EMAIL PROTECTED]) I believe that people would be alive today if we had the death penalty. -- Nancy Reagan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any good _online_ kernel BSD sockets reference out there??
On Thu, Aug 31, 2000 at 08:34:04AM -0700, Ivan Passos wrote: > > On Thu, 31 Aug 2000, Alan Cox wrote: > > > > BSD sockets in the kernel?? I'm trying to learn how to implement a > > > "raw" network point-to-point interface (i.e. no protocols, just data), but > > > I'm having trouble understanding what I need to change or do. > > > > Implement just the hardware driver. Open an AF_PACKET socket to it > > What I still don't understand is how the network layer will pass the > request directly to the driver _without_ goind through the INET (IP) > layer ... Do you know of any src code that I could use as a reference?? > Src code that does the "request passing" would be good too ... :) Most of your questions should be answered in packet(7) In future please try to consult the available documentation before asking user questions on the kernel list. Thanks, -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Large File support and blocks.
> It is propably from reasoning of: > > "there is really no point in it, as at 32bit systems >int and long are same size, thus same limit comes >with both types." > > At 64-bit machines there is, of course, definite difference. --- There ya go again -- confusing the issue with facts. Compare and contrast the appropriate 32 and 64 bit values. Using a 'long long' on ia32 for comparison vs. an int. Yes, with larger cluster sizes you can get larger virtual file sizes, but that's only pushing the problem a bit further back. Is it possible, I think there's an IRIX product to do this, CXFS' which can take an existing HD and allow you add-on more Hard disks to form a bigger and bigger drive. So -- maybe this is flawed, but I could easily see the mistake of starting out with a 1 K block size on your first HD, but then not being able to 'grow' it beyond a 2T limit. Some of our larger customers have had files larger than 2T -- customers exist today that use that functionality -- I have no idea what blocksize they use -- depending on their usage -- 4K might be reasonable, but if what you are doing is skipping around in a large database file and doing alot of small reads, 4K blocksizes might be less efficient. If our customers were doing this over a year ago (which they were), it's not gonna be long before the practice spreadsgrowth is a virus... it keeps spreading...:-) -l - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
> Some underlying block device subsystems can address that > currently, some others have inherent 512 byte "page_size" > with signed indexes... I think SCSI is in the first camp, > while IDE is in second. (And Ingo has assured us that RAID > code should handle this just fine too.) You can change logical block size on SCSI disk devices such that you won't be limited to a 1TB (512 byte logical blocksize) limit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Odd Xircom Realport Tulip Behavior
[this message was previously cc'ed to tulip-bug] It seems that my Xircom report refuses to work correctly when first initialized. I'm running Linux 2.4.0-test7 with the standard xircom_tulip_cb driver. I can get the Xircom to work just fine, but I seem to always need to go through a song and dance to do so. When the driver is first initialized, ifconfig eth0 with an IP and adding the default route will not work correctly. To get the realport to work, I have to: # ifconfig eth0 a.b.c.d netmask x.x.x.x # ifconfig eth0 down # ifconfig eth0 up # route add default gw l.m.n.o As soon as I bring it back up for the second time, it mysteriously starts working correctly. Here are the relevant kernel messages on boot: cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x220-0x22f 0x330-0x337 0x388-0x38f 0x398-0x39f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. tulip_attach(04:00.0) PCI: Setting latency timer of device 04:00.0 to 64 xircom_tulip_cb.c:v0.91 4/14/99 [EMAIL PROTECTED] (modified by [EMAIL PROTECTED] for XIRCOM CBE, fixed by Doug Ledford) eth0: Xircom Cardbus Adapter (DEC 21143 compatible mode) rev 3 at 0x1c00, 00:10:A4:EB:58:4C, IRQ 9. eth0: MII transceiver #0 config 3100 status 7809 advertising 01e1. Jordy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Large File support and blocks.
On Thu, Aug 31, 2000 at 01:13:09PM -0700, Linda Walsh wrote: > Ooopsthe time frame is closer to today on part of this. > While it may be a while before we hit the 1T limit on 1 single device, > things like readpage, do so based of the inode -- which on a metadisk > could have a filesize much larger than current physical device limits. > So it seems that at least at the vnode level this is something that may > have to go into the 2.4 series fairly soon, or am I missing something? > Why are blocks int's vs. unsigned's ? Was it to pass back errno's in > some cases? It is propably from reasoning of: "there is really no point in it, as at 32bit systems int and long are same size, thus same limit comes with both types." At 64-bit machines there is, of course, definite difference. Now our page-cache subsystem is based on the page cluster size (2^n times machine page size, where n is non negative integer), thus at i386 the page-cache can support up to PAGE_SIZE*2^32 -1 file offsets. (4k*4G = 16 T, larger page clusters drive the adressability higher -- and 64-bit machines drive it into cosmic magnitudes..) Some underlying block device subsystems can address that currently, some others have inherent 512 byte "page_size" with signed indexes... I think SCSI is in the first camp, while IDE is in second. (And Ingo has assured us that RAID code should handle this just fine too.) That part of the system needs to be verified/revised. (Verification to determine which need revision can be done now with document writing regarding the status, actual revisions are 2.5 issue.) > -- > Linda A Walsh| Trust Technology, Core Linux, SGI > [EMAIL PROTECTED] | Voice: (650) 933-5338 /Matti Aarnio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test7 remount/iocharset
I am running Debian 2.2 (Potato). On 2.4.0-test7 vfat, iocharset does not change on remount, but the option is shown in mounttab. Notice that the euc-jp nls module did not get loaded after a remount. Also, on remount, ntfs does not decrease nls module usage count, even if you don't change iocharset. Result is that the count increases by 1 each time you remount it, and you can't remove the module even if you umount the ntfs in question. hanagumi:~# uname -a Linux hanagumi 2.4.0-test7 #1 SMP Wed Aug 30 21:11:48 JST 2000 i686 unknown hanagumi:~# gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.2/specs gcc version 2.95.2 2220 (Debian GNU/Linux) hanagumi:~# mount /dev/sda6 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) usbdevfs on /proc/bus/usb type usbdevfs (rw) hanagumi:~# lsmod Module Size Used by parport_pc 22564 0 (autoclean) parport27168 0 (autoclean) [parport_pc] eepro100 17008 1 (autoclean) usb-uhci 22068 0 (unused) wacom 2836 0 (unused) input 3104 0 [wacom] usbcore50016 1 [usb-uhci wacom] hanagumi:~# mount /mnt/dosf hanagumi:~# lsmod Module Size Used by nls_iso8859-1 2840 1 (autoclean) nls_cp437 4352 1 (autoclean) parport_pc 22564 0 (autoclean) parport27168 0 (autoclean) [parport_pc] eepro100 17008 1 (autoclean) usb-uhci 22068 0 (unused) wacom 2836 0 (unused) input 3104 0 [wacom] usbcore50016 1 [usb-uhci wacom] hanagumi:~# mount /dev/sda6 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) usbdevfs on /proc/bus/usb type usbdevfs (rw) /dev/sda10 on /mnt/dosf type vfat (rw) hanagumi:~# mount -o remount,iocharset=euc-jp /mnt/dosf hanagumi:~# lsmod Module Size Used by nls_iso8859-1 2840 1 (autoclean) nls_cp437 4352 1 (autoclean) parport_pc 22564 0 (autoclean) parport27168 0 (autoclean) [parport_pc] eepro100 17008 1 (autoclean) usb-uhci 22068 0 (unused) wacom 2836 0 (unused) input 3104 0 [wacom] usbcore50016 1 [usb-uhci wacom] hanagumi:~# mount /dev/sda6 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) usbdevfs on /proc/bus/usb type usbdevfs (rw) /dev/sda10 on /mnt/dosf type vfat (rw,iocharset=euc-jp) hanagumi:~# umount /mnt/dosf hanagumi:~# mount -o iocharset=euc-jp /mnt/dosf hanagumi:~# lsmod Module Size Used by nls_cp932 76448 1 (autoclean) nls_euc-jp 892 1 (autoclean) nls_iso8859-1 2840 0 (autoclean) nls_cp437 4352 1 (autoclean) parport_pc 22564 0 (autoclean) parport27168 0 (autoclean) [parport_pc] eepro100 17008 1 (autoclean) usb-uhci 22068 0 (unused) wacom 2836 0 (unused) input 3104 0 [wacom] usbcore50016 1 [usb-uhci wacom] hanagumi:~# mount /dev/sda6 on / type ext2 (rw,errors=remount-ro,errors=remount-ro) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) usbdevfs on /proc/bus/usb type usbdevfs (rw) /dev/sda10 on /mnt/dosf type vfat (rw,iocharset=euc-jp) hanagumi:~# - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patchlet] Compile warning in drivers/media/video/bttv-cards.c (240t8p1)
Hi.
When I compile drivers/media/video/bttv-cards.c I get the following
warnings:
bttv-cards.c:781: warning: `init_tea5757' defined but not used
Since the call to init_tea5757() is languishing inside an #if 0
construct the following patch does the same to the function
declarations. Please comment:
--- linux-240test7-pre7-clean/drivers/media/video/bttv-cards.c Wed Aug 23 08:50:19
2000
+++ linux/drivers/media/video/bttv-cards.c Wed Aug 23 19:35:58 2000
@@ -41,7 +41,9 @@
static void hauppauge_eeprom(struct bttv *btv);
static void hauppauge_boot_msp34xx(struct bttv *btv);
static void init_PXC200(struct bttv *btv);
+#if 0
static void init_tea5757(struct bttv *btv);
+#endif /*0*/
MODULE_PARM(card,"1-4i");
MODULE_PARM(pll,"1-4i");
@@ -778,6 +780,7 @@
if (bttv_debug) tea_read(btv);
}
+#if 0
void init_tea5757(struct bttv *btv)
{
BUS_LOW(CLK);
@@ -788,6 +791,7 @@
/* normal mode for GPIO */
btaor(0, BT848_GPIO_DMA_CTL_GPIOMODE, BT848_GPIO_DMA_CTL);
}
+#endif /*0*/
/* --- */
/* winview */
--
Rasmus([EMAIL PROTECTED])
Without censorship, things can get terribly confused in the
public mind. -General William Westmoreland, during the war in Viet Nam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
Quoth a misinformed Alexander Viro re AFFS, > As for the silliness of the OFS... I apologize for repeating the > story if you know it already, but anyway: OFS looks awfully similar to > Alto filesystem. With one crucial difference: Alto kept the header/footer > equivalents in the sector framing. No silly 400-odd byte sectors for them. > That layout made a lot of sense - you could easily recover from many disk > faults, yodda, yodda, _without_ sacrificing performance. The whole design > relied on ability to put pieces of metadata in the sector framing. Take > that away and you've lost _very_ large part of the benefits. So large that > the whole design ought to be rethought - tradeoffs change big way. > > OFS took that away. Mechanically. It just stuffed the headers into > the data part of sectors. I don't know the story behind that decision - > being a jaded bastard I suspect that Commodore PHBs decided to save a > bit on floppy controller price and did it well after the initial design Comododo PHBs had nothing to do with it. And the Commododo floppy disk format is quite literally unreadable with a PC style controller. It was not an economic decision. If you are going to carp please do so from a basis of real knowledge Alexander. (The REAL blame for the disk fiasco goes to the people at Metacrap^H^H^H^HComCo.) > was done and so close to release that redesign was impossible for > schedule reasons, but it might be something else. We'll probably never > know unless somebody who had been in the original design team will leak > it. But whatever reasons were behind that decision, OFS was either blindly > copied without a single thought about very serious design factor _or_ > had been crippled at some point before the release. If it's the latter - I > commiserate with their fs folks. If it's the former... well, I think that > it says quite a few things about their clue level. Metacomco designed it based on their TripOS. OFS is very good for repairing the filesystem in the event of a problem, although the so called DiskDoctor they provided quickly earned the name DiskDestroyer. Metacomco and BSTRINGS and BPOINTERS and all that nonsense entered the picture when it was decided the originally planned OS was would take too long to develop. So what Metacomco had was grafted onto what the old Amiga Inc had done resulting in a hodgepodge mess. > AFFS took the headers out of the data sectors. But that killed the > whole reason behind having them anywhere - if you can't tell data blocks > from the rest, what's the point of marking free and metadata ones? > Now, links were total lossage - I think that even if you have some Kemo Sabe, links never existed UNTIL the Amiga FFS was developed, redeveloped, and redeveloped again. > doubts about that now, you will lose them when you will write down the > operations needed for rename(). And I mean pure set of on-disk changes - > forget about dentries, inodes and other in-core data. > > Why did they do it that way? Beats me. AmigaOS is a microkernel, > so replacing fs driver should be very easy. It ought to be easier than in > Linux. And they've pulled out the change from OFS to AFFS, so the > filesystem conversion was not an issue. Dunno how about UNIX-friendliness, > but their implementation of links definitely was not friendly to their own > OS. As it turns out many of the recovery tools people built worked remarkably well on FFS when it was introduced with little modification. (Most of the time tracing the actual data blocks was not necessary for rebuilding the disk. Thus the datablock metadata loss was not crippling.) FFS appeared in its first versions with AmigaDOS 1.3. (Er, if you want a copy of some of the earliest versions sent to developers for testing I can arrange something in that regard. I believe I still have most of that "stuff".) It underwent several rewrites as successive developers and demands were placed on it. One major change is evidenced in the hash algorithm used for the original OFS and FFS. It fails to treat international characters correctly when removing case. The international version corrected this deficiency. The old cruft is preserved for reading old disks. Later on DirCache was added principly for floppy disks. About that time Randall added both so called soft links and hard links. For what it is worth it took a long long time and series of modifications before either of them worked adequately. > And let's not go into the links to directories, implemented well > after it became painfully obvious that they were an invitation for > troubles (from looking into Amiga newsgroups it seems that miracle > didn't happen - I've seen quite a few complaints about fs breakage > answered with "don't use links to directories, they are broken"). They MAY be fixed in the OS3.5 BoingBag 2 (service pack 2 with a cutsiepie name.) Heinz has committed yet another rewrite. > Anyway, it's all history. We can't unroll the kludge, no matter > what we do. We've got w
RE: Large File support and blocks.
Ooopsthe time frame is closer to today on part of this. While it may be a while before we hit the 1T limit on 1 single device, things like readpage, do so based of the inode -- which on a metadisk could have a filesize much larger than current physical device limits. So it seems that at least at the vnode level this is something that may have to go into the 2.4 series fairly soon, or am I missing something? Why are blocks int's vs. unsigned's ? Was it to pass back errno's in some cases? -- Linda A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 > It may not matter too too much, but blocks are being passed around as > 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T > disk size. Probably don't need to worry about this today, but in a few > years? Should we be changing the internal interfaces to use a long (or > a long unsigned -- why signed?) Maybe for 2.5/2.6 timeframe? Just > curious... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: Silent breakage of cdrecord under 2.4? (fwd)
-- Forwarded message -- Date: Wed, 30 Aug 2000 00:26:13 +0100 (GMT) From: Damon LoCascio <[EMAIL PROTECTED]> To: Douglas Gilbert <[EMAIL PROTECTED]> Subject: Re: Silent breakage of cdrecord under 2.4? On Tue, 29 Aug 2000, Douglas Gilbert wrote: > Damon, > Sounds worrying. I have done a fair amount of testing > with sg in lk 2.4 and haven't seen a problem like this. > My adapters are also from advansys (but singles, not > quads). Could you send me a sample of the corruption > (100 byte one would be fine). Are you using SMP? > > A loop through character device, sitting between cdrecord > and sg would be useful in such situations. > > Doug Gilbert > I have just put together a table of what works and what doesn't under 2.4-test5. All I know for sure is that cdrecord 1.6 compiled against 2.2.16 and running under 2.2.16 works flawlessly. Attached is the results. As you can see I compiled against both the 2.2.16 trees and 2.4.0-test5 ones. Though I only ran it under 2.4. I suspect it would prolly work better under 2.2.16 but then again that is what I am noticing :) cdrecord is doing strange things in the later kernels? I'm not using SMP though, which in theory might make things easier to track??? How do I go about seting up a loop through device before the sg driver just out of interest? Don't know if this is any good. It's never very much corruption just a few bytes here and there? Or in this case a chunk of them -- cmp /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3 /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3 differ: char 3754969, line 13388 -- cmp -l /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3 3754969 372 251 3754970 263 23 3754971 16 234 3754972 144 65 3754973 254 203 3754974 301 22 3754975 101 77 3754976 31 2 -- cmp /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 differ: char 746761, line 3054 -- cmp -l /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 746761 375 242 746762 67 70 746763 72 343 746764 1 5 746765 264 60 746766 242 274 746767 50 231 746768 10 150 -- H I'm beginnning to see a pattern now..? 8 bytes Q. Is though.. why just these 3 files with the latest version of cdrecord? Ag this is gonna drive me nuts?! ;) Will this enlighten us all I wonder? Cheers, -- === "If you can keep your head when all about you are losing theirs... you're missing something IMPORTANT!" Rob. (prolly teefed tho') cdrecord-1.6-2.2.16 -v dev=1,1,0 speed=8 blank=all Result: No errors == cdrecord-1.6-2.2.16 -v dev=1,1,0 speed=8 test-isofs.img Result: Sucessful Burn Track 01: 64 of 64 MB written (fifo 100%). Track 01: Total bytes read/written: 67696640/67696640 (33055 sectors). Writing time: 60.687s Fixating... Fixating time: 35.265s cdrecord-1.6-2.2.16: fifo had 2066 puts and 2066 gets. cdrecord-1.6-2.2.16: fifo was 0 times empty and 1658 times full, min fill was 96%. == diff -r /cdrom /mnt/mnt2 Result: No Differences, identical copy. cdrecord-1.6-2.4-test5 -v dev=1,1,0 speed=8 blank=all Result: No errors == cdrecord-1.6-2.4-test5 -v dev=1,1,0 speed=8 test-isofs.img Result: Servo tracking errors when fixating: Track 01: 64 of 64 MB written (fifo 100%). Track 01: Total bytes read/written: 67696640/67696640 (33055 sectors). Writing time: 59.607s Fixating... cdrecord-1.6-2.4-test5: Success. close track/session: scsi sendcmd: retryable error CDB: 5B 00 02 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 04 00 00 00 00 0A 00 00 00 00 09 00 00 00 Sense Key: 0x4 Hardware Error, Segment 0 Sense Code: 0x09 Qual 0x00 (track following error) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 21.708s timeout 480s Fixating time: 21.711s cdrecord-1.6-2.4-test5: fifo had 2066 puts and 2066 gets. cdrecord-1.6-2.4-test5: fifo was 0 times empty and 1625 times full, min fill was 96%. == diff -r /cdrom /mnt/mnt2 Result: Failure, missing files and bad sectors I/O error: dev 0b:00, sector 108 Only in /mnt/mnt2/city_of_: goo_goo_.mp3 Only in /mnt/mnt2/city_of_: paula_co.mp3 Only in /mnt/mnt2/city_of_: sarah_mc.mp3 ___ cdrecord-1.8.1-2.2.16 -v dev=1,1,0 speed=8 blank=all Result: No errors == cdrecord-1.8.1-2.2.16 -v dev=1,1,0 speed=8 test-isofs.img Result: Clean burn, no errors Starting new track at sector: 0 Track 01: 64 of 64 MB written (fifo 100%). Track 01: Total bytes read/written: 67696640/67696640 (33055 sectors). Writing time: 74.440s Fixating... Fixating time: 34.024s cdrecord-1.8.1-2.2.16: fifo had 2066 puts and 2066 gets. cdrecord-1.8.1-2.2.16: fifo was 0 times empty and 1669 times full, min fill was 96%. == diff -r /cdrom /mnt/mnt2 Result: Failure, missing files and ba
Re: Silent breakage of cdrecord under 2.4?
On Tue, 29 Aug 2000, Douglas Gilbert wrote: > Damon, > Sounds worrying. I have done a fair amount of testing > with sg in lk 2.4 and haven't seen a problem like this. > My adapters are also from advansys (but singles, not > quads). Could you send me a sample of the corruption > (100 byte one would be fine). Are you using SMP? > > A loop through character device, sitting between cdrecord > and sg would be useful in such situations. > > Doug Gilbert > I have just put together a table of what works and what doesn't under 2.4-test5. All I know for sure is that cdrecord 1.6 compiled against 2.2.16 and running under 2.2.16 works flawlessly. Attached is the results. As you can see I compiled against both the 2.2.16 trees and 2.4.0-test5 ones. Though I only ran it under 2.4. I suspect it would prolly work better under 2.2.16 but then again that is what I am noticing :) cdrecord is doing strange things in the later kernels? I'm not using SMP though, which in theory might make things easier to track??? How do I go about seting up a loop through device before the sg driver just out of interest? Don't know if this is any good. It's never very much corruption just a few bytes here and there? Or in this case a chunk of them -- cmp /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3 /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3 differ: char 3754969, line 13388 -- cmp -l /cdrom/city_of_/goo_goo_.mp3 /mnt/mnt2/city_of_/goo_goo_.mp3 3754969 372 251 3754970 263 23 3754971 16 234 3754972 144 65 3754973 254 203 3754974 301 22 3754975 101 77 3754976 31 2 -- cmp /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 differ: char 746761, line 3054 -- cmp -l /cdrom/city_of_/sarah_mc.mp3 /mnt/mnt2/city_of_/sarah_mc.mp3 746761 375 242 746762 67 70 746763 72 343 746764 1 5 746765 264 60 746766 242 274 746767 50 231 746768 10 150 -- H I'm beginnning to see a pattern now..? 8 bytes Q. Is though.. why just these 3 files with the latest version of cdrecord? Ag this is gonna drive me nuts?! ;) Will this enlighten us all I wonder? Cheers, -- === "If you can keep your head when all about you are losing theirs... you're missing something IMPORTANT!" Rob. (prolly teefed tho') cdrecord-1.6-2.2.16 -v dev=1,1,0 speed=8 blank=all Result: No errors == cdrecord-1.6-2.2.16 -v dev=1,1,0 speed=8 test-isofs.img Result: Sucessful Burn Track 01: 64 of 64 MB written (fifo 100%). Track 01: Total bytes read/written: 67696640/67696640 (33055 sectors). Writing time: 60.687s Fixating... Fixating time: 35.265s cdrecord-1.6-2.2.16: fifo had 2066 puts and 2066 gets. cdrecord-1.6-2.2.16: fifo was 0 times empty and 1658 times full, min fill was 96%. == diff -r /cdrom /mnt/mnt2 Result: No Differences, identical copy. cdrecord-1.6-2.4-test5 -v dev=1,1,0 speed=8 blank=all Result: No errors == cdrecord-1.6-2.4-test5 -v dev=1,1,0 speed=8 test-isofs.img Result: Servo tracking errors when fixating: Track 01: 64 of 64 MB written (fifo 100%). Track 01: Total bytes read/written: 67696640/67696640 (33055 sectors). Writing time: 59.607s Fixating... cdrecord-1.6-2.4-test5: Success. close track/session: scsi sendcmd: retryable error CDB: 5B 00 02 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 04 00 00 00 00 0A 00 00 00 00 09 00 00 00 Sense Key: 0x4 Hardware Error, Segment 0 Sense Code: 0x09 Qual 0x00 (track following error) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 21.708s timeout 480s Fixating time: 21.711s cdrecord-1.6-2.4-test5: fifo had 2066 puts and 2066 gets. cdrecord-1.6-2.4-test5: fifo was 0 times empty and 1625 times full, min fill was 96%. == diff -r /cdrom /mnt/mnt2 Result: Failure, missing files and bad sectors I/O error: dev 0b:00, sector 108 Only in /mnt/mnt2/city_of_: goo_goo_.mp3 Only in /mnt/mnt2/city_of_: paula_co.mp3 Only in /mnt/mnt2/city_of_: sarah_mc.mp3 ___ cdrecord-1.8.1-2.2.16 -v dev=1,1,0 speed=8 blank=all Result: No errors == cdrecord-1.8.1-2.2.16 -v dev=1,1,0 speed=8 test-isofs.img Result: Clean burn, no errors Starting new track at sector: 0 Track 01: 64 of 64 MB written (fifo 100%). Track 01: Total bytes read/written: 67696640/67696640 (33055 sectors). Writing time: 74.440s Fixating... Fixating time: 34.024s cdrecord-1.8.1-2.2.16: fifo had 2066 puts and 2066 gets. cdrecord-1.8.1-2.2.16: fifo was 0 times empty and 1669 times full, min fill was 96%. == diff -r /cdrom /mnt/mnt2 Result: Failure, missing files and bad sectors I/O error: dev 0b:00, sector 92 Only in /mnt/mnt2: city_of_ Only in /mnt/mnt2: heart000 Only in /mnt/mnt2: heart_fu Only in /mnt/mnt2: hope_flo ___ cdrecord-1.8.1-2.4-tes
[patchlet] Compile warnings in net/ipx/af_ipx.c (2.4.0-t8p1)
Hi.
When I compile net/ipx/af_ipx.c without procfs support I get the
following warnings:
net/ipx/af_ipx.c:1508: warning: `ipx_interface_get_info' defined but not used
net/ipx/af_ipx.c:1551: warning: `ipx_get_info' defined but not used
net/ipx/af_ipx.c:1632: warning: `ipx_rt_get_info' defined but not used
The following patch fixes this:
--- linux/net/ipx/af_ipx.c.org Sat Jul 29 23:59:27 2000
+++ linux/net/ipx/af_ipx.c Sun Jul 30 00:00:36 2000
@@ -1503,6 +1503,7 @@
}
/* Called from proc fs */
+#ifdef CONFIG_PROC_FS
static int ipx_interface_get_info(char *buffer, char **start, off_t offset,
int length)
{
@@ -1671,7 +1672,7 @@
return (len);
}
-
+#endif /*CONFIG_PROC_FS*/
/**\
* *
* Handling for system calls applied via the various interfaces to an *
--
Regards,
Rasmus([EMAIL PROTECTED])
People are more violently opposed to fur than leather because
it's safer to pick on rich women than biker gangs. -- Anonymous
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2T for i386
On Thu, 31 Aug 2000, Alan Cox wrote: > > >You might be able to do that with hardware IDE raid controllers and the like > > >such as the 3ware 8 port cards, or scsi raid controllers and then run ext3 > > >or reiserfs. > > > > If you're building a 2TB array, you're not gonna do it with bloody IDE > > hardware. (I hope you're joking.) > > I used to think that. Im planning on deploying a 1Tb IDE raid using 3ware kit > for an ftp site very soon. Its very cheap and its very fast. UDMA with > one disk per channel and the controller doing some of the work. > > All it lacks is hot swap. especially when you start considering size and cost requirements ide looks particularly attractive. 75GB scsi disks are 11 platter (ibm) or 12 (seagate) half height drives vs the 75gxp ide (ibm) with has five platters and is 1" high. The 75GB scsi disks are around $1500ea vs the ide which are around $550. so if you're requirements are lots of disk space you can do ide in about 1/2 the physical space and for about 1/3 the cost of a similar scsi implementation, at this time. there are of course still good reasons to go with scsi for various applications, but raw space alone probably isn't one of them. we're bringing up two 675GB stripes shortly to augment an existing 160GB stripe we have. joelja -- Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Large File support and blocks.
It may not matter too too much, but blocks are being passed around as 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T disk size. Probably don't need to worry about this today, but in a few years? Should we be changing the internal interfaces to use a long (or a long unsigned -- why signed?) Maybe for 2.5/2.6 timeframe? Just curious... -l -- Linda A Walsh| Trust Technology, Core Linux, SGI [EMAIL PROTECTED] | Voice: (650) 933-5338 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a (large) memory block
On Thu, 31 Aug 2000 11:32:21 -0500 Timur Tabi <[EMAIL PROTECTED]> wrote: > ** Reply to message from [EMAIL PROTECTED] on Thu, 31 Aug 2000 > 08:57:20 -0700 >> Now the device behaves just like memory to the BIOS during POST >> etc, and is in fact, exactly memory if no device drivers are >> loaded. If a device driver is loaded and it detects one or more >> of these devices then they and their memory ranges become >> obviously special. Now, we can detect the devices and where >> their address ranges are via the SMBUS and some careful probing >> so we know what we are trying to grab. The problem is just >> telling the rest of the kernel that in a clean VM&heap-happy >> manner. > How do you know what SMBUS address to use? Probing the SMBUS > looking for devices has a tendency to lock the SMBUS and require a > complete power down to restore. I didn't write the SMBUS code (the author is not on this list), however, the basic SMBUS work was based off here: http://www.netroedge.com/%7elm78/ At this point we've only tried/tested/looked_at GX chipset based SMP MBs. Loosely we hit the chipset and get the specs for every individual memory card, and look for something that looks like one of our devices as per the SPDs (we have a mini in-driver eeprom-style client setup to get the SPDs). The cards are then identified as per a signature in the SPD. -- J C Lawrence Home: [EMAIL PROTECTED] -(*)Work: [EMAIL PROTECTED] http://www.kanga.nu/~claw/Keys etc: finger [EMAIL PROTECTED] --=| A man is as sane as he is dangerous to his environment |=-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Speed increase on SMP in 2.4.0 test 6 and up
Was done but Informix DS 7.3 still sees no shared memory. Either I did something wrong in the compile or I don't know. I am preparing straces since two members of the list offered to look into them. What I also don't understand is the ouput of df on /dev/shm. What does it give me ?? Michael On Thu, Aug 31, 2000 at 07:44:54PM +, Erik Mouw wrote: > On 31 Aug 2000 08:37:10 -0200, Michael Bielicki wrote: > > I am heavily impressed, besides my shared memory problem with Informix > > and Sybase > > this is excellent. > > I hope you have the shmfs mounted? If not, add the following line to > /etc/fstab: > > none/dev/shm shmdefaults 0 0 > > And of course make the mountpoint /dev/shm . > > > Erik > > -- > "I'm just this guy you know?" -- Zaphod Beeblebrox in > "The Hitchhikers Guide to the Galaxy" by Douglas Adams > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Speed increase on SMP in 2.4.0 test 6 and up
On 31 Aug 2000 08:37:10 -0200, Michael Bielicki wrote: > I am heavily impressed, besides my shared memory problem with Informix > and Sybase > this is excellent. I hope you have the shmfs mounted? If not, add the following line to /etc/fstab: none/dev/shm shmdefaults 0 0 And of course make the mountpoint /dev/shm . Erik -- "I'm just this guy you know?" -- Zaphod Beeblebrox in "The Hitchhikers Guide to the Galaxy" by Douglas Adams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Newbie question: mmap() and file descriptor limits
Please CC any replies to me at <[EMAIL PROTECTED]>. I hope this has not been discussed before. I think I have searched the archive fairly exhaustively. This issue may also no longer exist on the 2.4 kernel series because I have not tested it on that kernel. I have been experimenting with a web server (thttpd) which uses a cache of mmaped files to serve requests. It opens a file, mmaps it then closes it to avoid running into the perprocess file descriptor limits. Instead, it ends up running into the system file descriptor limits which makes the system unusable for anything but the web server process. FreeBSD does it differenly. Files can be mmaped and do not count towards the limit. Does this issue still exist in the 2.4 kernel series? If not, are there any plans for resolving it? Any suggestions for how I could modify the web server to avoid making the system unusable? Thank you Evan Jones <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
What about those of us who don't have modules enabled. "make modules_install" complains. I'm still like the idea of /lib/kernel or /lib/linux. Keep /lib/modules for modules. Or on my machines I won't even have to create /lib/modules. On Thu, 31 Aug 2000, Robert Greimel wrote: > It would be nice if "make modules_install" would automatically copy System.map > to /lib/modules// . -- Two penguins were walking on an iceburg. The first one said to the second, "you look like you are wearing a tuxedo." The second one said, "I might be..." --David Lynch, Twin Peaks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2T for i386
Alan Cox <[EMAIL PROTECTED]> wrote: > I used to think that. Im planning on deploying a 1Tb IDE raid using 3ware kit > for an ftp site very soon. Its very cheap and its very fast. UDMA with > one disk per channel and the controller doing some of the work. > > All it lacks is hot swap. I wonder if it is possible to have the manufacturers agree on a common electrical/physical standard for IDE hot-swap connector, like SCA for SCSI. Say, being able to use standard enclosures that is compatible with different manufacturer's disks, instead of those 5 inch bay tray hacks that are big and not compatible to each other. Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
On Tue, 29 Aug 2000, Pavel Machek wrote: > Hi! > [...] > > > So you need some hackery to make mount(8) cause change in all > > > namespaces at once. Whatever is done, this will be gross. > > > I suppose you'd require a loopback of some sort, so that one > > > might rip the real filesystem out from under /var/mail instead > > > of trying to unmount it in 50 different namespaces... ugh. > > > > Not. Loopback would be gross, but I'm not proposing it. OTOH, getting all > > mailreaders work with IMAP with _no_ changes in said mailreaders is a > > Good Thing(tm). So is free (for mailreaders) support of any weird > > protocol, format and location of mailbox, locking scheme, etc. - do it in > > one place and that's it. Everything looks like we have the mailbox in > > fixed format on local filesystem, no matter WTF is actually out there. > > And guess what? It doesn't have to be one process and it's nowhere near > > the kernel mode, or even suid. > > What does this have to do with private namespaces? > > mailfsd /dev/coda0 --enable-imap & > mount /dev/coda0 /var/spool/mail So every user will see /var/spool/mail. There must be a single mailfsd for all users. With private namespaces, every user can run his/her own mailfsd, privately mount /var/spool/mail, and run a mailer program to access one or more IMAP mailbox as /var/spool/mail/. But I must say I don't really get the difference in running my own mailfsd, mounting ~/mail and having the mailer program read IMAP mailboxes there (OK, /var/spool/mail/ is the default INBOX for many mailers, and some of them don't let you change that... but this is a minor issue, just recompile them). All I need is a private mount point (and privileges to mount on it). > > It looks easy to me, today and without private namespaces. > [Shall I hack podfuk into providing imap? Okay, it would not be easy > because > * /var/spool/mail/xxx is _writable_, so your imap dream is probably > dream. What does your mailfs do when someone does cat /bin/bash > > $MYMAIL > * podfuk is has file granularity > > I could see it working with some kind of directory format, however.] > Pavel > -- > I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." > Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hfs support for blocksize != 512
On Thu, 31 Aug 2000, Roman Zippel wrote: > Disclaimer: I know that the following doesn't match the current > implementation, it's just how I would intuitively would do it: > > - get dentry foo > - get dentry baz How? OK, you've found block of baz. You know the name, all right. Now you've got to do the full tracing all the way back to root. During that tracing you've got to do interesting things - essentially that's what Neil and Roman are trying to do with fh_to_dentry patches and it's _not_ simple. Moreover, it's even worse than the current code wrt amount of IO _and_ seeks. OK, nevermind, let's say you've done that. > - lock inode foo > - mark dentry foo as deleted > - getblk file header foo > - mark file header foo as deleted ? > - getblk file header baz You'll have to do it way before - how else would you find out that it was called baz, in the first place? > - update file header baz from file header foo If it would be that simple... Extent blocks refer to foo, unfortunately. Yes, copying the thing would be easier. Too bad, data structure prohibits that. > > On that specific operation. When you are done with > > that, I have a rename() for you, but I think that even simpler example > > (unlink()) will be sufficient. > > Please post it, I know there are some interesting examples, but I don't > have them at hand. Although I wanted to keep that flamewar for later, but > if we're already in it... Well, consider rename over the primary link and there you go... Keep in mind that extent blocks contain the reference to header block, so unless you want to update them all you've got to move the header into donor's chain ;-/ > > Again, we are talking about the data structure and operations it has to > > deal with _according to its designers_. I claim that due to a bad data > > structure design (single-linked lists in hash chains, requirement to have > > all entries belonging to some chain) unlink() (one of the operations it > > was designed to deal with) becomes very complicated and requires rather > > hairy exclusion rules. On Amiga. Linux has nothing with the problem. > > To be fair it shoud be mentioned, that links were added later to affs. Well, but we've got to deal with the result, not with the AFFS-without-links. I certainly agree that most of the blame for bad data structure design falls on the folks who added that kludge for pseudo-links, but that's purely historical question. Result is ugly. As for the silliness of the OFS... I apologize for repeating the story if you know it already, but anyway: OFS looks awfully similar to Alto filesystem. With one crucial difference: Alto kept the header/footer equivalents in the sector framing. No silly 400-odd byte sectors for them. That layout made a lot of sense - you could easily recover from many disk faults, yodda, yodda, _without_ sacrificing performance. The whole design relied on ability to put pieces of metadata in the sector framing. Take that away and you've lost _very_ large part of the benefits. So large that the whole design ought to be rethought - tradeoffs change big way. OFS took that away. Mechanically. It just stuffed the headers into the data part of sectors. I don't know the story behind that decision - being a jaded bastard I suspect that Commodore PHBs decided to save a bit on floppy controller price and did it well after the initial design was done and so close to release that redesign was impossible for schedule reasons, but it might be something else. We'll probably never know unless somebody who had been in the original design team will leak it. But whatever reasons were behind that decision, OFS was either blindly copied without a single thought about very serious design factor _or_ had been crippled at some point before the release. If it's the latter - I commiserate with their fs folks. If it's the former... well, I think that it says quite a few things about their clue level. AFFS took the headers out of the data sectors. But that killed the whole reason behind having them anywhere - if you can't tell data blocks from the rest, what's the point of marking free and metadata ones? Now, links were total lossage - I think that even if you have some doubts about that now, you will lose them when you will write down the operations needed for rename(). And I mean pure set of on-disk changes - forget about dentries, inodes and other in-core data. Why did they do it that way? Beats me. AmigaOS is a microkernel, so replacing fs driver should be very easy. It ought to be easier than in Linux. And they've pulled out the change from OFS to AFFS, so the filesystem conversion was not an issue. Dunno how about UNIX-friendliness, but their implementation of links definitely was not friendly to their own OS. And let's not go into the links to directories, implemented well after it became painfully obvious that they were an invitation for troubles (from looking into Amiga
Re: 2T for i386
> >You might be able to do that with hardware IDE raid controllers and the like > >such as the 3ware 8 port cards, or scsi raid controllers and then run ext3 > >or reiserfs. > > If you're building a 2TB array, you're not gonna do it with bloody IDE > hardware. (I hope you're joking.) I used to think that. Im planning on deploying a 1Tb IDE raid using 3ware kit for an ftp site very soon. Its very cheap and its very fast. UDMA with one disk per channel and the controller doing some of the work. All it lacks is hot swap. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCO: "thread creation is about a thousand times faster than on
Hi! > > > Erm? > > > * setuid is a fscking wart - THE mistake of dmr and/or ken. > > > > If not urban legend, dmr was the patent owner. > > Erm... That would be a nice way to bury one's mistake - patent it and > refuse to license ;-) Unfortunately, didn't happen... (-: > > So you need some hackery to make mount(8) cause change in all > > namespaces at once. Whatever is done, this will be gross. > > I suppose you'd require a loopback of some sort, so that one > > might rip the real filesystem out from under /var/mail instead > > of trying to unmount it in 50 different namespaces... ugh. > > Not. Loopback would be gross, but I'm not proposing it. OTOH, getting all > mailreaders work with IMAP with _no_ changes in said mailreaders is a > Good Thing(tm). So is free (for mailreaders) support of any weird > protocol, format and location of mailbox, locking scheme, etc. - do it in > one place and that's it. Everything looks like we have the mailbox in > fixed format on local filesystem, no matter WTF is actually out there. > And guess what? It doesn't have to be one process and it's nowhere near > the kernel mode, or even suid. What does this have to do with private namespaces? mailfsd /dev/coda0 --enable-imap & mount /dev/coda0 /var/spool/mail It looks easy to me, today and without private namespaces. [Shall I hack podfuk into providing imap? Okay, it would not be easy because * /var/spool/mail/xxx is _writable_, so your imap dream is probably dream. What does your mailfs do when someone does cat /bin/bash > $MYMAIL * podfuk is has file granularity I could see it working with some kind of directory format, however.] Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patch] Compile warnings in drivers/scsi/advansys.c (240t8p1)
Hi. When I compile drivers/scsi/advansys.c without procfs support I get the following warnings: drivers/scsi/advansys.c:9872: warning: `asc_proc_copy' defined but not used drivers/scsi/advansys.c:8746: warning: `asc_prt_board_devices' defined but not used drivers/scsi/advansys.c:8787: warning: `asc_prt_adv_bios' defined but not used drivers/scsi/advansys.c:8954: warning: `asc_prt_asc_board_eeprom' defined but not used drivers/scsi/advansys.c:9079: warning: `asc_prt_adv_board_eeprom' defined but not used drivers/scsi/advansys.c:9348: warning: `asc_prt_driver_conf' defined but not used drivers/scsi/advansys.c:9447: warning: `asc_prt_asc_board_info' defined but not used drivers/scsi/advansys.c:9632: warning: `asc_prt_adv_board_info' defined but not used drivers/scsi/advansys.c:10338: warning: `asc_prt_board_stats' defined but not used The following patch fixes this. Please commment: --- linux-240test6-clean/drivers/scsi/advansys.cMon Jul 31 21:03:17 2000 +++ linux/drivers/scsi/advansys.c Sat Aug 12 21:22:42 2000 @@ -4113,9 +4113,9 @@ * advansys.h contains function prototypes for functions global to Linux. */ -#if LINUX_VERSION_CODE >= ASC_LINUX_VERSION(1,3,0) +#if (LINUX_VERSION_CODE >= ASC_LINUX_VERSION(1,3,0)) && defined(CONFIG_PROC_FS) STATIC int asc_proc_copy(off_t, off_t, char *, int , char *, int); -#endif /* version >= v1.3.0 */ +#endif /* version >= v1.3.0 && CONFIG_PROC_FS*/ #if LINUX_VERSION_CODE < ASC_LINUX_VERSION(1,3,70) STATIC void advansys_interrupt(int, struct pt_regs *); #else /* version >= v1.3.70 */ @@ -4151,7 +4151,7 @@ STATIC intasc_rmqueue(asc_queue_t *, REQP); STATIC intasc_isqueued(asc_queue_t *, REQP); STATIC void asc_execute_queue(asc_queue_t *); -#if LINUX_VERSION_CODE >= ASC_LINUX_VERSION(1,3,0) +#if (LINUX_VERSION_CODE >= ASC_LINUX_VERSION(1,3,0)) && defined(CONFIG_PROC_FS) STATIC intasc_prt_board_devices(struct Scsi_Host *, char *, int); STATIC intasc_prt_adv_bios(struct Scsi_Host *, char *, int); STATIC intasc_get_eeprom_string(ushort *serialnum, uchar *cp); @@ -4161,15 +4161,15 @@ STATIC intasc_prt_asc_board_info(struct Scsi_Host *, char *, int); STATIC intasc_prt_adv_board_info(struct Scsi_Host *, char *, int); STATIC intasc_prt_line(char *, int, char *fmt, ...); -#endif /* version >= v1.3.0 */ +#endif /* version >= v1.3.0 && CONFIG_PROC_FS*/ /* Declaration for Asc Library internal functions referenced by driver. */ STATIC int AscFindSignature(PortAddr); STATIC ushort AscGetEEPConfig(PortAddr, ASCEEP_CONFIG *, ushort); -#ifdef ADVANSYS_STATS +#if defined(ADVANSYS_STATS) && defined(CONFIG_PROC_FS) STATIC int asc_prt_board_stats(struct Scsi_Host *, char *, int); -#endif /* ADVANSYS_STATS */ +#endif /* ADVANSYS_STATS && CONFIG_PROC_FS*/ #ifdef ADVANSYS_DEBUG STATIC void asc_prt_scsi_host(struct Scsi_Host *); @@ -8729,7 +8729,7 @@ return; } -#if LINUX_VERSION_CODE >= ASC_LINUX_VERSION(1,3,0) +#if (LINUX_VERSION_CODE >= ASC_LINUX_VERSION(1,3,0)) && defined(CONFIG_PROC_FS) /* * asc_prt_board_devices() * @@ -9923,7 +9923,7 @@ va_end(args); return ret; } -#endif /* version >= v1.3.0 */ +#endif /* version >= v1.3.0 && CONFIG_PROC_FS*/ /* @@ -10323,7 +10323,7 @@ * --- Tracing and Debugging Functions */ -#ifdef ADVANSYS_STATS +#if defined(ADVANSYS_STATS) && defined(CONFIG_PROC_FS) /* * asc_prt_board_stats() * @@ -10482,7 +10482,7 @@ return totlen; } -#endif /* ADVANSYS_STATS */ +#endif /* ADVANSYS_STATS && CONFIG_PROC_FS*/ #ifdef ADVANSYS_DEBUG /* -- Regards, Rasmus([EMAIL PROTECTED]) "I have a nice perspective on what it means to be in charge of the most important project in the history of mankind." --Brian Valentine, W2k Proj Mgr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2T for i386
On Tue, 29 Aug 2000, Alan Cox wrote: >At 2Tb in a single partition you might well start hitting barriers. I think >there is a 1Tb limit per device somewhere. You also need to ask yourself how >long 2Tb would take to fsck on a power failure. Right now 2.2 doesnt support >journalling over software raid so that would stop you using reiserfs and ext3. Who said he was going to use software RAID? For that matter, he didn't say he was going to use ext2 either. (However, that seems to be a logical assumption.) >You might be able to do that with hardware IDE raid controllers and the like >such as the 3ware 8 port cards, or scsi raid controllers and then run ext3 >or reiserfs. If you're building a 2TB array, you're not gonna do it with bloody IDE hardware. (I hope you're joking.) --Ricky PS: fsck is very expensive on a full filesystem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[patchlet] Minor compile warnings from net/appletalk/aarp.c (240t8p1)
Hi.
When I compile net/appletalk/aarp.c without procfs support I get the
following warning:
net/appletalk/aarp.c:1089: warning: `aarp_get_info' defined but not used
The following patch fixes this:
--- linux-240test7-pre2-clean/net/appletalk/aarp.c Mon Jul 31 21:05:04 2000
+++ linux/net/appletalk/aarp.c Sun Aug 13 21:05:01 2000
@@ -1085,6 +1085,7 @@
/*
* Called from proc fs
*/
+#ifdef CONFIG_PROC_FS
static int aarp_get_info(char *buffer, char **start, off_t offset, int length)
{
/* we should dump all our AARP entries */
@@ -1171,6 +1172,7 @@
return len;
}
+#endif /* CONFIG_PROC_FS */
#ifdef MODULE
/*
--
Rasmus([EMAIL PROTECTED])
"I have a nice perspective on what it means to be in charge of the
most important project in the history of mankind."
--Brian Valentine, W2k Proj Mgr
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
Robert Greimel writes: >> BTW, /boot/System.map-`uname -r` is the first place in which >> procps looks for the the System.map data. Red Hat and Debian > > Yes, but it is no good if you switch between different kernel > versions as you will get error messages about System.map being > the wrong version number (unless you copied it every time you > boot a different kernel, of course). Huh? The version number is right there. For example: /boot/System.map-2.3.99-pre3 Doing a "make install" should put System.map in the right place. Unless you have scripts to update them at boot, I suggest that you delete /System.map, /boot/System.map, and any other unversioned copies you might have floating around. You don't get the build number or a unique ID. This is a flaw but see below... > /lib/modules/ is a much more natural place, IMHO. > I would even go so far as to say that procps should look > there first before looking in /boot. Nope. The "release" is exactly what gets used in /boot. There is no advantage here. Modules might not exist, and System.map has nothing to do with modules anyway. System.map is derived from the kernel. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2T for i386
Hi! > My boss wants to know if linux can handle a 2Terabyte raid > partition. While I've seen various discussions that indicate that > linux *should* be able to handle an ext2 file system that big, has > anyone actually produced one on an i386 arch? I admit that 32 73 gig > disks are a *lot* of blocks to worry about. Check it yourself. Take nbd server, make it serve sparse file 2TB in size. Easy. [I played this game of mounting 100Gig ext2 at home. Granted, I did have only 10G of real disks ;-). NBD server even has special support so you don't hit 2G limit of older kernels.] Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
>BTW, /boot/System.map-`uname -r` is the first place in which >procps looks for the the System.map data. Red Hat and Debian Yes, but it is no good if you switch between different kernel versions as you will get error messages about System.map being the wrong version number (unless you copied it every time you boot a different kernel, of course). /lib/modules/ is a much more natural place, IMHO. I would even go so far as to say that procps should look there first before looking in /boot. Greetings Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
Alan Cox writes: >> where you overwrite your old kernel image with a new one without >> rebooting instantly). >> >> But is it so much more expensive than a /proc/config.whatever ? > > Use that argument 50 times and your kernel has grown 100K. If I get the same level of benefit 50 times, wonderful! With /proc/config.gz, there is no need to wonder where the previous admin stored his config file. > Unfortunately everyone keeps using the argument and forgetting > the cumulative effect The effect is additive, not multiplicative. Considering the exponential nature of Moore's Law, additive bloat is no bloat at all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
Michael Elizabeth Chastain writes: > I'm beginning to think that installation should copy everyting > (bzImage, System.map, modules) into /lib/modules/. This split > between resident and modules just causes endless hassle. That would be a serious error. Often /boot is a special partition located within the first 500 MB of the disk. Once I had it being a link to /dos/linux, which as you may guess was a FAT filesystem. BTW, /boot/System.map-`uname -r` is the first place in which procps looks for the the System.map data. Red Hat and Debian both seem to prefer this location, aside from some /System.map braindamage that Debian sometimes uses. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, Aug 31, 2000 at 04:26:55PM +0200, [EMAIL PROTECTED] wrote: > Or can we have a standard, reasonably reliable way for determining the > path name of the currently running image ? (E.g. for LILO, the command > is lilo -I `sed '/.*BOOT_IMAGE=\([^ ]*\).*/s//\1/' But what about GRUB, LOADLIN, SILO, MILO, ... ?) I've written scripts do copy any useful piece of (debug) info to /boot. To cope with MILO, you can use: [jbglaw@air:/home/jbglaw] $> sed '/.*bootfile=\([^ ]*\).*/s//\1/' sed '/.*bootdevice=\([^ ]*\).*/s//\1/' -- +49-177-5601720 */ keyID=0x8399E1BB fingerprint=250D 3BCF 7127 0D8C A444 A961 1DBD 5E75 8399 E1BB "insmod vi.o and there we go..." (Alexander Viro on linux-kernel) PGP signature
Re: 2.4.0-test4&6 scsi tape problem [not fixed :-/]
On Thu, 31 Aug 2000, G. Saraber wrote: > "Richard B. Johnson" wrote: > > > > On Wed, 30 Aug 2000, G. Saraber wrote: > > > > > Thanks for the excellent guide on how to pinpoint the problem ... > > > > > > guess what :-) I decided before I send in another bugreport i'll upgrade > > > to test7 so the developers dont have to dig through 'old' kernel > > > versions .. > > > anyway, the problem went away, they must have fixed it :-) > > ok, [SNIPPED...] Looks like your SCSI tape drive is getting hung and has grabbed the bus . Finally, the SCSI driver makes the last-ditch effort by aborting everything and resetting the bus. > Aug 31 00:57:20 ahr kernel: SCSI bus is being reset for host 0 channel > 0. > Aug 31 00:57:20 ahr kernel: (scsi0:0:5:0) Synchronous at 10.0 Mbyte/sec, > offset 15. > Aug 31 00:57:20 ahr kernel: (scsi0:0:3:0) Synchronous at 80.0 Mbyte/sec, > offset 31. > Aug 31 00:57:20 ahr kernel: (scsi0:0:4:0) Synchronous at 80.0 Mbyte/sec, > offset 31. > Aug 31 00:57:25 ahr kernel: st0: Error with sense data: Info fld=0x40, > Current st09:00: sns = f0 6 > Aug 31 00:57:25 ahr kernel: ASC=29 ASCQ= 0 Now you have a device not-ready. > Aug 31 00:57:25 ahr kernel: Raw sense data:0xf0 0x00 0x06 0x00 0x00 0x00 > 0x40 0x12 0x00 0x00 0x00 0x00 0x29 0x00 0x00 0x00 0x00 0x00 0x00 0x00 > 0x00 0x00 0x00 0x00 0x00 0x00 > Aug 31 00:57:25 ahr kernel: st0: Error with sense data: Info fld=0x1, > Current st09:00: sns = f0 2 > Aug 31 00:57:25 ahr kernel: ASC= 4 ASCQ= 1 And the device is now becoming ready. > Aug 31 00:57:25 ahr kernel: Raw sense data:0xf0 0x00 0x02 0x00 0x00 0x00 > 0x01 0x12 0x00 0x00 0x00 0x00 0x04 0x01 0x00 0x00 0x00 0x00 0x00 0x00 > 0x00 0x00 0x00 0x00 0x00 0x00 > Aug 31 00:57:25 ahr kernel: st0: Error on write filemark. > Maybe your drive can't handle the synchronous speed? Maybe it's too hot? Maybe anything. The kernel code __seems__ to be trying its hardest to handle a problem with the drive. The new kernel may be slightly faster in its transfer-rate, triggering a latent problem with the drive. I'd first try backing off on the sync-speed (through the SCSI BIOS). Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.[16,17pre20] VM do_try_to_free_pages
> When trying to compile SimGear-0.0.12 under 2.2.16, with gcc-2.95.2, > I could (quite reproducibly) cause an unbounded number of: > > VM: do_try_to_free_pages failed for x > >where x was cc1plus, kswapd, syslogd, etc. > >Under 2.2.17pre20, this still start to happen, but shortly thereafter >the kernel kills cc1plus, and it stops. I don't think I'm reaching >memory exhaustion; I've got 256M ram, and I ran the compile from the >console with nothing else running. > >Is the cause of this behavior known, and if not, what can I do to help >diagnose it? I've read that seeing a few of these messages is ok, but I too have experienced the case where these messages loop forever. Sys-Rq is still active, so some stats can be dumped. This occurs for me when I run a dbench test with 35 or more clients on a machine with 32Mb of RAM. I believe this first occured in the changes made between 2.2.17pre3 and pre4. With pre3 I can run dbench for days without problems, with pre4 it dies within a few hours. I've tried this with 2.2.17pre19 and the problem still exists. I think that reverting the changes to the do_try_to_swap_out & kswapd functions in mm/vmscan.c fixes the problem, but i've been busy fixing other things recently to prove that this really is a good fix. Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
Timur Tabi said once upon a time (Thu, 31 Aug 2000): > Of course, the smartest thing would be if the installation routine actually > built the kernel, with all options finely tuned to the hardware. If I'm > installing on a single CPU system, then I don't want the SMP kernel. Red Hat > doesn't understand that. It DOES understand that. The Red Hat installer does the right thing and install a proper kernel. My RH6.2 install CD has the following: kernel-2.2.16-3.i386.rpm kernel-2.2.16-3.i586.rpm kernel-2.2.16-3.i686.rpm kernel-smp-2.2.16-3.i386.rpm kernel-smp-2.2.16-3.i586.rpm kernel-smp-2.2.16-3.i686.rpm Dax - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] string-486.h modified
On Thu, 31 Aug 2000, Petko Manolov wrote: > "Richard B. Johnson" wrote: > > > > On Thu, 31 Aug 2000, Petko Manolov wrote: > > > > [Snipped...] > > > > Good. You understand. Keep up the good work. > > > I realy would like to see this code in use ;-) After you test it **THOUROUGHLY**, send a patch to Linus. I recommend testing it in a user-mode program with all kinds of sizes/shapes/lengths/offsets, etc., and making certain that you don't destroy any registers that are "precious" for the usual versions of gcc. If your patch doesn't hurt anything, even if it only adds marginal performance, I'm pretty sure that Linus will accept it. Cheers, Dick Johnson Penguin : Linux version 2.2.15 on an i686 machine (797.90 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
** Reply to message from Paul Jakma <[EMAIL PROTECTED]> on Thu, 31 Aug 2000 17:55:49 +0100 (IST) > as well as .config to /lib/modules//config. > > (i had to meant to write .config not System.map originally as that is > what the thread is about... doh!) > > whatever, there's no need for kernel memory to bloated out with > .config. It would be even better if all distributions made it a habit of providing the .config that perfectly matched whatever kernel was installed. That way, I don't have to figure out what kind of hardware I have in order to rebuild the kernel. Of course, the smartest thing would be if the installation routine actually built the kernel, with all options finely tuned to the hardware. If I'm installing on a single CPU system, then I don't want the SMP kernel. Red Hat doesn't understand that. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, 31 Aug 2000, Robert Greimel wrote: > It would be nice if "make modules_install" would automatically copy System.map > to /lib/modules// . > as well as .config to /lib/modules//config. (i had to meant to write .config not System.map originally as that is what the thread is about... doh!) whatever, there's no need for kernel memory to bloated out with .config. > Greetings > > Robert > --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
I'm beginning to think that installation should copy everyting (bzImage, System.map, modules) into /lib/modules/. This split between resident and modules just causes endless hassle. Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
>> cp System.map /boot/System.map- > >or even better cp to /lib/modules// and fix the tools to look >there if they don't do already. It would be nice if "make modules_install" would automatically copy System.map to /lib/modules// . Greetings Robert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Any good _online_ kernel BSD sockets reference out there??
> - Userspace: > sd = socket(AF_PACKET, SOCK_RAW, 0); (Is this correct??) It can be for pure raw data > bind(how do I bind this socket to the interface, if I don't have >an address?? Can I just make one up??); sockaddr_ll/sockaddr_pkt (see linux/if_packet.h> > send(sd, data, len); Yep > - Kernel: > "send" makes kernel call dev_queue_xmit(), which will call the > driver's hard_start_xmit function. Yep > Questions: > - Do I need to bring the interface up with ifconfig before being able to > do this?? My question is because ifconfig doesn't have a "raw mode" > address family ... It needs to be up, but it doesnt need to be assigned IP addresses in current kernels (2.0 does need IP) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a (large) memory block
** Reply to message from [EMAIL PROTECTED] on Thu, 31 Aug 2000 08:57:20 -0700 > Now the device behaves just like memory to the BIOS during POST > etc, and is in fact, exactly memory if no device drivers are loaded. > If a device driver is loaded and it detects one or more of these > devices then they and their memory ranges become obviously special. > Now, we can detect the devices and where their address ranges are > via the SMBUS and some careful probing so we know what we are trying > to grab. The problem is just telling the rest of the kernel that in > a clean VM&heap-happy manner. How do you know what SMBUS address to use? Probing the SMBUS looking for devices has a tendency to lock the SMBUS and require a complete power down to restore. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/sys/kernel/shmmax does not increase shared ram
Michael Bielicki <[EMAIL PROTECTED]> writes: > Hi, > I found this effect on both test6 and test7 that if I type: > > echo 12800 > /proc/sys/kernel/shmmax > it has no real effect on the amount of shared memory. # uname -a Linux ls3016 2.4.0-test7 #1 SMP Thu Aug 31 15:12:24 CEST 2000 i686 unknown # ipcs -ml -- Shared Memory Limits max number of segments = 4096 max seg size (kbytes) = 1048576 max total shared memory (kbytes) = 1224 min seg size (bytes) = 0 # cat /proc/sys/kernel/shmmax 1073741824 # ./ipctst 1 1073741824 1 0 100 using 1 segs of size 1073741824 (1 iterations) # ./ipctst 1 1073741825 1 0 100 using 1 segs of size 1073741825 (1 iterations) shmget (0x1): Invalid argument So this seems to work. > besides, what does the output of df on /dev/shm show me ? the amount > of max shared mem in bytes or kbytes like the other fs ? Yes, it does. You can increase the maximum overall size with mount option nr_blocks (in 4K blocks on ia32) and the maximum number of objects with nr_inodes. from ipc/shm.c: * There are the following mount options: * - nr_blocks (^= shmall) is the number of blocks of size PAGE_SIZE * we are allowed to allocate * - nr_inodes (^= shmmni) is the number of files we are allowed to * allocate * - mode is the mode for the root directory (default S_IRWXUGO | S_ISVTX) Greetings Christoph - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Reserving a (large) memory block
** Reply to message from Ingo Molnar <[EMAIL PROTECTED]> on Thu, 31 Aug 2000 14:09:48 +0200 (CEST) > in 2.4 there is an explicit interface for this that also guarantees that > the allocation consists of fully valid RAM (no matter how complex the RAM > map): alloc_bootmem(). We allocate 300MB+ worth of mem_map[] with this on > multi-gigabyte boxes. Could you explain this API in more detail, I'm having a hard time following the code. Can this API be called by drivers at any time? I don't see how this API is different than a normal kmalloc(). -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com When replying to a mailing-list message, please don't cc: me, because then I'll just get two copies of the same message. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
NWFS sb->s_blocksize issues
Why was it necessary to interlock the blocksize reported by a file system with the superblock with the page cache and the ll_rw_block() interface? I've gotten to the bottom of the bmap() problem with using a 1024/2048/4096 blocksize and the problem is related to the way the page cache asks for pages. NWFS will suballocate files < volume blocksize (4K,8K,16K,32K,64K). These suballocated file runs are not always block aligned which results in the page cache getting partial or scattered runs. The page cache always seems to assume that the blocks for a page will conform to the sb->s_blocksize value (which is ok), however, what's stilted about this model is that the underlying logic in ll_rw_block() will enforce buffer head reads to this blocksize value. My benchmarking shows best performance on Linux at 1024 blocksize settings (drivers seems optimized to this case). I have found that if I define sb->s_blocksize to a certain value, buffer heads get rejected if I attempt other values because set_blocksize() fails if the superblock value does not match. I can completely get around this problem by setting everything to a blocksize of 512, and using buffer heads set to this blocksize, however, this eats up more memory and creates more overhead in the ll_rw_block() code since it has to merge all these requests, plus there's the overhead of allocating tons of buffer heads for all the 512 blocks. It also increases (oink) the bmap() interative calling to map a file since smaller blocksizes result in more calls through the page cache interface. I guess what I am asking is why does there need to be a correlation beween page cache superblock size and an artificial enforement underneath in ll_rw_block() to force block I/O operations to be the same. One would think that ideally, I/O requests would allow variable length sector operations up to any size, and a config option to allow the page cache to bmap() sizes independently of I/O requests to the disks. I can get around what's there, but it's wasteful of memory and runs slower. This is probably a Linus issue. Please Advise, Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
