Re: Intellimouse in 2.4.5-ac7
Robert Love <[EMAIL PROTECTED]> wrote: >i am running ac7 right now (and was running ac6 with the patch) and my >IntelliMouse works fine. SOmetimes my laptop doesn't see my intellithingy as well (ac5) Reconnecting the mouse helpes to force recognising it. Mayby the same with ac6 ? Danny -- Holland Hosting www.hoho.nl [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.5-ac7 fix for rivers/net/wireless/Config.in problem
I got the following error from make xconfig: drivers/net/wireless/Config.in: 5: can't handle dep_bool/dep_mbool/dep_tristate condition make[1]: *** [kconfig.tk] Error 1 Here is a little micro patch to change the dep_tristate into a plain vanilla tristate. Steven --- linux/drivers/net/wireless/Config.in.ac7Sat Jun 2 21:27:18 2001 +++ linux/drivers/net/wireless/Config.inSat Jun 2 21:32:59 2001 @@ -2,7 +2,7 @@ # Wireless LAN device configuration # -dep_tristate ' Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards' CONFIG_AIRO + tristate ' Cisco/Aironet 34X/35X/4500/4800 ISA and PCI cards' CONFIG_AIRO if [ "$CONFIG_ALL_PPC" = "y" ]; then tristate ' Apple Airport support (built-in)' CONFIG_APPLE_AIRPORT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: keyboard hook?
Hi! Your best bet for a kernel driver is to use the linux input api like the usb keyboard do. The drivers are pretty simple to write and since all the keyboard drivers will be port over to this api it will save a lot of work done the road. If you need help let me know. I will be glad to help. It sounds alot alike the p2 to serial driver just placed in our CVS. You can access our CVS by doing cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/linuxconsole login cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/linuxconsole co ruby The driver is in ruby/linux/drivers/input as ps2serkbd.c. > I'm beginning the process of writing a driver for the "Qoder" > keyboard-fob barcode scanner made by InterMec. It communicates with the > host computer using the PS/2 port by way of a "dock" that sits in > between the keyboard and the computer. > One of them is "turn > numlock light on," which I can do with an ioctl from userspace (as root, > anyway), but also caps lock, num lock and carriage-return scancodes. EV_LED > The CueCat driver written by Pierre Coupard also modifies the keyboard > driver. It would be nice if it was possible to load modules that hook > into keyboard processing without requiring a kernel patch. And perhaps > there is, but I haven't run across it yet. input api :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
On Sat, Jun 02, 2001 at 10:47:49PM -0400, John Chris Wren wrote:
> I would have said just the opposite. That if it you have a large number of
> handles you're waiting on, and you have to go back through and set the bits
> everytime you timeout that you would incur a larger overhead. From the
Use a temp fd_set and assignment.
fd_set readset;
readset=set_to_watch
select(n, readset, NULL, NULL, timeout);
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: select() - Linux vs. BSD
> > [EMAIL PROTECTED] wrote: > > Of course, not looking at the sets upon a zero return is a > fairly obvious > > optimization as there is little point in doing so. > > No; a fairly obvious optimisation is to avoid calling FD_ZERO if you > can clear the bits individually when you test them. > > When you examine the sets, you can clear each bit that you examine and > then you know you have a zero set. Then you can set only the relevant > bits for the next call to select(). > > If you can't rely on the sets being cleared on a timeout, then you > will have to call FD_ZERO in that case, or you will have to go through > the list of descriptors and clear them individually. (This can be > avoided but it means keeping track of state between successive calls > to select()). This is contrary to the non-timeout case, where you > stop checking bits when you have counted N of them set. > > So you see, there is a handy optimisation if you can assume the sets > are zeroed on timeout. > I would have said just the opposite. That if it you have a large number of handles you're waiting on, and you have to go back through and set the bits everytime you timeout that you would incur a larger overhead. From the perspective of my application, it would have been more efficient to not zero them (I was waiting on a number of serial channels, and the timeout was used to periodically pump more data to the serial channel. When I received data, I buffered it, and another thread took care of processing it). It all really depends on the coding style of your program, and what you need to do on a timeout. Certain types of applications would benefit from non-zero'ing, others from zeroing. All what is *most* important is that the behavior is clearly understood and well documented. A google search made it pretty clear that it was a source of confusion. --John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: USB mouse problem
Yes I do have the same problem in console using gpm, and there is not yet a kernel update from redhat yet. I thought it was a kernel problem originally because I saw all these messages to this list about usb mouse problems. > On 02 Jun 2001 21:22:46 -0400, Hayden A. James wrote: > > This is a followup to my last e-mail, here is some information about my > > mouse/usb setup from dmesg. > is the mouse jerky on the console (using the mouse via GPM)? > i ask because i wager the bug is not a kernel bug but perhaps something > wrong with your X server/configuration. i dont think there is any known > problem with the RedHat kernel, which is fairly well tested. is there > an update for it? since this may not be a kernel bug, you may find > better help in a RedHat or similar forum. > you could always compile your own kernel and see if that alleviates the > problem :) > > -- > Robert M. Love > [EMAIL PROTECTED] > [EMAIL PROTECTED] Hayden A. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intellimouse in 2.4.5-ac7
I don't know what is the problem but the kernel doesn't report the IRQ of the UHCI.So no mouse.Maybe something wrong with the config?Please help. I have included dmesg. Linux version 2.4.5-ac7 (root@Santorini) (gcc version 2.95.3 20010315 (release)) #1 Êõñ Éïýí 3 02:59:47 EEST 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0ffec000 (usable) BIOS-e820: 0ffec000 - 0ffef000 (ACPI data) BIOS-e820: 0ffef000 - 0000 (reserved) BIOS-e820: 0000 - 1000 (ACPI NVS) BIOS-e820: - 0001 (reserved) On node 0 totalpages: 65516 zone(0): 4096 pages. zone(1): 61420 pages. zone(2): 0 pages. Local APIC disabled by BIOS -- reenabling. Found and enabled local APIC! Kernel command line: auto BOOT_IMAGE=try ro root=304 BOOT_FILE=/boot/vmlinuz.try parport=0x378,7,3 video=matrox:vesa:0x11A,fh:85,fv:80 Initializing CPU#0 Detected 609.046 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1215.69 BogoMIPS Memory: 254868k/262064k available (1433k kernel code, 6808k reserved, 453k data, 220k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 0183fbff c1c3fbff , vendor = 2 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 512K (64 bytes/line) CPU: After vendor init, caps: 0183fbff c1c3fbff CPU: After generic, caps: 0183fbff c1c3fbff CPU: Common caps: 0183fbff c1c3fbff CPU: AMD Athlon(tm) Processor stepping 01 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: Using local APIC timer interrupts. calibrating APIC timer ... . CPU clock speed is 609.0596 MHz. . host bus clock speed is 203.0200 MHz. cpu: 0, clocks: 2030200, slice: 1015100 CPU0 mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf1010, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:04.0 PCI: Disabling Via external APIC routing isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found PnP: PNP BIOS installation structure at 0xc00fc2b0 PnP: PNP BIOS version 1.0, entry at f:c2e0, dseg at f Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 IA-32 Microcode Update Driver: v1.08 <[EMAIL PROTECTED]> apm: BIOS version 1.2 Flags 0x03 (Driver version 1.14) Starting kswapd v1.8 udf: registering filesystem 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 8 0x378: readIntrThreshold is 8 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x10 cfgB=0x00 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] parport0: cpp_daisy: aa5500ff(00) parport0: assign_addrs: aa5500ff(00) parport0: cpp_daisy: aa5500ff(00) parport0: assign_addrs: aa5500ff(00) i2c-core.o: i2c core module i2c-dev.o: i2c /dev entries driver module i2c-core.o: driver i2c-dev dummy driver registered. i2c-algo-bit.o: i2c bit algorithm module matroxfb: Matrox Millennium G400 MAX (AGP) detected matroxfb: MTRR's turned on matroxfb: 1280x1024x16bpp (virtual: 1280x6552) matroxfb: framebuffer at 0xDE00, mapped to 0xd0805000, size 33554432 Console: switching to colour frame buffer device 160x64 fb0: MATROX VGA frame buffer device pty: 256 Unix98 ptys configured lp0: using parport0 (interrupt-driven). Serial driver version 5.05b (2001-05-03) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A block: queued sectors max/low 169258kB/56419kB, 512 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 21 VP_IDE: chipset revision 16 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c686a (rev 21) IDE UDMA66 controller on pci00:04.1 ide0: BM-DMA at 0xd800-0xd807, BIOS settings:
Re: select() - Linux vs. BSD
On Sat, 2 Jun 2001, Jamie Lokier wrote: > [EMAIL PROTECTED] wrote: > > Of course, not looking at the sets upon a zero return is a fairly obvious > > optimization as there is little point in doing so. > > No; a fairly obvious optimisation is to avoid calling FD_ZERO if you > can clear the bits individually when you test them. That would make sense. HOWEVER, you took my comment out of context. I had pointed out that since the zero return from select() is not an error condition, you can rely on the sets being zeroed out. The zero simply indicates that no descriptors had anything interesting occur and if the sets are not zeroed, the implementation is broken. Upon error, the values are undefined and the value of timeout is undefined. (In this case, doing nothing upon a zero return from select() is perfectly reasonable.) If I recall, the original posting was about whether the sets were zeroed upon an error condition which a timeout is not defined as in this case. William Astle finger [EMAIL PROTECTED] for further information Geek Code V3.12: GCS/M/S d- s+:+ !a C++ UL$ P++ L+++ !E W++ !N w--- !O !M PS PE V-- Y+ PGP t+@ 5++ X !R tv+@ b+++@ !DI D? G e++ h+ y? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LVM status in ac7?
Hi, What is the status of LVM in ac7? Is it safe to use the ac7 LVM code on a system currently using beta7? Is the beta7 patched needed with ac7? What is not in the ac7 patches? Is it apt to cause problems? TIA, Ed Tomlinson <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB mouse problem
On 02 Jun 2001 21:22:46 -0400, Hayden A. James wrote: > This is a followup to my last e-mail, here is some information about my > mouse/usb setup from dmesg. is the mouse jerky on the console (using the mouse via GPM)? i ask because i wager the bug is not a kernel bug but perhaps something wrong with your X server/configuration. i dont think there is any known problem with the RedHat kernel, which is fairly well tested. is there an update for it? since this may not be a kernel bug, you may find better help in a RedHat or similar forum. you could always compile your own kernel and see if that alleviates the problem :) -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
USB mouse problem
I have a clean redhat 7.1 installation using the standard redhat kernel (2.4.2-2) and I seem to have jerkiness with my mouse in X. When I move the mouse around in X, the mouse sometimes randomly changes the mouse pointer position. My mouse is a Logitech Mouseman optical usb. Hayden A. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB mouse problem
This is a followup to my last e-mail, here is some information about my mouse/usb setup from dmesg. usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-uhci.c: $Revision: 1.251 $ time 20:53:29 Apr 8 2001 usb-uhci.c: High bandwidth mode enabled PCI: Found IRQ 4 for device 00:04.2 PCI: The same IRQ used for device 00:09.0 PCI: The same IRQ used for device 00:09.1 PCI: The same IRQ used for device 00:0d.0 usb-uhci.c: USB UHCI at I/O 0xb400, IRQ 4 usb-uhci.c: Detected 2 ports usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected hub.c: USB new device connect on bus1/2, assigned device number 2 usb.c: USB device 2 (vend/prod 0x46d/0xc00b) is not claimed by any active driver. usb.c: registered new driver hid input0: USB HID v1.10 Mouse [Logitech USB Mouse] on usb1:2.0 mouse0: PS/2 mouse device for input0 mice: PS/2 mouse device common for all mice I am using /dev/mouse which is a symlink to /dev/input/mice. crw---1 root root 13, 63 Mar 23 23:37 /dev/input/mice Hayden A. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intellimouse in 2.4.5-ac7
I'm using yhe Intellimouse as USB over ac7 and the problems that I had with the previous HID seems to be solved. No problems reported for now. On Sun, 3 Jun 2001, mythos wrote: > > Using kernel 2.4.5-ac7 my intelli is not working at all. > The kernel doesn't report that it has found it.My config is the same > with the previous kernel I used 2.4.5-ac2. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Fabian Arias Mu~oz | Debian GNU/Linux Woody Facultad de Cs. Economicas y | Kernel 2.4.5ac7 - ReiserFS Administrativas. | "aka" dewback en Universidad de Concepcion - Chile | #linuxhelp IRC.CHILE - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
Alexander Viro wrote: > I can see how to implement per-mountpoint variant. However, I'm > less than enthusiastic about the API side of that and about the > ugliness it will lead to. It smells like a wrong approach. And > no, I don't see a good one right now. Aren't we one day going to have stackable filesystems? This looks like an idea for a trivial translation filesystem to me. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Intellimouse in 2.4.5-ac7
On 03 Jun 2001 03:34:14 +0300, mythos wrote: > Using kernel 2.4.5-ac7 my intelli is not working at all. > The kernel doesn't report that it has found it.My config is the same > with the previous kernel I used 2.4.5-ac2. can you test it with ac6? ac7 incorpates an incredibly simple patch to fix poor scrolling in ac4-ac6. i cant see how this could break anything. i am running ac7 right now (and was running ac6 with the patch) and my IntelliMouse works fine. I am using the USB HID driver, not the limited mouse-only driver. [20:48:33]rml@phantasy:~# uname -a Linux phantasy 2.4.5-ac7 #1 Sat Jun 2 19:38:20 EDT 2001 i686 unknown [20:49:43]rml@phantasy:~# grep Intelli /var/log/dmesg input0: USB HID v1.00 Mouse [Microsoft Microsoft IntelliMouse® Explorer] on usb1:2.0 maybe we should stop using microsoft products? :) -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote: > This evening I needed to work on a filesystem of a non-Linux OS, > full of absolute symlinks. After mounting the fs on /mnt, each > symlink pointing to /foo/bar in that filesystem should be > regarded as pointing to /mnt/foo/bar. > > Since doing ls -ld on every component of every pathname was > far too slow, I made a small kernel wart, where a mount option > -o symlink_prefix=/pathname would cause /pathname to be prepended > in front of every absolute symlink in the given filesystem > (when the symlink is followed). That works satisfactorily. > > Remain the questions: > (i) is there already a mechanism that would achieve this? > (ii) if not, do we want something like this in the kernel? > > There is already a vaguely similar (and much uglier) wart, > namely that of "altroot". It is really ugly - requires a path > set at kernel compile time. And the scope is different. > Instead of all processes and a single filesystem and symlinks only, > altroot affects a single process and all filesystems and all paths. > > I do not immediately see a common generalization of these two. altroot should be buried, not generalized. It was a mistake and we will be better off forgetting about that nightmare instead of trying to design something around it. Absolute symlinks... Dunno. _If_ we want that at all, we probably want it on per-mountpoint basis. However, that opens a door to _really_ ugly feature requests. E.g. "if symlink starts with /foo - replace it with /mnt/bar, but if it starts with /foo/baz - replace with /mnt/splat instead". I can see how to implement per-mountpoint variant. However, I'm less than enthusiastic about the API side of that and about the ugliness it will lead to. It smells like a wrong approach. And no, I don't see a good one right now. As for the API... How would you pass that option? Yet another mount(2) argument? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Intellimouse in 2.4.5-ac7
Using kernel 2.4.5-ac7 my intelli is not working at all. The kernel doesn't report that it has found it.My config is the same with the previous kernel I used 2.4.5-ac2. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bug in load_elf_binary [PATCH]
In kernel 2.4.3 and 2.2.18, there is a bug in fs/binfmt_elf.c function load_elf_binary(). An ET_DYN file that asks for a PT_INTERP, and whose first PT_LOAD is not at 0, gets AT_PHDR that is (load_bias + 2 * p_vaddr), instead of the correct (load_bias + p_vaddr). The patch for 2.4.3 is --- fs/OLDbinfmt_elf.c Mon Mar 19 17:05:16 2001 +++ fs/binfmt_elf.c Sat Jun 2 16:20:54 2001 @@ -632,5 +632,5 @@ load_bias += error - ELF_PAGESTART(load_bias + vaddr); - load_addr += error; + load_addr += load_bias; } } = Please cc: me if appropriate; I'm not subscribed. To demonstrate the problem on i386: cat >foo.s
Re: symlink_prefix
On 03 Jun 2001 01:54:43 +0200, [EMAIL PROTECTED] wrote: > This evening I needed to work on a filesystem of a non-Linux OS, > full of absolute symlinks. After mounting the fs on /mnt, each > symlink pointing to /foo/bar in that filesystem should be > regarded as pointing to /mnt/foo/bar. > > Since doing ls -ld on every component of every pathname was > far too slow, I made a small kernel wart, where a mount option > -o symlink_prefix=/pathname would cause /pathname to be prepended > in front of every absolute symlink in the given filesystem > (when the symlink is followed). That works satisfactorily. unfortunately i cant speak for whether or not this patch is reengineering the work of altroot (i have no experience with it) or whether there are other similar approaches. what i can say is that this is an excellent idea -- i have often cursed having absolute symlinsk v. relative ones and this option would provide a wonderful fix to that. plus, i bet this is a rather simple and clean option. i would like to see this in the kernel if it does not tread on any other similar feature. > (i) is there already a mechanism that would achieve this? cant answer > (ii) if not, do we want something like this in the kernel? for sure. -- Robert M. Love [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] [UPDATE] Directory index for ext2
On Thursday 31 May 2001 21:44, Andreas Dilger wrote: > I noticed something interesting when running "mongo" with debugging > on. It is adding filenames which are only sequential numbers, and the > hash code is basically adding to only two blocks until those blocks > are full, at which point (I guess) the blocks split and we add to two > other blocks. > > I haven't looked at it closely, but for _example_ it something like: > > 65531 to block 113 > 65532 to block 51 > 65533 to block 51 > 65534 to block 113 > 65535 to block 113 > (repeats) > 65600 to block 21 > 65601 to block 96 > 65602 to block 96 > 65603 to block 21 > 65604 to block 21 > (repeats) > > I will have to recompile and run with debugging on again to get > actual output. > > To me this would _seem_ bad, as it indicates the hash is not > uniformly distributing the files across the hash space. However, > skewed hashing may not necessarily be the bad for performance. It > may even be that because we never have to rebalance the hash index > structure that as long as we don't get large numbers of identical > hashes it is just fine if similar filenames produce similar hash > values. We just keep splitting the leaf blocks until the hash moves > over to a different "range". For a balanced tree-based structure a > skewed hash would be bad, because you would have to do full-tree > rebalancing very often then. A skewed hash doesn't hurt the fixed-depth tree in the obvious way - it just tends to leave a lot of half-full buckets around, which wastes about 1/3 of the leaf space. The reason for this behaviour is, when you create a lot of sequentially-related names a skewed hash will tend to dump a lot them into a tiny sliver of the hash space, and after splitting the little sliver it's quite unlikely that later entries will hit the same small range. The only good protection against this is to make the hash function vary wildly if even one bit in the string changes. This is what crc does, and that's why I'm interested in it. I've rehabilitated the hack_show_dir code, which is enabled by #defining DX_HACK. To kprint a dump of hash buckets and statistics do: cat /test_partition/indexed_dir This dump is extremely helpful in judging the effectiveness of hash functions, just take a look at how the range of hash values that gets mapped into each leaf block. Ideally, there should not be too much variance. The format of the dump is: bucketnumber:blocknumber hashstart/range (entrycount) Yusuf Goolamabbas sent me a pointer to some new work on hash functions: http://www.isthe.com/chongo/tech/comp/fnv/ I coded up the fnv_hash and included it in today's patch - there is a define to select which to use; dx_hack_hash is still the default. fnv_hash is only a little wose than dx_hack_hash, which still produces the most uniform distribution of all the hash functions I've tested. But I can see from the dumps that it's still not optimal, it's just that all the others are worse. I still have quite a few leads to follow up on the hashing question. Next week I hope I'll get time to try crc32 as a hashing function. I hope it doesn't win because I'll need a 1K table to evaluate it, and that would be 20% of the whole code size. The patch: http://nl.linux.org/~phillips/htree/dx.pcache-2.4.5-2 -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
symlink_prefix
This evening I needed to work on a filesystem of a non-Linux OS, full of absolute symlinks. After mounting the fs on /mnt, each symlink pointing to /foo/bar in that filesystem should be regarded as pointing to /mnt/foo/bar. Since doing ls -ld on every component of every pathname was far too slow, I made a small kernel wart, where a mount option -o symlink_prefix=/pathname would cause /pathname to be prepended in front of every absolute symlink in the given filesystem (when the symlink is followed). That works satisfactorily. Remain the questions: (i) is there already a mechanism that would achieve this? (ii) if not, do we want something like this in the kernel? There is already a vaguely similar (and much uglier) wart, namely that of "altroot". It is really ugly - requires a path set at kernel compile time. And the scope is different. Instead of all processes and a single filesystem and symlinks only, altroot affects a single process and all filesystems and all paths. I do not immediately see a common generalization of these two. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is a kernel panic supposed to happen if root fs is on a SCSIdisk and SCSI support is compiled in as module?
At 12:17 am +0100 3/6/2001, M.N. wrote: >Basically, that's the question. I compiled my kernel with the SCSI AIC7xxx.o >driver as a module, and then when it booted up, it paniced. I thought it was >some sort of a kernel bug, but it didn't really seem that way when I >recompiled the kernel with SCSI support built-in in the kernel itself >(monolithically). I'm just curious, does a _panic_ necessarily mean that >the kernel needs fixing, or can a panic be a result of something that the >user forgot to do which was required in order to avoid that panic? A kernel panic happens whenever it finds itself in a situation which is impossible or impractical to fix. In your case, it needed the SCSI module in order to load the root FS. But the SCSI module is itself located on the root FS. Catch 22, so panic. If you'd read the module documentation, you'd have known about this beforehand, but chalk this up to experience (aka. RTFM!). So, a kernel panic usually means it's a configuration error OR hardware failure OR (rarely) a kernel bug. Most often, kernel bugs are marked by an OOPS or BUG message splashing all over the console and the system log. HTH, -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) -END GEEK CODE BLOCK- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac7
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac7 o UML cleanups(Jeff Dike) o Trap invalid addresses in UML ethernet driver (Jeff Dike) o Reimplment UML user space access(Jeff Dike) o Add device node support to hostfs (Jorgen Cederlof) o Fix hang if the UML net helper fails to run (Jeff Dike) o Support setting time in UML kernels (Livio Baldini Soares) o Move more non portable code out of UML core (Jeff Dike) o Merge most of remaining UML ppc changes (Chris Emerson) o Printk cleanups, remove one non portable(James Stevenson) o Add speaker mixer support to the cmpci mixer(Carlos Gorges) o Fix inittdata ordering in i2c docs (Andrzej Krzysztofowicz) o Add usb skeleton driver (Greg Kroah-Hartmann) o Fix ns558 unload(Marcus Meissner) o Further cs46xx fixing (Frank Davies) o S/390 updates from the IBM folks(Martin Schwidefsky) o CS46xx pop/crackle fixes on IBM T20 (Thomas Woller) o Make USB require PCI(me) o Tulip driver update (Jeff Garzik) o Fix slip/slhc missing symbols problem (Michael Guntsche) o IRDA updates(Dag Brattli) o Add cs4232 isapnp probing (Marcus Meissner) o Merge airo_cs driver(Benjamin Reed, Javier Achirica, Jean Tourrilhes) o VIA workarounds for APIC IRQ routing(Jeff Garzik) o Fix bootmem.c comment cut accident(Richard Urena) o Update LVM with new VG_CREATE ioctl (and(Joe Thornber) VG_CREATE_OLD for back compatibility) o Fix pv_t/lv_t confusion in lv_status_bydev_req (Joe Thornber) o Lots of update/fixes for _lv_status_by* code(Joe Thornber) o Add support for I2O IOP's requiring private (me) resource spaces o Hopefully fix hid jerkiness (Michael) 2.4.5-ac6 o Fix the cs46xx right this time (me) o Further FATfs cleanup (OGAWA Hirofumi) o ISDN PPP code cleanup, cvs tag update (Kai Germaschewski) o Large amount of UFS file system cleanup (Al Viro) o Fix endianness problems in FATfs(Petr Vandrovec) o Fix -ac quota crashes (Jan Kara) o Fix bluetooth out of memory handling(Greg Kroah-Hartmann) o Fix freevxfs readdir(Christoph Hellwig) o Fix freevxfs sign/unsigned issues (Christoph Hellwig) o Fix doctypos, other freevxfs cleanup(Christoph Hellwig) o Fix flush_dirty_buffers warning (J A Magallon) o Add Carlos Gorges to credits(Carlos Gorges) o Further atm cleanup fixes (kmalloc/signedness) (Mitchell Blank) o Fix hotplug variable in matroxfb(Petr Vandrovec) o Fix ns558 crash (Vojtech Pavlik) o Revert to Pete Zaitcev's khub locking (Pete Zaitcev) | It works for me, Johannes changes don't seem to o Fix usb Config.in breakage for input devices(Vojtech Pavlik) o Add another 3c509 ISAPnP id (Marcus Meissner) o Fix oopses and null checks on iphase(Mitchell Blank) o CS46xx update (Thomas Woller) o Fix mmap cornercase (Maciej Rozycki) o Tidy up aironet and saa9730 delay abuse(Andrzej Krzysztofowicz) o Force initial umask to be sane for broken (Andrew Tridgell) init programs o Teach CML1 to strip out from the (Eric Raymond) Configure.help o Resync with Eric's master Configure.help(Eric Raymond) o Revert FIOQSIZE o Fix missing copy_*_user in cosa driver (me) | From Stanford tools o Fix missing copy_*_user in eicon(me) + clean up ioctls a bit more | From Stanford tools o Fix use after free in lpbether (me) | From Stanford tools o Fix missing return in rose_dev (me) | From Stanford tools o Fix use after free in
is a kernel panic supposed to happen if root fs is on a SCSI disk and SCSI support is compiled in as module?
Basically, that's the question. I compiled my kernel with the SCSI AIC7xxx.o driver as a module, and then when it booted up, it paniced. I thought it was some sort of a kernel bug, but it didn't really seem that way when I recompiled the kernel with SCSI support built-in in the kernel itself (monolithically). I'm just curious, does a _panic_ necessarily mean that the kernel needs fixing, or can a panic be a result of something that the user forgot to do which was required in order to avoid that panic? Thanks. Martin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SCSI errors using USB mass storage device
Hello, I'm running unmodified 2.4.5 on a Red Hat 7.1 system and have an IBM DiskOnKey (a USB not-so-mass storage device). When mounting the device, the SCSI layer responds with the error: SCSI error: host 1 id 0 lun 0 return code = 802 Sense class 7, sense error 0, extended sense 0 The device seems to work fine, and I have experienced no data corruption or other problems. I was wondering what the cause of this error was and if it should be taken as a warning of potential data loss. Thanks, Ryan Mack - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing sysrq
On Sat, Jun 02, 2001 at 03:10:55PM -0700, H. Peter Anvin wrote: > That seems like a very bad idea. What if there is a boot script bug? Also think about kernel panics - the only thing that works after that is the power or (if you have it connected) reset button. ctrl-alt-del needs keventd to work, and since sysrq-b is disabled by default... However, IMHO that is a non-point because you need to be physically at the system either way to solve the problem. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing sysrq
Russell King wrote: > > On Sat, Jun 02, 2001 at 03:10:55PM -0700, H. Peter Anvin wrote: > > That seems like a very bad idea. What if there is a boot script bug? > > Also think about kernel panics - the only thing that works after that > is the power or (if you have it connected) reset button. ctrl-alt-del > needs keventd to work, and since sysrq-b is disabled by default... > > However, IMHO that is a non-point because you need to be physically > at the system either way to solve the problem. > Not true if you have a serial console (and SysRq over serial console happens to work correctly that day.) Assuming this change is corrected to be sane. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] HPT370 misc (for real this time)
+ p += sprintf(p, "\nController: %d\n", i); + p += sprintf(p, "Chipset: HPT%s\n", chipset_nums[class_rev]); + p += sprintf(p, "Bus speed: %d MHz\n", dev->bus->bus_speed); ^^^ DNE -- Does Not Exist + p += sprintf(p, "--- Primary Channel " + "--- Secondary Channel " + "--\n"); + Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [newbie] NFS client: port-unreachable
> " " == Roland Kuhn <[EMAIL PROTECTED]> writes: > No, I have no port specific rules in the firewall (iptables), > but this machine does SNAT for 32 other linux boxes which also > get some directories from the same server (including YP). I had > some trouble with the YPSERV-calls until I bound two more IPs > to the network card and masqueraded the 32 boxes via these > additional addresses. What might happen is that the specific > port gets allocated by some port remapping in iptables during > the request, but I don't see why this should happen only for > specific directories (e.g. /home works and /compass doesn't > while both are from the same server). Are /home and /compass on the same mount point on the client though? If not, then they won't share the same port. IOW: they will only share the same port if you have '/' as the NFS mountpoint. Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing sysrq
Russell King wrote: > > On Fri, Jun 01, 2001 at 04:13:02PM -0700, H. Peter Anvin wrote: > > Let me guess... you're using a RedHat system? RedHat, for some > > idiotic reason, defaults to actively turning this off for you (and > > they turn Stop-A off on SPARC, too.) > > Umm, its off by default in 2.4.5 kernels, unless altered by a > distributions boot scripts. > That seems like a very bad idea. What if there is a boot script bug? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.4.5-ac6: hid-core.c Mouse Wheel Fix
since the merging of the new USB HID code (hid.c -> hid-core.c) in ac4,
the mouse wheel has been broken (losing events).
this patch, by Micheal <[EMAIL PROTECTED]>, fixes the problem.
Alan, please consider applying to the next -ac release.
thanks,
--
Robert M. Love
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--- linux.vanilla/drivers/usb/hid-core.cSat Jun 2 21:47:35 2001
+++ linux/drivers/usb/hid-core.cSat Jun 2 21:46:00 2001
@@ -773,10 +773,11 @@
if (HID_MAIN_ITEM_VARIABLE & field->flags) {
- if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n])
- continue;
- if (value[n] == field->value[n])
- continue;
+ if (field->flags & HID_MAIN_ITEM_RELATIVE) {
+ if (!value[n]) continue;
+ } else {
+ if (value[n] == field->value[n]) continue;
+ }
hid_process_event(hid, field, >usage[n], value[n]);
continue;
}
Re: missing sysrq
On Fri, Jun 01, 2001 at 04:13:02PM -0700, H. Peter Anvin wrote: > Let me guess... you're using a RedHat system? RedHat, for some > idiotic reason, defaults to actively turning this off for you (and > they turn Stop-A off on SPARC, too.) Umm, its off by default in 2.4.5 kernels, unless altered by a distributions boot scripts. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 2.4.5.ac6: more Via irq fixes
Hi, In case you didn't know, the patch doesn't solve interrup conflicts on VIA Apollo MVP3 chipsets. Box runs fine though. Regards, Koos Vriezen Some outputs: $ cat /proc/interrupts CPU0 0: 482219 XT-PIC timer 1: 2771 XT-PIC keyboard 2: 0 XT-PIC cascade 5: 3158 XT-PIC soundblaster 9: 53 XT-PIC bttv 10: 2276 XT-PIC eth0 12: 48097 XT-PIC PS/2 Mouse 14: 18781 XT-PIC ide0 15: 2 XT-PIC ide1 NMI: 0 ERR: 0 $ dmesg Linux version 2.4.5-ac6 (root@xwing) (gcc version 2.95.3 20010315 (release)) #4 Sat Jun 2 22:31:38 CEST 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0c00 (usable) BIOS-e820: - 0001 (reserved) On node 0 totalpages: 49152 zone(0): 4096 pages. zone(1): 45056 pages. zone(2): 0 pages. Kernel command line: BOOT_IMAGE=linux ro root=301 Initializing CPU#0 Detected 298.822 MHz processor. Console: colour VGA+ 132x60 Calibrating delay loop... 596.37 BogoMIPS Memory: 191448k/196608k available (844k kernel code, 4772k reserved, 200k data, 192k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 008001bf 808009bf , vendor = 2 CPU: L1 I Cache: 32K (32 bytes/line), D cache 32K (32 bytes/line) CPU: After vendor init, caps: 008001bf 808009bf CPU: After generic, caps: 008001bf 808009bf CPU: Common caps: 008001bf 808009bf CPU: AMD-K6(tm) 3D processor stepping 00 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xfb290, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router VIA [1106/0586] at 00:07.0 Activating ISA DMA hang workarounds. isapnp: Scanning for PnP cards... isapnp: Calling quirk for 01:00 isapnp: SB audio device quirk - increasing port range isapnp: Calling quirk for 01:02 isapnp: AWE32 quirk - adding two ports isapnp: Card 'Creative SB AWE64 PnP' isapnp: 1 Plug & Play card detected total PnP: PNP BIOS installation structure at 0xc00fbe40 PnP: PNP BIOS version 1.0, entry at f:be68, dseg at f Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd v1.8 pty: 256 Unix98 ptys configured block: queued sectors max/low 127061kB/42353kB, 384 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: VIA vt82c586b (rev 41) IDE UDMA33 controller on pci00:07.1 ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:DMA hda: QUANTUM FIREBALL EX6.4A, ATA DISK drive hdc: CD-ROM 36X/AKU, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 12594960 sectors (6449 MB) w/418KiB Cache, CHS=784/255/63, UDMA(33) Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 > NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 2048 buckets, 16Kbytes TCP: Hash tables configured (established 16384 bind 16384) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 192k freed reiserfs: checking transaction log (device 03:03) ... Using r5 hash to sort names ReiserFS version 3.6.25 reiserfs: checking transaction log (device 03:07) ... Using r5 hash to sort names ReiserFS version 3.6.25 Serial driver version 5.05b (2001-05-03) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A lirc_serial: auto-detected active low receiver ne2k-pci.c:v1.02 10/19/2000 D. Becker/P. Gortmaker http://www.scyld.com/network/ne2k-pci.html PCI: Assigned IRQ 10 for device 00:08.0 eth0: RealTek RTL-8029 found at 0xe800, IRQ 10, 00:40:05:6B:CF:E0. apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14) parport0: PC-style at 0x378 [PCSPP(,...)] lp0: using parport0 (polling). Serial driver version 5.05b (2001-05-03) with MANY_PORTS SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS01 at 0x02f8 (irq = 3) is a 16550A Linux video capture interface: v1.00
[PATCH] balance inactive_dirty list
For a long time I've been thinking that inactive list is too small,
while observing lots of different workloads (all I/O bound). Finally,
I decided to take a look and try to improve things. In mm/vmscan.c I
found this overly complicated piece of heuristics:
if (!target) {
int inactive = nr_free_pages() + nr_inactive_clean_pages() +
nr_inactive_dirty_pages;
int active = MAX(nr_active_pages, num_physpages / 2);
if (active > 10 * inactive)
maxscan = nr_active_pages >> 4;
else if (active > 3 * inactive)
maxscan = nr_active_pages >> 8;
else
return 0;
}
We're trying to be too clever there, and that eventually hurts
performance because inactive_dirty list is too small for typical
scenarios. Especially that 'return 0' is hurting us, as it effectively
stops background scan, so too many pages stay active without the real
need.
With patch below performance is much better under lots of workloads I
have tested. The patch simplifies code a lot and removes unnecessary
complex calculation. Code is now completely autotuning. I have a
modified xmem utility that shows the state of the lists in a graphical
manner, so it's easy to see what's going on. Things look much more
smooth now.
I think I've seen Mike Galbraith (on the list) trying to solve almost
the same problem, although in a slightly different way. Mike, could
you give this patch a try.
All comments welcome, of course. :)
Index: 5.2/mm/vmscan.c
--- 5.2/mm/vmscan.c Sat, 26 May 2001 20:44:49 +0200 zcalusic (linux24/j/9_vmscan.c
1.1.7.1.1.1.2.1.1.1 644)
+++ 5.2(w)/mm/vmscan.c Sat, 02 Jun 2001 23:25:40 +0200 zcalusic (linux24/j/9_vmscan.c
+1.1.7.1.1.1.2.1.1.1 644)
@@ -655,24 +655,10 @@
/*
* When we are background aging, we try to increase the page aging
-* information in the system. When we have too many inactive pages
-* we don't do background aging since having all pages on the
-* inactive list decreases aging information.
-*
-* Since not all active pages have to be on the active list, we round
-* nr_active_pages up to num_physpages/2, if needed.
+* information in the system.
*/
- if (!target) {
- int inactive = nr_free_pages() + nr_inactive_clean_pages() +
- nr_inactive_dirty_pages;
- int active = MAX(nr_active_pages, num_physpages / 2);
- if (active > 10 * inactive)
- maxscan = nr_active_pages >> 4;
- else if (active > 3 * inactive)
- maxscan = nr_active_pages >> 8;
- else
- return 0;
- }
+ if (!target)
+ maxscan = nr_active_pages >> 4;
/* Take the lock while messing with the list... */
spin_lock(_lru_lock);
--
Zlatko
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
keyboard hook?
I'm beginning the process of writing a driver for the "Qoder"
keyboard-fob barcode scanner made by InterMec. It communicates with the
host computer using the PS/2 port by way of a "dock" that sits in
between the keyboard and the computer.
The dock does handshaking with the host computer, which means that it
listens for specific signals sent from the host. One of them is "turn
numlock light on," which I can do with an ioctl from userspace (as root,
anyway), but also caps lock, num lock and carriage-return scancodes.
I will have to modify the keyboard driver to capture and process data
from the barcode scanner cleanly, and without requiring root access for
the client programs.
The CueCat driver written by Pierre Coupard also modifies the keyboard
driver. It would be nice if it was possible to load modules that hook
into keyboard processing without requiring a kernel patch. And perhaps
there is, but I haven't run across it yet.
I just need to scan the keystroke stream for an attention signal
(shift,shift,shift,alt,ctrl) and then respond ("turn on numlock light")
to initiate the data transfer; then, of course, capture and format that
data and make it available via /proc, or something.
Does anyone have any suggestions before I go ugly-up the keyboard
driver?
Thanks,
--
Michael Rothwell
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: select() - Linux vs. BSD
[EMAIL PROTECTED] wrote: > Of course, not looking at the sets upon a zero return is a fairly obvious > optimization as there is little point in doing so. No; a fairly obvious optimisation is to avoid calling FD_ZERO if you can clear the bits individually when you test them. When you examine the sets, you can clear each bit that you examine and then you know you have a zero set. Then you can set only the relevant bits for the next call to select(). If you can't rely on the sets being cleared on a timeout, then you will have to call FD_ZERO in that case, or you will have to go through the list of descriptors and clear them individually. (This can be avoided but it means keeping track of state between successive calls to select()). This is contrary to the non-timeout case, where you stop checking bits when you have counted N of them set. So you see, there is a handy optimisation if you can assume the sets are zeroed on timeout. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reading from /dev/fb0 very slow?
Pavel Machek wrote: > > Hi! > > I did some benchmarks, and my framebuffer is *way* faster when writing > than when reading: > > root@bug:/home/pavel# time cat /tmp/test > /dev/fb0 > 0.01user 0.08system 0.09 (0m0.097s) elapsed 93.13%CPU > root@bug:/home/pavel# time cat /dev/fb0 > /dev/null > 0.00user 0.62system 0.62 (0m0.620s) elapsed 99.93%CPU > root@bug:/home/pavel# > > That is 6 times slower! This is also very visible in X, where moving > regions is expensive, while just drawing regions is fast. For example > gnome-terminal is *way* faster *with* transparent background option. > > Any idea why such assymetry? [This is toshiba 4030cdt with vesafb and > 2.4.5] Do you have write combining enabled? -- Jeff Garzik | Echelon words of the day, from The Register: Building 1024| FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26 MandrakeSoft | Steak Knife Kill the President anarchy echelon | nuclear assassinate Roswell Waco World Trade Center - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Date goes four times faster!
Hi! > I'm using Redhat linux 7.0 on an HP vectra vei8-Piii450 computer. My > desktop environment is Gnome 1.2.1. > This noon I found that the date went four times faster! It was going well > before about 11 PM Wen May 30. But after that the date :-) On my system, date likes to go 3 times slower when I do heavy scrolling. Maybe we should teach our computers to do something in the middle ;-). Pavel > displayed by commod "date" accelerated. It told me Thu May 31 00:54:52 CST > 2001 while my watch was Wen May 30 17:40. > Also the "clock" applet on the Panel of Gnome told me 12:57 AM Thu > May 31! Can you do cat /proc/interrupts; sleep 1; cat /proc/interrupts? -- 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MII access (was [PATCH] support for Cobalt Networks (x86 only)
On Sat, 2 Jun 2001, Alan Cox wrote: > > One application needs to poll link status with 1 second resolution. On a > > Then it needs to be privileged Fine. Can you think of a default value for expiring cache ? > And if the approach is to block until the time for the next read occurs is > done then the program get stuck for 30 seconds, misses its deadline and kills > the cluster - how is this better ?? Is not better. Well, when somebody is playing against you, you're in trouble either way: - rate limit: - blocking - as above - non-blocking - notify the user that you can't get the info and probably stop or aquire elevated priviledges and try to restart the network - cache: get outdated info But when a HA application runs, it's usually preferable to stop (and you notice it) than to continue with wrong data. Especially if you set the cache expiry to something like 30 seconds; think in terms of how many transactions/second today's hardware allows... > Doing the MII monitoring somewhere centralised like the routing daemons would > certainly let more inteillgent management and reporting get done I don't argue over this point, already several people mentioned it. But I explained the present situation in a previous message: the MII info is normally read at a low rate and some applications need it more often. It doesn't matter that it's delivered through ioctl, netlink or any other way, you have to read it from the hardware and deliver to user-space at user request. So the "doing the MII monitoring" is the tough part. -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: here comes the summer...
Hi! > ...again (I think I asked just the same last summer) > and lm_sensors is still out of the kernel (we have got 40ºC in Spain > this week, and I would like to know how my PIIs suffer...) Send some summer over here. It is 15C outside... You should try latest ACPI patches, they include thermal managment, too. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reading from /dev/fb0 very slow?
Hi! I did some benchmarks, and my framebuffer is *way* faster when writing than when reading: root@bug:/home/pavel# time cat /tmp/test > /dev/fb0 0.01user 0.08system 0.09 (0m0.097s) elapsed 93.13%CPU root@bug:/home/pavel# time cat /dev/fb0 > /dev/null 0.00user 0.62system 0.62 (0m0.620s) elapsed 99.93%CPU root@bug:/home/pavel# That is 6 times slower! This is also very visible in X, where moving regions is expensive, while just drawing regions is fast. For example gnome-terminal is *way* faster *with* transparent background option. Any idea why such assymetry? [This is toshiba 4030cdt with vesafb and 2.4.5] 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
*BAD* impact of usb on PCI performance
Hi! I did some testing how does usb hurt rest of system; and it can be pretty bad. With Acher's uhci, even ifconfig up of usb-to-usb networking device [plusb handled by generic usb-to-usb driver; see -ac series]. does 50% slowdown. When fsbr is being used, systems slows down by 350% (running more than 4 times slower than normally. Ouch). Pavel 2.4.5: 300MHz, no usb at all (compiled out) 0.06user 3.25system 3.30 (0m3.308s) elapsed 100.00%CPU 0.06user 3.25system 3.30 (0m3.307s) elapsed 100.00%CPU 0.03user 3.28system 3.32 (0m3.323s) elapsed 99.61%CPU 2.4.5: 300MHz, usb ifconfig down [acher] 0.05user 3.28system 3.35 (0m3.357s) elapsed 99.18%CPU 0.03user 3.29system 3.31 (0m3.319s) elapsed 100.00%CPU 0.04user 3.29system 3.32 (0m3.325s) elapsed 100.00%CPU 0.01user 3.32system 3.32 (0m3.326s) elapsed 100.00%CPU 2.4.5: 300MHz, usb not plugged [JE] 0.06user 3.24system 3.30 (0m3.303s) elapsed 99.90%CPU 0.06user 3.25system 3.30 (0m3.304s) elapsed 100.00%CPU 0.02user 3.30system 3.33 (0m3.336s) elapsed 99.52%CPU 2.4.5: 300Mhz, plusb loaded and UP [acher] 0.03user 4.93system 4.99 (0m4.993s) elapsed 99.33%CPU 0.02user 4.94system 4.99 (0m4.991s) elapsed 99.37%CPU 0.04user 4.92system 4.99 (0m4.990s) elapsed 99.40%CPU 0.06user 4.90system 4.98 (0m4.985s) elapsed 99.49%CPU 0.04user 4.91system 4.98 (0m4.983s) elapsed 99.33%CPU 0.05user 4.91system 4.98 (0m4.985s) elapsed 99.50%CPU 0.06user 4.90system 4.98 (0m4.989s) elapsed 99.42%CPU 0.06user 4.91system 4.99 (0m4.995s) elapsed 99.49%CPU 2.4.5: 300Mhz, plusb plugged in [JE] 0.03user 3.29system 3.35 (0m3.352s) elapsed 99.05%CPU 0.02user 3.29system 3.34 (0m3.349s) elapsed 98.85%CPU 0.01user 3.30system 3.34 (0m3.349s) elapsed 98.84%CPU 2.4.5: 300Mhz, plusb plugged in and UP [JE] 0.04user 3.29system 3.32 (0m3.327s) elapsed 100.00%CPU 0.02user 3.31system 3.35 (0m3.356s) elapsed 99.23%CPU 0.04user 3.28system 3.35 (0m3.353s) elapsed 99.03%CPU 2.4.5: 300Mhz, plusb loaded and UP, fsbr forced ON [acher] 0.06user 14.39system 14.54 (0m14.542s) elapsed 99.37%CPU 0.03user 14.51system 14.62 (0m14.625s) elapsed 99.42%CPU 0.04user 14.63system 14.79 (0m14.798s) elapsed 99.14%CPU 2.4.5: 300Mhz, plusb loaded and UP, fsbr forced ON [JE] 0.04user 14.87system 14.98 (0m14.986s) elapsed 99.49%CPU 0.06user 14.85system 14.99 (0m14.994s) elapsed 99.43%CPU 0.04user 14.85system 14.98 (0m14.984s) elapsed 99.37%CPU -- 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: toshiba(freecom) USB cdrom kernel panic
Hi! > I have strange problems with my Toshiba(actually Freecom) USB cdrom cable. > inserting the usb-storage takes some minutes, until it returns. Then > mounting the cdrom works, but when i started copying from cd, a kernel > panic occured. It happens every time, i try to copy something from cd. > Kernel is 2.4.5. Hardware is Abit BE6-II / PIII 667. Decoded oops and > dmesg output included, if more info is needed, please write directly to > me, as i am not subscribed to this list. Thanks :) Can you compile usb-storage into kernel to get more usefull oops? Plus it would be nice to mail it linux-usb, where someone is more likely to listen. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
BUG: 2.4.x NFS client mmap race
Hi,
While debugging a rather strange WINE problem I came across a 2.4.x
NFS race condition.
I trimmed down the WINE code to a very small testcase, attached below,
which has following test patterns:
ext2 local : SUCCESS
2.4.5-ac6 -> 2.2.10 (unfsd): FAIL
2.4.2-ac26 -> 2.4.2ac26 (knfsd) : FAIL
2.2.14 -> 2.4.2ac26 (knfsd) : SUCCESS
For me this looks like there is a problem in the 2.4 NFS client.
The sleep() appears to be a key part. If we only sleep 1 second the
test usually succeeds. With 5 it always fails.
I am using the default mount options for nfs.
Ciao, Marcus
#include
#include
#include
#include
#include
#include
#include
main() {
int fd;
unsigned char *ptr;
char buf[10];
memset(buf,'0',10);
fd = open("/home/lstcore/mm/test.out",O_RDWR|O_CREAT|O_TRUNC,0644);
assert(fd!=-1);
ftruncate(fd,512);
ptr=mmap(NULL,512,PROT_WRITE|PROT_READ,MAP_SHARED,fd,0);
ptr[0]=0x42;
munmap(ptr,512);
sleep(5);
ftruncate(fd,69632);
ptr=mmap(NULL,69632,PROT_WRITE|PROT_READ,MAP_SHARED,fd,0);
assert(ptr[0]==0x42);
fprintf(stderr,"There was no race. Lucky you!\n");
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [newbie] NFS client: port-unreachable
On 1 Jun 2001, Trond Myklebust wrote: > > (port-unreachable) goes out to the server. This is annoying > > since it blocks all access to that directory. The request in > > question is sent and received at port 772. > > > I'm using kernel 2.4.4. > > You probably have set ipchains or ipfilter to block port 772 on your > client. No, I have no port specific rules in the firewall (iptables), but this machine does SNAT for 32 other linux boxes which also get some directories from the same server (including YP). I had some trouble with the YPSERV-calls until I bound two more IPs to the network card and masqueraded the 32 boxes via these additional addresses. What might happen is that the specific port gets allocated by some port remapping in iptables during the request, but I don't see why this should happen only for specific directories (e.g. /home works and /compass doesn't while both are from the same server). Ciao, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB mouse wheel breakage was Re: Linux 2.4.5-ac5
On Fri, Jun 01, 2001 at 05:32:26PM -0400, Robert M. Love wrote:
> I and another user thought the problem was in hid_input_field, but upon
> looking I now think not.
It is, check against hid.c in 2.4.5, the new code &&'s the first 2 if statements and
so it
now checks non-zero HID_MAIN_INPUT_RELATIVE values for new and old being
the same, which AFAICT, they can and often will be.
Patch against ac6 reverts back to original hid.c check :-
--- ../linux.orig/drivers/usb/hid-core.cSat Jun 2 21:47:35 2001
+++ drivers/usb/hid-core.c Sat Jun 2 21:46:00 2001
@@ -773,10 +773,11 @@
if (HID_MAIN_ITEM_VARIABLE & field->flags) {
- if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n])
- continue;
- if (value[n] == field->value[n])
- continue;
+ if (field->flags & HID_MAIN_ITEM_RELATIVE) {
+ if (!value[n]) continue;
+ } else {
+ if (value[n] == field->value[n]) continue;
+ }
hid_process_event(hid, field, >usage[n], value[n]);
continue;
}
--
Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
On Wed, 30 May 2001, Ralf Baechle wrote: > > This is no good. The ARM kernel just doesn't provide any atomic primitives > > that will work in user space. If you want atomicity you have to use > > libpthread. > > Similar on some MIPS processors where the kernel has to implement atomic > operations because there is no practical possibility to implement them > in userspace. Thanks for the answer, this means: It is specific to the arm, mips, mips64 and sparc ports that atomic_read, atomic_inc and atomic_dec won't work in user space and they do work on all other architectures. (my main concern wasn't whether the "#ifdef __KERNEL__" is correct or not but I was wondering whether there's a reason why it's different on different architectures) > Ralf cu Adrian -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5 and all ac-Patches] massive file corruption with reiser or NFS
Am Samstag, 2. Juni 2001 20:33 schrieb Chris Mason: > On Saturday, June 02, 2001 08:13:44 PM +0200 Andreas Hartmann > > <[EMAIL PROTECTED]> wrote: > > Am Samstag, 2. Juni 2001 18:42 schrieben Sie: > >> On Saturday, June 02, 2001 02:41:04 PM +0200 Andreas Hartmann > >> > >> >> <[EMAIL PROTECTED]> wrote: > >> > > >> > Am Samstag, 2. Juni 2001 12:52 schrieb Rasmus Bøg Hansen: > >> >> On Sat, 2 Jun 2001, Andreas Hartmann wrote: > >> >> > I got massive file corruptions with the kernels mentioned in the > >> >> > subject. I can reproduce it every time. > >> >> > > >> >> > >> >> >> You cannot use NFS on reiserfs unless you apply the knfsd > >> >> > >> >> >> patch. > >> >> >> > >> >> >> Look at > >> >> >> > >> >> >> >> www.namesys.com. > >> >> >> >> > >> >> >> > > Thank you very much for your advice. > >> > > > >> > > I tested your suggestion and run the machine without NFS-mounted > >> > > devices > >> > > > >> > >> > - it seems to be working fine. > > Anyway - I'm wondering why I > >> > >> > didn't > >> > > >> > get any problem until 2.4.4ac10 with this configuration without the > >> > appropriate patch on the client or on the server? > >> > > >> >> The problem only happens when the clients do an operation on a file > >> >> that > >> > >> has gone out of cache on the server. Under light load, this might > >> happen very rarely. > >> > > > The load didn't change. YOu can forget the load, it's very small. It's > > > my > > > > private server and I'm doing always the same thing via NFS - compiling > > e.g. This has been working fine until 2.4.4.ac10, afterwards it has been > > broken. > > Ok, there are two different problems here. The patch you posted to l-k is > a generic NFS fix for 2.4.5. ext2 would need this too. > > If you are serving NFS from your reiserfs disk, you need an additional > patch on the server only (this is the one I was talking about). Checkout > the FAQ on www.namesys.com for all the details. Just for my understanding: While I used 2.2.19 without patch on the server (it serves only reiser-based data) and 2.4.[1234]ac[...] on the client (without patch), it has been working because of the light load of the server. Since 2.4.4ac11 something has been broken in the NFS for 2.4.5, so I ran into problems. When this conclusion is right, the following combination should work for light load, as I usually have it: unpatched 2.2.19 on the server (as it has been working with 2.2.4ac10) and NFS-patched 2.4.5. The test showed, that it is working. The actual combination 2.4.5 on the server and on the client with the mentioned NFS-patch is the same situation as with the unpatched 2.2.19 on the server and the NFS-patch only on the 2.4.5-client. I hope, that there will be soon a 2.4.5 knfsd-patch for my server, because this is the secure way! And I hope, the broken NFS on the client in the 2.4.5-Kernels will be fixed soon - maybe in the next ac-patch? Regards, Andreas Hartmann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PID of init != 1 when initrd with pivot_root
> > Well, I upgraded and found pivot_root and the problem is that how do I make init > > run with PID 1. My linuxrc gets PID 7. > > > > 1 ?00:03:05 swapper > > 2 ?00:00:00 keventd > > 3 ?00:00:00 kswapd > > 4 ?00:00:00 kreclaimd > > 5 ?00:00:00 bdflush > > 6 ?00:00:00 kupdated > > 7 ?00:00:00 linuxrc > > > > init doesn't like running with any other PID than 1. I could probably revert to > > the not so old way of doing things and exit linuxrc and let the kernel change > > root. But then I wouldn't be able to mount root over samba :-(. ( not that I > > have any samba shares :-) > > This is this way for backwards bug compatibility. Use the following > command line options to make it behave properly: > > ram=/dev/ram0 init=/linuxrc That's what I did, almost. I think you meant root=/dev/rd/0 init=/linuxrc ( with devfs) though init parameter is made redundant by the new "root change mechanism" pivot_root. But the problem still remains. How do I make my /sbin/init run with PID 1 using initial ramdisk under the new root change mechanism? I don't want to use the old change_root mechanism since the Documentation/initrd.txt says: Obsolete root change mechanism -- The following mechanism was used before the introduction of pivot_root. Current kernels still support it, but you should _not_ rely on its continued availability. ... This old, deprecated mechanism is commonly called "change_root", while the new, supported mechanism is called "pivot_root". -- Ivan Vadovic - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MII access (was [PATCH] support for Cobalt Networks (x86 only)
> One application needs to poll link status with 1 second resolution. On a Then it needs to be privileged > for how long this situation lasts. If you have a proc/ioctl interface for > setting cache expiring time, this same interface can then be used for > reading back this info. This application can then check that this value is > lower than 1 second and if not, notify the user that it cannot run. And if the approach is to block until the time for the next read occurs is done then the program get stuck for 30 seconds, misses its deadline and kills the cluster - how is this better ?? > Usually, the transceivers return garbage if you read from locations you > are not supposed to (overwritting phy_ad). But if you begin overwritting > the READ command (0xf6 above)... Something like this should do: Some of them just hang. > Too tired to think straight yesterday... You're right. And if you alloc > 32*sizeof(int) (you want to keep jiffies, right ?) per netdevice, I think > that it could even be done outside the driver. Hmm, most of my > previous arguments are no longer valid 8-( Doing the MII monitoring somewhere centralised like the routing daemons would certainly let more inteillgent management and reporting get done - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MII access (was [PATCH] support for Cobalt Networks (x86 only)systems)
[ As this is becoming more and more MII specific, I changed the subject ] On Sat, 2 Jun 2001, Alan Cox wrote: > > This only answered the first part of the question: when. How do you pass > > the "how long" info ? > > Does the same applies for the MII ioctl case ? > > The mtime tells you exactly that. Alan, please consider this situation: One application needs to poll link status with 1 second resolution. On a system where caching is done with an unknown cache expiring time, this application is sometimes fed incorrect data. So, you need a way to tell for how long this situation lasts. If you have a proc/ioctl interface for setting cache expiring time, this same interface can then be used for reading back this info. This application can then check that this value is lower than 1 second and if not, notify the user that it cannot run. As this thread started as a general hardware access problem, would only _one_ value for all these cases be sufficient ? Or each case should have its own timeout ? Anyway, for MII, accessing the status at sub-second intervals might be a legit one, so what measuring units should be used? > I disagree. A non priviledged app should not be able to poke around in MII > registers anyway. So you only have to cache the generic state of the link. At the beginning of this thread, Jeff said "calling the ioctls without priveleges is quite useful". Now if you say that there is no such case, the whole problem could simply be solved by checking for the appropriate priviledges. I just realized another thing, important (IMHO) if a normal user is still allowed to access MII: the drivers (checked for 3c59x, eepro100, tulip) do not verify that the value passed for register number is within the allowed range and use it as: int read_cmd = (0xf6 << 10) | ((phy_id & 0x1f) << 5) | location; (phy_id is the MII address and location is the register number). There is also no check that the MII address specified is actually in use by the driver, but this is used with mii-diag to query a MII which was not correctly identified (maybe this should be allowed for CAP_NET_ADMIN only ?) >From one of Don Becker pages: "MII transceivers have 32 management registers. The first 16 are reserved for standard-defined uses, and the remaining one are available for chip-specific features. Only the first seven registers are currently defined." Usually, the transceivers return garbage if you read from locations you are not supposed to (overwritting phy_ad). But if you begin overwritting the READ command (0xf6 above)... Something like this should do: int read_cmd = (0xf6 << 10) | ((phy_id & 0x1f) << 5) | (location & 0x1f); > You don't need timers. Too tired to think straight yesterday... You're right. And if you alloc 32*sizeof(int) (you want to keep jiffies, right ?) per netdevice, I think that it could even be done outside the driver. Hmm, most of my previous arguments are no longer valid 8-( -- Bogdan Costescu IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868 E-mail: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Warning in ac6
Sean Jones <[EMAIL PROTECTED]> on 06/02/2001 01:17:15 PM To: Linux Kernel Mailing List <[EMAIL PROTECTED]> cc:(bcc: Wayne Brown/Corporate/Altec) Subject: Warning in ac6 >Also the file /proc/sys/fs/binfmt_misc seems to be missing on my >machine. How would I remedy this problem? To answer one of your questions: /proc/sys/fs/binfmt_misc is a directory, not a file. If you mean that this directory is present but empty, try this: mount -t binfmt_misc none /proc/sys/fs/binfmt_misc and see if the register and status files appear in it. If the directory isn't there at all, make certain you have CONFIG_BINFMT_MISC=y in your .config file. Wayne - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] natsemi update
A few bugfixes for the natsemi driver:
* multicast hashing used the wrong polynomial
* converted to pci_dma mappings
* SMP locking updates
* added full reset into tx_timeout.
If you had problems with multicast support, please try this patch
[against 2.4.5-ac6, but it should also apply to 2.4.5]
--
Manfred
--- 2.4/drivers/net/natsemi.c Sat Jun 2 14:19:44 2001
+++ build-2.4/drivers/net/natsemi.c Sat Jun 2 20:21:15 2001
@@ -51,10 +51,21 @@
* One-liner removal of a duplicate declaration of
netdev_error(). (uzi)
+ Version 1.0.7: (Manfred Spraul)
+ * pci dma
+ * SMP locking update
+ * full reset added into tx_timeout
+ * correct multicast hash generation
+ [copied from a natsemi driver version
+from Myrio Corporation, Greg Smith]
+
+ TODO:
+ * big endian support
+ * suspend/resume
*/
#define DRV_NAME "natsemi"
-#define DRV_VERSION"1.07+LK1.0.6"
+#define DRV_VERSION"1.07+LK1.0.7"
#define DRV_RELDATE"May 18, 2001"
@@ -111,6 +122,8 @@
/* Time in jiffies before concluding the transmitter is hung. */
#define TX_TIMEOUT (2*HZ)
+#define NATSEMI_RESET_TIMEOUT 200
+
#define PKT_BUF_SZ 1536/* Size of each temporary Rx
buffer.*/
#if !defined(__OPTIMIZE__)
@@ -134,6 +147,7 @@
#include
#include
#include
+#include
#include /* Processor type for cache alignment. */
#include
#include
@@ -145,10 +159,6 @@
KERN_INFO " http://www.scyld.com/network/natsemi.html\n;
KERN_INFO " (unofficial 2.4.x kernel port, version " DRV_VERSION ", " DRV_RELDATE "
Jeff Garzik, Tjeerd Mulder)\n";
-/* Condensed operations for readability. */
-#define virt_to_le32desc(addr) cpu_to_le32(virt_to_bus(addr))
-#define le32desc_to_virt(addr) bus_to_virt(le32_to_cpu(addr))
-
MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("National Semiconductor DP8381x series PCI Ethernet driver");
MODULE_PARM(max_interrupt_work, "i");
@@ -330,15 +340,17 @@
DescPktOK=0x0800, RxTooLong=0x0040,
};
-#define PRIV_ALIGN 15 /* Required alignment mask */
struct netdev_private {
/* Descriptor rings first for alignment. */
- struct netdev_desc rx_ring[RX_RING_SIZE];
- struct netdev_desc tx_ring[TX_RING_SIZE];
+ dma_addr_t ring_dma;
+ struct netdev_desc* rx_ring;
+ struct netdev_desc* tx_ring;
/* The addresses of receive-in-place skbuffs. */
struct sk_buff* rx_skbuff[RX_RING_SIZE];
+ dma_addr_t rx_dma[RX_RING_SIZE];
/* The saved address of a sent-in-place packet/buffer, for later free(). */
struct sk_buff* tx_skbuff[TX_RING_SIZE];
+ dma_addr_t tx_dma[TX_RING_SIZE];
struct net_device_stats stats;
struct timer_list timer;/* Media monitoring timer. */
/* Frequently used values: keep some adjacent for cache effect. */
@@ -348,10 +360,7 @@
unsigned int cur_tx, dirty_tx;
unsigned int rx_buf_sz; /* Based on MTU+slack. */
/* These values are keep track of the transceiver/media in use. */
- unsigned int full_duplex:1; /* Full-duplex operation
requested. */
- unsigned int duplex_lock:1;
- unsigned int medialock:1; /* Do not sense media. */
- unsigned int default_port:4;/* Last dev->if_port value. */
+ unsigned int full_duplex;
/* Rx filter. */
u32 cur_rx_mode;
u32 rx_filter[16];
@@ -360,23 +369,29 @@
/* original contents of ClkRun register */
u32 SavedClkRun;
/* MII transceiver section. */
- u16 advertising;/* NWay media
advertisement */
-
+ u16 advertising;/* NWay media advertisement */
unsigned int iosize;
spinlock_t lock;
};
static int eeprom_read(long ioaddr, int location);
static int mdio_read(struct net_device *dev, int phy_id, int location);
+static void natsemi_reset(struct net_device *dev);
static int netdev_open(struct net_device *dev);
-static void check_duplex(struct net_device *dev);
+static void check_link(struct net_device *dev);
static void netdev_timer(unsigned long data);
static void tx_timeout(struct net_device *dev);
+static int alloc_ring(struct net_device *dev);
static void init_ring(struct net_device *dev);
+static void drain_ring(struct net_device *dev);
+static void free_ring(struct net_device *dev);
+static void init_registers(struct net_device *dev);
static int start_tx(struct sk_buff *skb, struct net_device *dev);
static void intr_handler(int irq, void *dev_instance, struct pt_regs *regs);
static void netdev_error(struct net_device *dev, int intr_status);
-static int netdev_rx(struct net_device *dev);
+static void
[PROBLEM] 2.4.5 tulip receive slowdown, possibly highmem related
Hello,
I'm having a small problem with the tulip driver in 2.4.5 and have
gathered some data on the problem, so I thought I should report:
Intermittently the tulip ethernet interface in one of my machines becomes
very slow, e.g. the ping times to it on the idle local 100BaseT network
jump from 150us to about 300ms. Executing "ifdown ; ifup" on the
interface resolves the problem until the next time it occurs. Using
tcpdump on the machine and on another node on the local net (with ntpd
synchronized clocks) shows that the delay occurs while receiving. lspci
identifies the interface as: "Ethernet controller: Lite-On Communications
Inc LNE100TX (rev 20)".
I actually have two machines with similar configurations, but only one
shows the problem:
mf2 (problem): VIA Apollo Pro, PIII-733 x 2, 1GB RAM, LNE100TX rev 20
mf3 (OK): Intel 440BX,PIII-700 x 2, 512MB RAM, LNE100TX rev 21
Both machines have the same kernel configuration.
Below is the output of "tulip-diag -aaf -ee -mm". Specifically, I provide
a unified diff, where the old version is after the problem has occured,
before I reset the interface with "ifdown ; ifup", and the new version is
after I reset the interface.
As the problem is intermittent, I don't have a deterministic way to
trigger it, but it often occurs if I transfer "a lot" through the
interface. Based on the tulip-diag output, I thought it might be highmem
related, so I tried booting mf2 with mem=896M. In this configuration, I
have been unable to trigger it, although that is not definitive.
I should disclose that I am presently running MOSIX-1.0.3 on these
machines and that all of the data comes from this MOSIX kernel. However,
I have experienced this slowdown problem since early 2.4, when I was not
running MOSIX, and I have confirmed that the slowdown problem does occur
under plain 2.4.5 with mem=1G.
I'd be happy to provide any additional information or test any patches.
Cheers,
Wayne
[whitney@mf1 whitney]$ diff -u --unified=1000 /tmp/tulip.diag.{bad,good}.3
--- /tmp/tulip.diag.bad.3 Sat Jun 2 10:00:53 2001
+++ /tmp/tulip.diag.good.3 Sat Jun 2 10:00:53 2001
@@ -1,35 +1,35 @@
tulip-diag.c:v2.07 3/31/2001 Donald Becker ([EMAIL PROTECTED])
http://www.scyld.com/diag/index.html
Index #1: Found a Lite-On 82c168 PNIC adapter at 0xb800.
Lite-On 82c168 PNIC chip registers at 0xb800:
- 0x00: 8000 01ff0001 10450008 37879000 37879200 026e0010 810c2202 0001fbef
- 0x40: 3d8a 37879270 3405685c 0020 1001
+ 0x00: 8000 01ff 10450008 37879000 37879200 02660010 810c2202 0001fbef
+ 0x40: 37879200 378178c0 0020 1001
Extended registers:
- 80: f0022646 f0022646 0082 0082
- a0: 609645e1 609645e1 378790d0 378790d0 3756b054 3756b054 0201f978 0201f978
+ 80: f0022646 f0022646 00bf 00bf
+ a0: 609645e1 609645e1 378790c0 378790c0 1f168810 1f168810 0201f978 0201f978
c0:
e0:
Port selection is MII, full-duplex.
Transmit started, Receive started, full-duplex.
- The Rx process state is 'Transferring Rx frame into memory'.
+ The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 128.
A simplifed EEPROM data table was found.
The EEPROM does not contain transceiver control information.
EEPROM contents (64 words):
0x00: 00c0 f02d 3d8a f002 2646 00f1 a035
0x08:
0x10:
0x18:
0x20:
0x28:
0x30:
0x38: 0030
ID block CRC 0xef (vs. 00).
Full contents CRC 0x7ee5 (read as 0x).
MII PHY found at address 1, status 0x782d.
MII PHY #1 transceiver registers:
1100 782d 0302 d008 01e1 45e1 0005 2001
- 0001 0002 4096 8062
+ 0001 003c 8062
04a1 0039 .
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5 and all ac-Patches] massive file corruption with reiseror NFS
On Saturday, June 02, 2001 08:13:44 PM +0200 Andreas Hartmann <[EMAIL PROTECTED]> wrote: > Am Samstag, 2. Juni 2001 18:42 schrieben Sie: >> On Saturday, June 02, 2001 02:41:04 PM +0200 Andreas Hartmann >> >> <[EMAIL PROTECTED]> wrote: >> > Am Samstag, 2. Juni 2001 12:52 schrieb Rasmus Bøg Hansen: >> >> On Sat, 2 Jun 2001, Andreas Hartmann wrote: >> >> > I got massive file corruptions with the kernels mentioned in the >> >> > subject. I can reproduce it every time. >> >> > >> >> >> You cannot use NFS on reiserfs unless you apply the knfsd patch. >> >> >> Look at >> >> >> >> www.namesys.com. >> >> >> > > Thank you very much for your advice. >> > > I tested your suggestion and run the machine without NFS-mounted >> > > devices >> > >> > - it seems to be working fine. > > Anyway - I'm wondering why I didn't >> > get any problem until 2.4.4ac10 with this configuration without the >> > appropriate patch on the client or on the server? >> >> The problem only happens when the clients do an operation on a file that >> has gone out of cache on the server. Under light load, this might happen >> very rarely. > > The load didn't change. YOu can forget the load, it's very small. It's my > private server and I'm doing always the same thing via NFS - compiling > e.g. This has been working fine until 2.4.4.ac10, afterwards it has been > broken. Ok, there are two different problems here. The patch you posted to l-k is a generic NFS fix for 2.4.5. ext2 would need this too. If you are serving NFS from your reiserfs disk, you need an additional patch on the server only (this is the one I was talking about). Checkout the FAQ on www.namesys.com for all the details. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Configure.help is complete
On Fri, Jun 01, 2001 at 08:45:17AM -0700, Jonathan Lundell wrote: > >> It allows a general interface to the kernel that does not require new > >> syscalls/ioctls and can be accessed from user space without specifically > >> compiled programs. You can use shell scripts, java, command line etc. > > > >Yes, and it's also totally non standardised. > > It clearly fills a need, though, and has the distinct side benefit of > cutting down on the proliferation of ioctls. Sure, it's non-standard > and a mess. But it's semi-documented, easy to use, and v. general. > What's the preferred alternative, to state the first question another > way? For any single small project/driver, creating a new fs simply > isn't going to happen. > -- > /Jonathan Lundell. If I understand Al Viro correctly we'll get per driver filesystems in 2.5 (based on ramfs) which you can union-mount on /proc (possibly using autofs) to get the current /proc tree. Happy Hacking. -- Linux 2.4.5-ac6 #1 Fri Jun 1 17:12:42 CEST 2001 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5 and all ac-Patches] massive file corruption with reiser or NFS
Am Samstag, 2. Juni 2001 18:42 schrieben Sie: > On Saturday, June 02, 2001 02:41:04 PM +0200 Andreas Hartmann > > <[EMAIL PROTECTED]> wrote: > > Am Samstag, 2. Juni 2001 12:52 schrieb Rasmus Bøg Hansen: > >> On Sat, 2 Jun 2001, Andreas Hartmann wrote: > >> > I got massive file corruptions with the kernels mentioned in the > >> > subject. I can reproduce it every time. > >> > > >> >> You cannot use NFS on reiserfs unless you apply the knfsd patch. Look > >> >> at > >> > >> www.namesys.com. > >> > > > Thank you very much for your advice. > > > I tested your suggestion and run the machine without NFS-mounted > > > devices > > > > - it seems to be working fine. > > Anyway - I'm wondering why I didn't > > get any problem until 2.4.4ac10 with this configuration without the > > appropriate patch on the client or on the server? > > The problem only happens when the clients do an operation on a file that > has gone out of cache on the server. Under light load, this might happen > very rarely. The load didn't change. YOu can forget the load, it's very small. It's my private server and I'm doing always the same thing via NFS - compiling e.g. This has been working fine until 2.4.4.ac10, afterwards it has been broken. > > You only need the patch on the server. My experiences today are others: I need the patch on both, the server and the client (both 2.4.5) to get it working. See the other mailing to Alan in the list. Regards, Andreas Hartmann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5 and all ac-Patches] massive file corruption with reiser or NFS
Am Samstag, 2. Juni 2001 18:19 schrieben Sie: > > I got massive file corruptions with the kernels mentioned in the subject. > > I can reproduce it every time. > > Which other 2.4 trees have you tried ? I had the following situations: NFS server: linux 2.2.19 NFS Client: linux 2.4.[32]ac[...], linux 2.4.4ac[1-...] [1-10] have been working fine. Beginning with ac11, I got the problems I wrote. During this time, I never used any knfsd-patch. The following is the combination, which seems to be working fine: NFS Server: linux 2.2.19 with knfsd-patch or linux 2.4.5 with the following knfsd-Patch from Gergely Tamas <[EMAIL PROTECTED]> (I got it from the mailinglist of reiser) (there is no patch for ac6): -- --- linux-2.4.5/fs/inode.c.orig Fri May 25 14:15:38 2001 +++ linux-2.4.5/fs/inode.c Wed May 30 12:17:29 2001 @@ -1044,6 +1044,8 @@ inode->i_state|=I_FREEING; inodes_stat.nr_inodes--; spin_unlock(_lock); + if (inode->i_data.nrpages) + truncate_inode_pages(>i_data, 0); clear_inode(inode); } } --- linux-2.4.5-pre6/fs/nfs/dir.c.orig Fri May 25 14:15:38 2001 +++ linux-2.4.5-pre6/fs/nfs/dir.c Thu May 31 14:53:32 2001 @@ -753,6 +753,8 @@ nfs_zap_caches(dir); error = NFS_PROTO(dir)->rmdir(dir, >d_name); + if (!error) + dentry->d_inode->i_nlink -= 2; return error; } @@ -870,6 +872,8 @@ error = NFS_PROTO(dir)->remove(dir, >d_name); if (error < 0) goto out; + if (inode) + inode->i_nlink--; out_delete: /* I patched the original 2.4.5-sources. NFS Client: linux 2.4.5 with knfsd-patch. I need the patch on both the server and the client to get it working. > > Does booting with ide=nodma help ? [only in -ac] I tested the following combination: Server 2.2.19 without knfsd-Patch Client 2.4.5ac6 without knfsd-Patch but ide=nodma Result: IO-Errors as I wrote in my initial posting. Regards Adnreas Hartmann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Warning in ac6
I've recieved this warning in the past several ac versions both 2.4.5 and 2.4.4. Here is the out put from the compiler: gcc -D__KERNEL__ -I/usr/src/linux-2.4/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 -march=i586 -c -o init/main.o init/main.c In file included from /usr/src/linux-2.4/include/linux/raid/md.h:50, from init/main.c:24: /usr/src/linux-2.4/include/linux/raid/md_k.h: In function `pers_to_level': /usr/src/linux-2.4/include/linux/raid/md_k.h:41: warning: control reaches end of non-void function Also the file /proc/sys/fs/binfmt_misc seems to be missing on my machine. How would I remedy this problem? Could you CC all responces to me because my router does not support ECN. Thank you, Sean Jones - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC problem or 3com 3c590 driver problem in smp kernel 2.4.x
On Sat, 2 Jun 2001, Alan Cox wrote: > > It's our own's card. so it could be the card's problem. does the pci > > device have to do some special thing to support APIC? my card won't work > > Nope. APIC is invisible to a correctly built piece of hardware. It just changes > how INTA-INTD are handled at the host end of things > > > properly on uni-processor with APIC enable kernel or smp kernel when the > > card is sharing IRQ with some other pci devices. > > That sounds like the driver isnt testing the irq was sourced by that card. You > also see hangups on insmod/rmmod when people do > > writel(ENABLE_MY_IRQ, my_card->control); > > before they request the IRQ and are able to clear it > I forget to mention. in the same hardware configuration (same slot, sharing IRQ with other card) my card works perfect if I was using uni-processor without APIC support kernel (i tried 2.4.5-ac6 with apic disabled uniprocessor on a dual p3 box). If the driver did something wrong, it should not work on that system either. Maybe what I thought was wrong. Alex -- Feng Xian _o) .~. (o_ /\\ /V\ //\ _\_V// \\ V_/_ /( )\ ^^-^^ ALEX - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: union mounting file systems... retry #1
On Fri, Jun 01, 2001 at 05:11:54PM +0200, Roy Sigurd Karlsbakk wrote: > Q: Is it possible to union mount file systems in linux 2.4 (currently >using 2.4.5)? > > Q: Should I just go home and start doing my homework? > > Best regards > > roy AFAIK Al Viro is working on a patch, but it's not in 2.4.5 Happy Hacking. -- Linux 2.4.5-ac6 #1 Fri Jun 1 17:12:42 CEST 2001 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Athlon fast_copy_page revisited
[This message has also been posted.] On Wed, 30 May 2001 18:09:35 GMT, Jimmie Mayfield <[EMAIL PROTECTED]> wrote: > Arjan's original code is at: http://www.fenrus.demon.nl/athlon.c > My modifications are at: http://sackheads.org/~mayfield/jrm_athlon.c > > Example test runs: > > copy_page() tests > copy_page function 'warm up run' took 21350 cycles per page > copy_page function '2.4 non MMX' took 27706 cycles per page > copy_page function '2.4 MMX fallback'took 28600 cycles per page > copy_page function '2.4 MMX version' took 21370 cycles per page > copy_page function 'faster_copy' took 13119 cycles per page > copy_page function 'even_faster' took 14767 cycles per page > copy_page function 'jrm_copy_page_8nop' took 12774 cycles per page > copy_page function 'jrm_copy_page_10nop' took 12746 cycles per page > copy_page function 'jrm_copy_page_12nop' took 12740 cycles per page > > copy_page() tests > copy_page function 'warm up run' took 22499 cycles per page > copy_page function '2.4 non MMX' took 27769 cycles per page > copy_page function '2.4 MMX fallback'took 27696 cycles per page > copy_page function '2.4 MMX version' took 22666 cycles per page > copy_page function 'faster_copy' took 13058 cycles per page > copy_page function 'even_faster' took 13169 cycles per page > copy_page function 'jrm_copy_page_8nop' took 12691 cycles per page > copy_page function 'jrm_copy_page_10nop' took 12750 cycles per page > copy_page function 'jrm_copy_page_12nop' took 14786 cycles per page > > The values obviously fluctuate depending on system activity but the jrm_* > routines were faster in 13 out of 15 trials. > I have a Duron 800 socket A on an Epox 8KTA3. Has anyone noticed fluctuations with these tests.. such as jrm_athlon1: ... copy_page function 'faster_copy' took 9869 cycles per page copy_page function 'even_faster' took 9822 cycles per page ... jrm_athlon2: ... copy_page function 'faster_copy' took 9939 cycles per page copy_page function 'even_faster' took 17728 cycles per page ... jrm_athlon3: ... copy_page function 'faster_copy' took 17711 cycles per page copy_page function 'even_faster' took 9843 cycles per page ... I see these with gcc 2.95.4(Debian unstable) and a local build of gcc-3.0 from CVS last night. Almost as though some stall and/or caching is corrupting the results. -- Gordon Sadler - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMC-IRCC broken? 2.4.5-pre4 / -ac5+
From: Alan Cox <[EMAIL PROTECTED]> > > The kernel stops while booting at: > > TCP: Hash tables configured (established 16384 bind 16384) > > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > > SMC IrDA Controller found; IrCC version 2.0, port 0x118, dma=3, > irq=3 > IRDA compiled in ? If so is it ok modular . It sounds like yet > another boot > ordering wonder Just got it working as a module in -ac5, but still the kernel frezes if I use it compiled in. -ac6 makes no diff. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
test, sorry :-(
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NFS] Re: [RFC] yet another knfsd-reiserfs patch
On Saturday, June 02, 2001 12:19:59 AM +0200 Trond Myklebust <[EMAIL PROTECTED]> wrote: > > Hi Chris, > > Do you really need the parent inode in the filehandle? > > That screws rename up pretty badly, since the filehandle changes when > you rename into a different directory. It means for instance that when > I do > > open(foo) > mv foo bar/ > write (foo) > close(foo) > > then I have a pretty good chance of getting an ESTALE on the write() > statement. > Hmmm, didn't realize I had only answered this in private mail. The patch doesn't change when the parent dir's ino is included in the filehandle, it just adds wrappers for storing it and getting it out. For ext2, the parent inum is only sent for files when the subtree checks are turned on (_fh_update is unchanged if no fill_fh func is provided). The reiserfs one always puts the parent inum into the fh, but find_fh_dentry only pulls it out for directories or subtree checks so I didn't add the extra logic to the reiserfs fill_fh func. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: missing sysrq
Followup to: <[EMAIL PROTECTED]> By author:Dieter =?iso-8859-1?q?N=FCtzel?= <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Am Freitag, 1. Juni 2001 16:51 schrieben Sie: > > > Have you tried "echo 1 > /proc/sys/kernel/sysrq"? > > > You need both, compiled in and activation. > > > > no, look at the code. the enable variable defaults to 1. > > Then there must be a bug? > I get "0" with 2.4.5-ac2 and -ac5 without "echo 1". > > Fresh booted 2.4.5-ac2: > > SunWave1>cat /proc/version > Linux version 2.4.5-ac2 (root@SunWave1) (gcc version 2.95.2 19991024 > (release)) #1 Mon May 28 05:42:09 CEST 2001 > SunWave1>cat /proc/sys/kernel/sysrq > 0 > Let me guess... you're using a RedHat system? RedHat, for some idiotic reason, defaults to actively turning this off for you (and they turn Stop-A off on SPARC, too.) -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5 and all ac-Patches] massive file corruption with reiseror NFS
On Saturday, June 02, 2001 02:41:04 PM +0200 Andreas Hartmann <[EMAIL PROTECTED]> wrote: > Am Samstag, 2. Juni 2001 12:52 schrieb Rasmus Bøg Hansen: >> On Sat, 2 Jun 2001, Andreas Hartmann wrote: >> > I got massive file corruptions with the kernels mentioned in the >> > subject. I can reproduce it every time. >> >> You cannot use NFS on reiserfs unless you apply the knfsd patch. Look at >> www.namesys.com. > > Thank you very much for your advice. > > I tested your suggestion and run the machine without NFS-mounted devices > - it seems to be working fine. > > Anyway - I'm wondering why I didn't get any >problem until 2.4.4ac10 with > this configuration without the appropriate patch on the client or on the > server? The problem only happens when the clients do an operation on a file that has gone out of cache on the server. Under light load, this might happen very rarely. You only need the patch on the server. -chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] at slab.c ...
> What X server ? and also run the trace through ksymoops It's fresh installation of RH 7.1 (XFree86-4.0.3-5) ... >>EIP; c0129884<= Trace; c01b08db Trace; c01affd7 Trace; c01e4e79 Trace; c0129ddc Trace; c01adc1c Trace; c01b0a9b Trace; c01adf53 Trace; c01adfeb Trace; c01321bc <__remove_inode_queue+1c/20> Trace; c0129ddc Trace; c0140412 Trace; c0132323 Trace; c0106cab Code; c0129884 <_EIP>: Code; c0129884<= 0: 0f 0b ud2a <= Code; c0129886 2: 58pop%eax Code; c0129887 3: 8b 6b 10 mov0x10(%ebx),%ebp Code; c012988a 6: 5apop%edx Code; c012988b 7: 81 e5 00 04 00 00 and$0x400,%ebp Code; c0129891 d: 74 4d je 5c <_EIP+0x5c> c01298e0 Code; c0129893 f: b8 a5 c2 0f 17mov$0x170fc2a5,%eax Best, .R.V. -- _ |-| __ Robert Vojta -= Oo.oO =- |=| [Ll] IPEX, s.r.o. "^" `o PGP signature
Re: rtl8139too in 2.4.5
<[EMAIL PROTECTED]> wrote : > My RTL8139 (Identified 8139 chip type 'RTL-8139A') > was fine in 2.4.3 and doesnt work in 2.4.5. > Copying the 2.4.3 version of 8139too.c makes things work again. > but my old RTL8139 is working fine under 2.4.5 , without any changes. Jaswinder. -- These are my opinions not 3Di. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5 and all ac-Patches] massive file corruption with reiser or NFS
> I got massive file corruptions with the kernels mentioned in the subject. I > can reproduce it every time. Which other 2.4 trees have you tried ? Does booting with ide=nodma help ? [only in -ac] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CUV4X-D lockup on boot
> I have an ASUS CUV4X-D Dual Processor Mainboard based on a VIA > 694XDP chipset. I notice from the archives that someone else > has also reported a lockup with the m/b when using two cpus > and have some info that may be useful to track it down. > > Using kernel 2.4.5 the kernel locks up sporadically at boot > time. When I enable the NMI watchdog it occasionally gets > enabled prior to the lockup and perhaps can be useful for > debugging the problem. Here's what happens: At minimum you need the 1007 bios and to run noapic. As yet we don't know why or what the newer BIOS has done to make it boot at all - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[bug] at slab.c ...
Hi, I download kernel 2.4.5 and -ac6 patches and I see this ... After that I have black rxvt window on my desktop and I can't remove it in any way. kernel BUG at slab.c:1244! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010082 eax: 001b ebx: c1103768 ecx: 0001 edx: 1dcb esi: c1a57000 edi: c1a579aa ebp: 00012800 esp: c165fda4 ds: 0018 es: 0018 ss: 0018 Process rxvt (pid: 772, stackpage=c165f000) Stack: c01f8dca 04dc c1a57000 1000 c1a579aa 0246 0001 270f c165fe50 c2fe1214 0007 c165e000 080c c01b08db 085c 0007 c126c400 c01affd7 0820 0007 080c Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 58 8b 6b 10 5a 81 e5 00 04 00 00 74 4d b8 a5 c2 0f 17 If you want more informations, please write me and I will send you as much as will be possible. Best regards, .R.V. -- _ |-| __ Robert Vojta -= Oo.oO =- |=| [Ll] IPEX, s.r.o. "^" `o PGP signature
Re: [PATCH] es1371 race fixes
> o es1371_mmap used to use lock_kernel to do some synchronistation, > this is superceeded by s->sem. > o remap_page_range (used in es1371_mmap) needs the mm semaphore as > stated by a comment and the code. I have found _NO_ driver in the > tree so far that does this locking right... I think they rely on the lock_kernel stuff - which Id prefer not to take out to be honest. There is just a little too much vm related lock_kernel stuff left to do that - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5 VFS/ramdisk changes
Hi I'm having trouble with 2.4.5, where 2.4.4 worked fine. The problem is the following: I pass an initrd image to the kernel, which is a compressed image of an ext2 filesystem. The ramdisk size is set at 12 MB (12288 KB). The kernel is passed "root=/dev/rd/0" (using devfs, mounted automatically at boot-time by the kernel), but for some reason it can't find init (results in a kernel panic), this works perfectly with a 2.4.4 kernel. Oh, and btw, this works fine in 2.4.5 if I pass "root=/dev/fd/0 prompt_ramdisk=1" with the initrd image placed on a secondary floppydisk. What went wrong in 2.4.5? Thanks, Ole André Vadla Ravnås - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] es1371 race fixes
Hi all,
this are the sound locking fixes for es1371. While it is inspired by the
trident fixes it contains some changes over it:
o es1371_mmap used to use lock_kernel to do some synchronistation,
this is superceeded by s->sem.
o remap_page_range (used in es1371_mmap) needs the mm semaphore as
stated by a comment and the code. I have found _NO_ driver in the
tree so far that does this locking right...
Looks like we have another round of races...
Christoph
--
Of course it doesn't work. We've performed a software upgrade.
--- linux-2.4.5-ac6/drivers/sound/es1371.c Sat Jun 2 14:35:08 2001
+++ linux/drivers/sound/es1371.cSat Jun 2 17:35:11 2001
@@ -417,8 +417,16 @@
unsigned sctrl;
unsigned dac1rate, dac2rate, adcrate;
+ /*
+* Lock order (high->low):
+* - lock hardware lock
+* - open_sem guards opens
+* - sem guard dmabuf, write re-entry etc
+*/
spinlock_t lock;
struct semaphore open_sem;
+ struct semaphore sem;
+
mode_t open_mode;
wait_queue_head_t open_wait;
@@ -1336,21 +1344,27 @@
{
struct es1371_state *s = (struct es1371_state *)file->private_data;
DECLARE_WAITQUEUE(wait, current);
- ssize_t ret;
+ ssize_t ret = 0;
unsigned long flags;
unsigned swptr;
int cnt;
VALIDATE_STATE(s);
+
if (ppos != >f_pos)
return -ESPIPE;
if (s->dma_adc.mapped)
return -ENXIO;
- if (!s->dma_adc.ready && (ret = prog_dmabuf_adc(s)))
- return ret;
if (!access_ok(VERIFY_WRITE, buffer, count))
return -EFAULT;
- ret = 0;
+
+ /*
+* Guard against concurrent dmabuf programming.
+*/
+ down(>sem);
+ if (!s->dma_adc.ready && (ret = prog_dmabuf_adc(s)))
+ goto up_and_out;
+
add_wait_queue(>dma_adc.wait, );
while (count > 0) {
spin_lock_irqsave(>lock, flags);
@@ -1371,12 +1385,14 @@
ret = -EAGAIN;
break;
}
+ up(>sem);
schedule();
if (signal_pending(current)) {
if (!ret)
ret = -ERESTARTSYS;
- break;
+ goto out;
}
+ down(>sem);
continue;
}
if (copy_to_user(buffer, s->dma_adc.rawbuf + swptr, cnt)) {
@@ -1395,29 +1411,45 @@
if (s->dma_adc.enabled)
start_adc(s);
}
+ up(>sem);
+
+out:
remove_wait_queue(>dma_adc.wait, );
set_current_state(TASK_RUNNING);
return ret;
+up_and_out:
+ up(>sem);
+ return ret;
}
static ssize_t es1371_write(struct file *file, const char *buffer, size_t count,
loff_t *ppos)
{
struct es1371_state *s = (struct es1371_state *)file->private_data;
DECLARE_WAITQUEUE(wait, current);
- ssize_t ret;
+ ssize_t ret = -ENXIO;
unsigned long flags;
unsigned swptr;
int cnt;
VALIDATE_STATE(s);
+
if (ppos != >f_pos)
return -ESPIPE;
+
+ /*
+* Guard against an mmap or ioctl while writing
+*/
+ down(>sem);
+
if (s->dma_dac2.mapped)
- return -ENXIO;
+ goto up_and_out;
if (!s->dma_dac2.ready && (ret = prog_dmabuf_dac2(s)))
- return ret;
- if (!access_ok(VERIFY_READ, buffer, count))
- return -EFAULT;
+ goto up_and_out;
+ if (!access_ok(VERIFY_READ, buffer, count)) {
+ ret = -EFAULT;
+ goto up_and_out;
+ }
+
ret = 0;
add_wait_queue(>dma_dac2.wait, );
while (count > 0) {
@@ -1443,12 +1475,14 @@
ret = -EAGAIN;
break;
}
+ up(>sem);
schedule();
if (signal_pending(current)) {
if (!ret)
ret = -ERESTARTSYS;
- break;
+ goto out;
}
+ down(>sem);
continue;
}
if (copy_from_user(s->dma_dac2.rawbuf + swptr, buffer, cnt)) {
@@ -1468,9 +1502,15 @@
if (s->dma_dac2.enabled)
start_dac2(s);
}
+ up(>sem);
+
+out:
remove_wait_queue(>dma_dac2.wait, );
set_current_state(TASK_RUNNING);
return ret;
+up_and_out:
+
Re: [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis
On Fri, 1 Jun 2001, Bogdan Costescu wrote: > On Fri, 1 Jun 2001, jamal wrote: > > > One idea i have been toying with is to maintain hysteris or threshold of > > some form in dev_watchdog; > > AFAIK, dev_watchdog is right now used only for Tx (if I'm wrong, please > correct me!). So how do you sense link loss if you expect only high Rx > traffic ? > Good question. Makes me think. Thoughts further below. > > example: if watchdog timer expires threshold times, you declare the link > > dead and send netif_carrier_off netlink message. > > On recovery, you send netif_carrier_on > > I assume that you mean "on recovery" as in "first succesful hard_start_xmit". > right. > > Assumption: > > If the tx path is blocked, more than likely the link is down. > > Yes, but is this a good approximation ? I'm not saying that it's not, I'm > merely asking for counter-arguments. It is an indirect approximation. Note that if the system data is very asymetrical as in the case you pointed out, notification will take a long long time. You need a plan B. Still, the tx watchdogs are a good source of fault detection in the case of non-availabilty of MII detection and even with the presence of MII. I hate making this more complex than it should be: Since we already have a messaging system within the kernel and user<->kernel space aka "netlink" -- one could easily add a protocol in user space which "dynamically heartbeats" the devices. Control should come from user space; it would be a great idea to avoid ioctls. "Dynamic" in the above sense means trying to totaly avoid making it a synchronous poll. The poll rate is a function of how many packets go out that device per average measurement time. Basically, the period that the user space app dumps "hello" netlink packets to the kernel is a variable. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA timer bugfix, patch for 2.4.5
Hi!
I have compiled a little patch that contains the VIA timer bugfix (from the ac
kernel). the patch is against linus' 2.4.5 kernel. I have compiled and ran the patched
kernel sucessfully.
the only changes made by this patch are done to linux/arch/i386/kernel/timer.c
I would like to have this patch applied to linus' kernel tree (so that it comes in
2.4.6), because alan's kernel has USB problems on my machine.
Here's the patch:
--- arch/i386/kernel/time.c.origSat Jun 2 16:06:59 2001
+++ arch/i386/kernel/time.c Sat Jun 2 16:07:20 2001
@@ -178,6 +178,15 @@
jiffies_t = jiffies;
count |= inb_p(0x40) << 8;
+
+/* VIA686a test code... reset the latch if count > max + 1 */
+if (count > LATCH) {
+outb_p(0x34, 0x43);
+outb_p(LATCH & 0xff, 0x40);
+outb(LATCH >> 8, 0x40);
+count = LATCH - 1;
+}
+
spin_unlock(_lock);
/*
@@ -413,7 +422,7 @@
if (!user_mode(regs))
x86_do_profile(regs->eip);
#else
- if (!smp_found_config)
+ if (!using_apic_timer)
smp_local_timer_interrupt(regs);
#endif
@@ -492,6 +501,24 @@
count = inb_p(0x40);/* read the latched count */
count |= inb(0x40) << 8;
+
+
+/* VIA686a test code... reset the latch if count > max */
+if (count > LATCH-1) {
+static int last_whine;
+outb_p(0x34, 0x43);
+outb_p(LATCH & 0xff, 0x40);
+outb(LATCH >> 8, 0x40);
+count = LATCH - 1;
+if(time_after(jiffies, last_whine))
+{
+printk(KERN_WARNING "probable hardware bug: clock
+timer configuration lost - probably a VIA686a motherboard.\n");
+printk(KERN_WARNING "probable hardware bug: restoring
+chip configuration.\n");
+last_whine = jiffies + HZ;
+}
+}
+
+
spin_unlock(_lock);
count = ((LATCH-1) - count) * TICK_SIZE;
--end of patch---
This is my first patch, i hope it is ok. i followed the instructions in
Documentation/SubmittingPatches to create it.
- Jonas
PS: please CC me any reply, i haven't registered to the mailinglist.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
HANG 2.4.5-ac5: Netfinity 3000 IDE cdrom DMA enable
when dma enabled by default, hangs No time for exact investigation as the computer is here only for installation. There is SMP MB, UP kernel. SCSI HDD IDE CDROM: CRD-8400B,ATAPI CD/DVD-ROM drive hdparm utility says on /dev/hdc: getmultcount getnovers getgeo all failed without DMA, it just works, Elmer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usb mouse problem
Hi! I just installed 2.4.5-ac6 (from 2.4.5). I needed the ac kernel to fix my VIA timer bug. Now, my Intellimouse Explorer (USB) seems to have problems. It doesn't go smooth anymore. when i move the mouse slowly, it does not continually go on the screen. sometimes it stops for some time, just like a dirty ball mouse (mine is an optical one). is there something wrong with the ac kernels? - Jonas. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH 2.4.5.ac6: more Via irq fixes
Attached is a patch against 2.4.5-ac6 which should fix issues with
on-board Via devices and interrupts, particularly on Via SMP machines,
or Via machines that requires 'noapic' or "PNP-OS:No" to be functional.
This has been tested by a user with a Via SMP board under both MPS 1.1
and MPS 1.4, and has been shown to solve the problems he was having with
interrupt delivery. It has also been tested on my dinky, ancient K6-2
laptop to make sure there were no generic Via regressions.
Special thanks again to Adrian Cox, who pointed out the
somewhat-documented fact that PCI_INTERRUPT_LINE is not merely a
scratchpad register for the on-board Via devices. Since we blindly
write the values from IO-APIC into PCI_INTERRUPT_LINE, whose irq values
can exceed the register limit of 14, this caused some chaos for Via
users.
This patch also moves the Via ACPI to drivers/pci/quirks.c, because Via
ACPI is not x86 only, and it updates some comments and adds a helpful
printk.
2.5/LATE 2.4 NOTE: As Linus has pointed out, we really need
infrastructure to have different interrupt routers on a per-device
basis. If you look through the PCI quirks in the arch and generic code,
you see code working around this lack of infrastructure, sometimes in
really ugly ways.
--
Jeff Garzik | Echelon words of the day, from The Register:
Building 1024| FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26
MandrakeSoft | Steak Knife Kill the President anarchy echelon
| nuclear assassinate Roswell Waco World Trade Center
diff -urN linux.ac6/arch/i386/kernel/pci-pc.c linux.viairq/arch/i386/kernel/pci-pc.c
--- linux.ac6/arch/i386/kernel/pci-pc.c Sat May 26 18:44:02 2001
+++ linux.viairq/arch/i386/kernel/pci-pc.c Sat Jun 2 09:05:03 2001
@@ -940,18 +940,6 @@
pcibios_max_latency = 32;
}
-static void __init pci_fixup_via_acpi(struct pci_dev *d)
-{
- /*
-* VIA ACPI device: IRQ line in PCI config byte 0x42
-*/
- u8 irq;
- pci_read_config_byte(d, 0x42, );
- irq &= 0x0f;
- if (irq && (irq != 2))
- d->irq = irq;
-}
-
static void __init pci_fixup_piix4_acpi(struct pci_dev *d)
{
/*
@@ -1002,8 +990,6 @@
{ PCI_FIXUP_HEADER, PCI_ANY_ID, PCI_ANY_ID,
pci_fixup_ide_bases },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_5597,
pci_fixup_latency },
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_SI, PCI_DEVICE_ID_SI_5598,
pci_fixup_latency },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_3,
pci_fixup_via_acpi },
- { PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4,
pci_fixup_via_acpi },
#if 0
/* This seems completely bogus so I am removing it -- Alan */
{ PCI_FIXUP_HEADER, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C691,
pci_fixup_via691 },
diff -urN linux.ac6/drivers/pci/quirks.c linux.viairq/drivers/pci/quirks.c
--- linux.ac6/drivers/pci/quirks.c Thu May 17 13:11:23 2001
+++ linux.viairq/drivers/pci/quirks.c Sat Jun 2 09:04:33 2001
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#undef DEBUG
@@ -267,6 +268,9 @@
/*
* VIA 686A/B: If an IO-APIC is active, we need to route all on-chip
* devices to the external APIC.
+ *
+ * TODO: When we have device-specific interrupt routers,
+ * this code will go away from quirks.
*/
static void __init quirk_via_ioapic(struct pci_dev *dev)
{
@@ -277,6 +281,9 @@
else
tmp = 0x1f; /* all known bits (4-0) routed to external APIC */
+ printk(KERN_INFO "PCI: %sbling Via external APIC routing\n",
+ tmp == 0 ? "Disa" : "Ena");
+
/* Offset 0x58: External APIC IRQ output control */
pci_write_config_byte (dev, 0x58, tmp);
}
@@ -285,6 +292,56 @@
/*
+ * Via 686A/B: The PCI_INTERRUPT_LINE register for the on-chip
+ * devices, USB0/1, AC97, MC97, and ACPI, has an unusual feature:
+ * when written, it makes an internal connection to the PIC.
+ * For these devices, this register is defined to be 4 bits wide.
+ * Normally this is fine. However for IO-APIC motherboards, or
+ * non-x86 architectures (yes Via exists on PPC among other places),
+ * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
+ * interrupts delivered properly.
+ *
+ * TODO: When we have device-specific interrupt routers,
+ * quirk_via_irqpic will go away from quirks.
+ */
+
+/*
+ * FIXME: it is questionable that quirk_via_acpi
+ * is needed. It shows up as an ISA bridge, and does not
+ * support the PCI_INTERRUPT_LINE register at all. Therefore
+ * it seems like setting the pci_dev's 'irq' to the
+ * value of the ACPI SCI interrupt is only done for convenience.
+ * -jgarzik
+ */
+static void __init quirk_via_acpi(struct pci_dev *d)
+{
+ /*
+* VIA ACPI device: SCI IRQ line in PCI config byte 0x42
+*/
+ u8 irq;
+
Re: [2.4.5 and all ac-Patches] massive file corruption with reiser or NFS
Am Samstag, 2. Juni 2001 12:52 schrieb Rasmus Bøg Hansen: > On Sat, 2 Jun 2001, Andreas Hartmann wrote: > > I got massive file corruptions with the kernels mentioned in the subject. > > I can reproduce it every time. > > You cannot use NFS on reiserfs unless you apply the knfsd patch. Look at > www.namesys.com. Thank you very much for your advice. I tested your suggestion and run the machine without NFS-mounted devices - it seems to be working fine. Anyway - I'm wondering why I didn't get any problem until 2.4.4ac10 with this configuration without the appropriate patch on the client or on the server? I'm a little bit confused now about this patch. Do I need this knfsd-patch for the NFS-server or just for the clients or for both? Thank you for your advice, Andreas Hartmann - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CUV4X-D lockup on boot
Further information:
I inserted some printk()s in arch/i386/kernel/smpboot.c
320 static void __init synchronize_tsc_ap (void)
321 {
322 int i;
323
324 /*
325* smp_num_cpus is not necessarily known at the time
326* this gets called, so we first wait for the BP to
327* finish SMP initialization:
328*/
329 printk("ap %d\n", __LINE__);
330 while (!atomic_read(_start_flag)) mb();
331 printk("ap %d\n", __LINE__);
332
333 for (i = 0; i < NR_LOOPS; i++) {
334 atomic_inc(_count_start);
335 printk("ap %d\n", __LINE__);
...
When the kernel locks up it does so after line 329 is printk'd
However, on a successful boot it behaves as follows:
...
Intel machine check reporting enabled on CPU#1.
CPU: After vendor init, caps: 0383fbff
CPU: After generic, caps: 0383fbff
CPU: Common caps: 0383fbff
ap 329
OK.
CPU1: Intel Pentium III (Coppermine) stepping 06
CPU has booted.
Before bogomips.
Total of 2 processors activated (3742.10 BogoMIPS).
Before bogocount - setting activated=1.
Boot done.
ENABLING IO-APIC IRQs
...changing IO-APIC physical APIC ID to 2 ... ok.
Synchronizing Arb IDs.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-10, 2-13, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
number of MP IRQ sources: 21.
number of IO-APIC #2 registers: 24.
testing the IO APIC...
IO APIC #2..
register #00: 0200
...: physical APIC id: 02
register #01: 00178011
... : max redirection entries: 0017
... : IO APIC version: 0011
WARNING: unexpected IO-APIC, please mail
to [EMAIL PROTECTED]
register #02:
... : arbitration: 00
IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 003 03 011 1 11131
01 003 03 000 0 01139
02 003 03 000 0 01131
03 003 03 000 0 01141
04 003 03 000 0 01149
05 003 03 000 0 01151
06 003 03 000 0 01159
07 003 03 000 0 01161
08 003 03 000 0 01169
09 003 03 000 0 01171
0a 000 00 100 0 00000
0b 003 03 000 0 01179
0c 003 03 000 0 01181
0d 000 00 100 0 00000
0e 003 03 000 0 01189
0f 003 03 000 0 01191
10 003 03 110 1 01199
11 003 03 110 1 011A1
12 003 03 110 1 011A9
13 003 03 110 1 011B1
14 000 00 100 0 00000
15 000 00 100 0 00000
16 000 00 100 0 00000
17 000 00 100 0 00000
IRQ to pin mappings:
IRQ0 -> 0-> 2
IRQ1 -> 1
IRQ3 -> 3
IRQ4 -> 4
IRQ5 -> 5
IRQ6 -> 6
IRQ7 -> 7
IRQ8 -> 8
IRQ9 -> 9
IRQ11 -> 11
IRQ12 -> 12
IRQ14 -> 14
IRQ15 -> 15
IRQ16 -> 16
IRQ17 -> 17
IRQ18 -> 18
IRQ19 -> 19
done.
calibrating APIC timer ...
. CPU clock speed is 937.5342 MHz.
. host bus clock speed is 133.9332 MHz.
cpu: 0, clocks: 1339332, slice: 446444
CPU0
cpu: 1, clocks: 1339332, slice: 446444
CPU1
checking TSC synchronization across CPUs: ap 331
ap 335
ap 337
ap 340
ap 345
ap 347
ap 335
ap 337
ap 340
ap 345
ap 347
ap 335
ap 337
ap 340
ap 345
ap 347
ap 335
ap 337
ap 340
ap 345
ap 347
ap 335
ap 337
ap 340
ap 345
ap 347
BIOS BUG: CPU#0 improperly initialized, has -16 usecs TSC skew! FIXED.
BIOS BUG: CPU#1 improperly initialized, has 16 usecs TSC skew! FIXED.
Setting commenced=1, go go go
...
A notable difference is:
Synchronizing Arb IDs.
init IO_APIC IRQs
IO-APIC (apicid-pin) 2-10, 2-13, 2-20, 2-21, 2-22, 2-23 not connected.
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
whereas in a lockup the following occurs:
Synchronizing Arb IDs.
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
i.e. before the init IO_APIC IRQs
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: rtl8139too in 2.4.5
[EMAIL PROTECTED] wrote:
>
> My RTL8139 (Identified 8139 chip type 'RTL-8139A')
> was fine in 2.4.3 and doesnt work in 2.4.5.
> Copying the 2.4.3 version of 8139too.c makes things work again.
>
> Since lots of people complained about this, I have not tried to
> debug - maybe a fixed version already exists?
>
> One remark:
> 2.4.5 says "eth1: media is unconnected, link down, or incompatible connection"
> coming from 8139too.c line 1367. The code there is
>
> if (mii_reg5) {
> printk(KERN_INFO"%s: Setting %s%s-duplex based on"
> " auto-negotiated partner ability %4.4x.\n", dev->name,
> mii_reg5 == 0 ? "" :
> (mii_reg5 & 0x0180) ? "100mbps " : "10mbps ",
> tp->full_duplex ? "full" : "half", mii_reg5);
> } else {
> printk(KERN_INFO"%s: media is unconnected, link down, "
> "or incompatible connection\n",
> dev->name);
> }
>
> where mii_reg5 is tested against zero inside a conditional
> where we know that it is nonzero.
> Probably the outer test is wrong.
good spotting, though, it's the inner test that's wrong, and surrounding
logic. If the link partner is not advertising anything at all, mii_reg5
will be zero. But, if we are forcing media type, mii_reg5 might be zero
and we don't care, so people get a misinformative message. Not the core
problem (working on it) but a bug nonetheless.
Jeff
--
Jeff Garzik | Echelon words of the day, from The Register:
Building 1024| FRU Lebed HALO Spetznaz Al Amn al-Askari Glock 26
MandrakeSoft | Steak Knife Kill the President anarchy echelon
| nuclear assassinate Roswell Waco World Trade Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
rtl8139too in 2.4.5
My RTL8139 (Identified 8139 chip type 'RTL-8139A')
was fine in 2.4.3 and doesnt work in 2.4.5.
Copying the 2.4.3 version of 8139too.c makes things work again.
Since lots of people complained about this, I have not tried to
debug - maybe a fixed version already exists?
One remark:
2.4.5 says "eth1: media is unconnected, link down, or incompatible connection"
coming from 8139too.c line 1367. The code there is
if (mii_reg5) {
printk(KERN_INFO"%s: Setting %s%s-duplex based on"
" auto-negotiated partner ability %4.4x.\n", dev->name,
mii_reg5 == 0 ? "" :
(mii_reg5 & 0x0180) ? "100mbps " : "10mbps ",
tp->full_duplex ? "full" : "half", mii_reg5);
} else {
printk(KERN_INFO"%s: media is unconnected, link down, "
"or incompatible connection\n",
dev->name);
}
where mii_reg5 is tested against zero inside a conditional
where we know that it is nonzero.
Probably the outer test is wrong.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Interface "type".
Haseeb Budhani <[EMAIL PROTECTED]> ecrit : [...] > I have a fairly quick one: Is there an ioctl flag/call which can be used > to find out the "type" of the interface being used ? See net/core/dev.c:dev_ifsioc + SIOCGIFHWADDR + include/linux/if_arp.h + google/search?q=linux+ioctl+device+hardware+type=Google+Search + man ioctl_list -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problem with kernel 2.2.19 Ultra-DMA and SMP, once more
Hi Andre, The motherboard has VIA-chipset. What does this mean for me? Will the APIC-problems be solved in the future or do I have to deside upon running "noapic" semi-crippled or not run Ultra-DMA? _\\|//_ (-0-0-) /---ooO-(_)-Ooo--\ | Magnus SandbergEmail: [EMAIL PROTECTED] | | Network Engineer, Bluelabs http://www.bluelabs.se/ | | Phone: +46-8-470 2155(FAX: +46-8-470 2199)GSM: +46-708-225 805 | \/ || || ooO Ooo - On 1st of June 2001 Andre Hedrick wrote; - If this is a VIA SMP system there are APIC problems that you do not want to even think about addressing. MPS1.1 and passing "noapic" will fix most of there mess, but you have a semi-crippled system, but it runs. On Fri, 1 Jun 2001 [EMAIL PROTECTED] wrote: > Hi once more... > > I'm sorry for the layout of this mail. It is written in a web mail > system... > The attachements are in ASCII format even if the web-mail make it base-64 > > Now I have compiled a vanilla 2.2.19 kernel and have SMP working, without > Ultra-DMA. I used the functional kernel config from 2.2.19-ide and just > activated SMP. > > >From that I have 3 very simular kernel configurations: > 2.2.19 with Hidrick's IDE-patch, no SMP: working > 2.2.19 without IDE-patch, with SMP: working > 2.2.19 with IDE-patch and SMP: not booting > > With all the information I hope that someone can help me with the > IDE-and-SMP problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5 and all ac-Patches] massive file corruption with reiseror NFS
On Sat, 2 Jun 2001, Andreas Hartmann wrote: > I got massive file corruptions with the kernels mentioned in the subject. I > can reproduce it every time. You cannot use NFS on reiserfs unless you apply the knfsd patch. Look at www.namesys.com. Rasmus -- -- [ Rasmus 'Møffe' Bøg Hansen ] -- If you only have a hammer everything looks like a nail [ moffe at amagerkollegiet dot dk ] --0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Address
> Under which directory is the Linus's kernel? ftp://ftp.kernel.org/pub/linux/kernel/v2.[24] .R.V. -- _ |-| __ Robert Vojta -= Oo.oO =- |=| [Ll] IPEX, s.r.o. "^" `o PGP signature
[2.4.5 and all ac-Patches] massive file corruption with reiser or NFS
Hallo all, I got massive file corruptions with the kernels mentioned in the subject. I can reproduce it every time. What did I do? The kernel can't find files or directories which have been created seconds before. If I start configure of some program for example, the conftest-Directory can't be found again which is created during configure; datas can't be read in files (if it could open the file). I'm than getting an IO-error. No matter if it's local on reiser or remote via NFS. Always the same problem. If you want to mount some partitions, like mount /boot, the /boot-Directory can't be found (IO-error). If you try it again and again, it will suddenly work :-(. I tried to compile the 2.4.5ac6-Kernel under itself. It ended in massive errors while reading the sources. I rebooted the machine (with a lot of errors while unmounting) with kernel 2.2.19 and tried to compile the above mentioned kernel again. I got a lot of other errors -> 2.4.5 destroyed the files! I had to do a rm -R to get rid of the whole tree. After newcreation of the tree, the compiling under kernel 2.2.19 worked fine. I tried to compile the kernel with egcs 1.1.2 and gcc 2.95.3 - no matter. I tried to compile with or without APIC - no matter. Do you have any suggestions how to compile the kernel to get it working and to locate the problem? Some additional infos to my machine: 512 MB RAM AMD Athlon 800 no overclocking lspci -v 00:00.0 Host bridge: VIA Technologies, Inc. VT8371 [KX133] (rev 02) Flags: bus master, medium devsel, latency 0 Memory at d600 (32-bit, prefetchable) Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: VIA Technologies, Inc. VT8371 [PCI-PCI Bridge] (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, medium devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: c000-cfff Memory behind bridge: d400-d5ff Prefetchable memory behind bridge: d000-d3ff Capabilities: [80] Power Management version 2 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super] (rev 22) Subsystem: VIA Technologies, Inc. VT82C686/A PCI to ISA Bridge Flags: bus master, stepping, medium devsel, latency 0 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586 IDE [Apollo] (rev 10) (prog-if 8a [Master SecP PriP]) Flags: bus master, medium devsel, latency 32 I/O ports at d000 Capabilities: [c0] Power Management version 2 00:07.2 USB Controller: VIA Technologies, Inc. VT82C586B USB (rev 10) (prog-if 00 [UHCI]) Subsystem: Unknown device 0925:1234 Flags: bus master, medium devsel, latency 32, IRQ 9 I/O ports at d400 Capabilities: [80] Power Management version 2 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) Flags: medium devsel Capabilities: [68] Power Management version 2 00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 [Apollo Super AC97/Audio] (rev 20) Subsystem: VIA Technologies, Inc.: Unknown device 4511 Flags: medium devsel, IRQ 5 I/O ports at dc00 I/O ports at e000 I/O ports at e400 Capabilities: [c0] Power Management version 2 00:08.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet (rev 02) Subsystem: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet Adapter Flags: bus master, medium devsel, latency 32, IRQ 10 I/O ports at e800 Memory at d900 (32-bit, non-prefetchable) Capabilities: [40] Power Management version 1 00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RT8139 Flags: bus master, medium devsel, latency 32, IRQ 11 I/O ports at ec00 Memory at d9001000 (32-bit, non-prefetchable) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF (prog-if 00 [VGA]) Subsystem: ATI Technologies Inc: Unknown device 0008 Flags: bus master, stepping, 66Mhz, medium devsel, latency 32, IRQ 10 Memory at d000 (32-bit, prefetchable) I/O ports at c000 Memory at d500 (32-bit, non-prefetchable) Capabilities: [50] AGP version 2.0 Capabilities: [5c] Power Management version 2 My .config-file (without the options wich have not set): # # Automatically generated by make menuconfig: don't edit # CONFIG_X86=y CONFIG_ISA=y CONFIG_UID16=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y # # Loadable module support # CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y # # Processor type and features # CONFIG_MK7=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y
query
Hi All, i'm writing a file system code, i've a query regarding that, i want you to help me out if possible, is it possible to get the absolute mount point of a device at run time in that code ? if it is possible then how we can get it ? i'll be thankful. Regards Chanchal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Makefile/Config flaw
Compiling 2.4.5 with CONFIG_USB=y and CONFIG_PCI not set fails with drivers/usb/usbdrv.o: undefined reference to `pci_pool_*'. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5-ac5 locks on ReiserFS umount (ac4 doesn't)
On Fri, 1 Jun 2001 18:34:46 -0400 (EDT) Pavel Roskin <[EMAIL PROTECTED]> wrote: > Another problem is that the archive at > http://www.uwsg.indiana.edu/hypermail/linux/kernel/ updates only once a > day. I checked it and decided that my information could still be useful. > > I'd be grateful if somebody pointed me to a better archive. Try http://www.lib.uaa.alaska.edu/linux-kernel/ - it updates in pretty close to real-time, and you can search the archives as well. Bruce - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch][CFT] Re: via-rhine DFE-530TX rev A1
> >Are you sure. What's the version of your driver. Please tell me. It's
> >important.
> >I remember we have fixed it already.
>
> The driver version (dlkfet.sys) is 2.52 from 08/06/2000. this is the lastest
> driver from the original dlink site.
Perhaps Yiping Chen was talking about a D-Link linux driver?
David Vrabel has found a D-Link driver ("1.11") based on Donald Beckers
that fixes the "00:00:00:00:00 after rebooting from win98" problem.
Here is a patch vs 2.4.5-ac4 that may fix this (if I didn't break it).
http://www.hojdpunkten.ac.se/054/via-rhine-2.4.5-ac4-dlink-3.patch
Please test and let me know if it works. It should apply vs any 2.4.5*
kernel. I have added those that I know have reported this problem before
to the Cc list.
What the driver does differently at init time is disable wake-on-lan and
power-management-events and then reload the MAC Address from EEPROM.
The reload code is also in the latest test version (1.10) from Donald
Becker at www.scyld.com, and that is the code I have used with slight
modification. I don't know if reloading from EEPROM alone is enough to fix
the 00:00:00:00:00 bug.
There is also a minor thing with 0x01 being a reserved bit in TxConfig,
that should probably be 0x02 to set it to loopback.
The D-Link driver has some other changes for various things. I have been
unable to find the driver on dlinks site, but I have the copy David sent
me:
http://www.hojdpunkten.ac.se/054/via-rhineb1.zip
/Urban
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
CUV4X-D lockup on boot
I have an ASUS CUV4X-D Dual Processor Mainboard based on a VIA
694XDP chipset. I notice from the archives that someone else
has also reported a lockup with the m/b when using two cpus
and have some info that may be useful to track it down.
Using kernel 2.4.5 the kernel locks up sporadically at boot
time. When I enable the NMI watchdog it occasionally gets
enabled prior to the lockup and perhaps can be useful for
debugging the problem. Here's what happens:
I typed this in, so there may be typos:
..TIMER: vector=49 pin1=2 pin2=0
activating NMI Watchdog ... done.
[locks up here, or before activating NMI watchdog]
[this normally happens next but not in this case
number of MP IRQ sources: 21.
number of IO-APIC #2 registers: 24.
testing the IO APIC...
]
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU : 1
EIP: 0010:[]
EFLAGS: 0246
eax: ebx: ecx: 0001 edx: 0001
esi: edi: ebp: esp: cfff5fa4
ds: 0018 es: 0018 ss: 0018
Process swapper (pid: 0, stackpage = cfff5000)
Stack: c0235e8f 0001 0002 c0235eaa
0019 c1442000 2700 b00f
000d 000e c00bcf60 c0172029
Call Trace: []
Code: 85 c0 74 bf 00 e0 ff ff 21 e7 31 f6 bd 10 00 00 00 31 db
Console shuts up ...
[ksymoops output]
Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not
found in System.map. Ignoring ksyms_base entry
activating NMI Watchdog ... done.
[locks up here, or before activating NMI watchdog]
NMI Watchdog detected LOCKUP on CPU1, registers:
EIP: 0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 0246
eax: ebx: ecx: 0001 edx: 0001
esi: edi: ebp: esp: cfff5fa4
ds: 0018 es: 0018 ss: 0018
Stack: c0235e8f 0001 0002 c0235eaa
0019 c1442000 2700 b00f
000d 000e c00bcf60 c0172029
Call Trace: []
Code: 85 c0 74 bf 00 e0 ff ff 21 e7 31 f6 bd 10 00 00 00 31 db
>>EIP; c0235cdb<=
Trace; c0172029
Code; c0235cdb
<_EIP>:
Code; c0235cdb<=
0: 85 c0 test %eax,%eax <=
Code; c0235cdd
2: 74 bf je ffc3 <_EIP+0xffc3> c0235c9e
Code; c0235cdf
4: 00 e0 add%ah,%al
Code; c0235ce1
6: ff(bad)
Code; c0235ce2
7: ff 21 jmp*(%ecx)
Code; c0235ce4
9: e7 31 out%eax,$0x31
Code; c0235ce6
b: f6 bd 10 00 00 00 idiv 0x10(%ebp),%al
Code; c0235cec
11: 31 db xor%ebx,%ebx
2 warnings issued. Results may not be reliable.
# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping: 6
cpu MHz : 937.557
cache size : 256 KB
fdiv_bug: no
hlt_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 sse
bogomips: 1867.77
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping: 6
cpu MHz : 937.557
cache size : 256 KB
fdiv_bug: no
hlt_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 sse
bogomips: 1874.32
If this doesn't make someone go "aha!" then I can set up a serial
port for debugging and repeat this a few times.
Thanks,
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] interrupt problem with MPS 1.4 / not with MPS 1.1 ?
On Sat, Jun 02, 2001 at 03:41:08AM -0400, Jeff Garzik wrote: > > No, I'm afraid it doesn't :-( > > > Thanks for testing. > > Ok, how about this one? This is a more simple version of the logic > presented, which should give you the value that Manfred asked you plug > in manually. > No go, I'm afraid. I wonder why I do see the PCI: Disabling Via external APIC routing messages, but none of the PCI: Via IRQ fixup ... messages that I assume should have been printed Greetings, Jurriaan Total of 2 processors activated (2808.21 BogoMIPS). ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-15, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 number of MP IRQ sources: 22. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00178011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 003 03 000 0 01139 02 003 03 000 0 01131 03 003 03 000 0 01141 04 003 03 000 0 01149 05 000 00 100 0 00000 06 003 03 000 0 01151 07 003 03 000 0 01159 08 003 03 000 0 01161 09 003 03 000 0 01169 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 003 03 000 0 01171 0d 003 03 000 0 01179 0e 003 03 000 0 01181 0f 000 00 100 0 00000 10 003 03 110 1 01189 11 003 03 110 1 01191 12 003 03 110 1 01199 13 003 03 110 1 011A1 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ18 -> 0:18 IRQ19 -> 0:19 done. Using local APIC timer interrupts. calibrating APIC timer ... . CPU clock speed is 703.1867 MHz. . host bus clock speed is 100.4552 MHz. cpu: 0, clocks: 1004552, slice: 334850 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I10,P0) -> 17 PCI->APIC IRQ transform: (B0,I11,P0) -> 17 PCI->APIC IRQ transform: (B0,I14,P0) -> 18 PCI->APIC IRQ transform: (B1,I0,P0) -> 16 PCI->APIC IRQ transform: (B2,I0,P0) -> 16 PCI->APIC IRQ transform: (B2,I1,P0) -> 17 PCI->APIC IRQ transform: (B2,I2,P0) -> 18 PCI: Disabling Via external APIC routing Linux NET4.0 for Linux 2.4 i2c-core.o: adapter MAVEN:fb0 on i2c-matroxfb registered as adapter 2. usb.c: registered new driver hub uhci.c: USB UHCI at I/O 0xa000, IRQ 19 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected uhci.c: USB UHCI at I/O 0xa400, IRQ 19 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected uhci.c: Linus Torvalds, Johannes Erdfelt, Randy Dunlap, Georg Acher, Deti Fliegl, Thomas Sailer, Roman Weissgaerber uhci.c: USB Universal Host Controller Interface driver Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 hub.c: USB new device connect on bus1/1, assigned device number 2 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=2 (error=-110) hub.c: USB new device connect on bus1/1, assigned device number 3 reiserfs: checking transaction log (device 03:0a) ... Using r5 hash to sort names ReiserFS version 3.6.25 reiserfs: checking transaction log (device 21:04) ... Using r5 hash to sort names ReiserFS version 3.6.25 usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=3 (error=-110) reiserfs: checking transaction log (device 22:03) ... Using r5 hash to sort names CPU0 CPU1 0: 4964 8776IO-APIC-edge timer 1: 33 34IO-APIC-edge keyboard 2: 0 0 XT-PIC cascade 8:
about mips linux root file system
Hi, all, I am new to this mail list. Our university are porting linux to our mips evaluation board. There is no network card and CDROM driver can not work under linux. But we have serail port, I can download our modified kernel to evaluation board, and it can run, stop at mount root file system. I think if I can use ramdisk using serail port. I do not know how to combine kernel image with ramdisk root file image. And where can I get small size root file image for mipsel? If someone knows, please help me. Thanks in advance! Barry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] interrupt problem with MPS 1.4 / not with MPS 1.1 ?
> On Fri, Jun 01, 2001 at 04:42:40PM -0400, Jeff Garzik wrote:
> > Does this patch fix things for you, such that MPS 1.1 and MPS 1.4 both
> > work?
>
> No, I'm afraid it doesn't :-(
>
> Here are the dmesg (with some info cut out for brevity), the
> /proc/interrupts and the lspci -vvvxxx from a 2.4.5-ac6 kernel with this
> patch. I see in the dmesg the patch is active, but still I get:
Thanks for testing.
Ok, how about this one? This is a more simple version of the logic
presented, which should give you the value that Manfred asked you plug
in manually.
--
Jeff Garzik | Disbelief, that's why you fail.
Building 1024|
MandrakeSoft |
diff -urN linux-2.4.5/drivers/pci/quirks.c linux.viairq/drivers/pci/quirks.c
--- linux-2.4.5/drivers/pci/quirks.cSat May 19 20:43:06 2001
+++ linux.viairq/drivers/pci/quirks.c Sat Jun 2 03:38:48 2001
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#undef DEBUG
@@ -267,6 +268,8 @@
/*
* VIA 686A/B: If an IO-APIC is active, we need to route all on-chip
* devices to the external APIC.
+ *
+ * TODO: this should be done at IRQ assign time (pci_enable_device call)
*/
static void __init quirk_via_ioapic(struct pci_dev *dev)
{
@@ -277,6 +280,9 @@
else
tmp = 0x1f; /* all known bits (4-0) routed to external APIC */
+ printk(KERN_INFO "PCI: %sbling Via external APIC routing\n",
+ tmp ? "Disa" : "Ena");
+
/* Offset 0x58: External APIC IRQ output control */
pci_write_config_byte (dev, 0x58, tmp);
}
@@ -285,6 +291,34 @@
/*
+ * Via 686A/B: The PCI_INTERRUPT_LINE register for the on-chip
+ * devices, USB0/1, AC97, MC97, and ACPI, has an unusual feature:
+ * when written, it makes an internal connection to the PIC.
+ * For these devices, this register is defined to be 4 bits wide.
+ * Normally this is fine. However for IO-APIC motherboards, or
+ * non-x86 architectures (yes Via exists on PPC among other places),
+ * we must mask the PCI_INTERRUPT_LINE value versus 0xf to get
+ * interrupts delivered properly.
+ *
+ * TODO: this should be done at IRQ assign time (pci_enable_device call)
+ */
+static void __init quirk_via_irqpic(struct pci_dev *dev)
+{
+ u8 irq, new_irq;
+
+ pci_read_config_byte(dev, PCI_INTERRUPT_LINE, );
+ new_irq = irq & 0xf;
+ if (new_irq != irq) {
+ printk(KERN_INFO "PCI: Via IRQ fixup for %s, from %d to %d\n",
+ dev->slot_name, irq, new_irq);
+
+ udelay(15);
+ pci_write_config_byte(dev, PCI_INTERRUPT_LINE, new_irq);
+ }
+}
+
+
+/*
* PIIX3 USB: We have to disable USB interrupts that are
* hardwired to PIRQD# and may be shared with an
* external device.
@@ -372,6 +406,11 @@
#ifdef CONFIG_X86_IO_APIC
{ PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686,
quirk_via_ioapic },
#endif
+
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C586_2,
+ quirk_via_irqpic },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_4,
+ quirk_via_irqpic },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_5,
+ quirk_via_irqpic },
+ { PCI_FIXUP_FINAL, PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_82C686_6,
+ quirk_via_irqpic },
{ 0 }
};
diff -urN linux-2.4.5/drivers/sound/via82cxxx_audio.c
linux.viairq/drivers/sound/via82cxxx_audio.c
--- linux-2.4.5/drivers/sound/via82cxxx_audio.c Tue May 1 19:05:00 2001
+++ linux.viairq/drivers/sound/via82cxxx_audio.cFri Jun 1 16:32:25 2001
@@ -3012,7 +3012,6 @@
{
int rc;
struct via_info *card;
- u8 tmp;
static int printed_version = 0;
DPRINTK ("ENTER\n");
@@ -3107,19 +3106,6 @@
if (rc) {
printk (KERN_ERR PFX "interrupt init failed, aborting\n");
goto err_out_have_proc;
- }
-
- pci_read_config_byte (pdev, 0x3C, );
- if ((tmp & 0x0F) != pdev->irq) {
- printk (KERN_WARNING PFX "IRQ fixup, 0x3C==0x%02X\n", tmp);
- udelay (15);
- tmp &= 0xF0;
- tmp |= pdev->irq;
- pci_write_config_byte (pdev, 0x3C, tmp);
- DPRINTK ("new 0x3c==0x%02x\n", tmp);
- } else {
- DPRINTK ("IRQ reg 0x3c==0x%02x, irq==%d\n",
- tmp, tmp & 0x0F);
}
printk (KERN_INFO PFX "board #%d at 0x%04lX, IRQ %d\n",
SCSI-CD-Writer don't show up
#Include I have 3 SCSI-CD-Writers. "Strange" is that the boot-process only finds the first one (1 0 5 0), the other two i have to add with echo "scsi add-single-device 2 0 4 0" > /proc/scsi/scsi echo "scsi add-single-device 2 0 6 0" > /proc/scsi/scsi to make them useable. Here is the complete ist of my SCSI-Devices: Host: scsi0 Channel: 00 Id: 06 Lun: 00 Vendor: IBM Model: DDYS-T18350N Rev: S93E Type: Direct-AccessANSI SCSI revision: 03 Host: scsi1 Channel: 00 Id: 00 Lun: 00 Vendor: PLEXTOR Model: CD-ROM PX-32TS Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 01 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-303 Rev: 1.10 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi1 Channel: 00 Id: 05 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0N Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 02 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 03 Lun: 00 Vendor: PIONEER Model: DVD-ROM DVD-304 Rev: 1.03 Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 04 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0K Type: CD-ROM ANSI SCSI revision: 02 Host: scsi2 Channel: 00 Id: 06 Lun: 00 Vendor: TEAC Model: CD-R58S Rev: 1.0P Type: CD-ROM ANSI SCSI revision: 02 I have a "Symbios 53c1010 (Dual Channel Ultra 160)" and a "NCR 810a" The two devices which are not found are connected through adapters onto the second channel of the Symbios 53c1010. Kernel is 2.4.4 or 2.4.5ac6. As host-adapter-driver i use the "SYM53C8XX"-driver If other info is needed, no problem. :-) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] interrupt problem with MPS 1.4 / not with MPS 1.1 ?
On Fri, Jun 01, 2001 at 04:42:40PM -0400, Jeff Garzik wrote: > Does this patch fix things for you, such that MPS 1.1 and MPS 1.4 both > work? No, I'm afraid it doesn't :-( Here are the dmesg (with some info cut out for brevity), the /proc/interrupts and the lspci -vvvxxx from a 2.4.5-ac6 kernel with this patch. I see in the dmesg the patch is active, but still I get: usb.c: registered new driver hub usb.c: new USB bus registered, assigned bus number 1 usb.c: new USB bus registered, assigned bus number 2 usb.c: registered new driver usb-storage usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=2 (error=-110) usb_control/bulk_msg: timeout usb.c: USB device not accepting new address=3 (error=-110) Good luck, Jurriaan D APIC at: 0xFEE0 Processor #0 Pentium(tm) Pro APIC version 17 Processor #1 Pentium(tm) Pro APIC version 17 I/O APIC #2 Version 17 at 0xFEC0. Processors: 2 Kernel command line: auto BOOT_IMAGE=SuSE-2.4.5ac6 ro root=2101 BOOT_FILE=/boot/prod/vmlinuz-245ac6 video=matrox:vesa:0x11E,fv:80,sgram Initializing CPU#0 Detected 703.169 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1402.47 BogoMIPS Total of 2 processors activated (2808.21 BogoMIPS). ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 2 ... ok. init IO_APIC IRQs IO-APIC (apicid-pin) 2-0, 2-5, 2-10, 2-11, 2-15, 2-20, 2-21, 2-22, 2-23 not connected. ..TIMER: vector=49 pin1=2 pin2=0 number of MP IRQ sources: 22. number of IO-APIC #2 registers: 24. testing the IO APIC... IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 00178011 ... : max redirection entries: 0017 ... : IO APIC version: 0011 WARNING: unexpected IO-APIC, please mail to [EMAIL PROTECTED] register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 100 0 00000 01 003 03 000 0 01139 02 003 03 000 0 01131 03 003 03 000 0 01141 04 003 03 000 0 01149 05 000 00 100 0 00000 06 003 03 000 0 01151 07 003 03 000 0 01159 08 003 03 000 0 01161 09 003 03 000 0 01169 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 003 03 000 0 01171 0d 003 03 000 0 01179 0e 003 03 000 0 01181 0f 000 00 100 0 00000 10 003 03 110 1 01189 11 003 03 110 1 01191 12 003 03 110 1 01199 13 003 03 110 1 011A1 14 000 00 100 0 00000 15 000 00 100 0 00000 16 000 00 100 0 00000 17 000 00 100 0 00000 IRQ to pin mappings: IRQ0 -> 0:2 IRQ1 -> 0:1 IRQ3 -> 0:3 IRQ4 -> 0:4 IRQ6 -> 0:6 IRQ7 -> 0:7 IRQ8 -> 0:8 IRQ9 -> 0:9 IRQ12 -> 0:12 IRQ13 -> 0:13 IRQ14 -> 0:14 IRQ16 -> 0:16 IRQ17 -> 0:17 IRQ18 -> 0:18 IRQ19 -> 0:19 done. Using local APIC timer interrupts. calibrating APIC timer ... . CPU clock speed is 703.0694 MHz. . host bus clock speed is 100.4384 MHz. cpu: 0, clocks: 1004384, slice: 334794 CPU0 cpu: 1, clocks: 1004384, slice: 334794 CPU1 checking TSC synchronization across CPUs: passed. mtrr: your CPUs had inconsistent fixed MTRR settings mtrr: your CPUs had inconsistent variable MTRR settings mtrr: probably your BIOS does not setup all CPUs PCI: PCI BIOS revision 2.10 entry at 0xfb3a0, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I7,P3) -> 19 PCI->APIC IRQ transform: (B0,I10,P0) -> 17 PCI->APIC IRQ transform: (B0,I11,P0) -> 17 PCI->APIC IRQ transform: (B0,I14,P0) -> 18 PCI->APIC IRQ transform: (B1,I0,P0) -> 16 PCI->APIC IRQ transform: (B2,I0,P0) -> 16 PCI->APIC IRQ transform: (B2,I1,P0) -> 17 PCI->APIC IRQ transform: (B2,I2,P0) -> 18 PCI: Setting Via APIC control PCI: Via IRQ fixup for 00:07.2, from 5 to 19 PCI: Via IRQ fixup for 00:07.3, from 5 to 19 PCI: Via IRQ fixup for 00:07.4, from 0 to 3 Linux NET4.0 for Linux 2.4 i2c-core.o: adapter MAVEN:fb0 on i2c-matroxfb registered as adapter 2. usb.c: registered new driver hub uhci.c: USB UHCI at I/O 0xa000, IRQ 19 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected uhci.c: USB UHCI at I/O 0xa400, IRQ 19 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found
Re: [RFC] yet another knfsd-reiserfs patch
Why are people afraid to put Neil Brown's code into 2.4? It works, we have tons
of users using it, it is the only nfs solution that has a tested reiserfs user
base, don't worry that it isn't tested and shouldn't go into 2.4 because it is
better tested than any of these quick fixes that are floated by people afraid of
Neil's code am I missing something?
Hans
Chris Mason wrote:
>
> > On Monday, April 23, 2001 10:45:14 AM -0400 Chris Mason <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> Hi guys,
> >>
> >> This patch is not meant to replace Neil Brown's knfsd ops stuff, the
> >> goal was to whip up something that had a chance of getting into 2.4.x,
> >> and that might be usable by the AFS guys too. Neil's patch tries to
> >> address a bunch of things that I didn't, and looks better for the
> >> long run.
> >>
> >
>
> Updated to 2.4.5, with the nfs list cc'd this time in hopes of comments
> or flames...
>
> -chris
>
> diff -Nru a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> --- a/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
> +++ b/fs/nfsd/nfsfh.c Fri Jun 1 16:08:41 2001
> @@ -116,40 +116,12 @@
> return error;
> }
>
> -/* this should be provided by each filesystem in an nfsd_operations interface as
> - * iget isn't really the right interface
> - */
> -static struct dentry *nfsd_iget(struct super_block *sb, unsigned long ino, __u32
>generation)
> +static struct dentry *dentry_from_inode(struct inode *inode)
> {
> -
> - /* iget isn't really right if the inode is currently unallocated!!
> -* This should really all be done inside each filesystem
> -*
> -* ext2fs' read_inode has been strengthed to return a bad_inode if the inode
> -* had been deleted.
> -*
> -* Currently we don't know the generation for parent directory, so a
>generation
> -* of 0 means "accept any"
> -*/
> - struct inode *inode;
> struct list_head *lp;
> struct dentry *result;
> - inode = iget(sb, ino);
> - if (is_bad_inode(inode)
> - || (generation && inode->i_generation != generation)
> - ) {
> - /* we didn't find the right inode.. */
> - dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
> - inode->i_ino,
> - inode->i_nlink, atomic_read(>i_count),
> - inode->i_generation,
> - generation);
> -
> - iput(inode);
> - return ERR_PTR(-ESTALE);
> - }
> - /* now to find a dentry.
> -* If possible, get a well-connected one
> + /*
> +* If possible, get a well-connected dentry
> */
> spin_lock(_lock);
> for (lp = inode->i_dentry.next; lp != >i_dentry ; lp=lp->next) {
> @@ -173,6 +145,92 @@
> return result;
> }
>
> +static struct inode *__inode_from_fh(struct super_block *sb, int ino,
> +int generation)
> +{
> + struct inode *inode ;
> +
> + inode = iget(sb, ino);
> + if (is_bad_inode(inode)
> + || (generation && inode->i_generation != generation)
> + ) {
> + /* we didn't find the right inode.. */
> + dprintk("fh_verify: Inode %lu, Bad count: %d %d or version %u %u\n",
> + inode->i_ino,
> + inode->i_nlink, atomic_read(>i_count),
> + inode->i_generation,
> + generation);
> +
> + iput(inode);
> + return ERR_PTR(-ESTALE);
> + }
> + return inode ;
> +}
> +
> +static struct inode *inode_from_fh(struct super_block *sb,
> + __u32 *datap,
> + int len)
> +{
> + if (sb->s_op->inode_from_fh)
> + return sb->s_op->inode_from_fh(sb, datap, len) ;
> + return __inode_from_fh(sb, datap[0], datap[1]) ;
> +}
> +
> +static struct inode *parent_from_fh(struct super_block *sb,
> + __u32 *datap,
> + int len)
> +{
> + if (sb->s_op->parent_from_fh)
> + return sb->s_op->parent_from_fh(sb, datap, len) ;
> +
> + if (len >= 3)
> + return __inode_from_fh(sb, datap[2], 0) ;
> + return ERR_PTR(-ESTALE);
> +}
> +
> +/*
> + * two iget funcs, one for inode, and one for parent directory
> + *
> + * this should be provided by each filesystem in an nfsd_operations interface as
> + * iget isn't really the right interface
> + *
> + * If the filesystem doesn't provide funcs to get inodes from datap,
> + * it must be: inum, generation, dir inum. Length of 2 means the
> + * dir inum isn't there.
> + *
> + * iget isn't really right if the inode is currently unallocated!!
> + * This should really all be done inside each filesystem
> + *
> + * ext2fs'
