2.4.6-pre1 unresolved symbols
depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/3c59x.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/bonding.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/plip.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/ppp_generic.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/net/slip.o depmod: do_softirq depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/scsi/imm.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/drivers/scsi/ppa.o depmod: tasklet_hi_schedule depmod: *** Unresolved symbols in /lib/modules/2.4.6-pre1/kernel/net/ipv6/ipv6.o depmod: do_softirq - 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-ac7 SMP crash (hotplug race?)
Hello! On Mon, Jun 04, 2001 at 04:41:48PM -0400, Pete Zaitcev wrote: > >I told device to go to sleep, it reported (over serial console that I > >looked at with minicom), that it turned off internal devices > >(including USB client), reported it is going to sleep, and turned > >serial and itself off. > What does it mean "I told device to go to sleep"? It mean just it. I forced device to enter "suspend" mode. > What device? How (what command line)? Device is Compaq iPaq running Linux. Command line is echo >/proc/sys/pm/suspend (on iPAQ prompt) This even generates 2 simultaneous irqs: one is for serial (DCD clear) and one is for USB (device detachment) (which iun turn should call 2 usermode helpers on is for net.hotplug helper (usb0 net device unregistering) and one is usb.hotplug helper (USB device unregistering)) > > wait_on_irq, CPU 1 > > irq: 1 [1 0] > > bh: 1 [0 1] > > CPU 0: > > CPU 1: c167fe68 c01d805d ... (not recorded full stack) > > Trace; c0108522 <__global_cli+e2/170> > > Trace; c0170f97 > > Trace; c0170f60 > > Trace; c011d706 > > Trace; c011a56c > > Trace; c011a423 > > Trace; c011a2ab > > Trace; c0108935 > > Trace; c0108525 <__global_cli+e5/170> > > Trace; c01617e8 > > Trace; c011a67d <__run_task_queue+5d/70> > > Trace; c0121c35 > > Trace; c0121670 > > Trace; c0105000 > > Trace; c0105556 > > Trace; c0121670 > Curious. What host controller driver do you use? I use uhci, but I saw no usb symbols in backtrace so I think it does not matter. Also I must say that this is 100% repeatable (and backtrace is almost the same, except for last few items) Bye, Oleg - 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: semaphores and noatomic flag
Will it not be a very specialized case rather than being general call type? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mihai Moise Sent: Monday, June 04, 2001 11:05 PM To: [EMAIL PROTECTED] Subject: semaphores and noatomic flag I write this to discuss the reasons why the semop system call should have an IPC_NOATOMIC flag. Suppose we have two processes, called client and server, which communicate through a shared memory segment and two semaphores, and need to synchonize their activities so that they don't operate simultaneously except at startup. The server would do, down(smephore 0) to wait for a message from the client. When the client needs the server to execute, it would, up(semaphore 0) /* wake up server */ down(semaphore 1) /* put itself to sleep */ after the server has completed its portion of the task, it would, up(semaphore 1) /* wake up client */ down(semaphore 0) /* put iself to sleep */ The problem is that the two system calls make the whole process twice as slow as it needs to be, and they are both needed because the semop system call is implemented in an atomic manner. If the semop system call had an IPC_NOATOMIC flag, then the each process would only have to do one call, semop(up semaphore 0 & down semaphore 1, IPC_NOATOMIC) which would be interpreted in the kernel as the sequence of two system calls I have written previously. I want to know what other people think about this idea. Mihai - 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/ - 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] fs/devfs/base.c
Followup to: <[EMAIL PROTECTED]> By author:Bill Pringlemeir <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > There was a discussion on comp.arch.embedded about bounded stack use. > It is fairly easy to calculate the stack usage for call trees, but > much more difficult for `DAGs'. Ie, a recursive functions etc. > It's trivial to calculate for DAGs -- directed acyclic graphs. It's when the "acyclic" constraint is violated that you have problems! -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/
[PATCH] devfs v179 available
Hi, all. Version 179 of my devfs patch is now available from: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html The devfs FAQ is also available here. Patch directly available from: ftp://ftp.??.kernel.org/pub/linux/kernel/people/rgooch/v2.4/devfs-patch-current.gz AND: ftp://ftp.atnf.csiro.au/pub/people/rgooch/linux/kernel-patches/v2.4/devfs-patch-current.gz This is against 2.4.5. Highlights of this release: - Adjusted to account for fix Regards, Richard Permanent: [EMAIL PROTECTED] Current: [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/
Speed to please all......
beetle:/src/DiskPerf-1.0.5 # ./DiskPerf.rw /dev/hdb Device: Maxtor 5T020H2 Serial Number: T2J0HC0C LBA 0 DMA Read Test = 68.82 MB/Sec (3.63 Seconds) Outer Diameter Sequential DMA Read Test = 36.68 MB/Sec (6.81 Seconds) Inner Diameter Sequential DMA Read Test = 21.36 MB/Sec (11.70 Seconds) LBA 1 DMA Write Test = 65.57 MB/Sec (3.81 Seconds) Outer Diameter Sequential DMA Write Test = 36.89 MB/Sec (6.78 Seconds) Inner Diameter Sequential DMA Write Test = 21.42 MB/Sec (11.67 Seconds) The new driver for 2.5 can read and write at near the same speeds. Andre Hedrick ASL Kernel Development Linux ATA 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/
Where can find document of RPC program in kernel.
Hello: I try to write a kernel modules with RPC (SUN Remote Procedure Call) ,Someone know where can find documents for it. thanks -- Best Regard! Àñ£¡ -- mail from: hugang [ºú¸Õ] mail : [EMAIL PROTECTED] [EMAIL PROTECTED] China Beijing Soul [±±¾©ÖÚÖ¾ºÏ´ï] -- - 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 cache flush.
In article <[EMAIL PROTECTED]>, Chris Wedgwood <[EMAIL PROTECTED]> wrote: >On Mon, Jun 04, 2001 at 07:03:01PM -0700, David S. Miller wrote: > >The x86 doesn't have dumb caches, therefore it really doesn't >need to flush anything. Maybe a mb(), but that is it. > >What if the memory is erased underneath the CPU being aware of this? >In such a way ig generates to bus traffic... Doing bank switching etc is outside the scope of the current DMA cache flush macros - they are there only for "sane" cache coherency issues, not to be used as generic "we have to flush the cache because we went behind the back of the CPU and switched a bank of memory around". You will have to come up with some new primitive for this. The x86 has the "wbinval" instruction, although it should be noted that - it is buggy and will lock up some CPU's. Use with EXTREME CAUTION. Intel set a special field in the MP table for whether wbinval is usable or not, and you can probably find their errata on which CPU's it doesn't work on (I think it was some early PPro steppings). When wbinval doesn't work, there's another strategy to flush the cache, but I forget what it was. It was something ridiculous like reading in a few megabytes of memory from consecutive physical addresses to make sure that the cache has been replaced. - even when it works, it is necessarily very very very slow. Not to be used lightly. As you can imagine, the work-around is even slower. On the whole, I would suggest avoiding this like the plague, and just marking such memory to be non-cacheable, regardless of whether there is a performance impact or not. If you mark it write-combining and speculative, it's going to perform a bit better. Linus - 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: Reg mkdir syscall
Followup to:By author:"SATHISH.J" <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Actually I had written a small file system(on 2.2.14 kernel) similar to > RAMFS on 2.4 kernel. I am able to mount it but when I try to create > directory under it, it gives EEXIST error saying" file already exists" but > when I check the directory again that file gets created. But the link > count of the parent remains the same. I do not know how this directory > gets created but with an error message. Please also tell me what all > functions mkdir passes thro' while creating a directory. One more thing is > when I took an strace of mkdir command the syscall mkdir fails with > EEXIST error. > Please help me with your thoughts. > Your code is broken. -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: (lkml)2.4.5-ac7 usb-uhci appears twice in /proc/interrupts
On Mon, Jun 04, 2001 at 03:07:56AM -0400, Pavel Roskin wrote: > Hello! > > I don't know, maybe it's Ok, but it looks confusing - usb-uhci is listed > twice on the same IRQ 9. > My Abit VP6 (VIA694) says in dmesg: 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. And more, if I read the handbook I get an adapter to get another two usb plugs at the backside. So yes, this motherboard has 2 usb controllers. I think it is okay - you may want to check your own manual. Good luck, Jurriaan -- BOFH excuse #131: telnet: Unable to connect to remote host: Connection refused GNU/Linux 2.4.5-ac7 SMP/ReiserFS 2x1402 bogomips load av: 0.00 0.00 0.00 - 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
Adrian Bunk writes: > (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) The only valid reason for userspace programs to be including kernel headers is to get definitions that are part of the kernel API. (And in fact others here will go further and assert that there are *no* valid reasons for userspace programs to include kernel headers.) If you want some atomic functions or whatever for your userspace program and the ones in the kernel look like they would be useful, then take a copy of the relevant kernel code if you like, but don't include the kernel headers directly. If you do, you will get bitten at some point in the future when we decide to change some internal implementation detail in the kernel, and your program suddenly won't compile any more. This is why I added #ifdef __KERNEL__ around most of the contents of include/asm-ppc/*.h. It was done deliberately to flush out those programs which are depending on kernel headers when they shouldn't. 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: TCP Connection lockup between 2.4.0 and 2.4.5
Darryl Miles writes: > It appears the .218 end stops ACKing, even though it is obviously seeing > the data come in, since the TCPDUMP is from the .218 host. I've been > running 2.4.0 on 10.0.0.218 since 9th Jan and can't believe that this > problem is a bug in 2.4.0, since it was speaking with the .219 box all > this time until I recently updated the .219 end from 2.0.32 to 2.4.5 > over last weekend. Believe it or not, it is likely a bug in 2.4.0 :-) 2.4.0 has several major TCP failures, not fixed until 2.4.4/2.4.5. Later, David S. Miller [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/
TCP Connection lockup between 2.4.0 and 2.4.5
Hi, 10.0.0.218 = Linux 2.4.0 SMP (tcp_timestamps, tcp_window_scaling and tcp_sack all turned off, this doesn't appear to be relevant, since the problem is just the same when they are turned on). 10.0.0.219 = Linux 2.4.5 UP It appears the .218 end stops ACKing, even though it is obviously seeing the data come in, since the TCPDUMP is from the .218 host. I've been running 2.4.0 on 10.0.0.218 since 9th Jan and can't believe that this problem is a bug in 2.4.0, since it was speaking with the .219 box all this time until I recently updated the .219 end from 2.0.32 to 2.4.5 over last weekend. These are the only two linux boxes on the LAN, so this is the first time two 2.4.x boxes have been talking to each other at LAN speeds, both boxes have had full access to the Internet at dialup speeds all though this year (using a non NAT connection, the 10.x.x.x addrs aren't what they really operate as). I did get an inconsistant tcpdump when taken from the .219 end, in that the entries marked with '*' (which I have added a blank line around below) are actually reported like the following (note this is from a DIFFERENT session, NOT the same one as the larger dump below): 02:38:37.162128 0:20:af:52:3d:17 0:50:da:8a:4c:80 0800 1514: 10.0.0.219.119 > 10.0.0.218.2226: P 3113:4313(1200) ack 46 win 5792 (DF) 02:38:37.172128 0:20:af:52:3d:17 0:50:da:8a:4c:80 0800 1514: 10.0.0.219.119 > 10.0.0.218.2226: P 3113:4313(1200) ack 46 win 5792 (DF) 02:38:37.172128 0:20:af:52:3d:17 0:50:da:8a:4c:80 0800 1266: 10.0.0.219.119 > 10.0.0.218.2226: P 3113:4313(1200) ack 46 win 5792 (DF) Notice the difference in ethernet frame length and TCP segment length. >From the other end everything looks normal, as in the 1st packet is "217:1665(1448)", 2nd packet is "1665:3113(1448)" and last is "3113:4313(1200)". It is like tcpdump got a hold of the last packet and repeated it 3 times, and somehow missed being able to sniff the first two. So what tcpdump reports from the .219 end isn't what .218 actually sees on the wire. This dump from the .218 end: 02:50:42.549261 10.0.0.218.2296 > 10.0.0.219.119: S 1468859836:1468859836(0) win 5840 (DF) 02:50:42.551250 10.0.0.219.119 > 10.0.0.218.2296: S 1410961156:1410961156(0) ack 1468859837 win 5840 (DF 02:50:42.551462 10.0.0.218.2296 > 10.0.0.219.119: . ack 1 win 5840 (DF) 02:50:42.741803 10.0.0.219.119 > 10.0.0.218.2296: P 1:108(107) ack 1 win 5840 (DF) 02:50:42.741925 10.0.0.218.2296 > 10.0.0.219.119: . ack 108 win 5840 (DF) 02:50:42.742347 10.0.0.218.2296 > 10.0.0.219.119: P 1:14(13) ack 108 win 5840 (DF) 02:50:42.744136 10.0.0.219.119 > 10.0.0.218.2296: . ack 14 win 5840 (DF) 02:50:42.761240 10.0.0.219.119 > 10.0.0.218.2296: P 108:117(9) ack 14 win 5840 (DF) 02:50:42.772263 10.0.0.218.2296 > 10.0.0.219.119: P 14:21(7) ack 117 win 5840 (DF) 02:50:42.77 10.0.0.219.119 > 10.0.0.218.2296: P 117:160(43) ack 21 win 5840 (DF) 02:50:42.784379 10.0.0.218.2296 > 10.0.0.219.119: P 21:40(19) ack 160 win 5840 (DF) 02:50:42.795936 10.0.0.219.119 > 10.0.0.218.2296: P 160:217(57) ack 40 win 5840 (DF) 02:50:42.799369 10.0.0.218.2296 > 10.0.0.219.119: P 40:46(6) ack 217 win 5840 (DF) 02:50:42.832749 10.0.0.219.119 > 10.0.0.218.2296: . ack 46 win 5840 (DF) * 02:50:42.846780 10.0.0.219.119 > 10.0.0.218.2296: . 217:1677(1460) ack 46 win 5840 (DF) 02:50:42.846975 10.0.0.218.2296 > 10.0.0.219.119: . ack 1677 win 8760 (DF) * 02:50:42.849085 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack 46 win 5840 (DF) * 02:50:42.851092 10.0.0.219.119 > 10.0.0.218.2296: P 3137:4313(1176) ack 46 win 5840 (DF) 02:50:42.851279 10.0.0.218.2296 > 10.0.0.219.119: . ack 1677 win 8760 (DF) 02:50:42.858301 10.0.0.219.119 > 10.0.0.218.2296: . 4313:5773(1460) ack 46 win 5840 (DF) 02:50:42.859679 10.0.0.218.2296 > 10.0.0.219.119: . ack 1677 win 8760 (DF) 02:50:42.860612 10.0.0.219.119 > 10.0.0.218.2296: . 5773:7233(1460) ack 46 win 5840 (DF) 02:50:42.867351 10.0.0.219.119 > 10.0.0.218.2296: . 7233:8693(1460) ack 46 win 5840 (DF) 02:50:42.867523 10.0.0.218.2296 > 10.0.0.219.119: . ack 1677 win 8760 (DF) 02:50:42.871097 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack 46 win 5840 (DF) 02:50:43.074807 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack 46 win 5840 (DF) 02:50:43.494738 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack 46 win 5840 (DF) 02:50:44.334641 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack 46 win 5840 (DF) 02:50:46.014434 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack 46 win 5840 (DF) 02:50:49.374022 10.0.0.219.119 > 10.0.0.218.2296: . 1677:3137(1460) ack 46 win 5840 (DF) -- Darryl Miles - 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: gdb/ptrace problem
Stanislav Malyshev <[EMAIL PROTECTED]> writes: > Since installing 2.2.19, I have the following problem: each time I try to > attach to a running program with gdb, the result is: > > ptrace: Operation not permitted. > > and attaching fails. No problem with 2.2.18. Have I missed something? Any > advice on how this can be fixed? > > gdb version: > GNU gdb 5.0 > Copyright 2000 Free Software Foundation, Inc. I did a cursory look throught the 18->19 patch and didn't see anything obvious that could be causing this. Are you talking about an i386 box? Are you running any other special patches on it? You could try running gdb itself under strace. Perhaps this will show some info on exactly how this ptrace call is failing. The EPERM would suggest that gdb doesn't have permission to attach. You can't attach to setuid/setgid processes unless you're root. Otherwise, you can generally attach to processes you're allowed to send signals to (unless something has changed). So you could try running gdb as root as see if you can attach then. Or, you could try doing a 'kill -STOP' on the process instead of attaching to it. Does it work? Also, check for operator error. :-) --Mike -- Mike Coleman, [EMAIL PROTECTED] http://www.mathdogs.com -- problem solving, expert software development - 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: Unit attention in USB storage
>> [things work better when "Unit Attention: not ready to ready transition" >> is not regarded as an error] > I suggest trying this with 2.4.5 -- several people report that kernel > works much better than previous ones with usb-storage. The details of the behaviour are a bit different, but the essence is unchanged: with the same .config as the 2.4.3 I reported on, 2.4.5 failed. (With a different one it was successful. It is a matter of timing.) Again adding the patch: diff -r -u ../linux-2.4.5/linux/drivers/usb/storage/debug.c linux/drivers/usb/storage/debug.c --- ../linux-2.4.5/linux/drivers/usb/storage/debug.cSat Sep 9 01:39:12 2000 +++ linux/drivers/usb/storage/debug.c Tue Jun 5 05:23:46 2001 @@ -302,6 +302,8 @@ case 0x1C00: what="defect list not found"; break; case 0x2400: what="invalid field in CDB"; break; case 0x2703: what="associated write protect"; break; + case 0x2800: what="not ready to ready transtion (media change?)"; + break; case 0x2903: what="bus device reset function occurred"; break; case 0x2904: what="device internal reset"; break; case 0x2B00: what="copy can't execute since host can't disconnect"; diff -r -u ../linux-2.4.5/linux/drivers/usb/storage/transport.c linux/drivers/usb/storage/transport.c --- ../linux-2.4.5/linux/drivers/usb/storage/transport.cWed Apr 18 20:49:12 2001 +++ linux/drivers/usb/storage/transport.c Tue Jun 5 05:23:13 2001 @@ -793,6 +793,15 @@ /* If things are really okay, then let's show that */ if ((srb->sense_buffer[2] & 0xf) == 0x0) srb->result = GOOD << 1; + + /* A transition from non-ready to ready sounds OK. */ + if ((srb->sense_buffer[2] & 0xf) == 0x6 /* unit attention */ + && srb->sense_buffer[12] == 0x28 + && srb->sense_buffer[13] == 0 /* not ready -> ready */) { + srb->result = GOOD << 1; + srb->sense_buffer[0] = 0; + } + } else /* if (need_auto_sense) */ srb->result = GOOD << 1; makes things work. 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/
Starfire driver updates
Hi Jeff, The patch below updates the starfire driver to support zerocopy operations and adds full ethtool support. It also adds a small perl utility (already present in the -ac tree) people can use to generate the firmware header file from Adaptec's own Netware drivers. Please apply.. Thanks, Ion -- It is better to keep your mouth shut and be thought a fool, than to open it and remove all doubt. --- --- /src/vanilla/linux-2.4-jg/drivers/net/starfire.cThu May 31 23:38:19 2001 +++ linux-2.4/drivers/net/starfire.cMon Jun 4 19:12:05 2001 @@ -2,6 +2,10 @@ /* Written 1998-2000 by Donald Becker. + Current maintainer is Ion Badulescu <[EMAIL PROTECTED]>. Please + send all bug reports to me, and not to Donald Becker, as this code + has been modified quite a bit from Donald's original version. + This software may be used and distributed according to the terms of the GNU General Public License (GPL), incorporated herein by reference. Drivers based on or derived from this code fall under the GPL and must @@ -70,15 +74,20 @@ LK1.2.9a (Ion Badulescu) - More updates from Jeff Garzik + LK1.3.0 (Ion Badulescu) + - Merged zerocopy support + + LK1.3.1 (Ion Badulescu) + - Added ethtool support + - Added GPIO (media change) interrupt support + TODO: - implement tx_timeout() properly - - support ethtool */ #define DRV_NAME "starfire" -#define DRV_VERSION"1.03+LK1.2.9" -#define DRV_RELDATE"April 19, 2001" - +#define DRV_VERSION"1.03+LK1.3.1" +#define DRV_RELDATE"June 04, 2001" /* * Adaptec's license for their Novell drivers (which is where I got the @@ -87,7 +96,7 @@ * * However, an end-user is allowed to download and use it, after * converting it to C header files using starfire_firmware.pl. - * Once that's done, the #undef must be changed into a #define + * Once that's done, the #undef below must be changed into a #define * for this driver to really use the firmware. Note that Rx/Tx * hardware TCP checksumming is not possible without the firmware. * @@ -100,6 +109,12 @@ * of length 1. If and when this is fixed, the #define below can be removed. */ #define HAS_BROKEN_FIRMWARE +/* + * Define this if using the driver with the zero-copy patch + */ +#if defined(HAS_FIRMWARE) && defined(MAX_SKB_FRAGS) +#define ZEROCOPY +#endif /* The user-configurable values. These may be modified when a driver module is loaded.*/ @@ -138,8 +153,8 @@ The media type is usually passed in 'options[]'. */ #define MAX_UNITS 8/* More are supported, limit only on options */ -static int options[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1}; -static int full_duplex[MAX_UNITS] = {-1, -1, -1, -1, -1, -1, -1, -1}; +static int options[MAX_UNITS] = {0, }; +static int full_duplex[MAX_UNITS] = {0, }; /* Operational parameters that are set at compile time. */ @@ -155,9 +170,23 @@ /* Operational parameters that usually are not changed. */ /* Time in jiffies before concluding the transmitter is hung. */ -#define TX_TIMEOUT (2*HZ) +#define TX_TIMEOUT (2 * HZ) +#ifdef ZEROCOPY +#if MAX_SKB_FRAGS <= 6 +#define MAX_STARFIRE_FRAGS 6 +#else /* MAX_STARFIRE_FRAGS > 6 */ +#warning This driver will not work with more than 6 skb fragments. +#warning Turning off zerocopy support. +#undef ZEROCOPY +#endif /* MAX_STARFIRE_FRAGS > 6 */ +#endif /* ZEROCOPY */ + +#ifdef ZEROCOPY +#define skb_first_frag_len(skb)skb_headlen(skb) +#else /* not ZEROCOPY */ #define skb_first_frag_len(skb)(skb->len) +#endif /* not ZEROCOPY */ #if !defined(__OPTIMIZE__) #warning You must compile this file with the correct options! @@ -180,22 +209,25 @@ #include #include #include -#include -#include #include /* Processor type for cache alignment. */ #include #include +#include -/* These identify the driver base version and may not be removed. */ -static char version[] __devinitdata = -KERN_INFO DRV_NAME ".c:v1.03 7/26/2000 Written by Donald Becker <[EMAIL PROTECTED]>\n" -KERN_INFO " Updates and info at http://www.scyld.com/network/starfire.html\n"; -KERN_INFO " (unofficial 2.4.x kernel port, version " DRV_VERSION ", " DRV_RELDATE ")\n"; +#ifdef SIOCETHTOOL +#include +#endif #ifdef HAS_FIRMWARE #include "starfire_firmware.h" #endif /* HAS_FIRMWARE */ +/* These identify the driver base version and may not be removed. */ +static char version[] __devinitdata = +KERN_INFO "starfire.c:v1.03 7/26/2000 Written by Donald Becker <[EMAIL PROTECTED]>\n" +KERN_INFO " Updates and info at http://www.scyld.com/network/starfire.html\n"; +KERN_INFO " (unofficial 2.4.x kernel port, version " DRV_VERSION ", " DRV_RELDATE +")\n"; + MODULE_AUTHOR("Donald Becker <[EMAIL PROTECTED]>"); MODULE_DESCRIPTION("Adaptec Starfire Ethernet driver"); MODULE_PARM(max_interrupt_work, "i"); @@ -242,7 +274,7 @@ each structure
Comment on patch to remove nr_async_pages limit
Zlatko, I've read your patch to remove nr_async_pages limit while reading an archive on the web. (I have to figure out why lkml is not being delivered correctly to me...) Quoting your message: "That artificial limit hurts both swap out and swap in path as it introduces synchronization points (and/or weakens swapin readahead), which I think are not necessary." If we are under low memory, we cannot simply writeout a whole bunch of swap data. Remember the writeout operations will potentially allocate buffer_head's for the swapcache pages before doing real IO, which takes _more memory_: OOM deadlock. - 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/
Tulip 0.9.15-pre3 - still no dice
A tulip driver 0.9.15-pre3, as included in 2.4.5-ac8, still does not work for me and I have to replace it with 0.9.14d (April 3, 2001) to get a functional network. Trying it with 'tulip_debug=3' option I see this: Linux Tulip driver version 0.9.15-pre3 (June 1, 2001) 00:0b.0: MWI config mwi=0, cacheline=16, csr0=00a0d000 tulip0: EEPROM default media type Autosense. tulip0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. tulip0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. tulip0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. tulip0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: tulip_up(), irq==11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: Done tulip_open(), CSR0 f8a0d000, CSR5 f016 CSR6 b2422202. eth0: 21143 link status interrupt 50ca, CSR5 f0668010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. eth0: 21143 non-MII 10baseT transceiver control 08af/0005. eth0: Setting CSR15 to 08af0008/00050008. eth0: Using media type 10baseT, CSR12 is c6. eth0: Setting CSR6 8242/b2422002 CSR12 10c6. eth0: 21143 negotiation status 10c6, 10baseT. eth0: 21143 negotiation failed, status 10c6. eth0: Testing new 21143 media 100baseTx. eth0: The transmitter stopped. CSR5 is f0008102, CSR6 b242, new CSR6 8386. eth0: 21143 link status interrupt 02ca, CSR5 f0668010, fffbff7f. eth0: 21143 100baseTx link beat failed. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: 21143 link status interrupt 50ca, CSR5 f0008010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. . (and a loop with at "Autonegotiation failed" until 'ifdown eth0') . eth0: Shutting down ethercard, status was f102. There was a variation once. A status changed to this: eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: 21143 link status interrupt 52ca, CSR5 f0008010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 52ca. but it went back to the same loop: This is, for a comparison, the same level of debug with 0.9.14d working driver. Note different values for CSR0 and CSR5 on tulip_open(). Linux Tulip driver version 0.9.14d (April 3, 2001) eth0: Digital DS21143 Tulip rev 65 at 0x8800, 00:00:F0:51:00:72, IRQ 11. eth0: EEPROM default media type Autosense. eth0: Index #0 - Media 10baseT (#0) described by a 21142 Serial PHY (2) block. eth0: Index #1 - Media 10baseT-FDX (#4) described by a 21142 Serial PHY (2) block. eth0: Index #2 - Media 100baseTx (#3) described by a 21143 SYM PHY (4) block. eth0: Index #3 - Media 100baseTx-FDX (#5) described by a 21143 SYM PHY (4) block. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: tulip_up(), irq==11. eth0: Restarting 21143 autonegotiation, csr14=0003. eth0: Done tulip_open(), CSR0 f8a0e000, CSR5 f072 CSR6 b2422202. eth0: 21143 link status interrupt 50ca, CSR5 f0668010, fffb. eth0: Autonegotiation failed, using 10baseT, link beat status 50ca. eth0: 21143 non-MII 10baseT transceiver control 08af/0005. eth0: Setting CSR15 to 08af0008/00050008. eth0: Using media type 10baseT, CSR12 is ca. eth0: Setting CSR6 8242/b2422002 CSR12 50ca. eth0: 21143 negotiation status 50ca, 10baseT. Here is an output of tulip-diag, as much as I can get, in a non-working state: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0d000 0efb 0efb0200 f000 b2420200 fbfffbff 0x40: e000 cbf8 10ce 0001 fffb 8ff5 Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 10ce. EEPROM 64 words, 6 address bits. PCI Subsystem IDs, vendor 1011, device 500b. CardBus Information Structure at offset . Ethernet MAC Station Address 00:00:F0:51:00:72. EEPROM transceiver/media description table. Leaf node at offset 65, default media type 0800 (Autosense). 4 transceiver description blocks: Media 10baseT, block type 2, length 6. Serial transceiver for 10baseT (media type 0). GP pin direction 08af GP pin data 0005. Media 10baseT-Full Duplex, block type 2, length 6. Serial transceiver for 10baseT-Full Duplex (media type 4). GP pin direction 08af GP pin data 0005. Media 100baseTx, block type 4, length 8. SYM transceiver for 100baseTx (media type 3). GP pin direction 08af GP pin data 0005. No media detection indication (command 80 61). Media 100ba
Re: symlink_prefix
In article <[EMAIL PROTECTED]>, Hank Leininger <[EMAIL PROTECTED]> writes: > On 2001-06-03, [EMAIL PROTECTED] wrote: > >> Suppose I have devices /dev/a, /dev/b, /dev/c that contain the >> /, /usr and /usr/spool filesystems for FOO OS. Now >> mount /dev/a /mnt -o symlink_prefix=/mnt >> mount /dev/b /mnt/usr -o symlink_prefix=/mnt >> mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt > > Cool. > > What happens when someone creates new absolute symlinks under /mnt ? > Will/should the magic /mnt/ header be stripped from any symlink created > under such a path-translated volume? The answer is probably 'yes', but > either one violates POLA :( > I think the semantics should be these that are used in the old usespace nfsd for the "link_relative" option. That one had very intuitive semantics and behaved sanely even if you had insane recursive machine crossmounts - 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: lowlatency 2.2.19
On Mon, 4 Jun 2001, safemode wrote: > this is just a general question about low latency patches on 2.2, I > remember hearing about low latency patches for 2.4 not playing well with X > 4.x, is this true for 2.2 low latency patches as well? > Not sure. My testing uses XFree86 3.3.6. Wm - 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/
forcibly unmap pages in driver?
I am writing a device driver that, like many others, exposes a shared memory region to user-space via mmap(). The region is allocated with vmalloc(), the pages are marked reserved, and the user-space mapping is implemented with remap_page_range(). In my driver, I may have to free the underlying vmalloc() region while the user-space program is still running. I need to remove the user-space mapping -- otherwise the user process would still have access to the now-freed pages. I need an inverse of remap_page_range(). Is zap_page_range() the function I am looking for? Unfortunately it's not exported to modules =(. As a quick fix, I was thinking I could just remap all of the user pages to point to a zeroed page or something... Another question- in the mm.c sources, I see that many of the memory-mapping functions are surrounded by calls to flush_cache_range() and flush_tlb_range(). But I don't see these calls in many drivers. Is it necessary to make them when my driver maps or unmaps the shared memory region? Regards, Dan - 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: Oops while unmounting a reiserfs partition
get patch from www.namesys.com, bug was added and fixed by viro, we just put the patch up while waiting for 2.4.6 to come out. Hans Mathieu Chouquet-Stringer wrote: > > Hello! > > I just mkreiserfsed a new partition (a 50g hardware raid0 array, I know > this is just a testing machine), mounted it, and then unmounted it, and > OOPS! My kernel version is plain 2.4.5... > If you need more information, let me know. > > Jun 4 17:25:03 nynetops03 kernel: reiserfs: checking transaction log (device 08:11) >... > Jun 4 17:25:07 nynetops03 kernel: Using r5 hash to sort names > Jun 4 17:25:07 nynetops03 kernel: ReiserFS version 3.6.25 > Jun 4 17:26:11 nynetops03 kernel: journal_begin called without kernel lock held > Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! > Jun 4 17:26:11 nynetops03 kernel: invalid operand: > Jun 4 17:26:11 nynetops03 kernel: CPU:1 > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[] > Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 > Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 >edx: 0001 > Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 >esp: d8e15eac > Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 > Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) > Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf >c0268a61 d7e75250 00e8 > Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 >0018 d8e15f24 df9c5400 c02a8620 > Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 >000a c017ffdc d8e15f24 > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] >[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] >[kill_super+162/288] [path_release+41/48] > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [] [] >[] [] [] [] [] > Jun 4 17:26:11 nynetops03 kernel:[sys_umount+301/352] [sys_munmap+51/80] >[sys_oldumount+12/16] [system_call+51/56] > Jun 4 17:26:11 nynetops03 kernel:[] [] [] >[] > Jun 4 17:26:11 nynetops03 kernel: > Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 >00 00 00 8d bc 27 > > And the decoded output: > ksymoops 2.4.0 on i686 2.4.5. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.5/ (default) > -m /boot/System.map-2.4.5 (default) > > Warning: You did not tell me where to find symbol information. I will > assume that the log matches the kernel and modules that are running > right now and I'll use the default options above for symbol resolution. > If the current kernel and/or modules do not match the log, you can get > more accurate output by telling me the kernel version and where to find > map, modules, ksyms etc. ksymoops -h explains the options. > > Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not >found in System.map. Ignoring ksyms_base entry > Warning (compare_maps): ksyms_base symbol >machine_real_restart_R__ver_machine_real_restart not found in System.map. Ignoring >ksyms_base entry > Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! > Jun 4 17:26:11 nynetops03 kernel: invalid operand: > Jun 4 17:26:11 nynetops03 kernel: CPU:1 > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] > Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 > Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 >edx: 0001 > Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 >esp: d8e15eac > Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 > Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) > Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf >c0268a61 d7e75250 00e8 > Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 >0018 d8e15f24 df9c5400 c02a8620 > Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 >000a c017ffdc d8e15f24 > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] >[journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] >[kill_super+162/288] [path_release+41/48] > Jun 4 17:26:11 nynetops03 kernel: Call Trace: [] [] >[] [] [] [] [] > Jun 4 17:26:11 nynetops03 kernel:[] [] [] >[] > Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 >00 00 00 8d bc 27 > > >>EIP; c018bb98<= > Trace; c018e2cf > Trace;
Re: Missing cache flush.
David Woodhouse writes: > > What should it do on i386? mb()? > > For it to have any use in the situation I described, it would need to > writeback and invalidate the dcache for the affected range. It doesn't seem > to do so, so it seems that it isn't what I require. It only needs to do that on cpus where the cache is not consistent with the rest of the system. x86 caches are fully consistent with the rest of the system, thus no flushing necessary. Later, David S. Miller [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: Missing cache flush.
Jeff Garzik writes: > David Woodhouse wrote: > > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very > > helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on > > i386 shows that it doesn't do what's required anyway. > > What should it do on i386? mb()? The x86 doesn't have dumb caches, therefore it really doesn't need to flush anything. Maybe a mb(), but that is it. Later, David S. Miller [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: kernel oops when burning CDs
Hello, At Mon, 4 Jun 2001 22:43:30 +0100 (BST), Alan Cox wrote: > > > I get an ooops and immediate kernel panic when I break (CTRL-C) cdrecord. I > > can reproduce it anytime. I use 2.4.5-ac series. Obviously, Linus' 2.4.5 is > > fine. > > I know, I know. I was supposed to make a serios oops report, BUT I wasn't > > Write down the EIP and the call trace then look them up in System.map. Also > include the hardware details. The -ac tree has a newer version of the scsi > generic code. It fixes some oopses but in your case it apparently added a new > failure case Oops occures in SG driver. This patch fixes the problem. diff -r -u linux.org/drivers/scsi/sg.c linux/drivers/scsi/sg.c --- linux.org/drivers/scsi/sg.c Fri Jun 1 10:10:22 2001 +++ linux/drivers/scsi/sg.c Fri Jun 1 17:08:00 2001 @@ -1114,7 +1114,8 @@ sg_remove_sfp(sdp, sfp); sfp = NULL; } - __MOD_DEC_USE_COUNT(sg_template.module); + if (sg_template.module) + __MOD_DEC_USE_COUNT(sg_template.module); if (sdp->device->host->hostt->module) __MOD_DEC_USE_COUNT(sdp->device->host->hostt->module); } @@ -1311,7 +1312,8 @@ sg_finish_rem_req(srp); } if (sfp->closed) { - __MOD_DEC_USE_COUNT(sg_template.module); + if (sg_template.module) + __MOD_DEC_USE_COUNT(sg_template.module); if (sdp->device->host->hostt->module) __MOD_DEC_USE_COUNT(sdp->device->host->hostt->module); __sg_remove_sfp(sdp, sfp); @@ -2207,7 +2209,8 @@ else { sfp->closed = 1; /* flag dirty state on this fd */ /* MOD_INC's to inhibit unloading sg and associated adapter driver */ - __MOD_INC_USE_COUNT(sg_template.module); + if (sg_template.module) + __MOD_INC_USE_COUNT(sg_template.module); if (sdp->device->host->hostt->module) __MOD_INC_USE_COUNT(sdp->device->host->hostt->module); SCSI_LOG_TIMEOUT(1, printk( - 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: lowlatency 2.2.19
safemode wrote: > > this is just a general question about low latency patches on 2.2, I > remember hearing about low latency patches for 2.4 not playing well with X > 4.x, is this true for 2.2 low latency patches as well? Yes, it would be the case. Some video cards have a PCI cheat-mode in which they keep the PCI bus busy until they are ready to accept new commands, rather forcing a retry. Figures of up to twenty milliseconds have been mentioned. Your X server *may* support the `PCIRetry' config option which will defeat this. Info: http://www.lib.uaa.alaska.edu/linux-kernel/archive/2001-Week-02/1566.html http://www.zefiro.com/vgakills.txt http://www.zdnet.com/pcmag/news/trends/t980619a.htm http://www.research.microsoft.com/~mbj/papers/tr-98-29.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: lowlatency 2.2.19
this is just a general question about low latency patches on 2.2, I remember hearing about low latency patches for 2.4 not playing well with X 4.x, is this true for 2.2 low latency patches as well? - 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/
TRG vger.timpanogas.org hacked
Our master server (vger.timpanogas.org) running 2.2.19 was hacked and completely obliterated by someone using a Novell Proxy Cache via a kernel level exploit in [sys_wait+4]. They somehow created a segmentation fault down inside the kernel, then gained access to the /lib directory and relinked the libraries to a set of bogus libs, which gave them access to the server. Only public code and email is processed on this server. For those interested in reviewing this attack, I have the entire previous hard disk available and can mount it under the public ftp area if anyone is curious as to how these folks did this. They exploited BIND 8.2.3 to get in and logs indicated that someone was using a "back door" in Novell's NetWare proxy caches to perform the attack (since several different servers were used as "blinds" to get in). We are unable to determine just how they got in exactly, but they kept trying and created an oops in the affected code which allowed the attack to proceed. Jeff - 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: disk-based fds in select/poll
Pierre Phaneuf <[EMAIL PROTECTED]> wrote: > It's fairly widely-known that select/poll returns immediately when > testing a filesystem-based file descriptor for writability or > readability. > > On top of this, even when in non-blocking mode, read() could block if > the pages needed aren't in core. sendfile() behaves in a similar way. > > What would be needed to alleviate this? > ... > I remember seeing a suggestion by Linus for an event-based I/O > interface, similar to kqueue on FreeBSD but much simpler. I'd just say > "I want it too!", ok? :-) > > SGI's AIO might be a solution here, does it use threads? I'm trying to > avoid context switching as much as possible, to keep the CPU cache as > warm as possible. IMHO, you want AIO. SGI's is fine for now. I hear rumors that there will be something even better coming in 2.5, though I have no details. Or you could use explicit userspace threads... say, divide up your network connections among 8 or so threads. Then if one thread blocks, the others are there to usefully soak up the CPU time. Readiness events for readahead completion on disk files used to seem like a neat idea to me, but now AIO seems more appealing in the long run, since they handle random access properly. - Dan - 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: reschedule_idle changes in ac kernels
On Mon, 4 Jun 2001, Mike Kravetz wrote: > I just noticed the changes to reschedule_idle() in the 2.4.5-ac > kernel. I suspect these are the changes made for: > > o Fix off by one on real time pre-emption in scheduler > > I'm curious if anyone has ran any benchmarks before and after > applying this fix. I was running realtime benchmarks, which was how I found the bug. > The reason I ask is that during the development of my multi-queue > scheduler, I 'accidently' changed reschedule_idle code to trigger > a preemption if preemption_goodness() was greater than 0, as > opposed to greater than 1. I believe this is the same change made > to the ac kernel. After this change, we saw a noticeable drop in > performance for some benchmarks. > > The drop in performance I saw could have been the result of a > combination of the change, and my multi-queue scheduler. However, > in any case aren't we now going to trigger more preemptions? > > I understand that we need to make the fig to get the realtime > semantics correct, but we also need to be aware of performance in > the non-realtime case. The realtime bug was caused by whoever decided, sometime in 2.4, that the result of preemption_goodness() should be compared to 1 instead of 0 (without changing the comment above that function). An alternative fix for the realtime bug would be weight = 1000 + (p->rt_priority * 2); in goodness(), so that two realtime tasks with priorities that differ by 1 would have goodness values that differ by more than one. However, before anyone rushes to implement this, I'd like to suggest that any performance problems that may be found with the SCHED_OTHER goodness calculation should be fixed in goodness(), if at all possible, and not leak out as an undocumented magic number into reschedule_idle(). Nigel Gamble[EMAIL PROTECTED] Mountain View, CA, USA. http://www.nrg.org/ MontaVista Software [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/
Oh Bother
Morning Guys, (or whatever time you call this ungodly hour) A couple of things to bring up: 1) I was just rebuilding gcc (for an i586 on my faster PII) everything was going fine and suddenly silence, all my ssh sessions have locked up, the serial console is dead, the system is not responding to ping's on any of its interfaces and when connecting a monitor / keyboard up, they are dead too the monitor is in "blank mode" (HaHa -- the most irritating thing i find with linux) mode. My conclusion: the system has completely died / hung with no warning of anykind (any panic issued would not be noticed as the damn monitor has been put in blank mode by the system). Anyone got any suggestions (more so with point 2) ? 2) How do you stop the stupid system blanking / power saving the monitor sure, it can be done with a setterm command, but, i dont use the monitor for a terminal, the box is remote access only... its only for looking at error messages that apear at the console 3) upon looking at the log files, where nothing about todays incident is mentioned, but i did notice some from a previous day : Jun 2 21:38:52 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window 1109891031:1:1109891568. Bad, what else can I say? Jun 2 21:38:53 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window 1109891032:1:1109891568. Bad, what else can I say? Jun 2 21:38:58 kernel: NET: 1 messages suppressed. Jun 2 21:38:58 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window 1109891034:1:1109891568. Bad, what else can I say? Jun 2 21:39:03 kernel: TCP: peer 216.41.36.109:80/2880 shrinks window 1068438541:1:1068439073. Bad, what else can I say? Jun 2 21:39:13 kernel: NET: 2 messages suppressed. Jun 2 21:39:13 kernel: TCP: peer 216.41.36.109:80/2876 shrinks window 1066801908:1:1066802376. Bad, what else can I say? Jun 2 21:39:17 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window 1109891036:1:1109891568. Bad, what else can I say? Jun 2 21:39:44 kernel: TCP: peer 216.41.36.109:80/2882 shrinks window 1109891037:1:1109891568. Bad, what else can I say? Jun 2 21:40:58 kernel: TCP: peer 216.41.36.109:80/2906 shrinks window 125703:1:1257011569. Bad, what else can I say? Jun 2 21:40:58 kernel: TCP: peer 216.41.36.109:80/2907 shrinks window 1250316486:1:1250316939. Bad, what else can I say? what on earth is all that about ? the systems running 2.4.5 on a PII Anyway, i had better get back to sorting out this box, it seems the crash has done some nast stuff to the file system ... it seems that part of gcc is now crosslinked with a hell of alot of other files, i can only hope that all the devel and research work on that box is unharmed! Thanks, Dave --- The information in this e-mail and any files sent with it is confidential to the ordinary user of the e-mail address to which it was addressed and may also be legally privileged. It is not to be relied upon by any person other than the addressee except with the sender's prior written approval. If no such approval is given, the sender will not accept liability (in negligence or otherwise) arising from any third party acting, or refraining from acting, on such information. If you are not the intended recipient of this e-mail you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this e-mail in error please notify the sender immediately, destroy any copies and delete it from your computer system. Have a nice Day ! - - 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.2 <-> 2.4.5-ac5 tcp too slow
i tracked it down to the 8139 driver in 2.4. On Mon, Jun 04, 2001 at 06:28:34PM -0400, Tom Vier wrote: > has the same effect) and an alpha pws 500 running 2.4.5-ac5. tcp starts slow > and get slower. it's not a 10/100 or duplex issue. icmp goes at full speed. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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 cache flush.
[EMAIL PROTECTED] said: > > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem > > very helpful - it's very PCI-specific, and a quick perusal of > > pci_dma_sync() on i386 shows that it doesn't do what's required anyway. > What should it do on i386? mb()? For it to have any use in the situation I described, it would need to writeback and invalidate the dcache for the affected range. It doesn't seem to do so, so it seems that it isn't what I require. The situation is simple - I have a paged RAM setup and I need it cached. All I want to do is flush and invalidate the cache when I'm about to waggle whatever I/O ports I waggle to change pages. There are other situations in which I need the cache flushed, but the above is one of the simplest. Even flush_page_to_ram() doesn't seem to do what its name implies, on most architectures. -- dwmw2 - 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 cache flush.
David Woodhouse wrote: > I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very > helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on > i386 shows that it doesn't do what's required anyway. What should it do on i386? mb()? -- 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: disk-based fds in select/poll
> Ok, so while knowing about select "lying" about readability of a file > fd, if I would stick a file fd in my select-based loop anyway, but would You could fix select to return when the page was cachied and return EWOULDBLOCK on reads if the page was not present to be honest. I don't think that would actually break any apps, and the specs seem to allow it > only try to read a bit at a time (say, 4K or 8K) would trigger > readahead, yet finish quickly enough that I can get back to processing > other fds in my select loop? Probably > Wouldn't that cause too many syscalls to be done? Or if this is actually > the way to go without an actual thread, how should I go determining an > optimal block size? fs block size I suspect or small multiple thereof - 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/
Missing cache flush.
The flash mapping driver arch/cris/drivers/axisflashmap.c uses a cached mapping of the flash chips for bulk reads, but obviously an uncached mapping for sending commands and reading status when we're actually writing to or erasing parts of the chip. However, it fails to flush the dcache for the range used when the flash is accessed through the uncached mapping. So after an erase or write, we may read old data from the cache for the changed area. All the mapping driver needs to do is invalidate the dcache for the affected area before the next copy_from() operation. No need to worry about writeback in this case, because we never write to flash chips through the cached mapping. However, I can't see a cache operation which performs this function. flush_dcache_page() is defined as a NOP on CRIS as, it seems, it is on most architectures. On other architectures, there's dma_cache_wback_inv(), but that also seems to be a NOP on i386, to pick a random example. I'm aware that some architectures can't handle having both cached and uncached mappings of the same physical range - so to prevent dismissal of the question out of hand by people assuming all the world's a PeeCee - consider the alternative situation where we have ROM or RAM chips in a paged mapping such that only a 64K 'page' is visible by the CPU at a time (remember XMS?). Using an uncached mapping is extremely suboptimal - all we want to do is invalidate the cache when we change the page, or writeback and invalidate in the case of RAM. I would have thought that's the function that dma_cache_wback_inv() is supposed to perform - but it seems not to do so. So how is this _supposed_ to be done? I was pointed at Documentation/DMA-mapping.txt but that doesn't seem very helpful - it's very PCI-specific, and a quick perusal of pci_dma_sync() on i386 shows that it doesn't do what's required anyway. -- dwmw2 - 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/
reschedule_idle changes in ac kernels
I just noticed the changes to reschedule_idle() in the 2.4.5-ac kernel. I suspect these are the changes made for: o Fix off by one on real time pre-emption in scheduler I'm curious if anyone has ran any benchmarks before and after applying this fix. The reason I ask is that during the development of my multi-queue scheduler, I 'accidently' changed reschedule_idle code to trigger a preemption if preemption_goodness() was greater than 0, as opposed to greater than 1. I believe this is the same change made to the ac kernel. After this change, we saw a noticeable drop in performance for some benchmarks. The drop in performance I saw could have been the result of a combination of the change, and my multi-queue scheduler. However, in any case aren't we now going to trigger more preemptions? I understand that we need to make the fig to get the realtime semantics correct, but we also need to be aware of performance in the non-realtime case. -- Mike Kravetz [EMAIL PROTECTED] IBM Linux Technology 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: disk-based fds in select/poll
Alan Cox wrote: > > I am thinking that a read() (or sendfile()) that would block because the > > pages aren't in core should instead post a request for the pages to be > > loaded (some kind of readahead mecanism?) and return immediately (maybe > > having given some data that *was* in core). A subsequent read() could > > reads posts a readahead anyway so streaming reads tend not to block much Ok, so while knowing about select "lying" about readability of a file fd, if I would stick a file fd in my select-based loop anyway, but would only try to read a bit at a time (say, 4K or 8K) would trigger readahead, yet finish quickly enough that I can get back to processing other fds in my select loop? Wouldn't that cause too many syscalls to be done? Or if this is actually the way to go without an actual thread, how should I go determining an optimal block size? Was there anything new on the bind_event/get_events API idea that Linus proposed a while ago? That one had got me foaming at the mouth... :-) -- Pierre Phaneuf - 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/
vmstat help
Hi, I am using the vmstat that came along with the SuSE 7.0 distribution. I have problem interpretting the data reported by vmstat. The vmstat document reads that the block information reported is always in terms of 1K blocks. Just to findout the validity of the data reported by vmstat, I carried out the a small copy test. Here is the configuration I have 1) I have two file systems which are created with 4096 block size 2) These two file systems are on two different disks. (but both are sitting on same scsi controller) 3) I am trying to copy a 4GB file from one disk to another using the simple "cp" command. 4) I am capturing vmstat with 30 sec interval. I stop the vmstat after cp is done 5) The copy takes anywhere between 7 to 10 minutes. On vmstat report has bi and bo's ranging form 700 to 4000. Just to get the total blocks read, I multiple the value reported in bi column with 30 (as 30 sec was my sampling interval) and sum them all. To my surprise, they add up only to around (1 GB). What is wrong here, the documentation or my intepretation of vmstat output. - 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.2 <-> 2.4.5-ac5 tcp too slow
i seem to remember this being mentioned before, but couldn't find any reference in the list archives. i have an x86 laptop running 2.2.17 (2.2.19 has the same effect) and an alpha pws 500 running 2.4.5-ac5. tcp starts slow and get slower. it's not a 10/100 or duplex issue. icmp goes at full speed. it doesn't matter which side starts the connection. has anyone else experienced this? any suggestions? -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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/
Question on Partial Checksum in TCP/IP
Hello all, I am trying to understand a little bit about the TCP path in the Linux kernel. I saw that while we were even copying the user data into kernel space, we were doing the partial checksum of the data portion alone (as the TCP header is not yet filled up) and storing it in skb->csum. Later on when we fill the header portion, we do the checksum of the header and "add" it to the already calculated checksum of the data. Here we check if the HW performs the checksum or not (skb->ip_summed == CHECKSUM_HW). I am looking into kernel ver 2.4 My question is, why is this check not performed when the data is copied initially. Instead of calling csum_and_copy_from_user, if we did a memcpy in the case when HW does the checksum, would'nt that be more efficient? Or have I overlooked something... Thanks a lot PS. Please CC responses to me also as I am not subscribed to the mailing list. Thanks Bharath - 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: IO-APIC, beaten with stick, routes USB
> Any chance you can try Alan Cox's patch against 2.4.5? It has a number > of IO-APIC fixes. > patch-2.4.5-ac7.bz2 behaves the same as 2.4.4. Whatever is happening in IO-APIC setup, USB interrupts actually arrive on IRQ 12. I can include the usual pile of config info and boot messages, but they look the same as previous l-k postings. Since IRQ 12 is a popular destination for USB, the following patch may work for people with this problem: --- usb-ohci.c Sun May 6 08:42:51 2001 +++ usb-ohci.c.rico Mon Jun 4 20:49:56 2001 @@ -2524,3 +2524,3 @@ - return hc_found_ohci (dev, dev->irq, mem_base, id); + return hc_found_ohci (dev, 12, mem_base, id); } If 12 fails, they can look for the stray interrupt in /proc/stat. - 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 writes: > leaves ncp with its ioctls ugliness. Authentication will be ugly. Joe mounts a filesystem, and does not bother to authenticate. He gets world-accessible files. Then Kevin authenticates as himself, and later as db_adm too. Along comes Sue, who can authenticate the whole box as trusted. The /fs/ext2 stuff is one of the nastiest hacks I've seen in a long time, and it doesn't solve the authentication problem. GUI users might like to see a dialog box pop up whenever they hit restricted filesystem space. (example: an authentication tool blocked on /dev/auth-notify or getting signals with info) - 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-ac8
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-ac8 o Fix sign handling bug in random sysctl (me) | From Stanford tools o Add more idents to the NS558 driver (Vojtech Pavlik) o Fix oops on some HID descriptor sets(Vojtech Pavlik) o Fix reuse bug in UML net code + clean up(Jeff Dike) o ES1370 driver locking (Frank Davis) o Update init/main.c patch for umask (Andrew Tridgell) o Fix uml fault race, and looping fault on(Jeff Dike) protection error o Update devices.txt (H Peter Anvin) o Update the airo driver (fix pci pm oops.(Jeff Garzik) spinlock abuse, delete after kfree, unchecked copies) o Remove old UML umn driver (Jeff Dike) o Fix resource leaks and printk levels in isapnp (Mike Borrelli) o Add new procfs programming documentation(Erik Mouw) o Fix usb xconfig breakage(Andrzej Krzysztofowicz) o Replace accidentaly lost UP_APIC help (Mikael Pettersson) o Olypmic driver update (Mike Phillips) o Clean up LVM spelling, debug macros (Andreas Dilger) o Make various bits of LVM static (Andreas Dilger) o Make lvm_snapshot_use_rate its own function (Andreas Dilger) o Make lvm_do_lv_create loop the right amount o Fix lvm stamping on a semaphore causing an oops o Fix lvm hardware block size handling(Andrea Arcangeli) 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&paste 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
Re: I/O tracing
You can use either dprobes to set up a tracepoint dynamically anywhere you please see: http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes Or, you can use gkhi to define a hook anywhere in the kernel you please. You can write a hook exit as a kmod to do whatever you fancy and have it activate at a tome of your choosing. See, http://oss.software.ibm.com/developerworks/opensource/linux/projects/gkhi Or, you can investigate some of the standard tracepoint Linux Trace Toolkit creates, see: http://www.opersys.com/ And that's only three of many Richard Moore - RAS Project Lead - Linux Technology Centre (ATS-PIC). http://oss.software.ibm.com/developerworks/opensource/linux Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK "YU,SAMMY (HP-Roseville,ex1)" <[EMAIL PROTECTED]> on 04/06/2001 19:37:23 Please respond to "YU,SAMMY (HP-Roseville,ex1)" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: I/O tracing Hi, Please CC me as I'm not subscribed on the list, thanks. Not sure if this is appropriate forum, is there an existing tool/module for capturing all the I/O requests such as: Unique Identifier Start Time End Time Device Identifier Operation Type (Read Or Write) Offset Length (Number Of Bytes) I am aware of existing /proc/disks and partitions, but these aren't real time. If not, are there any facilities in the kernel I can put a hook in to keep track of the I/O? Thanks in advance, Sammy Yu Hewlett-Packard - 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/ - 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: disk-based fds in select/poll
> I am thinking that a read() (or sendfile()) that would block because the > pages aren't in core should instead post a request for the pages to be > loaded (some kind of readahead mecanism?) and return immediately (maybe > having given some data that *was* in core). A subsequent read() could reads posts a readahead anyway so streaming reads tend not to block much > SGI's AIO might be a solution here, does it use threads? I'm trying to > avoid context switching as much as possible, to keep the CPU cache as > warm as possible. glibc 2.2 does thread based aio_ and it will tend to avoid cache damage as the thread share the mm but on SMP its quite possible the read wil occur on the other CPU. Of course kernel based I/O might do the same too.. - 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/
Oops while unmounting a reiserfs partition
Hello! I just mkreiserfsed a new partition (a 50g hardware raid0 array, I know this is just a testing machine), mounted it, and then unmounted it, and OOPS! My kernel version is plain 2.4.5... If you need more information, let me know. Jun 4 17:25:03 nynetops03 kernel: reiserfs: checking transaction log (device 08:11) ... Jun 4 17:25:07 nynetops03 kernel: Using r5 hash to sort names Jun 4 17:25:07 nynetops03 kernel: ReiserFS version 3.6.25 Jun 4 17:26:11 nynetops03 kernel: journal_begin called without kernel lock held Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! Jun 4 17:26:11 nynetops03 kernel: invalid operand: Jun 4 17:26:11 nynetops03 kernel: CPU:1 Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[] Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 edx: 0001 Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 esp: d8e15eac Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf c0268a61 d7e75250 00e8 Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 0018 d8e15f24 df9c5400 c02a8620 Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 000a c017ffdc d8e15f24 Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] [journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] [kill_super+162/288] [path_release+41/48] Jun 4 17:26:11 nynetops03 kernel: Call Trace: [] [] [] [] [] [] [] Jun 4 17:26:11 nynetops03 kernel:[sys_umount+301/352] [sys_munmap+51/80] [sys_oldumount+12/16] [system_call+51/56] Jun 4 17:26:11 nynetops03 kernel:[] [] [] [] Jun 4 17:26:11 nynetops03 kernel: Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 00 00 00 8d bc 27 And the decoded output: ksymoops 2.4.0 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /boot/System.map-2.4.5 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Warning (compare_maps): ksyms_base symbol machine_real_restart_R__ver_machine_real_restart not found in System.map. Ignoring ksyms_base entry Jun 4 17:26:11 nynetops03 kernel: kernel BUG at journal.c:423! Jun 4 17:26:11 nynetops03 kernel: invalid operand: Jun 4 17:26:11 nynetops03 kernel: CPU:1 Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[reiserfs_check_lock_depth+56/64] Jun 4 17:26:11 nynetops03 kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jun 4 17:26:11 nynetops03 kernel: EFLAGS: 00010282 Jun 4 17:26:11 nynetops03 kernel: eax: 001d ebx: d8e15f24 ecx: 0001 edx: 0001 Jun 4 17:26:11 nynetops03 kernel: esi: df9c5400 edi: ebp: 3b1bfcf3 esp: d8e15eac Jun 4 17:26:11 nynetops03 kernel: ds: 0018 es: 0018 ss: 0018 Jun 4 17:26:11 nynetops03 kernel: Process umount (pid: 4577, stackpage=d8e15000) Jun 4 17:26:11 nynetops03 kernel: Stack: c02678b3 c0267a44 01a7 c018e2cf c0268a61 d7e75250 00e8 Jun 4 17:26:11 nynetops03 kernel:df731000 40173000 d8e15f60 0018 d8e15f24 df9c5400 c02a8620 Jun 4 17:26:11 nynetops03 kernel:c02a8698 c018e516 d8e15f24 df9c5400 000a c017ffdc d8e15f24 Jun 4 17:26:11 nynetops03 kernel: Call Trace: [do_journal_begin_r+31/560] [journal_begin+22/32] [reiserfs_put_super+28/224] [iput+63/368] [fsync_super+180/192] [kill_super+162/288] [path_release+41/48] Jun 4 17:26:11 nynetops03 kernel: Call Trace: [] [] [] [] [] [] [] Jun 4 17:26:11 nynetops03 kernel:[] [] [] [] Jun 4 17:26:11 nynetops03 kernel: Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 8d b6 00 00 00 00 8d bc 27 >>EIP; c018bb98<= Trace; c018e2cf Trace; c018e516 Trace; c017ffdc Trace; c014bf3f Trace; c0137494 Trace; c013bd72 Trace; c0140e79 Trace; c013c22d Trace; c0126ec3 Trace; c013c26c Trace; c0106e0b Code; c018bb98 <_EIP>: Code; c018bb98<= 0: 0f 0b ud2a <= Code; c018bb9a 2: 83 c4 0c
Re: ide retry on 2.4.5-ac7
On Mon, Jun 04, 2001 at 11:09:33PM +0200, Jens Axboe wrote: > > This is not the case that is attempted solve. The above could be a cable > error (it looks like it). These are usually genuine and indicate a real > hw problem. I know about that, but I tried with other cable and the trouble leaves the same. On the other hand, before kernel 2.4.2 I think, (not sure of the number) the kernel does not want to activate UDMA on startup even with the option activated, and this on via mb. At that time, I used to force the DMA with hdparm, and I had no troubles in dma mode 3 with that hard disk, and I can remeber that udma mode 4 was even not indicate when I try hdparm -I /dev/hdc, so I don't know why it detects dma 4, and I did not manage to change that at boot time. Another example is the hda, which is an ibm DTLA hard drive. In 2.4.2 a 2.4.3 he made the same error in udma mode4, and since 2.4.4 no troubles anymore... I find it difficult to believe that it is hardware trouble! Furthemore, I began this thread because I heard someone else on this mailing list with the same crc error and I thought the patch in ac4 was in a way to solve the dma detect fails. thanks for your help Mike > > -- > Jens Axboe - 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: ide retry on 2.4.5-ac7
On Mon, Jun 04 2001, PROFETA Mickael wrote: > On Mon, Jun 04, 2001 at 10:14:04PM +0200, Jens Axboe wrote: > > > > It worked sucessfully for you in 2.4.5-ac4 but not in -ac7? I can't see > > any changes to the patch, so more details on the nature of the problem > > would be helpful. > > Ok, this is the results of a hdparm -tT on my second hard disk: > > hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } > hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } > hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } > ide1: reset: success > 64 MB in 7.03 seconds = 9.10 MB/sec > > and then the kernel has shifted to udma3 and I have no more error in this > session with that hard disk > > I tried the same thing on -ac7 and I always have the errors, the kernel does > not reset ide... Looking at the different change on ac patches, I can not see > why... This is not the case that is attempted solve. The above could be a cable error (it looks like it). These are usually genuine and indicate a real hw problem. -- Jens Axboe - 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: ide retry on 2.4.5-ac7
On Mon, Jun 04, 2001 at 10:14:04PM +0200, Jens Axboe wrote: > > It worked sucessfully for you in 2.4.5-ac4 but not in -ac7? I can't see > any changes to the patch, so more details on the nature of the problem > would be helpful. Ok, this is the results of a hdparm -tT on my second hard disk: hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } hdc: dma_intr: status=0x51 { DriveReady SeekComplete Error } hdc: dma_intr: error=0x84 { DriveStatusError BadCRC } ide1: reset: success 64 MB in 7.03 seconds = 9.10 MB/sec and then the kernel has shifted to udma3 and I have no more error in this session with that hard disk I tried the same thing on -ac7 and I always have the errors, the kernel does not reset ide... Looking at the different change on ac patches, I can not see why... Mike > > -- > Jens Axboe - 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/
disk-based fds in select/poll
Pardon me if some parts of this seem clueless. While I'm no newbie in userland, kernelspace I don't play in very often... It's fairly widely-known that select/poll returns immediately when testing a filesystem-based file descriptor for writability or readability. On top of this, even when in non-blocking mode, read() could block if the pages needed aren't in core. sendfile() behaves in a similar way. What would be needed to alleviate this? I am thinking that a read() (or sendfile()) that would block because the pages aren't in core should instead post a request for the pages to be loaded (some kind of readahead mecanism?) and return immediately (maybe having given some data that *was* in core). A subsequent read() could have the data available, but not necessarily (again, it should give whatever it has in core, but return immediately). sendfile() would be a lot more tricky to fix in that way I guess, but could still be possible (the destination fd would be unwritable for a while, until the transfer is finished). Also, the complexity would be higher (instead of simply causing readahead to happen (which might anyway), it would have to trigger the readahead, then get notification of when the pages are in core to send over, all the while preventing data from being written to the destination fd in some way). In the mean time, I was also wondering if issuing smaller read() requests in a row might give me a better chance of success. I *know* read() will block, but if I only ask for, say, a page of data (rather than asking for the full data and relying on the non-blocking to return EAGAIN (like it should, IMHO!)), it shouldn't take too long, and could possibly trigger some readahead to be done by the kernel, right? Or will the readahead be done "on my own time", read() only returning after the whole thing (my request + readahead) has been done? I remember seeing a suggestion by Linus for an event-based I/O interface, similar to kqueue on FreeBSD but much simpler. I'd just say "I want it too!", ok? :-) I know about the mincore() trick with mmap()'d files, but with small files, mmap()ing might not make sense (could be very often). SGI's AIO might be a solution here, does it use threads? I'm trying to avoid context switching as much as possible, to keep the CPU cache as warm as possible. Well, I might not have the choice to use threads, after all... (sorry if this message got in twice, I used an NNTP gateway the previous time, I don't think it got through) -- Pierre Phaneuf - 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: lowlatency 2.2.19
On Mon, 4 Jun 2001, Andrea Arcangeli wrote: > On Sun, Jun 03, 2001 at 10:38:34AM -0400, William Montgomery wrote: > > Anyone have any ideas? > > Which options did you enabled? In theory the ikd patch could only make > the latency worse ;), there are no performance improvements in it but > only runtime debugging stuff. > I am including a snippet from my .config: # # Kernel hacking # CONFIG_MAGIC_SYSRQ=y # CONFIG_KMSGDUMP is not set CONFIG_KERNEL_DEBUGGING=y # CONFIG_SEMAPHORE_DEADLOCK is not set # CONFIG_DEBUG_KSTACK is not set # CONFIG_KSTACK_METER is not set # CONFIG_DEBUG_SOFTLOCKUP is not set # CONFIG_PROFILE_GCC is not set CONFIG_TRACE=y CONFIG_TRACE_SIZE=16384 CONFIG_TRACE_TIMESTAMP=y # CONFIG_TRACE_TRUNCTIME is not set CONFIG_TRACE_PID=y CONFIG_TRACE_CPU=y CONFIG_DEBUG_MCOUNT=y # CONFIG_PRINT_EIP is not set # CONFIG_MEMLEAK is not set # CONFIG_KDB is not set --- I cant see anything that could make latency better either but I can induce 1 to 2.5msec jitter in a 2.2.19 kernel with only lowlatency patch after a few minutes stress testing. The kernel with both ikd and lowlatency patches tests fine after 24 hrs of stress testing - jitter always under 1msec. Wm - 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/
kernel oops when burning CDs
Hello everybody! I get an ooops and immediate kernel panic when I break (CTRL-C) cdrecord. I can reproduce it anytime. I use 2.4.5-ac series. Obviously, Linus' 2.4.5 is fine. I know, I know. I was supposed to make a serios oops report, BUT I wasn't able to get the serial console running. (I've read some people couldn't get it to run either.) Can anyone help me with any of the problems? Rudo Thomas. - 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-ac7 SMP crash (hotplug race?)
>I told device to go to sleep, it reported (over serial console that I >looked at with minicom), that it turned off internal devices >(including USB client), reported it is going to sleep, and turned >serial and itself off. What does it mean "I told device to go to sleep"? What device? How (what command line)? > wait_on_irq, CPU 1 > irq: 1 [1 0] > bh: 1 [0 1] > CPU 0: > CPU 1: c167fe68 c01d805d ... (not recorded full stack) > Call Trace: [] [] [] [] [] >[] [] [] [] [] [] >[] [] [] [] [] > Warning (Oops_read): Code line not seen, dumping what data is available > > Trace; c0108522 <__global_cli+e2/170> > Trace; c0170f97 > Trace; c0170f60 > Trace; c011d706 > Trace; c011a56c > Trace; c011a423 > Trace; c011a2ab > Trace; c0108935 > Trace; c0108525 <__global_cli+e5/170> > Trace; c01617e8 > Trace; c011a67d <__run_task_queue+5d/70> > Trace; c0121c35 > Trace; c0121670 > Trace; c0105000 > Trace; c0105556 > Trace; c0121670 Curious. What host controller driver do you use? -- Pete - 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: ide retry on 2.4.5-ac7
On Mon, Jun 04 2001, PROFETA Mickael wrote: > Hi > > Since my first try on 2.4 kernel, I had trouble with DMA when I > select activate on boot time because it selects udma4, whereas > my HD is only able to do udma2. I correct that with hdparm, but > I was quite happy of the patch in ac4 whixh detect ide lost > interrupt and retry with a value lower of dma. But it seems > that this patch does not work anymore in ac7?? I can not see in > the changelog that you come back or made other change in ide?? > Should it work in the same way or not? > > My hardware: via 686a of course, with Athlon 500 on a k7m MB It worked sucessfully for you in 2.4.5-ac4 but not in -ac7? I can't see any changes to the patch, so more details on the nature of the problem would be helpful. -- Jens Axboe - 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: Linux 2.4.5-ac7
> 2.4.5-ac7 fixes the cs46xx problems I had with my ThinkPad 600X in > 2.4.5-ac[456]. It works great now. Many thanks to Frank Davis and Alan Cox! And also to Tom Woller and Crystal themselves who have been fixing a lot of the cs46xx real problems while we broke and fixed the locking - 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: Error Compiling Driver code:
1) Check the FAQ - http://www.tux.org/lkml/#s8 2) RH6.2 as it is doesn't come with all the newest tools versions needed for the 2.4.x kernels. See Documentation/versions. HTH, Vassilii > -Original Message- > Hi , > I am trying to compile a driver code in Red Hat 6.2 > which is already a working code, but I get the > following errors when i compile. > > /usr/src/linux/include/asm/smp.h:206: arguments given > to macro `hard_smp_processor_id' > [snip] > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Error Compiling Driver code:
Hi , I am trying to compile a driver code in Red Hat 6.2 which is already a working code, but I get the following errors when i compile. /usr/src/linux/include/asm/smp.h:206: arguments given to macro `hard_smp_processor_id' Any clue or hint will be helpful. Thanks jalaja __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.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/
Kernel Stack usage [was: [PATCH] fs/devfs/base.c]
> Bill Pringlemeir <[EMAIL PROTECTED]> writes: > There was a discussion on comp.arch.embedded about bounded stack > use. It is fairly easy to calculate the stack usage for call > trees, but much more difficult for `DAGs'. Ie, a recursive > functions etc. I don't know about the policy on recursion in the > kernel, but I think it would be bad. > Perhaps the checker could be modified to keep track of the call > tree and find the largest value used in the tree. Each function > will have a maximum, to which you should add the interrupt > handling overhead, which would be calculated in a similar way. > This will work if you do not allow re-entrant interrupts and you > do not have any `cycles' in the function call hierarchies. Sorry, I neglected the important case of `alloca', and other variable length stack allocation functions/constructs. Maybe this becomes too restrictive to be useful. regards, Bill Pringlemeir - 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-ac7 usb-uhci appears twice in /proc/interrupts
PR> I don't know, maybe it's Ok, but it looks confusing - usb-uhci is listed PR> twice on the same IRQ 9. [...] PR> 9: 0 XT-PIC usb-uhci, usb-uhci [...] PR> 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) PR> 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) This is normal, you do have two of these. But a there's a little copy-paste error(?) on uhci.c: both usb-uhci.c and uhci.c register themselves as usb-uhci. (in request_region and request_irq and uhci_pci_driver). -- Meelis Roos ([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: [PATCH] fs/devfs/base.c
> "Richard" == Richard Gooch <[EMAIL PROTECTED]> writes: [snip] > I guess we should ask the question as to what's an > acceptable usage. Theoretically, any amount could pose a > problem, but that's hardly a useful position to work There was a discussion on comp.arch.embedded about bounded stack use. It is fairly easy to calculate the stack usage for call trees, but much more difficult for `DAGs'. Ie, a recursive functions etc. I don't know about the policy on recursion in the kernel, but I think it would be bad. Perhaps the checker could be modified to keep track of the call tree and find the largest value used in the tree. Each function will have a maximum, to which you should add the interrupt handling overhead, which would be calculated in a similar way. This will work if you do not allow re-entrant interrupts and you do not have any `cycles' in the function call hierarchies. hth, Bill Pringlemeir. - 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(-ac*] still broken NFS/Reiserfs
I've got two machines here running 2.4.5-ac6 with Chris Mason's posted 2.4.5 Reiserfs/knfsd patch, plus the small 2.4.5 NFS client patch posted last week as well. Even with all of this, I still have NFS weirdness. >From the client, I can mount and read pretty much anything I like from the server. I can create files in existing directories on the server. I can create new directories on the server. I _cannot_, however, create anything in a directory I created from the client (I get "file/directory does not exist" errors). I have also seen one case where the client's directory listing for a directory at the root of an export point did not match the server's listing until I unmounted and remounted the NFS mount. Most of the time, this problem does not occur. It's very intermittent. I can boot up my client, and it will work fine for 24 hours, or it will fail in five minutes. Once it fails, an unmount/remount seems to cure it. There is still major weirdness going on here, and I'm hesitant to try unfsd unless someone can say that it works reliably... I do need to find a solution to this though, and am willing to help in whatever way I can. - 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-storage and 2.4.2
Try 2.4.5, which has some assorted fixes that should solve this problem. Matt On Sun, Jun 03, 2001 at 08:08:25PM -0500, Jerry Frana wrote: > Hi, i've been having a problem with my usb zip drive (older 100mb model) > > it's 100% repeateble: > > copy a large file to anywhere, and within a minute or so: > copy stops dead. > and the following appears in the syslog: > > Jun 3 21:10:56 int-21h kernel: uhci: host controller process error. something bad >happened > Jun 3 21:10:56 int-21h kernel: uhci: host controller halted. very bad > > my machine is a K6-3/350, kernel 2.4.2, via mvp3 chipset > > if you need any more info, please let me know, > > Thanks > David F. > - > 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/ -- Matthew Dharm Home: [EMAIL PROTECTED] Senior Software Designer, Momentum Computer C: Why are you upgrading to NT? AJ: It must be the sick, sadistic streak that runs through me. -- Chief and A.J. User Friendly, 5/12/1998 PGP signature
Re: keyboard hook?
> Input API looks nice. For now, I'll write a patch against pc_keyb.c to add a > hook for my qoder stuff, and a loadable module for the meat of the > driver. Okay. > Then I'll port up to the input API. Just send me the code and I will place it into CVS. >I have a Sparc here; does it have drivers you wish to have ported? Alot of work has to be done their :-/ If you are up to it I would be happy to work with you. - 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/
I/O tracing
Hi, Please CC me as I'm not subscribed on the list, thanks. Not sure if this is appropriate forum, is there an existing tool/module for capturing all the I/O requests such as: Unique Identifier Start Time End Time Device Identifier Operation Type (Read Or Write) Offset Length (Number Of Bytes) I am aware of existing /proc/disks and partitions, but these aren't real time. If not, are there any facilities in the kernel I can put a hook in to keep track of the I/O? Thanks in advance, Sammy Yu Hewlett-Packard - 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/
iptables port remapping problem (was: [newbie] NFS client:port-unreachable)
On Sun, 3 Jun 2001, Trond Myklebust wrote: > 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. When I mount via nfs each mount gets its own local port to communicate with the server. Looking at /proc/net/ip_conntrack I see that one such port (797) got remapped to 772, so I see packets emerging from 772 and getting back from the server, but the mapping is not done upon receive, so that it does not reach port 797 (where it originally came from) but port 772 which has no process attached. This results in an ICMP_PORT_UNREACH to the server and an nfs client not getting an answer. This problem can be cured by 'rmmod ip_conntrack' and restarting the firewall, which is not a good solution. My conclusion: Either iptables has a problem when remapping ports under moderate load (several RPCs masqueraded per second) or the nfs-client does not properly reserve the local port when mounting. BTW: I use util-linux-2.11d but still get 'nfs warning: mount version older than kernel'. DETAILS: I have a DECstation being nis domain server and nfs server for /home, /compass, /usr/local and some other things (all different directories on the server, I have given the mount points for the clients). There are a dozen clients being served without problems, mostly running 2.2.14 (RedHat 6.2), some 2.4.2 (SuSE 7.1). Besides I have another server (RedHat 7.1, kernel 2.4.4 with knfsd-reiserfs-patch from namesys.com), which also mounts /home and /compass from the DEC and serves some internal disk space to a linux cluster (RedHat 6.2). This server has IP 217, but masquerades (via iptables -j SNAT) the cluster as having IPs 218 or 219 (roughly half of the 32 machines on each address), since the cluster machines have no other connection to the internet because we ran out of IPs. Ciao, Roland +-+ |Tel.:089/326493320561/873744 | |in Radeberger Weg 8Am Fasanenhof 16| | 85748 Garching 34125 Kassel| +---+-+ |Physik-Department E18 | Raum3558 | |James-Franck-Str. | Telefon 089/289-12592 | |85747 Garching | | +---+-+ | May the Source be with you! | +-+ - 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, Jun 03, 2001 at 07:25:25AM -0400, Alexander Viro wrote: > BTW, bind and friends are also easy - it's > what = open(old, 0); > where = open(mountpoint, 0); > new_mount(where, MNT_BIND, what); > > Comments? What if `what' and or `where' aren't directories but e.g. sockets? (IOW, would this allow binding sockets into the filesystem, or am I being too perverse here?) Happy Hacking -- Linux 2.4.5-ac6 #2 Sun Jun 3 15:45:27 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: symlink_prefix
> Current interface had grown an impressive collection of warts. > Worse yet, you _can't_ put parsing into generic code. > There are filesystems that have a binary object as 'data'. Yes, that was a very unfortunate decision, back in the good old times when nfs was implemented. And smb, ncp, coda followed nfs. Nevertheless, there is no problem adding vfs_parse_mount_options(). For example, one can have a flag FS_HAS_BINARY_MOUNT_DATA in the fs_flags field of the struct file_system_type that describes the filesystem type, and refrain from trying to parse the mount data when this bit is set. 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: symlink_prefix
On 2001-06-03, [EMAIL PROTECTED] wrote: > Suppose I have devices /dev/a, /dev/b, /dev/c that contain the > /, /usr and /usr/spool filesystems for FOO OS. Now > mount /dev/a /mnt -o symlink_prefix=/mnt > mount /dev/b /mnt/usr -o symlink_prefix=/mnt > mount /dev/c /mnt/usr/spool -o symlink_prefix=/mnt Cool. What happens when someone creates new absolute symlinks under /mnt ? Will/should the magic /mnt/ header be stripped from any symlink created under such a path-translated volume? The answer is probably 'yes', but either one violates POLA :( -- Hank Leininger <[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/
Tulip and eepro100 problems
Hi all, First of all.. please include [EMAIL PROTECTED] in your replies since my regular mail account in which I get the list mails is not functional at the moment. I've just installed a fresh linux system. Default Mandrake 8.0 kernel (2.4.3-20mdksmp) and the plain vanilla 2.4.5 kernel both give me this same behaviour. LNE100TX card in my system gets initialized just fine - however no matter what I do it will not send any data. Not if I run it via a 10 Mbit hub neither via a cross cable at 100 Mbit. At the other side there is a LNE100TX card in a Win2k Pro system. There is an Intel onboard card in this system as well using the eepro100 driver. This card seems to function fine when used via the 10 Mbit hub - however once I connect it via a cross cable and it switches from 10 Mbit half duplex to 100 Mbit full duplex it stops responding completely as well. I've seen some emails in the archives about the tulip driver being broken for some people - however the mails I saw mentioned 2.4.4 and above. I've tried both the 2.4.5 vanilla and the mandrake 2.4.3-20 (both compiled with smp support). The log file shows: Jun 3 18:07:50 badaboom kernel: eth0: DC21041 at 0xf480 (PCI bus 0, device 11), h/w address 00:00:c5:0c:f1:82, Jun 3 18:07:50 badaboom kernel: and requires IRQ16 (provided by PCI BIOS). Jun 3 18:07:50 badaboom kernel: de4x5.c:V0.546 2001/02/22 [EMAIL PROTECTED] Jun 3 18:07:50 badaboom kernel: eth0: media is TP. Jun 3 18:07:50 badaboom kernel: eepro100.c:v1.09j-t 9/29/99 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html Jun 3 18:07:50 badaboom kernel: eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[EMAIL PROTECTED]> and ot hers Jun 3 18:07:50 badaboom kernel: eth1: Intel Corporation 82557 [Ethernet Pro 100], 00:A0:C9:49:BC:D0, IRQ 18. Jun 3 18:07:50 badaboom kernel: Receiver lock-up bug exists -- enabling work-around. Jun 3 18:07:50 badaboom kernel: Board assembly 645520-034, Physical connectors present: RJ45 Jun 3 18:07:50 badaboom kernel: Primary interface chip DP83840 PHY #1. Jun 3 18:07:50 badaboom kernel: DP83840 specific setup, setting register 23 to 8462. Jun 3 18:07:50 badaboom kernel: General self-test: passed. Jun 3 18:07:50 badaboom kernel: Serial sub-system self-test: passed. Jun 3 18:07:50 badaboom kernel: Internal registers self-test: passed. Jun 3 18:07:50 badaboom kernel: ROM checksum self-test: passed (0x49caa8d6). Jun 3 18:07:50 badaboom kernel: Receiver lock-up workaround activated. Jun 3 18:07:50 badaboom kernel: Linux Tulip driver version 0.9.15-pre2 (May 16, 2001) Jun 3 18:07:50 badaboom kernel: PCI: Unable to reserve I/O region #1:80@f480 for device 00:0b.0 Jun 3 18:07:50 badaboom kernel: Trying to free nonexistent resource Jun 3 18:07:50 badaboom kernel: tulip1: MII transceiver #1 config 3100 status 7809 advertising 01e1. Jun 3 18:07:50 badaboom kernel: eth2: Lite-On 82c168 PNIC rev 32 at 0xf800, 00:C0:F0:3E:70:57, IRQ 19. Anyone any ideas on how to get this to work? Thanks, Jasper - 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/
Cache size calculation on Athlon/Duron
Hi, Reading through arch/i386/kernel/setup.c in 2.4.5, I noticed that the code which sets x86_cache_size sets it to the size of the chip's L2 cache if present. Which is fine for everything except the Athlon/Duron, which have exclusive L1/L2 caches, so surely they should be added together in this case to give the total cache size? Or am I just missing something stupid? --- arch/i386/kernel/setup.c.orig Sun Jun 3 21:49:45 2001 +++ arch/i386/kernel/setup.cSun Jun 3 22:16:58 2001 @@ -1098,7 +1098,15 @@ if ( l2size == 0 ) return; /* Again, no L2 cache is possible */ - c->x86_cache_size = l2size; + /* +* Athlon/Duron have exclusive L1/L2 cache, so sum them, +* for everyone else set cache size to be L2 only. +*/ + if (c->x86_vendor == X86_VENDOR_AMD && c->x86 == 6) { + c->x86_cache_size += l2size; + } else { + c->x86_cache_size = l2size; + } printk(KERN_INFO "CPU: L2 Cache: %dK (%d bytes/line)\n", l2size, ecx & 0xFF); -- James Slater [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: XMM: monitor Linux MM inactive/active lists graphically
> XMM is heavily modified XMEM utility that shows graphically size of > different Linux page lists: active, inactive_dirty, inactive_clean, > code, free and swap usage. It is better suited for the monitoring of > Linux 2.4 MM implementation than original (XMEM) utility. > > Find it here: http://linux.inet.hr/> interesting. I prefer to collect data separately from viewing it, and use the following simple perl script to do so; obviously, it generates a bunch of separate files, one for each metric, suitable for traditional filtering, gnuplot, etc. #!/bin/perl use IO::Handle; require 'sys/syscall.ph'; sub gettimeofday { $timeval = pack("LL", ()); syscall( &SYS_gettimeofday, $timeval, 0) != -1 or die "gettimeofday: $!"; ($sec,$usec) = unpack("LL", $timeval); return $sec + 1e-6 * $usec; } open(S,"pi.st"); PI->autoflush(1); open(PO,">po.st"); PO->autoflush(1); open(SI,">si.st"); SI->autoflush(1); open(SO,">so.st"); SO->autoflush(1); open(CX,">ctx.st"); CX->autoflush(1); open(MF,">free.st");MF->autoflush(1); open(BF,">buf.st"); BF->autoflush(1); open(AC,">act.st"); AC->autoflush(1); open(ID,">id.st"); ID->autoflush(1); open(IC,">ic.st"); IC->autoflush(1); open(IT,">it.st"); IT->autoflush(1); open(SW,">swap.st");SW->autoflush(1); open(BH,">bh.st"); BH->autoflush(1); open(IN,">inode.st"); IN->autoflush(1); open(DE,">dentry.st"); DE->autoflush(1); $c = 0; $first = gettimeofday(); while (1) { sleep(1); $now = gettimeofday() - $first; seek(S,0,SEEK_SET); while () { if (/^page\s+(\d+)\s+(\d+)$/) { if ($c) { print PI "$now ",4*($1 - $pi),"\n"; } if ($c) { print PO "$now ",4*($2 - $po),"\n"; } $pi = $1; $po = $2; next; } if (/^swap\s+(\d+)\s+(\d+)$/) { if ($c) { print SI "$now ",4*($1 - $si),"\n"; } if ($c) { print SO "$now ",4*($2 - $so),"\n"; } $si = $1; $so = $2; next; } if (/^ctxt\s+(\d+)$/) { if ($c) { print CX "$now ",$1 - $cx,"\n"; } $cx = $1; next; } } seek(M,0,SEEK_SET); while () { if (/^MemFree:\s+(\d+) kB$/) {print MF "$now ",$1,"\n"; next; } if (/^Buffers:\s+(\d+) kB$/) {print BF "$now ",$1,"\n"; next; } if (/^Active:\s+(\d+) kB$/) { print AC "$now ",$1,"\n"; next; } if (/^Inact_dirty:\s+(\d+) kB$/) {print ID "$now ",$1,"\n"; next; } if (/^Inact_clean:\s+(\d+) kB$/) {print IC "$now ",$1,"\n"; next; } if (/^Inact_target:\s+(\d+) kB$/) { print IT "$now ",$1,"\n"; next; } if (/^Inact_target:\s+(\d+) kB$/) { print IT "$now ",$1,"\n"; next; } if (/^Swap:\s+\d+\s+(\d+)/) { print SW "$now ",$1,"\n"; next; } } seek(B,0,SEEK_SET); while () { if (/^buffer_head\s+(\d+)\s+(\d+)\s+(\d+)/) { print BH "$now ",$1*$3/1024,"\n"; next; } if (/^inode_cache\s+(\d+)\s+(\d+)\s+(\d+)/) { print IN "$now ",$1*$3/1024,"\n"; next; } if (/^dentry_cache\s+(\d+)\s+(\d+)\s+(\d+)/) {print DE "$now ",$1*$3/1024,"\n"; next; } } $c++; } - 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/
I810 Sound broke between 2.4.2 and 2.4.3
I use amp to play my mp3s and it seem to stop functioning since 2.4.3. I captured the kernel messages from the module : --- 2.4.2 --- Intel 810 + AC97 Audio, version 0.01, 14:04:06 Jun 4 2001 PCI: Found IRQ 10 for device 00:1f.5 PCI: The same IRQ used for device 00:1f.3 PCI: The same IRQ used for device 01:09.0 PCI: Setting latency timer of device 00:1f.5 to 64 i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, IRQ 10 ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881) i810_audio: Codec refused to allow VRA, using 48Khz only. --- 2.4.3 --- Intel 810 + AC97 Audio, version 0.01, 14:18:58 Jun 4 2001 PCI: Found IRQ 10 for device 00:1f.5 PCI: The same IRQ used for device 00:1f.3 PCI: The same IRQ used for device 01:09.0 PCI: Setting latency timer of device 00:1f.5 to 64 i810: Intel ICH 82801AA found at IO 0xe100 and 0xe000, IRQ 10 ac97_codec: AC97 Audio codec, id: 0x4144:0x5340 (Analog Devices AD1881) i810_audio: Codec refused to allow VRA, using 48Khz only. i810_audio: 9576 bytes in 50 milliseconds an strace of amp seems to halt on writing to the /dev/dsp I have an Intel Celeron on an Asus-MEW motherboard which has this soundcard integrated. Any ideas? Ben - 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...
On 06.02 Pavel Machek wrote: > 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. > I have tried the latest CVS i2c+lm_sensors2, and the patches it generates look like much more clean. I am waiting for the announced 2.6 relase, and then will try to send a patch to Alan (if official mantainer do not does it himself...) -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac6 #2 SMP Sat Jun 2 01:52:13 CEST 2001 i686 - 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-storage and 2.4.2
Hi, i've been having a problem with my usb zip drive (older 100mb model) it's 100% repeateble: copy a large file to anywhere, and within a minute or so: copy stops dead. and the following appears in the syslog: Jun 3 21:10:56 int-21h kernel: uhci: host controller process error. something bad happened Jun 3 21:10:56 int-21h kernel: uhci: host controller halted. very bad my machine is a K6-3/350, kernel 2.4.2, via mvp3 chipset if you need any more info, please let me know, Thanks David F. - 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? We upgraded to 2.4.5-ac2 for some test, noted that the ethernet card was agian in 6-packets-per-second mode (i.e. very slow) and then continued to 2.4.5-ac4 where the driver was reverted to the one in 2.4.3. That worked. Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - 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-ac7 usb-uhci appears twice in /proc/interrupts
Hello! I don't know, maybe it's Ok, but it looks confusing - usb-uhci is listed twice on the same IRQ 9. # cat /proc/interrupts CPU0 0: 82287 XT-PIC timer 1: 2624 XT-PIC keyboard 2: 0 XT-PIC cascade 8: 1 XT-PIC rtc 9: 0 XT-PIC usb-uhci, usb-uhci 10:781 XT-PIC eth0 11: 0 XT-PIC eth1 12:900 XT-PIC PS/2 Mouse 14: 17434 XT-PIC ide0 15: 9 XT-PIC ide1 NMI: 0 LOC: 82250 ERR: 15 .config is here: http://www.red-bean.com/~proski/linux/config In short, all USB stuff is compiled as modules. # CONFIG_USB_UHCI is not set CONFIG_USB_UHCI_ALT=m # CONFIG_USB_OHCI is not set It's a brand new VIA motherboard, so I don't know whether the problem existed in the earlier kernels or not (if it's a problem). It looks like that the motherboard has two USB controllers: 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 20) 00:08.0 Ethernet controller: 3Com Corporation 3c900 10BaseT [Boomerang] 00:09.0 Ethernet controller: Bridgecom, Inc: Unknown device 0985 (rev 11) 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c) -- Regards, Pavel Roskin - 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
From [EMAIL PROTECTED] Sun Jun 3 13:25:31 2001 > [One could start a subdiscussion about that part. > The mount(2) system call needs to transport vfs information > and per-fs information. So far, the vfs information used > flag bits only, but sooner or later we'll want to have > strings, and need a vfs_parse_mount_options(). > Indeed, many filesystems today have uid= and gid= and > umask= options that might be removed from the individual > filesystems and put into vfs. After all, such options > are also useful for (foreign) ext2 filesystems.] _Please_, if we do anything of that kind - let's use a new syscall. Ideally, I'd say fs_fd = open("/fs/ext2", O_RDWR); /* error -> no such filesystem */ write(fs_fd. "/dev/sda1", strlen("/dev/sda1")); /* error handling */ write(fs_fd, "reserve=5", strlen()); ... dir = open("/usr/local", O_DIRECTORY); /* error handling */ new_mount(dir, MNT_SET, fs_fd);/* closes dir and fs_fd */ /* error handling */ Comments? I do not think this is an improvement. Anyway, it is orthogonal to what I discussed. [My version: keep interface constant, reorganize kernel source to do certain things in one place instead of in several places. Advantage: treatment becomes uniform and some options that make sense for all filesystem types but are available today for some only are generalized. Your version: invent a new interface, be silent about what happens inside the kernel.] 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: USB mouse wheel breakage was Re: Linux 2.4.5-ac5
On Fri, Jun 01, 2001 at 10:57:17AM +0100, Michael wrote: > On Wed, May 30, 2001 at 09:30:39PM +0100, Alan Cox wrote: > > 2.4.5-ac4 > > o Update USB hid drivers (Vojtech Pavlik) > > I think these changes have broken my USB wheel mouse. > > Events seems to be getting lost (/dev/input/mice) > > It only scrolls when either the scroll direction has changed or if other > mouse events occur (e.g. you need to wiggle mouse from side to side to > scroll down a long page in mozilla) > > problems seems to be in drivers/usb/hid-core.c hid_input_field line 772 > > for (n = 0; n < count; n++) { > > if (HID_MAIN_ITEM_VARIABLE & field->flags) { > > if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n]) > continue; > The next 2 lines are dropping the scroll wheel events (which appear in the > input code as type:2, code: 8, value -1 or 1 depending on direction) > > if (value[n] == field->value[n]) > continue; > hid_process_event(hid, field, &field->usage[n], value[n]); > continue; > } Thanks for the detailed report. Here is the fix. Alan, please apply this to -ac5. -- Vojtech Pavlik SuSE Labs diff -urN linux-2.4.5-ac4/drivers/usb/hid-core.c linux/drivers/usb/hid-core.c --- linux-2.4.5-ac4/drivers/usb/hid-core.c Tue May 29 19:48:15 2001 +++ linux/drivers/usb/hid-core.cFri Jun 1 16:30:33 2001 @@ -775,7 +775,7 @@ if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n]) continue; - if (value[n] == field->value[n]) + if ((~field->flags & HID_MAIN_ITEM_RELATIVE) && value[n] == +field->value[n]) continue; hid_process_event(hid, field, &field->usage[n], value[n]); continue;
Looking for device to write device driver for
This may well be a question whose appropriate response is RTFM. However, I did look first. I am taking a class on writing device drivers for Linux. I am currently looking for a device to write a driver for. I first tried to get the engineering specification for my soundcard, but after much frustration I gave up on dealing with the manufacturer. I then tried to get the interface information from 3com on their new 3cr990 card to add IPsec offload support to the linux driver. They responded by telling me that due to IP-heavy nature of the product that they would not be releasing the interface. It was later explained to me (in different terms) that most cards on the market are fundamentally commodity items and as such the only way that manufacturers can ensure their margins is by obscuring the interface so that other manufacturers don't use the same interface and undercut them. This leads to my question: Is there some central resource for listing unsupported cards that people have expressed an interest in seeing supported. The closest I could find was Cosource, but that is fairly limited. -Kip - 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: Linux 2.4.5-ac7
On Sun, 3 Jun 2001, Oleg Drokin wrote: > Hello! > > In article <[EMAIL PROTECTED]> you wrote: > > AC> 2.4.5-ac7 > AC> o Make USB require PCI(me) > Huh?! > How about people from StrongArm sa11x0 port, who have USB host controller (in > sa companion chip) but do not have PCI? If it ever gets to a stability point where it's worth including in Alan's tree, then the dependency could easily be modified to be "USB requires PCI or SA". In the mean time I keep that hairball in my tree. Nicolas - 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: Linux 2.4.5-ac7
2.4.5-ac7 fixes the cs46xx problems I had with my ThinkPad 600X in 2.4.5-ac[456]. It works great now. Many thanks to Frank Davis and Alan Cox! 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/
Re: symlink_prefix
On Sun, 3 Jun 2001 [EMAIL PROTECTED] wrote: > What I did was: add a field `char *mnt_symlink_prefix;' to the > struct vfsmount, fill it in super.c:add_vfsmnt(), use it in > namei.c:vfs_follow_link(). Pick the value up by recognizing > in super.c:do_mount() the option "symlink_prefix=" before > giving the options to the separate filesystems. > > [One could start a subdiscussion about that part. The mount(2) > system call needs to transport vfs information and per-fs information. > So far, the vfs information used flag bits only, but sooner or later > we'll want to have strings, and need a vfs_parse_mount_options(). > Indeed, many filesystems today have uid= and gid= and umask= options > that might be removed from the individual filesystems and put into vfs. > After all, such options are also useful for (foreign) ext2 filesystems.] _Please_, if we do anything of that kind - let's use a new syscall. Ideally, I'd say fs_fd = open("/fs/ext2", O_RDWR); /* error -> no such filesystem */ write(fs_fd. "/dev/sda1", strlen("/dev/sda1")); /* error handling */ write(fs_fd, "reserve=5", strlen()); ... dir = open("/usr/local", O_DIRECTORY); /* error handling */ new_mount(dir, MNT_SET, fs_fd); /* closes dir and fs_fd */ /* error handling */ First open gives you a new channel. Preferably - wit datagram semantics (i.e. write() boundaries are preserved). Then you convince fs driver to give you fs. Then you mount it. Notice that all cruft with "mount ncpfs and then use ioctls to authenticate" goes away - authentication happens before you mount. Parsers are also easier that way. Moreover, seeing what filesystem types are available is also trivial, etc. We need only one special case - mounting that fstypefs. Fine, let's make new_mount(dir, MNT_TYPES) do that. BTW, bind and friends are also easy - it's what = open(old, 0); where = open(mountpoint, 0); new_mount(where, MNT_BIND, what); Comments? - 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: Benchmarks for Linux kernel
On Fri, Jun 01, 2001 at 09:12:14PM -0700, Jaswinder Singh wrote: > Can please point me some nice benchmarks for linux kernel . Linux Benchmark Suite http://lbs.sf.net/ -- Nate Straz [EMAIL PROTECTED] sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ - 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: [CHECKER] security rules? (and 2.4.5-ac4 security bug)
On 2001-06-03, Dawson Engler <[EMAIL PROTECTED]> wrote: > Additionally, do people have suggestions for good security rules? > We're looking to expand our security checkers. Right now we just have > checkers that warn when: Do you already have checks for signed/unsigned issues? Those often result in security problems, although you may already be checking for them simply for reliable-code purposes. ...Hm, looking at the archives, I see Chris Evans responded about signedness issues when you asked last month :-P You may want to check out and/or subscribe to the security-audit list; most of the discussion is about userland security issues but kernel problems (or potential ones) are discussed as well. We have archives of the list at: http://marc.theaimsgroup.com/?l=linux-security-audit&r=1&w=2 And see http://www.linuxhelp.org/lsap.shtml for more info, subscribing, etc. -- Hank Leininger <[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/
Linux-2.4.5 BUG
Hi to all of you ! I have this problem with the linux-2.4.5. When I want to shutdown the system I get this error message: // journal_begin called without kernel lock held kernel BUG at journal.c:423! invalid operand: CPU:1 EIP:0010:[] EFLAGS: 00010286 eax: 001d ebx: c12b3f2c ecx: 0001 edx: 0001 esi: c7f41600 edi: c12b3f2c ebp: 000a esp: c12b3ec4 ds: 0018 es: 0018 ss: 0018 Process umount (pid: 2861, stackpage = c12b3000) Stack: c025416c c0254304 01a7 c017791e c0255321 c12b3f2c c7f41600 c02996a0 c7f41644 3b1a4df9 c12b3f98 3b1a4df9 0010 c025532f c0177b4e c12b3f2c c7f41600 000a c0169d7c c12b3f2c c7f41600 000a Call Trace: [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 0c c3 89 f6 31 c0 c3 90 31 c0 c3 90 56 53 31 db Unmounting any remaining filesystems... // Then the machine stops and I have to switch it off , I use the linux-2.4.5 kernel with reiserfs compiled in and glibc-2.2.2 If you can help me solve this would be very apreciated. Thank you in advance. Sasa Ostrouska - 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/
multicast hash incorrect on big endian archs
I noticed that the multicast hash calculations assumed little endian byte ordering in the winbond-840 driver, and it seems that several other drivers are also affected: 8139too, epic100, fealnx, pci-skeleton, sis900, starfile, sundance, via-rhine, yellowfin perhaps drivers/net/pcmcia/xircom_tulip_cb I've attached an untested patch. It's possible that the nic performs another byte swap if configured for big endian support, but I've never seen a nic that performs byte swaps on register writes, only on memory reads. Please cc me, I'm not subscribed to the mailing lists. -- Manfred diff -u 2.4/drivers/net/8139too.c build-2.4/drivers/net/8139too.c --- 2.4/drivers/net/8139too.c Sat Jun 2 14:19:44 2001 +++ build-2.4/drivers/net/8139too.c Sun Jun 3 19:46:05 2001 @@ -2248,6 +2248,10 @@ return crc; } +static void set_bit_32(int offset, u32 * data) +{ + data[offset >> 5] |= (1 << (offset & 0x1f)); +} static void rtl8139_set_rx_mode (struct net_device *dev) { @@ -2283,7 +2287,7 @@ mc_filter[1] = mc_filter[0] = 0; for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count; i++, mclist = mclist->next) - set_bit (ether_crc (ETH_ALEN, mclist->dmi_addr) >> 26, + set_bit_32(ether_crc (ETH_ALEN, mclist->dmi_addr) >> 26, mc_filter); } diff -u 2.4/drivers/net/epic100.c build-2.4/drivers/net/epic100.c --- 2.4/drivers/net/epic100.c Sat May 26 10:06:26 2001 +++ build-2.4/drivers/net/epic100.c Sun Jun 3 19:48:44 2001 @@ -1305,11 +1305,16 @@ return crc; } +static void set_bit_16(int offset, u16 *data) +{ + data[offset >> 4] |= (1<<(offset & 0xf)); +} + static void set_rx_mode(struct net_device *dev) { long ioaddr = dev->base_addr; struct epic_private *ep = dev->priv; - unsigned char mc_filter[8]; /* Multicast hash filter */ + u16 mc_filter[8];/* Multicast hash filter */ int i; if (dev->flags & IFF_PROMISC) { /* Set promiscuous. */ @@ -1332,13 +1337,13 @@ memset(mc_filter, 0, sizeof(mc_filter)); for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count; i++, mclist = mclist->next) - set_bit(ether_crc_le(ETH_ALEN, mclist->dmi_addr) & 0x3f, + set_bit_16(ether_crc_le(ETH_ALEN, mclist->dmi_addr) & 0x3f, mc_filter); } /* ToDo: perhaps we need to stop the Tx and Rx process here? */ if (memcmp(mc_filter, ep->mc_filter, sizeof(mc_filter))) { for (i = 0; i < 4; i++) - outw(((u16 *)mc_filter)[i], ioaddr + MC0 + i*4); + outw(mc_filter[i], ioaddr + MC0 + i*4); memcpy(ep->mc_filter, mc_filter, sizeof(mc_filter)); } return; diff -u 2.4/drivers/net/fealnx.c build-2.4/drivers/net/fealnx.c --- 2.4/drivers/net/fealnx.cSat May 26 10:06:26 2001 +++ build-2.4/drivers/net/fealnx.c Sun Jun 3 19:49:45 2001 @@ -1642,6 +1642,10 @@ return crc; } +static void set_bit_32(int offset, u32 * data) +{ + data[offset >> 5] |= (1 << (offset & 0x1f)); +} static void set_rx_mode(struct net_device *dev) { @@ -1667,7 +1671,7 @@ memset(mc_filter, 0, sizeof(mc_filter)); for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count; i++, mclist = mclist->next) { - set_bit((ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26) ^ 0x3F, + set_bit_32((ether_crc(ETH_ALEN, mclist->dmi_addr) >> 26) ^ +0x3F, mc_filter); } rx_mode = AB | AM; diff -u 2.4/drivers/net/pci-skeleton.c build-2.4/drivers/net/pci-skeleton.c --- 2.4/drivers/net/pci-skeleton.c Fri Apr 20 20:54:23 2001 +++ build-2.4/drivers/net/pci-skeleton.cSun Jun 3 20:01:52 2001 @@ -1862,6 +1862,10 @@ return crc; } +static void set_bit_32(int offset, u32 * data) +{ + data[offset >> 5] |= (1 << (offset & 0x1f)); +} static void netdrv_set_rx_mode (struct net_device *dev) { @@ -1896,7 +1900,7 @@ mc_filter[1] = mc_filter[0] = 0; for (i = 0, mclist = dev->mc_list; mclist && i < dev->mc_count; i++, mclist = mclist->next) - set_bit (ether_crc (ETH_ALEN, mclist->dmi_addr) >> 26, + set_bit_32 (ether_crc (ETH_ALEN, mclist->dmi_addr) >> 26, mc_filter); } diff -u 2.4/drivers/net/sis900.c build-2.4/drivers/net/sis900.c --- 2.4/drivers/net/sis900.cSat Jun 2 14:19:44 2001 +++ build-2.4/drivers/net/sis900.c Sun Jun 3 19:51:38 2001 @@ -1870,6 +1870,11 @@ * Multicast hash table changes from 128 to 256 bits for 635M/B &
Linux networking and disk IO issues
I recently released a clusted storage system for Linux (the software in binary form and manual can be downloaded from www.northforknet.com). This software, you can create a highly available storage cluster out of standard PC hardware. During this work, we encountered a number of problems with the Linux kernel. I believe these all apply to the current kernels (though I'm working with the 2.4.2 kernel). If you respond, please CC me directly, since I follow Linux kernel development through weekly summaries in Linux Weekly News. regards, Mark Hayden [EMAIL PROTECTED] * The Linux networking stack requires all skbuff buffers to be contiguous. As far as I can tell, this makes it impossible to write high-bandwidth UDP applications on Linux. For instance, the kernel will drop a fragmented 8KB message if it cannot allocate 8KB of contiguous memory to reassemble it into. I have found that it is relatively easy to enter regimes where this can cause massive packet loss. * readv()/writev(). Linux serializes scatter/gather IO operations into an operation for each iovec entry. This is the relevent code from a 2.4-series kernel: /* VERIFY_WRITE actually means a read, as we write to user space */ fn = (type == VERIFY_WRITE ? file->f_op->read : (io_fn_t) file->f_op->write); ret = 0; vector = iov; while (count > 0) { void * base; size_t len; ssize_t nr; base = vector->iov_base; len = vector->iov_len; vector++; count--; nr = fn(file, base, len, &file->f_pos); if (nr < 0) { if (!ret) ret = nr; break; } ret += nr; if (nr != len) break; } This causes several problems: * For writes, it forces read-modify-write when the individual iovecs are not block-aligned. * For reads, it prevents all the read requests from being presented at the same time to the IO system. This is a problem for raw IO without read-ahead. * There is no preadv(), pwritev(). (The pread/pwrite() system calls combine a llseek with a read/write system call.) This means that if you want to have multiple threads in a process write random blocks using scatter-gather, you need to open() a device file multiple times and make the extra llseek() calls. * The requirement that everything about operations to raw character device files (length, offset in file, *and* address in memory) has to be 512-byte aligned is a real hassle. * There are several assumptions in the kernel that make it very difficult to write virtual block devices that convert IO operations into networked RPC requests. For instance, if you run the normal NBD device where the server is on the same machine in the client, you will likely deadlock your system. Our software distribution includes a patch to the 2.4.2 kernel that prevents these deadlock scenarios with NBD, but it is something of a hack (I want to thank Stephen Tweedie for his help in developing this work-around, though of course the hack is my responsibility.) I don't know what could be done to fix these problems correctly, without a major changes to block IO in the kernel. - 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/
semaphores and noatomic flag
I write this to discuss the reasons why the semop system call should have an IPC_NOATOMIC flag. Suppose we have two processes, called client and server, which communicate through a shared memory segment and two semaphores, and need to synchonize their activities so that they don't operate simultaneously except at startup. The server would do, down(smephore 0) to wait for a message from the client. When the client needs the server to execute, it would, up(semaphore 0) /* wake up server */ down(semaphore 1) /* put itself to sleep */ after the server has completed its portion of the task, it would, up(semaphore 1) /* wake up client */ down(semaphore 0) /* put iself to sleep */ The problem is that the two system calls make the whole process twice as slow as it needs to be, and they are both needed because the semop system call is implemented in an atomic manner. If the semop system call had an IPC_NOATOMIC flag, then the each process would only have to do one call, semop(up semaphore 0 & down semaphore 1, IPC_NOATOMIC) which would be interpreted in the kernel as the sequence of two system calls I have written previously. I want to know what other people think about this idea. Mihai - 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: query
Chanchal Chawla writes: > 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 ? It was possible in 2.2 with a minor hack. I did it by passing mountpoint dentry via sb->s_root to filesystem, and using d_path() to do the path lookup inside the filesystem. s_root is overwritten by the filesystem to hold the new fs root dentry, so you need to get the path and store it elsewhere before s_root is overwritten. In 2.4 I was trying to get Al Viro to tell me the best way to do this, but because it is _possible_ to mount a filesystem multiple times under 2.4 it raises a question about which mountpoint you should use. In 2.4 you need to supply an additional vfsmnt parameter to d_path(), and I never did get an answer out of Al as to how to get a vfsmnt inside the filesystem, even if there is only one mount of the filesystem. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - 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
> We can kludge around anything. The question being, what for? > It still leaves ncp with its ioctls ugliness. I show how to simplify the kernel source without changing the interface. That is good, and there are some free benefits. You want to design a new interface. Maybe that is good as well, but since it is the interface of essentially a unique program I do not regard that as very urgent. 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: 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: > USB mouse wheel has been broke since 2.4.5-ac4 (when new USB HID, > hid-core.c, was integrated). The mouse in general seems jerky, and > specifically the input device does not receive events for consecutive > wheel movements -- just the first "spin," until the mouse is moved > again. > > obviously the bug is in the new hid-core.c, but I confirmed this by > compiling with that part of the ac6 patch removed. I have since been > trying to write a patch but I can not fix the problem, so I am reporting > it to you. > > I and another user thought the problem was in hid_input_field, but upon > looking I now think not. > > My mouse is fairly unusable in X, and unfortunately I can not figure out > a fix. It is a quite stupid bug. Here is the fix (already sent to Alan). -- Vojtech Pavlik SuSE Labs diff -urN linux-2.4.5-ac4/drivers/usb/hid-core.c linux/drivers/usb/hid-core.c --- linux-2.4.5-ac4/drivers/usb/hid-core.c Tue May 29 19:48:15 2001 +++ linux/drivers/usb/hid-core.cFri Jun 1 16:30:33 2001 @@ -775,7 +775,7 @@ if ((field->flags & HID_MAIN_ITEM_RELATIVE) && !value[n]) continue; - if (value[n] == field->value[n]) + if ((~field->flags & HID_MAIN_ITEM_RELATIVE) && value[n] == +field->value[n]) continue; hid_process_event(hid, field, &field->usage[n], value[n]); continue;
2.4.5-ac5 BUG in slab.c
I was playing with (a romfs) initrd and modularising everything, including ext2 and ide-*. (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)) More info on request. ksymoops 2.4.0 on i686 2.4.5-ac5-4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac5-4/ (default) -m /boot/System.map-2.4.5-ac5-4 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Error (expand_objects): cannot stat(/lib/ext2.o) for ext2 ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/eepro100.o) for eepro100 ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/ide-disk.o) for ide-disk ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/ide-probe-mod.o) for ide-probe-mod ksymoops: No such file or directory Error (expand_objects): cannot stat(/lib/ide-mod.o) for ide-mod ksymoops: No such file or directory kernel BUG at slab.c:1200! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00210082 eax: 001b ebx: c824e000 ecx: 0001 edx: 6518 esi: edi: c144713c ebp: cd14fa4c esp: c6fd7ee8 ds: 0018 es: 0018 ss: 0018 Process netscape-commun (pid: 3901, stackpage=c6fd7000) Stack: c01bfacb 04b0 c824e019 cd14fa4c c824f019 c824e019 c01286a5 c144713c cd14fa4c c824e019 0001 00200246 ce680934 ffeb c6fd7f84 cb5c0de4 c013bafe c144713c c824e019 c6fd7f84 ce680934 0001 0002 fffb Call Trace: [] [] [] [] [] [] Code: 0f 0b 5a 59 8b 5d 14 83 fb ff 74 2b 8d 74 26 00 8d bc 27 00 Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/net/ipv4/netfilter/netfilter.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/net/ipv6/netfilter/netfilter.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/md/mddev.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/net/wireless/orinoco_drvs.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/char/drm/drm.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/misc/misc.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/cdrom/driver.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/media/radio/radio.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/media/video/video.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/media/media.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/sound/sounddrivers.o Warning (read_object): no symbols in /lib/modules/2.4.5-ac5-4/build/drivers/parport/driver.o Warning (map_ksym_to_module): cannot match loaded module ext2 to a unique module object. Trace may not be reliable. Warning (map_ksym_to_module): cannot match loaded module eepro100 to a unique module object. Trace may not be reliable. Warning (map_ksym_to_module): cannot match loaded module ide-disk to a unique module object. Trace may not be reliable. Warning (map_ksym_to_module): cannot match loaded module ide-probe-mod to a unique module object. Trace may not be reliable. Warning (map_ksym_to_module): cannot match loaded module ide-mod to a unique module object. Trace may not be reliable. Reading Oops report from the terminal kernel BUG at slab.c:1200! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00210082 eax: 001b ebx: c824e000 ecx: 0001 edx: 6518 esi: edi: c144713c ebp: cd14fa4c esp: c6fd7ee8 ds: 0018 es: 0018 ss: 0018 Process netscape-commun (pid: 3901, stackpage=c6fd7000) Stack: c01bfacb 04b0 c824e019 cd14fa4c c824f019 c824e019 c01286a5 c144713c cd14fa4c c824e019 0001 00200246 ce680934 ffeb c6fd7f84 cb5c0de4 c013bafe c144713c c824e019 c6fd7f84 ce680934 0001 0002 fffb Call Trace: [] [] [] [] [] [] Code: 0f 0b 5a 59 8b 5d 14 83 fb ff 74 2b 8d 74 26 00 8d bc 27 00 >>EIP; c01280d9<= Trace; c01286a5 Trace; c013bafe Trace; c013e3d8 Trace; c0130254 Trace; c0130543 Trace; c0106e5b Code; c01280d9 <_EIP>: Code; c01280d9<= 0: 0f 0b ud2a <= Code; c01280db 2: 5apop%edx Code; c01280dc 3: 59pop%ecx Code; c01280dd 4: 8b 5d 14 mov0x14(%ebp),%ebx Code; c01280e0 7: 83 fb ff cmp$0x,%ebx Code; c01280e3 a: 74 2b
Is Via 8633/8233 supported?
Hello, Recently (on May 16, locked 3c905B with 2.4.5pre2) I asked about a problem with APIC. I see that some recent changes fix problems with Via 82C686* chipsets. What about Via 8633/8233 chipset. Is it really supported, someone successfully running SMP box? Is "... Using IRQ router default..." ok for this chipset? Regards -- Julian Anastasov <[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: VIA's Southbridge bug: Latest (pseudo-)patch
Marc Lehmann wrote: > Aren't PCI delayed transaction supposed to be handled by the pci master > (e.g. my northbridge), not by the (software) driver for my pdc(?) I would > also be surprised if my pdc actually used that feature, not to speak of > the fact that the promise + harddisk worked fine in another computer (the > data corruption was easily detectable, one couldn't even write 500megs > without altered bytes). Wrong way round. You're right that the pci master is supposed to handle delayed transactions, but during data transfer the pdc is the pci master and the northbridge is the PCI target. -- Adrian Cox http://www.humboldt.co.uk/ - 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.2 TTY race condition (do_tty_hangup and tty_release)
I am running linux 2.2.14 with a 96-modem board and have been getting kernel oops'es. These generally only occur when I am running the system under constant swapping conditions. After much diagnosis, I have found the following sequence of events causes the oops: - do_tty_hangup called for the TTY - ldisc.open() called for the TTY - ldisc.open blocks (probably waiting for memory) - tty_release called for the same TTY - release_dev() called - release_dev() completes - tty_release completes I know that ldisc.open is blocking because I never see the message that indicates it has completed. Then the oops occurs: >>EIP; 205d3335 Before first symbol <= Trace; c01a6e20 Trace; c01a8632 Trace; c01a4826 Trace; c02161a0 Trace; c01131fe Trace; c01fcf2a Trace; c011327e Trace; c01fcf40 Trace; c0106000 Trace; c0108853 Note that the tq_scheduler list is being run out of a kernel thread here instead of being executed directly by schedule(); this was necessary to eliminate a kernel panic. Given this, how should this race condition be avoided? It seems that the TTY structure has a life outside its use in the file structure since hangups can occur on the TTY at any time. Would it make sense to break the strong association between the TTY structures and the file handling? Then, the file interface could be a client of the TTY service, as would the driver when it wants to propagate asynchronous events. As such, each would then do its own "get" and "put" operations on the TTY structures. Also, is there a short-term solution that would prevent the problem? -art P.S. Please CC: me on replies. - 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: SCSI-CD-Writer don't show up
On Sun, Jun 03, 2001 at 06:38:27PM +0200, Gérard Roudier wrote: > > On Sat, 2 Jun 2001, Matthias Schniedermeyer wrote: > > > 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. :-) > > You should check if your devices are enabled for SCAN in the NVRAM. I had disabled all IDs from scanning (except those which had a drive) when i first installed the system. Now i enabled all IDs for scanning. :-) 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/
the value of PROC_CHANGE_PENALTY
as I understand, for i386 in Linux-2.2.x the default length of a quantum was 200ms, and in 2.4.x it had changed to 50ms ( according to the following 2.4.5 sched.c code: #if HZ < 200 #define TICK_SCALE(x) ((x) >> 2) ... #define NICE_TO_TICKS(nice) (TICK_SCALE(20-(nice))+1) ... /* in the `recalculate' portion of schedule(): ... */ for_each_task(p) p->counter = (p->counter >> 1) + NICE_TO_TICKS(p->nice); ) But, the value of PROC_CHANGE_PENALTY was not changed accordingly, and is still 15. This means that the result of the following goodness() code: if (p->processor == this_cpu) weight += PROC_CHANGE_PENALTY; is that any task that executed on `this_cpu' (goodness > 15) will always be more "desirable" then a task that executed on another cpu (goodness <= 6) which was not the case in 2.2.x . am I correct ? and if so, is this what the authors meant, or did they simply forget to update PROC_CHANGE_PENALTY's value when moving from 2.2 to 2.4 ? please cc me: [EMAIL PROTECTED] thanks, dan. - 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/
Dual AMD Palomino from Australia
Hello Alan, do you have an dual AMD 760MP based mobo, too? It should be more interesting to see some multi processing workloads. Here are the links: http://www.overclockers.com.au/techstuff/a_tyan_thunder/ http://www.overclockers.com.au/techstuff/a_tyan_thunder/page2.shtml http://www.overclockers.com.au/techstuff/a_tyan_thunder/boot.txt Thanks, Dieter - 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] balance inactive_dirty list
> while observing lots of different workloads (all I/O bound). Finally, well, not all loads are IO-bound in the sense you're looking at. in particular, the test I usually run (make -j2 with mem=48m) is actually hurt by this patch. but you're right, this change does improve streaming IO. > We're trying to be too clever there, and that eventually hurts > performance because inactive_dirty list is too small for typical I certainly agree the code is dubious, but this is the reason inactive_target exists, afaikt. > have tested. The patch simplifies code a lot and removes unnecessary > complex calculation. Code is now completely autotuning. I have a otoh, the "complex calculation" was always trivial, and *more* autotuning than your suggested fix... > - 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; - 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/