Re: gettimeofday question
On Sat, Mar 03, 2001 at 12:49:04PM +, Russell King wrote: > Hi, > > I've noticed that one of my machines here suffers from the "time going > backwards problem" and so started thinking about the x86 solution. > > I've come to the conclusion that it has a hole which could cause it > to return the wrong time in one specific case: > > - in do_gettimeofday(), we disable irqs (read_lock_irqsave) > - the ISA timer wraps, but we've got interrupts disabled, so no update > of xtime or jiffies occurs > - in do_slow_gettimeoffset(), we read the timer, which has wrapped > - since jiffies_p != jiffies, we do not apply any correction > - our idea of time is now one jiffy slow. I never heard any response to this. Could some knowledgeable person please take a look at it? Thanks. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: rsync over ssh on 2.4.2 to 2.2.18
On Wed, Feb 28, 2001 at 11:20:22PM +0300, [EMAIL PROTECTED] wrote: > I remember this your report. However, recent news force to suspect > that the reason was in Solaris yet. Actually, if you send tcpdump of > failed session, this question can be answered. Well, since I moved the rsync to 5pm, and then back to 9pm, I haven't seen this problem - everything is again working as expected (touch wood) with 2.2.15pre13 and 2.4.0. This is odd, since it wasn't a one-off problem, but something that happened each and every day of a particular week. Anyway, if it starts happening again, I'll get a tcpdump of the session. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[CHECKER] 10 additional >= 1K stack variables
Hi, after some config problems were fixed, there were 10 additional stack variables found that were >= 1K in size. (Though the two tty_io* ones are already known.) Dawson /u2/engler/mc/oses/linux/2.4.1/drivers/char/tty_io.c:2030:tty_unregister_devfs: ERROR:VAR:2030:2030: suspicious var 'tty' = 3112 bytes /u2/engler/mc/oses/linux/2.4.1/drivers/char/tty_io.c:1995:tty_register_devfs: ERROR:VAR:1995:1995: suspicious var 'tty' = 3112 bytes /u2/engler/mc/oses/linux/2.4.1/drivers/i2o/i2o_proc.c:2492:i2o_proc_read_lan_alt_addr: ERROR:VAR:2492:2492: suspicious var 'result' = 2060 bytes /u2/engler/mc/oses/linux/2.4.1/net/irda/af_irda.c:1743:irda_setsockopt: ERROR:VAR:1743:1743: suspicious var 'ias_opt' = 1356 bytes /u2/engler/mc/oses/linux/2.4.1/net/irda/af_irda.c:1981:irda_getsockopt: ERROR:VAR:1981:1981: suspicious var 'ias_opt' = 1356 bytes /u2/engler/mc/oses/linux/2.4.1/drivers/block/../../lib/inflate.c:750:inflate_dynamic: ERROR:VAR:750:750: suspicious var 'll' = 1264 bytes /u2/engler/mc/oses/linux/2.4.1/drivers/block/../../lib/inflate.c:301:huft_build: ERROR:VAR:301:301: suspicious var 'v' = 1152 bytes /u2/engler/mc/oses/linux/2.4.1/drivers/block/../../lib/inflate.c:688:inflate_fixed: ERROR:VAR:688:688: suspicious var 'l' = 1152 bytes /u2/engler/mc/oses/linux/2.4.1/fs/devfs/base.c:3156:devfsd_read: ERROR:VAR:3156:3156: suspicious var 'info' = 1056 bytes /u2/engler/mc/oses/linux/2.4.1/drivers/net/wan/cycx_x25.c:983:hex_dump: ERROR:VAR:983:983: suspicious var 'hex' = 1024 bytes - 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.2: kernel patch for , nanosleep
Hello,
originally intended for my PPSkit patch I found out that the "normal"
kernel might like this patch as well:
nanosleep() currently uses "udelay()" from as there is no
"ndelay()". I implemented "ndelay()" for i386 and adjusted the other
macros. During that I found that some files have or use their own
"delay()" routines. The original delay is dangerous, because depending
on the CPU it requires loop cycles or clock cycles as argument, giving
non-reliable code. Affected sources:
drivers/net/hamradio/yam.c: "delay(100)"
drivers/scsi/wd
I also found that the scaling factor used in the existing code should
be rounded up (increased by one) for a more exact value.
With the new code there are two possible disadvantages: 1) Reduced
accuracy, and 2) possible overflow. I hope both are not really a
problem.
Regards,
Ulrich
Index: arch/i386/kernel/i386_ksyms.c
===
RCS file: /root/LinuxCVS/Kernel/arch/i386/kernel/i386_ksyms.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 i386_ksyms.c
--- arch/i386/kernel/i386_ksyms.c 2001/03/11 13:51:19 1.1.1.3
+++ arch/i386/kernel/i386_ksyms.c 2001/03/17 18:08:20
@@ -82,9 +82,9 @@
/* Networking helper routines. */
EXPORT_SYMBOL(csum_partial_copy_generic);
/* Delay loops */
-EXPORT_SYMBOL(__udelay);
+EXPORT_SYMBOL(__ndelay);
EXPORT_SYMBOL(__delay);
-EXPORT_SYMBOL(__const_udelay);
+EXPORT_SYMBOL(__const_sndelay);
EXPORT_SYMBOL_NOVERS(__get_user_1);
EXPORT_SYMBOL_NOVERS(__get_user_2);
Index: arch/i386/lib/delay.c
===
RCS file: /root/LinuxCVS/Kernel/arch/i386/lib/delay.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 delay.c
--- arch/i386/lib/delay.c 2001/01/08 20:17:36 1.1.1.2
+++ arch/i386/lib/delay.c 2001/03/17 18:12:36
@@ -64,16 +64,27 @@
__loop_delay(loops);
}
-inline void __const_udelay(unsigned long xloops)
+/* convert scaled nanoseconds to execution loops and delay */
+inline void __const_sndelay(unsigned long scaled_nsecs)
{
int d0;
__asm__("mull %0"
- :"=d" (xloops), "=" (d0)
- :"1" (xloops),"0" (current_cpu_data.loops_per_jiffy));
-__delay(xloops * HZ);
+ :"=d" (scaled_nsecs), "=" (d0)
+ :"1" (scaled_nsecs),"0" (current_cpu_data.loops_per_jiffy));
+__delay(scaled_nsecs * HZ);
}
-void __udelay(unsigned long usecs)
+void __ndelay(unsigned long nsecs)
{
- __const_udelay(usecs * 0x10c6); /* 2**32 / 100 */
+ /* 2**32 / 10 == 4.2946... */
+ if (nsecs > NDELAY_LIMIT) {
+ static int complaints = 7;
+
+ if (complaints > 0) {
+ --complaints;
+ printk(KERN_ERR "__ndelay(%lu) exceeds limit\n", nsecs);
+ }
+ nsecs = NDELAY_LIMIT;
+ }
+ __const_sndelay((nsecs * 429) / 100);
}
Index: include/asm-i386/delay.h
===
RCS file: /root/LinuxCVS/Kernel/include/asm-i386/delay.h,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 delay.h
--- include/asm-i386/delay.h2001/01/08 20:22:29 1.1.1.2
+++ include/asm-i386/delay.h2001/03/17 17:58:33
@@ -7,14 +7,19 @@
* Delay routines calling functions in arch/i386/lib/delay.c
*/
-extern void __bad_udelay(void);
+extern void __bad_ndelay(void);
-extern void __udelay(unsigned long usecs);
-extern void __const_udelay(unsigned long usecs);
-extern void __delay(unsigned long loops);
+extern void __ndelay(unsigned long nsecs);
+extern void __const_sndelay(unsigned long scaled_nsecs);
+extern void __delay(unsigned long xloops);
-#define udelay(n) (__builtin_constant_p(n) ? \
- ((n) > 2 ? __bad_udelay() : __const_udelay((n) * 0x10c6ul)) : \
- __udelay(n))
+#defineNDELAY_LIMIT2000/* 20 ms (2 / HZ)? */
+
+#define ndelay(n) (__builtin_constant_p(n) ? \
+ ((n) > NDELAY_LIMIT ? \
+ __bad_ndelay() : __const_sndelay(((n) * 429ul) / 100)) : \
+ __ndelay(n))
+
+#define udelay(n) ndelay(n * 1000)
#endif /* defined(_I386_DELAY_H) */
Index: kernel/timer.c
===
RCS file: /root/LinuxCVS/Kernel/kernel/timer.c,v
retrieving revision 1.1.1.2.8.1
diff -u -r1.1.1.2.8.1 timer.c
--- kernel/timer.c 2001/03/11 15:29:17 1.1.1.2.8.1
+++ kernel/timer.c 2001/03/17 17:22:57
@@ -592,10 +592,11 @@
/*
* Short delay requests up to 2 ms will be handled with
* high precision by a busy wait for all real-time processes.
+* Anything else will be delayed for at least 1/HZ.
*
* Its important on SMP not to do this holding locks.
*/
- udelay((t.tv_nsec + 999) / 1000);
+ ndelay(t.tv_nsec);
Re: sysrq.txt
Hi! > I've found that the Sysrq Keys on Apple Computers > are 'Keypad+-F13-', maybe it would > be a good idea to include that in Documentation/sysrq.txt. > > The Patch: This patch is reversed, but otherwise looks okay. Generate non-reversed one and mail it to linus, possibly saying I agree. Pavel > +++ sysrq.txt Tue Dec 12 20:46:38 2000 > @@ -29,8 +29,6 @@ > You send a BREAK, then within 5 seconds a command key. Sending > BREAK twice is interpreted as a normal BREAK. > > -On Mac - Press 'Keypad+-F13-' > - > On other - If you know of the key combos for other architectures, please > let me know so I can add them to this section. > > > regards, > jmk > - > 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'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improved version reporting
Riley Williams writes: >> The rule should be like this: >> >> List the lowest version number required to get >> 2.2.xx-level features while running a 2.4.xx kernel. > > That's a meaningless definition, and can only be taken as such. What > use would such a list be to somebody wishing (like I recently was) to > upgrade a system running the 2.0.12 kernel so it runs the 2.4.2 > kernel instead? ... >> Basically I ask: would existing scripts for a 2.2.xx kernel >> break? If the old mount can still do what it used to do, then >> "mount" need not be listed at all. > > Replace that "a 2.2.xx" with "my current" and remove all restrictions > on what the current kernel is, and that becomes an important question. No, not "my current" but "the previous stable". I say "2.2.xx" because that is the previous stable kernel. If you upgrade from 2.0.xx, you should read the 2.2.xx changes file. The important thing is to avoid version number inflation. I don't even bother reading the changes file, because I know it is bogus. Nearly all of my old software works great with a 2.4.xx 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/
Jiffy question and sound.
With the 2.4.0 kernel the loops_per_sec field was replaced (for i386) with current_cpu_data.loops_per_jiffy. So... since I am using the ALSA drivers that Mandrake supplied, for the 2.4.x series of kernels I replaced the equated #define with #define LOOPS_PER_SEC current_cpu_data.loops_per_jiffy * 100 This seems to build modules that work for 2.4.0. However, if you play many songs then do some heavy disk I/0 after awhile the songs start sounding like a hellicoptor is hovering right next to the speakers. This wasn't too bad as it usually took about 30 to 40 mins to go south. Now compiling the same ALSA modules with 2.4.2 this problem happens much quicker and you don't need any other activity. In fact it is hard to play more than half a song. (MP3) It doesn't matter if what set of music players or tools I use the problem is quite visible. When I boot back to the original 2.2.x kernel everything is perfect. So I guess I have a few questions here. 1) Is a jiffy 100th of a second or is it smaller (so my loop count is starving things.) (10ms) ? 2) Why is it so much worse in 2.4.2 than 2.4.0? 3) Any other "gotch's" that are important to watch for when moving 2.2.x drivers to 2.4.x? Thanks Watermodem - 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: [sligthly OT] serial console on palm
Andreas Dilger wrote: > > John Lenton writes: > > I remember seing a project to get a palm pilot working as a > > serial console, but now google seems unable to find it. Does > > anyone know of such a project? > > I got one recently called "serialrecord" for the Palm, but it is one-way > only (useful for capturing OOPSes or so. If someone had a two-way console > for the Palm, it would be great. Sorry, no URL, but you _should_ be able > to find it in l-k archives. > > 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/ This one has proved handy in the past. I've used it to log into routers and the like, it's pretty cool. The actual website (not palmgear) is incredibly slow tho. http://www.palmgear.com/software/showsoftware.cfm?prodID=552 Nathan - 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: [sligthly OT] serial console on palm
I use my Palm VX as a serial console on Linux, OpenBSD, FreeBSD, and Solaris. Just get a serial cable for your unit and some console program such as pTelnet. The rest is quite simple. If you find something different than pTelnet for console, please let me know as I find it crashes too much. pete On Sun, 18 Mar 2001, Andreas Dilger wrote: > John Lenton writes: > > I remember seing a project to get a palm pilot working as a > > serial console, but now google seems unable to find it. Does > > anyone know of such a project? > > I got one recently called "serialrecord" for the Palm, but it is one-way > only (useful for capturing OOPSes or so. If someone had a two-way console > for the Palm, it would be great. Sorry, no URL, but you _should_ be able > to find it in l-k archives. PGP signature
Re: [sligthly OT] serial console on palm
there is a vt100 terminal emulater available for the palm (I had it, but haven't used it in a while, I may have lost it due to not backing things up properly) David Lang On Sun, 18 Mar 2001, Andreas Dilger wrote: > Date: Sun, 18 Mar 2001 22:10:20 -0700 (MST) > From: Andreas Dilger <[EMAIL PROTECTED]> > To: John R Lenton <[EMAIL PROTECTED]> > Cc: Linux Kernel Mailing List <[EMAIL PROTECTED]> > Subject: Re: [sligthly OT] serial console on palm > > John Lenton writes: > > I remember seing a project to get a palm pilot working as a > > serial console, but now google seems unable to find it. Does > > anyone know of such a project? > > I got one recently called "serialrecord" for the Palm, but it is one-way > only (useful for capturing OOPSes or so. If someone had a two-way console > for the Palm, it would be great. Sorry, no URL, but you _should_ be able > to find it in l-k archives. > > 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/ > - 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: [sligthly OT] serial console on palm
John Lenton writes: > I remember seing a project to get a palm pilot working as a > serial console, but now google seems unable to find it. Does > anyone know of such a project? I got one recently called "serialrecord" for the Palm, but it is one-way only (useful for capturing OOPSes or so. If someone had a two-way console for the Palm, it would be great. Sorry, no URL, but you _should_ be able to find it in l-k archives. 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/
[sligthly OT] serial console on palm
I remember seing a project to get a palm pilot working as a serial console, but now google seems unable to find it. Does anyone know of such a project? -- John Lenton ([EMAIL PROTECTED]) -- Random fortune: BOFH excuse #280: Traceroute says that there is a routing problem in the backbone. It's not our problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] off-by-1 error in ide-probe (2.4.x)
On Sun, 18 Mar 2001, Linus Torvalds wrote: > > > On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote: > > > > Agreed. That would be a trivially easy bug in the firmware, limiting to > > 255 sectors seems safer. > > > > Linus > > > > Yes, possibly. > > I checked old standards, and see that "0 means 256 as a sector count" > > is already in ATA-1. > > Yes. But we could have some silly bug in the Linux drivers too, if some > part of the driver reads back the sector count and doesn't do the 0==256 > conversion. So let's not blame the disk quite yet. Although it would be > interesting to hear if the problem only happens for a specific disk or > manufacturer... LT, This is why I want to standardize the data-phase rules, but we have agreed to postpone for 2.5. Since the glue for the main loops is spread like hot butter, it covers up a lot of issues and threads get messy. I had all but given up on chasing them down and then resolved to start from scratch. Andre Hedrick Linux ATA 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: [CHECKER] blocking w/ spinlock or interrupt's disabled
In article <001801c0af8e$bda30c10$5517fea9@local>, Manfred Spraul <[EMAIL PROTECTED]> wrote: > >Unortunately schedule() with disabled interrupts is a feature, it's >needed for the old (deprecated and waiting for termination in 2.5) >sleep_on() functions. Yes. But that should only cover "sleep_on()" and it's interruptible cousing "sleep_on_interruptible()". No other blocking call should have interrupts disabled, I would hope. The special-case is a fairly specific "some old-style drivers avoid race conditions by having interrupts disabled over explicit conditional sleeps", not a generic "you may have interrupts disabled before blocking". 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/
2.4.3-pre4: Unable to handle kernel NULL pointer dereference at virtual address 000000fb
I have included the ksymoops debug and dmesg (both small).. Any ideas? Shawn. ksymoops 2.3.7 on i586 2.4.3-pre4. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.3-pre4/ (default) -m /boot/System.map (specified) Intel Pentium with F0 0F bug - workaround enabled. Unable to handle kernel NULL pointer dereference at virtual address 00fb c2016531 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010082 eax: ebx: c0709dc8 ecx: c10e3a60 edx: c1258800 esi: edi: 0082 ebp: c1258878 esp: c0709f54 ds: 0018 es: 0018 ss: 0018 Process scsi_eh_0 (pid: 297, stackpage=c0709000) Stack: 0282 c1258800 c1274a00 c20165cf c1258800 c1258878 0282 c1274a00 c019dddf c1274a00 2003 c019e427 c1274a00 c0708000 c0709fdc c0709fdc c1258800 c0709fe8 c0709fe8 c10e3a60 c019e8fb Call Trace: [] [] [] [] [] Code: f6 80 fb 00 00 00 10 75 70 8b 4d 00 31 d2 eb 0a 89 ca 8b 82 >>EIP; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <= Trace; c20165cf <[aha152x]aha152x_bus_reset+13/a0> Trace; c019dddf Trace; c019e427 Trace; c019e8fb Trace; c010742c Code; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <_EIP>: Code; c2016531 <[aha152x]free_hard_reset_SCs+21/ac> <= 0: f6 80 fb 00 00 00 10 testb $0x10,0xfb(%eax) <= Code; c2016538 <[aha152x]free_hard_reset_SCs+28/ac> 7: 75 70 jne79 <_EIP+0x79> c20165aa <[aha152x]free_hard_reset_SCs+9a/ac> Code; c201653a <[aha152x]free_hard_reset_SCs+2a/ac> 9: 8b 4d 00 mov0x0(%ebp),%ecx Code; c201653d <[aha152x]free_hard_reset_SCs+2d/ac> c: 31 d2 xor%edx,%edx Code; c201653f <[aha152x]free_hard_reset_SCs+2f/ac> e: eb 0a jmp1a <_EIP+0x1a> c201654b <[aha152x]free_hard_reset_SCs+3b/ac> Code; c2016541 <[aha152x]free_hard_reset_SCs+31/ac> 10: 89 ca mov%ecx,%edx Code; c2016543 <[aha152x]free_hard_reset_SCs+33/ac> 12: 8b 82 00 00 00 00 mov0x0(%edx),%eax Linux version 2.4.3-pre4 (root@stucko) (gcc version 2.95.3 20010219 (prerelease)) #1 Sun Mar 18 01:29:02 EST 2001 BIOS-provided physical RAM map: BIOS-88: 0009f000 @ (usable) BIOS-88: 0170 @ 0010 (usable) On node 0 totalpages: 6144 zone(0): 4096 pages. zone(1): 2048 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=Linux ro root=302 Initializing CPU#0 Detected 83.524 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 166.29 BogoMIPS Memory: 22124k/24576k available (996k kernel code, 2064k reserved, 382k data, 60k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) CPU: Before vendor init, caps: 013f , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 013f CPU: After generic, caps: 013f CPU: Common caps: 013f CPU: Intel OverDrive PODP5V83 stepping 02 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX isapnp: Scanning for Pnp cards... isapnp: Card 'Adaptec AVA-1505AI' isapnp: Card '3Com 3C509B EtherLink III' isapnp: 2 Plug & Play cards detected total Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 parport0: PC-style at 0x378 [PCSPP(,...)] pty: 256 Unix98 ptys configured block: queued sectors max/low 14605kB/4868kB, 64 slots per queue Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx keyboard: Timeout - AT keyboard not present? keyboard: Timeout - AT keyboard not present? hda: ST3491A D, ATA DISK drive hdb: QUANTUM PD210A, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: 836070 sectors (428 MB) w/120KiB Cache, CHS=899/15/62 hdb: 408564 sectors (209 MB) w/32KiB Cache, CHS=873/13/36 Partition check: hda: hda1 hda2 hdb: hdb1 hdb2 paride: epat registered as protocol 0 pd: pd version 1.05, major 45, cluster 64, nice 0 pda: Sharing parport0 at 0x378 pda: epat 1.01, Shuttle EPAT chip c6 at 0x378, mode 1 (5/3), delay 1 pda: AVATAR AR2250, master, 489472 blocks [239M], (956/16/32), removable media pda: pda1 Floppy drive(s): fd0 is 1.44M FDC 0 is an 8272A eth0: 3c509 at 0x220, 10baseT port, address 00 a0 24 46 41 c0, IRQ 5. 3c509.c:1.16 (2.2) 2/3/98 [EMAIL PROTECTED] loop: loaded (max 8 devices) Serial driver version 5.05 (2000-12-13) with ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16450 ttyS01 at 0x02f8 (irq = 3) is a 16450 SCSI subsystem
Re: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Linus Torvalds wrote: > On Sun, 18 Mar 2001, Rik van Riel wrote: > > > > Indeed, having threaded apps do multiple page faults at the > > same time is the main goal of this patch. However, I don't > > see how it would be good for scalability to have multiple > > threads fault in the same page at the same time, when they > > could just wait for one of them to do the work. > > But they will. > > That's what lock_page() etc are there for - there's no need for the VM > to synchronize because we already have the synchronization primitives > at a lower level. Indeed. I'll go multithread the do_no_page and do_swap_page functions tomorrow (maybe even tonight ;)). regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: /proc/cpuinfo for Intel P4 D850GB
On Sun, 18 Mar 2001 [EMAIL PROTECTED] wrote: > On a 2.0.36 kernel the above-referenced mb > shows: > ... > Is the problem is due to the older 2.0.36 kernel, Yes. > or would the problem also present itself on a newer 2.2.x kernel? Current 2.2 and 2.4 are both fixed for this problem. This and a few other CPU related fixes should probably be backported to 2.0 if someone has the spare time. regards, Dave. -- | Dave Jones.http://www.suse.de/~davej | SuSE Labs - 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/
/proc/cpuinfo for Intel P4 D850GB
On a 2.0.36 kernel the above-referenced mb shows: dragonwind:/proc# cat cpuinfo processor : 0 cpu : ?86 model : 386 SX/DX vendor_id : GenuineIntel At the least, java breaks because of the '?' char. Is the problem is due to the older 2.0.36 kernel, or would the problem also present itself on a newer 2.2.x kernel? Annette - 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] blocking w/ spinlock or interrupt's disabled
> Is it difficult to split it into "interrupts disabled" and "spin lock > held"? Nope, since it's already done ;-) The suffix of each error message should say whether it's because you have a spinlock, ints disabled, or both: 2.4.1/drivers/atm/idt77105.c:153:fetch_stats: ERROR:BLOCK:151:153: calling blocking fn '__constant_copy_to_user' w/ int's disabled 2.4.1/drivers/atm/iphase.c:2426:ia_led_timer: ERROR:BLOCK:2423:2426: calling blocking fn 'ia_tx_poll' w/ spin lock held Dawson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] kernel BUG at printk.c:458! -- 2.4.2-ac20
Em Mon, Mar 19, 2001 at 02:14:35AM +0100, BERECZ Szabolcs escreveu: > Hi! > > I was copying some files from ext2fs to reiserfs, and then this bug > occured: > > kernel BUG at printk.c:458! same thing here, two or three times, I was too lazy to write down the oops and decode it, will try next time, and I also have reiserfs here in one partition, 2.4.2-ac18, gcc 2.95.3 as well, further details available upon request. - Arnaldo - 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] 28 potential interrupt errors
> Request: can the checker check for skb's being freed correctly? The > rules: > > If an skb is in interrupt context, call dev_kfree_skb_irq. > If an skb might be in interrupt context, call dev_kfree_skb_any. > If an skb is not in interrupt context, call dev_kfree_skb. It shouldn't be hard to check this. The only thing interesting will be deriving when you're in an interrupt context. Thanks for the pointer. Are there other context-sensitive rules that we could go after as well? > I dunno WTF the programmer was thinking here... Your de-ref checker > should have caught this too: check 'lp' for NULL after de-referencing > lp->lock. These reports are for an older version of the checker --- we've fixed some bugs in the system, which should catch more of these errors. Dawson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] kernel BUG at printk.c:458! -- 2.4.2-ac20
BERECZ Szabolcs wrote:
>
> kernel BUG at printk.c:458!
>
--- drivers/char/console.c.orig Mon Mar 19 12:38:27 2001
+++ drivers/char/console.c Mon Mar 19 12:38:49 2001
@@ -2305,6 +2305,9 @@
{
struct vt_struct *vt = (struct vt_struct *)tty->driver_data;
+ if (in_interrupt())
+ return;
+
pm_access(pm_con);
acquire_console_sem();
set_cursor(vt->vc_num);
-
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.2-ac18 and lvm_0.9
I met following errors errors when compiling lvm_0.9(lvm-0.9 in latest Rawhide) with gcc-2.95.3-test5 under kernel-2.4.2-ac18 and glibc-2.2.2. make[1]: Entering directory `/usr/src/redhat/BUILD/LVM/0.9/tools' make[2]: Entering directory `/usr/src/redhat/BUILD/LVM/0.9/tools/lib' make[3]: Entering directory `/usr/src/redhat/BUILD/LVM/0.9/tools/lib' gcc -c -pipe -D_GNU_SOURCE -O2 -march=i686 -mcpu=i686 -pipe -Wall \ -I../../tools/lib -I../../tools -o basename.o basename.c In file included from /usr/include/linux/prefetch.h:13, from /usr/include/linux/list.h:6, from ../../tools/lib/lvm.h:98, from ../../tools/lib/liblvm.h:90, from basename.c:34: /usr/include/asm/processor.h:47: parse error before `u16' /usr/include/asm/processor.h:47: warning: no semicolon at end of struct \ or union /usr/include/asm/processor.h:56: parse error before `}' make[3]: *** [basename.o] Error 1 make[3]: Leaving directory `/usr/src/redhat/BUILD/LVM/0.9/tools/lib' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/src/redhat/BUILD/LVM/0.9/tools/lib' make[2]: Entering directory `/usr/src/redhat/BUILD/LVM/0.9/tools/man8' make[3]: Entering directory `/usr/src/redhat/BUILD/LVM/0.9/tools/man8' make[3]: Leaving directory `/usr/src/redhat/BUILD/LVM/0.9/tools/man8' make[2]: Leaving directory `/usr/src/redhat/BUILD/LVM/0.9/tools/man8' make[2]: Entering directory `/usr/src/redhat/BUILD/LVM/0.9/tools' gcc -c -pipe -D_GNU_SOURCE -O2 -march=i686 -mcpu=i686 -pipe -Wall \ -I../tools/lib -I../tools -o e2fsadm.o e2fsadm.c In file included from /usr/include/linux/prefetch.h:13, from /usr/include/linux/list.h:6, from ../tools/lib/lvm.h:98, from ../tools/lib/liblvm.h:90, from ../tools/lvm_user.h:44, from e2fsadm.c:45: /usr/include/asm/processor.h:47: parse error before `u16' /usr/include/asm/processor.h:47: warning: no semicolon at end of \ struct or union /usr/include/asm/processor.h:56: parse error before `}' make[2]: *** [e2fsadm.o] Error 1 This is true to 2.4.2-20, too. After applying folling patch to kernel source, the compile process of lvm-0.9 went through flawlessly. I guess it is a typo introduced into 2.4.2-ac18 or so. --- linux/include/asm/processor.h.orig Tue Mar 13 03:55:41 2001 +++ linux/include/asm/processor.h Tue Mar 13 03:52:16 2001 @@ -44,7 +44,7 @@ charx86_model_id[64]; int x86_cache_size; /* in KB - valid for CPUS which support this call */ - u16 clockmul;/* Clock multiplier */ + __u16 clockmul;/* Clock multiplier */ int fdiv_bug; int f00f_bug; int coma_bug; -- "Where there is a will, there is a way." [EMAIL PROTECTED] For the future of you and me!hitel: jinbo21 - 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] off-by-1 error in ide-probe (2.4.x)
On Mon, 19 Mar 2001 [EMAIL PROTECTED] wrote: > > Agreed. That would be a trivially easy bug in the firmware, limiting to > 255 sectors seems safer. > > Linus > > Yes, possibly. > I checked old standards, and see that "0 means 256 as a sector count" > is already in ATA-1. Yes. But we could have some silly bug in the Linux drivers too, if some part of the driver reads back the sector count and doesn't do the 0==256 conversion. So let's not blame the disk quite yet. Although it would be interesting to hear if the problem only happens for a specific disk or manufacturer... 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: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Rik van Riel wrote: > > Indeed, having threaded apps do multiple page faults at the > same time is the main goal of this patch. However, I don't > see how it would be good for scalability to have multiple > threads fault in the same page at the same time, when they > could just wait for one of them to do the work. But they will. That's what lock_page() etc are there for - there's no need for the VM to synchronize because we already have the synchronization primitives at a lower level. And there isn't any other lock that could work anyway. It's either the whole MM or a page. There's nothing in between. 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/
[BUG] kernel BUG at printk.c:458! -- 2.4.2-ac20
Hi! I was copying some files from ext2fs to reiserfs, and then this bug occured: kernel BUG at printk.c:458! invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 001c ebx: c11f290c ecx: c01eea20 edx: 0296 esi: c0e22000 edi: c0e2216b ebp: esp: c057fe78 ds: 0018 es: 0018 ss: 0018 Process xmms (pid: 11695, stackpage: c057f000) Stack: c01bea04 01ca c0169eac c0e22041 c015e71f c0e22000 c0e22568 c0e22168 c057ffbc 4157ff68 c15a0aa0 0007 c0e2256b c0e2216b c18806e4 c04e2000 c04e2000 c0699320 c04e2000 c2855e23 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 b9 20 ea 1e c0 ff 0d 20 ea 1e c0 0f 88 16 16 <0>Kernel panic: Aiee, killing interrupt handler! In interrupt handler - not syncing ksymoops: Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in vmlinux. Ignoring ksyms_base entry kernel BUG at printk.c:458! invalid operand: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010286 eax: 001c ebx: c11f290c ecx: c01eea20 edx: 0296 esi: c0e22000 edi: c0e2216b ebp: esp: c057fe78 ds: 0018 es: 0018 ss: 0018 Stack: c01bea04 01ca c0169eac c0e22041 c015e71f c0e22000 c0e22568 c0e22168 c057ffbc 4157ff68 c15a0aa0 0007 c0e2256b c0e2216b c18806e4 c04e2000 c04e2000 c0699320 c04e2000 c2855e23 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 b9 20 ea 1e c0 ff 0d 20 ea 1e c0 0f 88 16 16 >>EIP; c01136ee<= Trace; c0169eac Trace; c015e71f Trace; c2855e23 <[reiserfs]reiserfs_get_unused_objectid+53/c4> Trace; c0111212 Trace; c0128a3e <__free_pages+1a/1c> Trace; c0128a64 Trace; c013b09b Trace; c015cbf5 Trace; c0116ec4 <__run_task_queue+4c/68> Trace; c0119736 Trace; c0116def Trace; c0116d27 Trace; c0116c30 Trace; c010a152 Trace; c0108df0 Code; c01136ee <_EIP>: Code; c01136ee0: 0f 0b ud2a <= Code; c01136f02: 83 c4 08 add $0x8,%esp Code; c01136f35: b9 20 ea 1e c0mov $0xc01eea20,%ecx Code; c01136f8a: ff 0d 20 ea 1e c0 decl 0xc01eea20 Code; c01136fe 10: 0f 88 16 16 00 00 js 162c <_EIP+0x162c> c0114d1a <0>Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. ver_linux: Linux kama3 2.4.2-ac20 #1 Wed Mar 14 21:02:11 CET 2001 i586 unknown Gnu C 2.95.3 Gnu make 3.79.1 binutils 2.9.5.0.37 util-linux util-linux Note: /usr/bin/fdformat is obsolete and is no longer available. util-linux Please use /usr/bin/superformat instead (make sure you have the util-linux fdutils package installed first). Also, there had been some util-linux major changes from version 4.x. Please refer to the documentation. util-linux modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0d PPP2.4.0 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Procps 2.0.7 Net-tools 1.58 Kbd0.96 Sh-utils 2.0.11 Modules Loaded snd-pcm-oss snd-pcm-plugin reiserfs snd-mixer-oss snd-card-fm801 snd-mpu401-uart snd-rawmidi snd-seq-device snd-opl3 snd-hwdep snd-fm801 snd-pcm snd-timer snd-ac97-codec snd-mixer snd soundcore from 'dpkg -s util-linux': Version: 2.10s-2 I had to reboot, so maybe the modules aren't correct. Bye, Szabi - 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 audio and parport in 2.4.2
On Mon, Mar 19, 2001 at 12:16:26AM +, Will Newton wrote: > In /etc/modules.conf I have: > > options parport_pc irq=none > > but dmesg says: > > parport0: PC-style at 0x378 (0x778), irq 7, dma 3 > [PCSPP,TRISTATE,COMPAT,ECP,DMA] Jeff, this is a bug with the Via code in parport_pc.c. Basically, the problem is that the code that detects the Via doesn't know what parameters you passed. I know about the problem, but I don't know the fix yet. Tim. */ - 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] off-by-1 error in ide-probe (2.4.x)
On Sun, 18 Mar 2001, Jens Axboe wrote:
>
> The 256 is _not_ a bug in the driver, it's more likely a bug in your
> drive. 256 is a perfectly legal transfer size. That said, maybe it is
> a good idea to leave it at 255 just for safety on drives not handling
> 0 sectors == 128kB transfer.
Agreed. That would be a trivially easy bug in the firmware, limiting to
255 sectors seems safer.
Linus
Yes, possibly.
I checked old standards, and see that "0 means 256 as a sector count"
is already in ATA-1.
Is there any evidence that other people have been hit by this?
Unfortunately, the
"status error: status=0x58 { DriveReady SeekComplete DataRequest }"
is reported frequently these days, and has many causes.
In old reports it is rare. (E.g. none in lk for 1997.)
Paul: is there only one disk that you can make fail this way?
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: VIA audio and parport in 2.4.2
On Sat, 17 Mar 2001, Mike Galbraith wrote: > No device I'm using has irq troubles.. at least nothing obvious. I've > no idea if the spurious irq is VIA chipset related or not.. only that > it's a fairly recent arrival. All devices work fine here. In /etc/modules.conf I have: options parport_pc irq=none but dmesg says: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] parport0: cpp_mux: aa55f00f52ad51(80) parport0: cpp_daisy: aa5500ff(80) parport0: assign_addrs: aa5500ff(80) parport0: cpp_mux: aa55f00f52ad51(80) parport0: cpp_daisy: aa5500ff(80) parport0: assign_addrs: aa5500ff(80) parport_pc: Via 686A parallel port: io=0x378, irq=7, dma=3 lp0: using parport0 (interrupt-driven). How do I stop the parport module from using interrupts? - 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: Q: "kapm-idled" and CPU usage
On Sun, 18 Mar 2001, Jeff Garzik wrote: > Is there some way to hack the scheduler statistics so that idle > processes are special cases, which do not accumulate CPU time nor > contribute to the load average? It's trivial. I remember seeing a patch that does exactly this on linux-kernel, probably around the time kapmd was renamed. regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Rik van Riel <[EMAIL PROTECTED]> wrote: > > > >OK, I'll write some code to prevent multiple threads from > >stepping all over each other when they pagefault at the > >same address. > > > >What would be the preferred method of fixing this ? > > > >- fixing do_swap_page and all ->nopage functions > > There is no need to fix gthe "nopage" functions. They never see the > page table directly anyway. > > So the only thing that _should_ be needed is to make sure that > do_no_page(), do_swap_page() and do_anonymous_page() will re-aquire > the mm->page_table_lock and undo their work if it turns out that the > page table entry is no longer empty.. ... in which case concurrency is maximised, but there is a possibility of doing double work... > >- hacking handle_mm_fault to make sure no overlapping > > pagefaults will be served at the same time > > No. The whole reason the rw_semaphores were done in the first place > was to allow page faults to happen concurrently to allow threaded > applictions to scale up even when faulting. Indeed, having threaded apps do multiple page faults at the same time is the main goal of this patch. However, I don't see how it would be good for scalability to have multiple threads fault in the same page at the same time, when they could just wait for one of them to do the work. Only faults for different addresses would proceed, not faults for the same address... regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: Q: "kapm-idled" and CPU usage
[EMAIL PROTECTED] (Jeff Garzik) writes: > Is there some way to hack the scheduler statistics so that idle > processes are special cases, which do not accumulate CPU time nor > contribute to the load average? I wondered about getting kapm-idled to take the CPU time allocated to itself, and reallocate to the idle task. Something like the following at a strategic point inside the apm loop. unsigned long user, system; user = current->times.tms_utime; system = current->times.tms_stime; current->times.tms_utime = current->times.tms_stime = 0; idle->times.tms_utime += user; idle->times.tms_stime += system; I haven't looked to see what point would be a good idea, and investigated what locks need to be held. I've also just peeked at the 2.4 code, and seen "current->per_cpu_utime[cpu]" -- does this need handling? Is it visible to user space? If you looked closely, you might see the CPU time falling for kapm-idled, but generally you would see it allocated to the idle task, and not kapm-idled. > I agree that it's not pretty to special case idle function process(es), > but those idle functions in turn are causing an incorrect picture of the > system state to be presented to userland. At least with this scheme, the special casing is inside the kapm specific code, and not within the general timer handling. Of course, this is no more than an idea. I haven't got as far as running 2.4 on my only APM machine (486 Thinkpad), let alone trying out this scheme. -- `O O' | [EMAIL PROTECTED] // ^ \\ | http://www.pyrites.org.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/
Re: IP Alias with 2.2.18?
On 18-Mar-2001 Stephen "M." Williams wrote: > Marco, > > Recompile your kernel and select IP: aliasing support under > Networking Options > > > Steve Infact that's the problem! Sorry everybody! Marco > On 17 Mar 2001 22:06:44 +0100, Marco Calistri wrote: >> My first post on the "top of mailing-list"... >> >> Is there same IP aliasing support with kernel 2.2.18? >> >> My eth0:0 doesn't works anymore. >> >> Thanks! >> >> -- >> Regards,: Marco Calistri <[EMAIL PROTECTED]> >> gpg key available on http://www.qsl.net/ik5bcu >> Xfmail 1.4.7p2 on linux RedHat 6.2 - 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/
pcmcia "plug and hang" 2.4
As long as I don't plugin or unplug any of my pcmcia devices the system is fine, I can even do cardctl eject, and cardctl insert, but if I physically remove or insert the cards it hangs without any messages. Also, if I don't load the usb drivers then I can yank and plug them all day, but as soon as I load hte usb drivers it hangs. The pcmcia driver doesn't register an irq. The usb drivers use irq 11. Windows on the same machine lists the cardbus driver as using irq 11, so I'm guessing some kind of irq problem here. It used to work in the 2.3 series, then again I don't remember if I just wasn't using USB at the time. System is a Laptop Toshiba Portege 3015CT. NoSpace:~$ cat /proc/modules xirc2ps_cs 12080 1 serial_cs 4832 0 (unused) ds 6700 2 [xirc2ps_cs serial_cs] i82365 13332 2 pcmcia_core39744 0 [xirc2ps_cs serial_cs ds i82365] snd-card-opl3sa28964 0 snd-cs4231 13864 0 [snd-card-opl3sa2] snd-opl36164 0 [snd-card-opl3sa2] snd-hwdep 4044 0 [snd-opl3] snd-mpu401-uart 3120 0 [snd-card-opl3sa2] snd-rawmidi10444 0 [snd-mpu401-uart] snd-pcm-oss39232 0 (unused) snd-pcm38584 0 [snd-cs4231 snd-pcm-oss] snd-timer 9336 0 [snd-cs4231 snd-opl3 snd-pcm] snd-mixer-oss 9612 0 [snd-pcm-oss] snd27768 1 [snd-card-opl3sa2 snd-cs4231 snd-opl3 snd-hwdep snd-mpu401-uart snd-rawmidi snd-pcm-oss snd-pcm snd-timer snd-mixer-oss] soundcore 3748 5 [snd] usb-ohci 16516 0 (unused) hid11920 0 (unused) evdev 3732 0 (unused) mousedev4164 1 input 3264 0 [hid evdev mousedev] usbcore46372 1 [usb-ohci hid] serial 42468 0 [serial_cs] PCI devices found: Bus 0, device 0, function 0: Host bridge: Toshiba America Info Systems 601 (rev 162). Bus 0, device 4, function 0: VGA compatible controller: Neomagic Corporation NM2160 [MagicGraph 128XD] (rev 1). IRQ 11. Master Capable. Latency=64. Min Gnt=16.Max Lat=255. Prefetchable 32 bit memory at 0xfd00 [0xfdff]. Non-prefetchable 32 bit memory at 0xffc0 [0xffdf]. Non-prefetchable 32 bit memory at 0xffb0 [0xffbf]. Bus 0, device 11, function 0: USB Controller: NEC Corporation USB (rev 2). IRQ 11. Master Capable. Latency=16. Min Gnt=1.Max Lat=21. Non-prefetchable 32 bit memory at 0xffaff000 [0xffaf]. Bus 0, device 17, function 0: Communication controller: Toshiba America Info Systems FIR Port (rev 35). IRQ 11. Master Capable. Latency=64. I/O at 0xffc0 [0xffdf]. Bus 0, device 19, function 0: CardBus bridge: Toshiba America Info Systems ToPIC97 (rev 6). Non-prefetchable 32 bit memory at 0x1000 [0x1fff]. Bus 0, device 19, function 1: CardBus bridge: Toshiba America Info Systems ToPIC97 (#2) (rev 6). Non-prefetchable 32 bit memory at 0x10001000 [0x10001fff]. relavant boot messages Kernel command line: auto BOOT_IMAGE=2.4.3-pre4 root=302 BOOT_FILE=/boot/kernel/2.4.3-pre4 PCI: PCI BIOS revision 2.10 entry at 0xfd837, last bus=21 PCI: Using configuration type 1 PCI: Probing PCI hardware got res[1000:1fff] for resource 0 of Toshiba America Info Systems ToPIC97 got res[10001000:10001fff] for resource 0 of Toshiba America Info Systems ToPIC97 (#2) usb.c: registered new driver usbdevfs usb.c: registered new driver hub mice: PS/2 mouse device common for all mice usb.c: registered new driver hid usb-ohci.c: USB OHCI at membase 0xc303c000, IRQ 11 usb-ohci.c: usb-00:0b.0, NEC Corporation USB usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found hub.c: 2 ports detected Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] Intel PCIC probe: Intel i82365sl B step ISA-to-PCMCIA at port 0x3e0 ofs 0x00, 2 sockets host opts [0]: none host opts [1]: none ISA irqs (scanned) = 3,4,7,9,10,15 status change on irq 15 cs: IO port probe 0x0c00-0x0cff: clean. cs: IO port probe 0x0800-0x08ff: clean. cs: IO port probe 0x0100-0x04ff: excluding 0x220-0x22f 0x330-0x337 0x378-0x37f 0x480-0x48f 0x4d0-0x4d7 cs: IO port probe 0x0a00-0x0aff: clean. cs: memory probe 0x0d-0x0d: clean. xirc2ps_cs.c 1.31 1998/12/09 19:32:55 (dd9jn+kvh) eth0: Intel: port 0x300, irq 3, hwaddr 00:A0:C9:7A:CE:D5 eth0: autonegotiation failed; using 10mbs eth0: MII detected; using 10mbs eth0: media 10BaseT, silicon revision 4 ttyS01 at port 0x02f8 (irq = 9) is a 16550A inet6_ifa_finish_destroy xirc2ps_cs.c 1.31 1998/12/09 19:32:55 (dd9jn+kvh) eth0: Intel: port 0x300, irq 3, hwaddr 00:A0:C9:7A:CE:D5 eth0: autonegotiation failed; using 10mbs eth0: MII detected; using 10mbs eth0: media 10BaseT, silicon revision 4 eth0: no IPv6
Re: [PATCH] off-by-1 error in ide-probe (2.4.x)
On Sun, 18 Mar 2001, Linus Torvalds wrote: > > > On Sun, 18 Mar 2001, Jens Axboe wrote: > > > > The 256 is _not_ a bug in the driver, it's more likely a bug in your > > drive. 256 is a perfectly legal transfer size. That said, maybe it is > > a good idea to leave it at 255 just for safety on drives not handling > > 0 sectors == 128kB transfer. > > Agreed. That would be a trivially easy bug in the firmware, limiting to > 255 sectors seems safer. Guys which side of the counter is the decrementer? Telling the drive to transfer 256 sectors in PIO is filling the sector_count register with '0' == 'zero'. As long as 255 == 255 and 0 == 256 for total sectors to transfer all is cool. Andre Hedrick Linux ATA 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: [PATCH] off-by-1 error in ide-probe (2.4.x)
On Sun, 18 Mar 2001, Jens Axboe wrote: > > The 256 is _not_ a bug in the driver, it's more likely a bug in your > drive. 256 is a perfectly legal transfer size. That said, maybe it is > a good idea to leave it at 255 just for safety on drives not handling > 0 sectors == 128kB transfer. Agreed. That would be a trivially easy bug in the firmware, limiting to 255 sectors seems safer. 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/
right way to export VM data to userspace for a performance tool
Hi everybody, I want to write a tool that can extract information from the kernel about the VM situation. Conceptually, I want something that looks like this: # cacheinfo /var/mysql/data/powerdns/records.MYD 75% of blocks in memory 12% dirty # cacheinfo -d -v /var/mysql/data/powerdns/records.MYD 0 M 1 M 2 - 3 - 4 D Before writing this, I'm wondering how the kernel people feel that this sort of information should be exported to userland. There are lots of options, but not being a kernel architect/philosopher, I don't have a clue. My goal is to have a patch included in the main kernel, so it is very important that I write stuff people will agree on. Please let me know what you think. Kind regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - 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: [OT] how to catch HW fault
Hi, I tried memtest86 for 24 hours also and that didn't gave a clue. When bad ram was really involved I'd expected to find things like: failing fsck's, failing kernel compiles and such. But none of them the system runs perfect if it doesn't freeze(lockup). So yes, only the CPU's and the mobo are at question. What I was looking for was a tool like memtest86 but now for motherboards. regards Kees On Sat, 17 Mar 2001, Aaron Lunansky wrote: > Sounds like the only thing you haven't swapped out of your machine is the > ram/cpu. > > It could very well be your ram (I don't suspect the cpu). If you can, try a > different stick of ram. > > - 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] off-by-1 error in ide-probe (2.4.x)
On Sun, Mar 18 2001, Paul Gortmaker wrote: > There is a potentially serious bug in ide-probe.c in which max_sectors > is set to 256 instead of 255. I am surprised that this hasn't bit anyone > else yet. Perhaps because you need a disk that is slow in comparison to > the host in order for the queue to climb up to and then hit the 256, at > which point it then falls over. You don't need a slow disk, it's trivial to provoke 256 sector sized request on even the fastest disk available. People hit it all the time, just with working drives... > For example, with an old 700MB Maxtor on a "fast" 486, VL-bus, PIO, > hdparm -c1 -m8 -u1, I could pretty much on demand generate the following > error by multiple builds, or by the final linking of any big project: The 256 is _not_ a bug in the driver, it's more likely a bug in your drive. 256 is a perfectly legal transfer size. That said, maybe it is a good idea to leave it at 255 just for safety on drives not handling 0 sectors == 128kB transfer. -- 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/
Kernel panic: Aiee, killing interrupt handler!
Hi, I got this machine, which I use for my research groups file (samba) and printing (lpd over samba) needs. This is the second time it has gone down for me, as shown below. There's really nothing to say about it; it has worked fine for about two weeks, and then an unprovoked panic. As you might see, it went down on a saturday, and this is the only thing in the log on that day; it's been standing idle for the whole day. The spec. is, as I'm sure you can see from the dmesg+lspci attachment: Pentium 90MHz 32Mb RAM SiS 85C501/2 CMD640 IDE SMC-Ultra 8216C IBM Deskstar DTLA-305040 41Gb, 128Mb swap, 2Gb ext2, and the rest one big reiserfs. linux-2.4.2 RedHat 6.2 I have to use setmax (from LARGE-HDD-HOWTO) in order to get the deskstar to mount. An oddity is this; We didn't have enough network points in our office, so I made a bridge (the bridging code is compiled into the kernel), using a second (SMC-Ultra) network card. And all of a sudden, I didn't have to use setmax any more. The kernel took care of the disk fine. As we got new points installed, I stopped using the bridge, and, once again I had to use setmax. Strange. I must add, I've used this machine for about a year to run an instrument, without any problems, only with linux-2.2 and a 6Gb harddrive instead of the deskstar. I've also added an extra ISA card parport for a second printer. I hope something of this helps. And if someone could tell me what is wrong here, I would be much obliged. I've had much resistance within the university for using linux as it is, and, if it starts going down every now and again, they'll chuck it out without a doubt. If I can do somthing else, in order to help, plese let me know. Cheeres, /Chris Kernel panic: Aiee, killing interrupt handler! In interrupt handler not syncing Unable to handle kernel NULL pointer dereference at virtual address 000b printing eip: c01104c3 *pde = Oops: CPU: 0 EIP: 0010: [] EFLAGS: 00010013 eax: epx: 000b ecx: c10a6000 edx: c02108dc esi: c0210c18 edi: 0003 ebp: c10a5eb0 esp: c10a5e94 Process kreclaimd pid:4, stackpage = c10a5000 Stack: c02109c0 c0210c18 c02108dc 0001 0286 0001 0002 c0128335 0020 0002 c10af124 0002 0002 c0210c10 c012850c c012532a c10af124 0246 0002 0021 0003 c0125467 Call trace: [] [] [] [] [] [] [] [] [] [] [] Code: 8b 1b 8b 4f 04 8b 01 85 45 fc 74 51 31 c0 9c 5e fa c7 01 00 Kernel panic: Aiee, killing interrupt handler! In interrupt handler not syncing -- Christer Bäckström Optoelectronic Materials Chemistry Group Department of Chemistry University of Wales, Bangor Bangor, Gwynedd LL57 2UW Wales, UK E-mail : [EMAIL PROTECTED] Telephone Office: +44(0)1248 388302 Telephone Laboratory: +44(0)1248 388304 Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) #23 Thu Feb 22 22:03:19 GMT 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 00018000 @ 000e8000 (reserved) BIOS-e820: 01f0 @ 0010 (usable) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=2 ro root=302 hda=79780,16,63 ide_setup: hda=79780,16,63 Initializing CPU#0 Detected 90.001 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 179.40 BogoMIPS Memory: 30320k/32768k available (846k kernel code, 2060k reserved, 286k data, 180k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) CPU: Before vendor init, caps: 01bf , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 01bf CPU: After generic, caps: 01bf CPU: Common caps: 01bf CPU: Intel Pentium 75 - 200 stepping 04 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.00 entry at 0xfc920, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Unable to handle 64-bit address for device 00:00.0 PCI: Unable to handle 64-bit address for device 00:00.0 PCI: Unable to handle 64-bit address for device 00:00.0 PCI: Failed to allocate resource 1 for Silicon Integrated Systems [SiS] 85C501/2 PCI: Failed to allocate resource 3 for Silicon Integrated Systems [SiS] 85C501/2 PCI: Failed to allocate resource 5 for Silicon Integrated Systems [SiS] 85C501/2 isapnp: Scanning for Pnp cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer
tcp retransmit timeout?
How can I set the timeout for retransmitting non-acknowledged packets? I'd like to set linux up to more aggressive about assuming a packet didn't make it. Thanks! Mordy - 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: Where to find -pre releases?
Em Sun, Mar 18, 2001 at 12:30:45PM -0600, George R. Kasica escreveu: > Where in the ftp sites should I find the 2.4.3 -pre kernels? The > instructions from freshmeat are not correct and I just can't remember > the location... http://www.kernel.org/pub/linux/kernel/testing - 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/
Q: "kapm-idled" and CPU usage
The message quoted below is from a MandrakeSoft co-worker and friend, in a thread discussing APM's kernel thread, and how the idle function uses CPU time. This thread was in response to yet another Bugzilla bug report about kapm-idled using CPU time. Several months ago, kapmd was renamed to kapm-idled in an attempt to signal users that it was a special process, and that its CPU time wasn't "real CPU time." This hasn't silenced the bug reports and confusion. Is there some way to hack the scheduler statistics so that idle processes are special cases, which do not accumulate CPU time nor contribute to the load average? I agree that it's not pretty to special case idle function process(es), but those idle functions in turn are causing an incorrect picture of the system state to be presented to userland. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. Guillaume Cottenceau wrote: > On the other hand, you'll agree Jeff that it needs some fixing: it's > fucking up many statistics such as load average and instant cpu usage, and > is very confusing for people.. > > On another side, what I don't understand is that its cpu usage is not > constant, which makes people things it's sort of a bug: for example my > machine is up 1 day, 18:33 with 2.4.2-15mdk, kapm-ideld is reported to > have consumed 1355m, but currently it's staying at 0.0% of cpu. Sometimes > it gets bigger, sometimes it gets lower. Rather confusing. - 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: Where to find -pre releases?
ftp://ftp.us.kernel.org/pub/linux/kernel/testing/ On Sun, 18 Mar 2001, George R. Kasica wrote: > Hello: > > Where in the ftp sites should I find the 2.4.3 -pre kernels? The > instructions from freshmeat are not correct and I just can't remember > the location... > > George > > George, MR. Tibbs & The Beast Kasica > Waukesha, WI USA > [EMAIL PROTECTED] > http://www.netwrx1.com > ICQ #12862186 > > Zz >zZ > |\ z_,,,---,,_ > /,`.-'`'_ ;-;;,_ >|,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/ > __ Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] ANTC & NSRC [EMAIL PROTECTED] -- "On two occasions I have been asked [by members of Parliament!], `Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." -- Charles Babbage - 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: Where to find -pre releases?
"George R. Kasica" wrote: > Where in the ftp sites should I find the 2.4.3 -pre kernels? The > instructions from freshmeat are not correct and I just can't remember > the location... ftp://ftp.??.kernel.org/pub/linux/kernel/testing/ ?? == country code: us, de, dk, uk, ... Maybe I'm blind, but I didn't find an answer to this in the FAQ at http://www.tux.org/lkml/ Richard Gooch, FAQ maintainer, is CC'd. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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 to find -pre releases?
Hello: Where in the ftp sites should I find the 2.4.3 -pre kernels? The instructions from freshmeat are not correct and I just can't remember the location... George George, MR. Tibbs & The Beast Kasica Waukesha, WI USA [EMAIL PROTECTED] http://www.netwrx1.com ICQ #12862186 Zz zZ |\ z_,,,---,,_ /,`.-'`'_ ;-;;,_ |,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/
Re: changing mm->mmap_sem (was: Re: system call for processinformation?)
In article <[EMAIL PROTECTED]>, Rik van Riel <[EMAIL PROTECTED]> wrote: > >OK, I'll write some code to prevent multiple threads from >stepping all over each other when they pagefault at the >same address. > >What would be the preferred method of fixing this ? > >- fixing do_swap_page and all ->nopage functions There is no need to fix gthe "nopage" functions. They never see the page table directly anyway. So the only thing that _should_ be needed is to make sure that do_no_page(), do_swap_page() and do_anonymous_page() will re-aquire the mm->page_table_lock and undo their work if it turns out that the page table entry is no longer empty.. (do_wp_page() should already be ok in this regard - it already does this exactly because present pagetable entries can already race with kswapd. What we're adding is that _nonpresent_ page table entries can race with multiple invocations of concurrent page faults) >- hacking handle_mm_fault to make sure no overlapping > pagefaults will be served at the same time No. The whole reason the rw_semaphores were done in the first place was to allow page faults to happen concurrently to allow threaded applictions to scale up even when faulting. 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: [CHECKER] 28 potential interrupt errors
On Sun, 18 Mar 2001, Andrew Morton wrote:
> I'm planning on poking through everything which has been
> identified as a posible problem. But I won't start for
> several weeks - give the maintainers (if any) time to
> address these things.
I took a look at the ISDN issues, here's a patch which should fix most of
it (sleeping in IRQ, and unchecked user access still missing).
I'ld appreciate it if somebody felt like looking through it. The patch is
against current CVS, but applies against current 2.4.3-pre.
--Kai
diff -ur isdn-HEAD/drivers/isdn/avmb1/capi.c isdn-h/drivers/isdn/avmb1/capi.c
--- isdn-HEAD/drivers/isdn/avmb1/capi.c Thu Mar 15 22:19:21 2001
+++ isdn-h/drivers/isdn/avmb1/capi.cSat Mar 17 18:21:23 2001
@@ -1082,6 +1082,8 @@
return -ENODEV;
skb = alloc_skb(count, GFP_USER);
+ if (!skb)
+ return -ENOMEM;
if ((retval = copy_from_user(skb_put(skb, count), buf, count))) {
kfree_skb(skb);
@@ -1501,6 +1503,8 @@
return -EINVAL;
skb = alloc_skb(CAPI_DATA_B3_REQ_LEN+count, GFP_USER);
+ if (!skb)
+ return -ENOMEM;
skb_reserve(skb, CAPI_DATA_B3_REQ_LEN);
if ((retval = copy_from_user(skb_put(skb, count), buf, count))) {
Only in isdn-h/drivers/isdn/avmb1: capi.c%
diff -ur isdn-HEAD/drivers/isdn/avmb1/capidrv.c isdn-h/drivers/isdn/avmb1/capidrv.c
--- isdn-HEAD/drivers/isdn/avmb1/capidrv.c Thu Mar 15 17:05:56 2001
+++ isdn-h/drivers/isdn/avmb1/capidrv.c Sat Mar 17 18:23:33 2001
@@ -2065,8 +2065,8 @@
__u16 datahandle;
if (!card) {
- printk(KERN_ERR "capidrv-%d: if_sendbuf called with invalid driverId
%d!\n",
- card->contrnr, id);
+ printk(KERN_ERR "capidrv: if_sendbuf called with invalid driverId
+%d!\n",
+ id);
return 0;
}
if (debugmode > 1)
@@ -2137,8 +2137,8 @@
__u8 *p;
if (!card) {
- printk(KERN_ERR "capidrv-%d: if_readstat called with invalid driverId
%d!\n",
- card->contrnr, id);
+ printk(KERN_ERR "capidrv: if_readstat called with invalid driverId
+%d!\n",
+ id);
return -ENODEV;
}
Only in isdn-h/drivers/isdn/avmb1: capidrv.c%
diff -ur isdn-HEAD/drivers/isdn/hisax/config.c isdn-h/drivers/isdn/hisax/config.c
--- isdn-HEAD/drivers/isdn/hisax/config.c Thu Mar 15 22:19:21 2001
+++ isdn-h/drivers/isdn/hisax/config.c Sat Mar 17 18:07:41 2001
@@ -925,13 +925,12 @@
save_flags(flags);
cli();
- if (!(cs = (struct IsdnCardState *)
- kmalloc(sizeof(struct IsdnCardState), GFP_ATOMIC))) {
+ cs = kmalloc(sizeof(struct IsdnCardState), GFP_ATOMIC)
+ if (!cs) {
printk(KERN_WARNING
"HiSax: No memory for IsdnCardState(card %d)\n",
cardnr + 1);
- restore_flags(flags);
- return (0);
+ goto out;
}
memset(cs, 0, sizeof(struct IsdnCardState));
card->cs = cs;
@@ -950,241 +949,235 @@
#endif
cs->protocol = card->protocol;
- if ((card->typ > 0) && (card->typ <= ISDN_CTYPE_COUNT)) {
- if (!(cs->dlog = kmalloc(MAX_DLOG_SPACE, GFP_ATOMIC))) {
- printk(KERN_WARNING
- "HiSax: No memory for dlog(card %d)\n",
- cardnr + 1);
- restore_flags(flags);
- return (0);
- }
- if (!(cs->status_buf = kmalloc(HISAX_STATUS_BUFSIZE, GFP_ATOMIC))) {
- printk(KERN_WARNING
- "HiSax: No memory for status_buf(card %d)\n",
- cardnr + 1);
- kfree(cs->dlog);
- restore_flags(flags);
- return (0);
- }
- cs->stlist = NULL;
- cs->status_read = cs->status_buf;
- cs->status_write = cs->status_buf;
- cs->status_end = cs->status_buf + HISAX_STATUS_BUFSIZE - 1;
- cs->typ = card->typ;
- strcpy(cs->iif.id, id);
- cs->iif.channels = 2;
- cs->iif.maxbufsize = MAX_DATA_SIZE;
- cs->iif.hl_hdrlen = MAX_HEADER_LEN;
- cs->iif.features =
- ISDN_FEATURE_L2_X75I |
- ISDN_FEATURE_L2_HDLC |
- ISDN_FEATURE_L2_HDLC_56K |
- ISDN_FEATURE_L2_TRANS |
- ISDN_FEATURE_L3_TRANS |
+ if (card->typ <= 0 || card->typ > ISDN_CTYPE_COUNT) {
+ printk(KERN_WARNING
+ "HiSax: Card Type %d out of range\n",
+ card->typ);
+ goto outf_cs;
+ }
+ if (!(cs->dlog =
pselect
For people who prefer programming above documenting, here is a simple small thing to do: POSIX.1g and Austin document a pselect() call intended to remove the race condition that is present when one wants to wait on either a signal or some file descriptor. (See also Stevens, Unix Network Programming, Volume 1, 2nd Ed., 1998, p. 168 and the pselect.2 man page released today.) Glibc 2.0 has a bad version (wrong number of parameters) and glibc 2.1 a better version, but the whole purpose of pselect is to avoid the race, and glibc cannot do that, one needs kernel support. So, probably someone should make a system call pselect almost identical to the present select, adding a sigmask parameter. (Or something more general.) 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/
[OT] man-pages-1.35 released
A moment ago I put man-pages-1.35 the usual places (e.g. on ftp://ftp.win.tue.nl/pub/linux-local/manpages). David Mosberger expressed his worry that especially man page Section 2 is out-dated and x86 specific, with no indication that other architectures even exist. No doubt he is right. So, request to all: (i) point out which man pages are outdated or missing, and if possible (ii) supply patches or entirely new pages. Send contributions to [EMAIL PROTECTED], not (only) to some mailing list or bug list. 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/
UDMA 100 / PIIX4 question
Hi, This question is much the same as one I posted a couple of months ago, at which time I was using the stock 2.2.18 kernel supplied with my SuSE distro. Some people suggested that I should upgrade, and since then I have been learning my way around kernel compilation and following this list. I am now running 2.4.2, but my problem remains, so I thought I might reasonably ask again. I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller. The drive is properly cabled and correctly recognised. I have, I think, set the right options in my kernel config (I have quoted the relevant part below). Lilo.conf includes append="ide0=ata66. Boot.msg includes: <4>PIIX4: chipset revision 1 <4>PIIX4: not 100% native mode: will probe irqs later <4>PIIX4: ATA-66/100 forced bit set (WARNING)!! <4>ide0: BM-DMA at 0xa800-0xa807, BIOS settings: hda:DMA, hdb:pio <4>ide1: BM-DMA at 0xa808-0xa80f, BIOS settings: hdc:DMA, hdd:pio <4>hda: IBM-DTLA-307030, ATA DISK drive ... <6>hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100) According to hdparm -i the drive thinks that it is in UDMA mode 5. My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I fall back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes any difference. I do appreciate that there are some issues involving higher UDMA rates and certain hardware. I have read a number of relevant posts, including those passing between Linus, Andre Hedrick, Alan Cox and others on the subject last January, but I cannot understand from what I have read whether or not my particular configuration (in particular the PIIX4),is subject to these problems - or if I am simply screwed up. TIA, Geoff CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD7409 is not set # CONFIG_AMD7409_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_OSB4 is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y CONFIG_IDEDMA_IVB=y # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y _ Do You Yahoo!? Get your free @yahoo.com address at http://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/
Re: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Mike Galbraith wrote: > > No, this was make -j30 bzImage. (nscd was running though...) > > I rebooted, shut down nscd prior to testing and did 5 builds in a row > without a single gripe. Started nscd for sixth run and instantly the > kernel griped. Yup.. threaded apps pushing swap. OK, I'll write some code to prevent multiple threads from stepping all over each other when they pagefault at the same address. What would be the preferred method of fixing this ? - fixing do_swap_page and all ->nopage functions - hacking handle_mm_fault to make sure no overlapping pagefaults will be served at the same time regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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] big stack variables
[EMAIL PROTECTED] said: > ObUML (again): Any estimated time of submission to Linus?! Is this an > early v2.5-thing, or are the changes minor enough to the rest of the > tree to allow for an v2.4-merge? There are almost no changes to the rest of the tree, and none of those affect any of the other arches, so it's an early 2.4 thing. The reason I've waiting this long to put it in is that UML is not a normal port. With the other ports, few enough people have the relevant hardware that if the port isn't all that great at submission time, not many people will be affected. With UML, the vast majority of Linux users (the i386-using ones) have the relevant platform (we could get a lot closer to 100% if owners of non-i386 boxes would port UML to them, hint, hint :-). I expect that getting it into the pool will be considered something of a stamp of approval for UML, so a lot more people will start using it. If it sucks, it will affect a large number of people, word will get around that it sucks, and lots of people won't give it a second chance. So, my goal for UML when it's submitted is that it make a solid, stable, UP virtual machine. You can see a measure of my progress by my TODO list, which I post to my devel list occasionally. The most recent one is at http://www.geocrawler.com/lists/3/SourceForge/709/25/5339352/ After the 2.4 submission, I'm going to start working on some more radical things, like SMP emulation, clustering, and artifical environments. 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/
floppy programming
Hi, some body know if exist or is possible to do one driver to makes floppy drive use some type of "balanced" bits distribution? The idea is simple: format a disk doing inner tracks with less bits than in external tracks. Maybe is better think in sectors and not bits banlancing? I want opinions about the idea, pleace. Where can I find information about floppy drivers programming, DMA setup,...? Thanks, Leandro __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. 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/
[OOPS] 2.4.2-ac20
hi, i got this oops followed by a freeze aris Gnu C egcs-2.91.66 Gnu make 3.79 binutils 2.9.1.0.25 util-linux 2.10l modutils 2.4.1 e2fsprogs 1.18 pcmcia-cs 3.1.16 Linux C Library2.1.3 ldd: version 1.9.9 Procps 2.0.6 Net-tools 1.55 Kbd0.99 Sh-utils 2.0 Modules Loaded serial isa-pnp nsc-ircc irda apm vfat fat eepro100 esssolo1 ksymoops 2.3.7 on i686 2.4.2-ac20. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2-ac20/ (default) -m /boot/System.map.2.4.2.ac20 (specified) CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010213 eax: ebx: c290270c ecx: c28f2000 edx: 0015 esi: c28f2000 edi: 0246 ebp: c28f236c esp: 0022be64 Process swapper (pid: 0, stackpage=c021b000) Stack: c01770b4 c28f2020 c016ad00 c28f2000 c28f2768 c28f2368 c28f2568 c021bfa4 c0181d00 c1121d00 20181834 c28f276c 0001 0008 3286 c10ccd84 c10ccd84 c021bedc 0082 c10ccd58 c10ccd80 Call Trace: [] [c016ad00>] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b b9 80 a5 20 c0 ff 0d 80 a5 20 c0 0f 88 6e 76 0c 00 c7 >>EIP; c011645b<= Trace; c01770b4 Trace; c0119c60 <__run_task_queue+50/60> Trace; c011c0ee Trace; c0119b7f Trace; c0119ac0 Trace; c01199ca Trace; c010a175 Trace; c0107160 Trace; c0108e50 Trace; c0107160 Trace; c0107160 Trace; c0100018 Trace; c0107180 Trace; c01071e2 Trace; c0105000 Trace; c0100192 Code; c011645b <_EIP>: Code; c011645b<= 0: 0f 0b ud2a <= Code; c011645d 2: b9 80 a5 20 c0movl $0xc020a580,%ecx Code; c0116462 7: ff 0d 80 a5 20 c0 decl 0xc020a580 Code; c0116468 d: 0f 88 6e 76 0c 00 js c7681 <_EIP+0xc7681> c01ddadc Code; c011646e 13: c7 00 00 00 00 00 movl $0x0,(%eax)
Upgrading to 2.2.19pre to fix do_try_to_free_pages bug
Hi all, I've been running into the do_try_to_free_pages problem on a server running 2.2.18 and I just wish I'd looked at the list earlier to see if it was a known bug. (And I'm relieved that it is a known bug, I'm just surprised that I hadn't hit it earlier!) Now that I know there's a fix in 2.2.19pre*, I need to upgrade. Since I have limited opportunities to reboot (this is a Samba server for student labs, and the coming week is the last week of term with everyone working on their assignments), I need to be reasonably sure that 2.2.19pre17 doesn't have any known showstopper bugs. So, does anyone have any comments on whether or not 2.2.19pre17 is a good move, or should I be looking at an earlier 2.2.19pre? This is a dual PIII/600E, with a Mylex RAID controller, one 3c905B NIC, an on-board Intel EEPro 100 interface, ext2 filesystems and disk quotas. Thanks in advance for comments. Martin -- Martin Radford | "Only wimps use tape backup: _real_ [EMAIL PROTECTED] | men just upload their important stuff -o) Registered Linux user #9257 | on ftp and let the rest of the world /\\ - see http://counter.li.org | mirror it ;)" - Linus Torvalds _\_V - 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] 28 potential interrupt errors
On Sun, 18 Mar 2001, Andrew Morton wrote:
> There's another thing which needs doing to n_r3964.c, BTW - the
> abuse of task queues in r3964_close(). This is, I think, the
> only client of task queues which needs to poke so deeply into
> the implementation internals and Linus has mentioned something about
> needing to redesign the task queues in 2.5. So n_r3964 needs
> somehow to be redesigned so that it can use standard APIs.
Hmmm. That particular piece of ugliness seems to have been particularly
gratuitous. We had two task queues, each of which would decrement a
countdown value, calling on_timeout() if it reached zero, and stick the
other on the tq_timer list.
Is there anyone out there that can test this and save me the trouble of
trying to remember how to drive it?
Index: drivers/char/n_r3964.c
===
RCS file: /inst/cvs/linux/drivers/char/Attic/n_r3964.c,v
retrieving revision 1.1.2.7
diff -u -r1.1.2.7 n_r3964.c
--- drivers/char/n_r3964.c 2001/02/24 19:01:19 1.1.2.7
+++ drivers/char/n_r3964.c 2001/03/18 13:02:49
@@ -13,6 +13,12 @@
* L. Haag
*
* $Log: n_r3964.c,v $
+ * Revision 1.10 2001/03/18 13:02:24 dwmw2
+ * Fix timer usage, use spinlocks properly.
+ *
+ * Revision 1.9 2001/03/18 12:52:14 dwmw2
+ * Merge changes in 2.4.2
+ *
* Revision 1.8 2000/03/23 14:14:54 dwmw2
* Fix race in sleeping in r3964_read()
*
@@ -110,8 +116,6 @@
#define TRACE_Q(fmt, arg...) /**/
#endif
-static void on_timer_1(void*);
-static void on_timer_2(void*);
static void add_tx_queue(struct r3964_info *, struct r3964_block_header *);
static void remove_from_tx_queue(struct r3964_info *pInfo, int error_code);
static void put_char(struct r3964_info *pInfo, unsigned char ch);
@@ -120,7 +124,7 @@
static void transmit_block(struct r3964_info *pInfo);
static void receive_char(struct r3964_info *pInfo, const unsigned char c);
static void receive_error(struct r3964_info *pInfo, const char flag);
-static void on_timeout(struct r3964_info *pInfo);
+static void on_timeout(unsigned long priv);
static int enable_signals(struct r3964_info *pInfo, pid_t pid, int arg);
static int read_telegram(struct r3964_info *pInfo, pid_t pid, unsigned char *buf);
static void add_msg(struct r3964_client_info *pClient, int msg_id, int arg,
@@ -217,7 +221,7 @@
{
int status;
- printk ("r3964: Philips r3964 Driver $Revision: 1.8 $\n");
+ printk ("r3964: Philips r3964 Driver $Revision: 1.10 $\n");
/*
* Register the tty line discipline
@@ -247,40 +251,11 @@
* Protocol implementation routines
*/
-static void on_timer_1(void *arg)
-{
- struct r3964_info *pInfo = (struct r3964_info *)arg;
-
- if(pInfo->count_down)
- {
- if(!--pInfo->count_down)
- {
- on_timeout(pInfo);
- }
- }
- queue_task(>bh_2, _timer);
-}
-
-static void on_timer_2(void *arg)
-{
- struct r3964_info *pInfo = (struct r3964_info *)arg;
-
- if(pInfo->count_down)
- {
- if(!--pInfo->count_down)
- {
- on_timeout(pInfo);
- }
- }
- queue_task(>bh_1, _timer);
-}
-
static void add_tx_queue(struct r3964_info *pInfo, struct r3964_block_header *pHeader)
{
unsigned long flags;
- save_flags(flags);
- cli();
+ spin_lock_irqsave(>lock, flags);
pHeader->next = NULL;
@@ -294,7 +269,7 @@
pInfo->tx_last = pHeader;
}
- restore_flags(flags);
+ spin_unlock_irqrestore(>lock, flags);
TRACE_Q("add_tx_queue %x, length %d, tx_first = %x",
(int)pHeader, pHeader->length, (int)pInfo->tx_first );
@@ -337,8 +312,7 @@
wake_up_interruptible (>read_wait);
}
- save_flags(flags);
- cli();
+ spin_lock_irqsave(>lock, flags);
pInfo->tx_first = pHeader->next;
if(pInfo->tx_first==NULL)
@@ -346,7 +320,7 @@
pInfo->tx_last = NULL;
}
- restore_flags(flags);
+ spin_unlock_irqrestore(>lock, flags);
kfree(pHeader);
TRACE_M("remove_from_tx_queue - kfree %x",(int)pHeader);
@@ -359,8 +333,7 @@
{
unsigned long flags;
- save_flags(flags);
- cli();
+ spin_lock_irqsave(>lock, flags);
pHeader->next = NULL;
@@ -375,7 +348,7 @@
}
pInfo->blocks_in_rx_queue++;
- restore_flags(flags);
+ spin_unlock_irqrestore(>lock, flags);
TRACE_Q("add_rx_queue: %x, length = %d, rx_first = %x, count = %d",
(int)pHeader, pHeader->length,
@@ -396,8 +369,7 @@
TRACE_Q("remove_from_rx_queue: %x, length %d",
(int)pHeader, (int)pHeader->length );
- save_flags(flags);
- cli();
+ spin_lock_irqsave(>lock, flags);
if(pInfo->rx_first == pHeader)
{
@@ -430,7 +402,7 @@
}
}
- restore_flags(flags);
+ spin_unlock_irqrestore(>lock, flags);
kfree(pHeader);
TRACE_M("remove_from_rx_queue - kfree %x",(int)pHeader);
@@ -471,17 +443,16 @@
unsigned long flags;
- save_flags(flags);
-
Re: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Rik van Riel wrote: > > VFS: Mounted root (ext2 filesystem) readonly. > > Freeing unused kernel memory: 196k freed > > Adding Swap: 265064k swap-space (priority 2) > > VM: Bad swap entry 00011e00 > > VM: Bad swap entry 00058d00 > > Unused swap offset entry in swap_dup 00058d00 > > Unused swap offset entry in swap_dup 00011e00 > > VM: Bad swap entry 00011e00 > > VM: Bad swap entry 00058d00 > > Heh, I guess do_swap_page isn't too happy when multiple threads > of the same program take a page fault at the same address at the > same time. > > I take it you were testing something like mysql, jvm or apache2 ? No, this was make -j30 bzImage. (nscd was running though...) -Mike - 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] 120 potential dereference to invalid pointers errors forlinux 2.4.1
On Sun, 18 Mar 2001 06:29:50 -0500, Jeff Garzik <[EMAIL PROTECTED]> wrote: >Junfeng Yang wrote: >> Start ---> >> busy = kmalloc(sizeof(erase_busy_t), GFP_KERNEL); >> Error ---> > >This sizeof() construct may be a special case for your checker, but it's >a common one for the kernel... It definitely doesn't de-reference a >pointer. IMHO the above line is a bad construct. If the type of the variable changes it is extremely easy to miss the fact that *alloc is now returning the wrong size. I always do busy = kmalloc(sizeof(*busy), GFP_KERNEL); and let the compiler insert the correct type. For the checker, you can also have typeof(). kdb has this line typeof (*ef)local_ef; The type definition of ef is kdb_eframe_t which is "pointer to some arch dependent type" and local_ef is in arch independent code, much easier to do this than use multiple #ifdef. Of course it would have been even easier if kdb had separate types for the struct and the pointer to the struct, then I would not need typeof(). OTOH I am sure that somebody will find a use for typeof(). - 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] 28 potential interrupt errors
Junfeng Yang wrote: > [BUG] error path > > /u2/acc/oses/linux/2.4.1/drivers/net/appletalk/cops.c:776:cops_rx: >ERROR:INTR:763:804: Interrupts inconsistent, severity `20':804 Fixed. Request: can the checker check for skb's being freed correctly? The rules: If an skb is in interrupt context, call dev_kfree_skb_irq. If an skb might be in interrupt context, call dev_kfree_skb_any. If an skb is not in interrupt context, call dev_kfree_skb. I also found and fixed an error of this sort on cops.c as well. > [BUG] error path. this bug is interesting > > >/u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:2561:wavelan_get_wireless_stats: > ERROR:INTR:2528:2561: Interrupts inconsistent, severity `20':2561 > > /* Disable interrupts & save flags */ > Start ---> > spin_lock_irqsave (>lock, flags); > > if(lp == (net_local *) NULL) > return (iw_stats *) NULL; Fixed. I dunno WTF the programmer was thinking here... Your de-ref checker should have caught this too: check 'lp' for NULL after de-referencing lp->lock. > [BUG] error path > > /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/smctr.c:3655:smctr_open_tr: >ERROR:INTR:3594:3661: Interrupts inconsistent, severity `20':3661 Seems to be fixed already. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Mouse Problem in 2.4 Kernels - 2.2.18 Works Fine
On 17 Mar 2001 22:11:29 -0500, Pete Zaitcev wrote: > > From: Andree Leidenfrost ([EMAIL PROTECTED]) > > > I am experiencing problems with a USB mouse: The machine boots, X > > starts, I log on, everything works as expected. When I restart X or just > > change to an alpha terminal and back to x the mouse does not work any > > more. [...] > > Hardware is an ASUS K7V motherboard (VIA chip set), [...] > > T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 5 Spd=1.5 MxCh= 0 > > I am working on something similar. > After a device reset a hub drops PORT_CONNECTION > flag from wPortStatus. The reason is unknown. > > Unfortunately, I do not have a hardware that exibits this. > If would be invaluable someone enabled > dbg() in devices/usb/hub.c only, run the test with > BOTH working (2.2) and not working (2.4) kernels > then sent me dmesg. If you do, please tell me precisely what > you were doing to trip this. > > Here is an example of a change: > > --- linux-2.4.2-0.1.19/drivers/usb/hub.cTue Mar 13 12:04:05 2001 > +++ linux-2.4.2-0.1.19-p3/drivers/usb/hub.c Tue Mar 13 13:49:32 2001 > @@ -29,6 +29,10 @@ > > #include "hub.h" > > +/* P3 #23670 run01 */ > +#undef dbg > +#define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ": " format "\n" , ## arg) > + > /* Wakes up khubd */ > static spinlock_t hub_event_lock = SPIN_LOCK_UNLOCKED; > static DECLARE_MUTEX(usb_address0_sem); > > Example output of broken kernel: > > ub.c: enabling power on all ports > hub.c: port 1 connection change > hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s > hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s > hub.c: USB new device connect on bus1/1, assigned device number 2 > usb.c: USB device 2 (vend/prod 0x458/0x3) is not claimed by any active driver. > usb.c: registered new driver hid > input0: USB HID v1.00 Mouse [KYE Genius USB Wheel Mouse] on usb1:2.0 > mouse0: PS/2 mouse device for input0 > mice: PS/2 mouse device common for all mice > [ok, works, pulling the cable] > hub.c: port 1 connection change > hub.c: port 1, portstatus 100, change 3, 12 Mb/s > usb.c: USB disconnect on device 2 > hub.c: port 1 enable change, status 100 > [cable pulled, putting it back] > hub.c: port 1 connection change > hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s > hub.c: port 1, portstatus 100, change 0, 12 Mb/s > hub.c: port 1 of hub 1 not enabled, trying reset again... > hub.c: port 1, portstatus 100, change 0, 12 Mb/s > hub.c: port 1 of hub 1 not enabled, trying reset again... > hub.c: port 1, portstatus 100, change 0, 12 Mb/s > hub.c: port 1 of hub 1 not enabled, trying reset again... > hub.c: port 1, portstatus 100, change 0, 12 Mb/s > hub.c: port 1 of hub 1 not enabled, trying reset again... > hub.c: port 1, portstatus 100, change 0, 12 Mb/s > hub.c: port 1 of hub 1 not enabled, trying reset again... > hub.c: Cannot enable port 1 of hub 1, disabling port. > hub.c: Maybe the USB cable is bad? > > Now I need something like that for a working kernel > on the same hardware. > > I'll let folks know if I find anything. If anyone wants > to investigate in parallel, it would be appreciated too. > > -- Pete Here is the output of a 2.2.18 kernel with the above patch: Mar 18 22:40:18 aurich kernel: usb.c: usb_mouse driver claimed interface cdbc1960 Mar 18 22:40:26 aurich kernel: hub.c: port 3 connection change Mar 18 22:40:26 aurich kernel: hub.c: portstatus 100, change 1, 12 Mb/s Mar 18 22:40:26 aurich kernel: usb.c: USB disconnect on device 4 Mar 18 22:40:43 aurich kernel: hub.c: port 3 connection change Mar 18 22:40:43 aurich kernel: hub.c: portstatus 301, change 1, 1.5 Mb/s Mar 18 22:40:43 aurich kernel: hub.c: portstatus 303, change 10, 1.5 Mb/s Mar 18 22:40:43 aurich kernel: usb.c: USB new device connect, assigned device number 4 Mar 18 22:40:43 aurich kernel: usb.c: kmalloc IF cdbc19a0, numif 1 Mar 18 22:40:43 aurich kernel: usb.c: skipped 1 class/vendor specific interface descriptors Mar 18 22:40:43 aurich kernel: usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0 Mar 18 22:40:43 aurich kernel: usb.c: USB device number 4 default language ID 0x409 Mar 18 22:40:43 aurich kernel: Manufacturer: KYE Mar 18 22:40:43 aurich kernel: Product: Genius USB Wheel Mouse Mar 18 22:40:43 aurich kernel: mouse0: PS/2 mouse device for input0 Mar 18 22:40:43 aurich kernel: input0: KYE Genius USB Wheel Mouse on usb1:4.0 Mar 18 22:40:43 aurich kernel: usb.c: usb_mouse driver claimed interface cdbc19a0 [ok, works, pulling the cable] Mar 18 22:41:41 aurich kernel: hub.c: port 3 connection change Mar 18 22:41:41 aurich kernel: hub.c: portstatus 100, change 1, 12 Mb/s Mar 18 22:41:41 aurich kernel: usb.c: USB disconnect on device 4 [cable pulled, putting it back] Mar 18 22:41:53 aurich kernel: hub.c: port 3 connection change Mar 18 22:41:53 aurich kernel: hub.c: portstatus 301, change 1, 1.5 Mb/s Mar 18 22:41:54 aurich kernel: hub.c: portstatus 303,
Re: [CHECKER] 120 potential dereference to invalid pointers errors forlinux 2.4.1
Junfeng Yang wrote: > [BUG] dev_alloc_skb can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/3c505.c:619:receive_packet: ERROR:NULL:598:619: >Using NULL ptr "skb" illegally! set by 'dev_alloc_skb':598 Fixed. > [BUG] init_etherdev could return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/3c515.c:604:corkscrew_found_device: >ERROR:NULL:603:604: Using unknown ptr "dev" illegally! set by 'init_etherdev':603 > > Start ---> > dev = init_etherdev(dev, sizeof(struct corkscrew_private)); > Error ---> > dev->base_addr = ioaddr; > dev->irq = irq; init_etherdev is a special case -- It can conditionally take NULL as its first argument. If that is the case, when an allocation is performed, and the return val needed to be checked for NULL. If init_etherdev's first arg is guaranteed to be non-NULL, you do not need to check its return value. 3c515 is one such case. > [BUG] init_etherdev can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/aironet4500_card.c:537:awc4500_isa_probe: >ERROR:NULL:535:537: Using unknown ptr "dev" illegally! set by 'init_etherdev':535 Fixed. > [BUG] > /u2/acc/oses/linux/2.4.1/drivers/net/aironet4500_card.c:375:awc4500_pnp_probe: >ERROR:NULL:373:375: Using unknown ptr "dev" illegally! set by 'init_etherdev':373 Fixed. > [BUG] dev_alloc_skb can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/defxx.c:2719:dfx_rcv_init: >ERROR:NULL:2712:2719: Using unknown ptr "newskb" illegally! set by >'dev_alloc_skb':2712 Seems to be fixed already in my 2.4.3-pre4-based tree. > [BUG] kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/dgrs.c:1258:dgrs_found_device: >ERROR:NULL:1256:1258: Using unknown ptr "dev" illegally! set by 'kmalloc':1256 Seems to be fixed already in my 2.4.3-pre4-based tree. > [BUG] kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/dgrs.c:1297:dgrs_found_device: >ERROR:NULL:1294:1297: Using unknown ptr "devN" illegally! set by 'kmalloc':1294 Seems to be fixed already in my 2.4.3-pre4-based tree. > [BUG] kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/aironet4500_cs.c:181:awc_attach: >ERROR:NULL:179:181: Using unknown ptr "link" illegally! set by 'kmalloc':179 > > Start ---> > link = kmalloc(sizeof(struct dev_link_t), GFP_KERNEL); > memset(link, 0, sizeof(struct dev_link_t)); > Error ---> > link->dev = kmalloc(sizeof(struct dev_node_t), GFP_KERNEL); > memset(link->dev, 0, sizeof(struct dev_node_t)); Fixed. Your checker missed two other problems of the same sort in the same function... one of the two missed is the link->dev kmalloc you show in your example here. > [BUG] kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:4463:wavelan_attach: >ERROR:NULL:4458:4463: Using unknown ptr "dev" illegally! set by 'kmalloc':4458 Seems to be fixed already in my 2.4.3-pre4-based tree. > [BUG] kmalloc can return NULL > /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:4430:wavelan_attach: >ERROR:NULL:4426:4430: Using unknown ptr "link" illegally! set by 'kmalloc':4426 Seems to be fixed already in my 2.4.3-pre4-based tree. > [BUG] dev could be NULL, then init_etherdev -> init_netdev will alloc a new device >-- it could fail. > /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:559:tulip_probe1: >ERROR:NULL:522:559: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 Fixed, although this driver is going away when Arjan's Xircom driver matures. > [BUG] init_etherdev > /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:577:tulip_probe1: >ERROR:NULL:522:577: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 > [BUG] init_etherdev > /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:607:tulip_probe1: >ERROR:NULL:522:607: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 > [BUG] init_etherdev > /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:636:tulip_probe1: >ERROR:NULL:522:636: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 > [BUG] init_etherdev > /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:642:tulip_probe1: >ERROR:NULL:522:642: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 Fixed by the above fix. Is this a checker bug... or does the checker spit out each incorrect de-ref? > [BUG] function doesn't exit if skb == NULL. just printk > /u2/acc/oses/linux/2.4.1/drivers/net/smc9194.c:1356:smc_rcv: ERROR:NULL:1341:1356: >Using NULL ptr "skb" illegally! set by 'dev_alloc_skb':1341 Seems to be fixed already in my 2.4.3-pre4-based tree. > [BUG] init_etherdev can return NULL if dev is NULL > /u2/acc/oses/linux/2.4.1/drivers/net/sunhme.c:2838:happy_meal_pci_init: >ERROR:NULL:2806:2838: Using unknown ptr "dev" illegally! set by 'init_etherdev':2806 Fixed. > [BUG] dev could be NULL, then init_trdev will call init_netdev to allocate a new >device. >
Re: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Manfred Spraul wrote: > > The problem is that mmap_sem seems to be protecting the list > > of VMAs, so taking _only_ the page_table_lock could let a VMA > > change under us while a page fault is underway ... > > No, that can't happen. > VMA changes only happen if both the mmap_sem and the page table lock is > acquired. (check insert_vm() at the end of mm/mmap.c) > The page fault path uses the map_sem, kswaps uses page_table_lock. You're right here, I missed this "little detail"... > << from your patch: > --- linux-2.4.2-ac20-vm/mm/vmscan.c.orig Sat Mar 17 11:30:49 2001 > +++ linux-2.4.2-ac20-vm/mm/vmscan.c Sat Mar 17 20:53:10 2001 > @@ -231,6 +231,7 @@ >* Find the proper vm-area after freezing the vma chain >* and ptes. >*/ > + down_read(>mmap_sem); > spin_lock(>page_table_lock); > > > Why do you acquire the mmap semaphore in swapout_mm()? The old rule was > that kswapd should never sleep on the mmap semaphore. Isn't there a > deadlock if mmap sem is already acquired? I don't remember the details. You're right, kswapd shouldn't do this. I have this removed from my code right now... > > The problem is that mmap_sem seems to be protecting the list > > of VMAs, so taking _only_ the page_table_lock could let a VMA > > change under us while a page fault is underway ... > > I remember that the pmd_alloc() and pte_alloc() functions need > additional locking. Isn't this what the page_table_lock is for ? (too bad they're not using it...) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Mike Galbraith wrote: > I gave this patch a try, and the initial results are extremely encouraging. > Not only do I have vmstat (SCHED_RR) info in realtime with zero delays :)) > I also have a _nice_ throughput improvement. There are some worrisome > warnings below along with the compile changes I made here, but for an > initial patch, things look pretty darn wonderful. [snip compile fixes .. integrated] > VFS: Mounted root (ext2 filesystem) readonly. > Freeing unused kernel memory: 196k freed > Adding Swap: 265064k swap-space (priority 2) > VM: Bad swap entry 00011e00 > VM: Bad swap entry 00058d00 > Unused swap offset entry in swap_dup 00058d00 > Unused swap offset entry in swap_dup 00011e00 > VM: Bad swap entry 00011e00 > VM: Bad swap entry 00058d00 Heh, I guess do_swap_page isn't too happy when multiple threads of the same program take a page fault at the same address at the same time. I take it you were testing something like mysql, jvm or apache2 ? regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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: changing mm->mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Rik van Riel wrote: > On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: > > > Right, I'm not suggesting removing that: making the mmap_sem > > read/write is fine, but yes, we still need that semaphore. > > Initial patch (against 2.4.2-ac20) is available at > http://www.surriel.com/patches/ > > > But as for the "page faults would use an extra lock to protect against > > each other" bit --- we already have another lock, the page table lock, > > which can be used in this way, so ANOTHER lock should be unnecessary. > > Tomorrow I'll take a look at the various ->nopage > functions and do_swap_page to see if these functions > would be able to take simultaneous faults at the same > address (from multiple threads). If not, either we'll > need to modify these functions, or we could add a (few?) > extra lock to prevent these functions from faulting at > the same address at the same time in multiple threads. Hi Rik, I gave this patch a try, and the initial results are extremely encouraging. Not only do I have vmstat (SCHED_RR) info in realtime with zero delays :)) I also have a _nice_ throughput improvement. There are some worrisome warnings below along with the compile changes I made here, but for an initial patch, things look pretty darn wonderful. Cheers, -Mike --- ./include/linux/sched.h.org Sun Mar 18 10:20:42 2001 +++ ./include/linux/sched.h Sun Mar 18 10:27:48 2001 @@ -238,7 +238,7 @@ mm_users: ATOMIC_INIT(2), \ mm_count: ATOMIC_INIT(1), \ map_count: 1, \ - mmap_sem: __MUTEX_INITIALIZER(name.mmap_sem), \ + mmap_sem: __RWSEM_INITIALIZER(name.mmap_sem, RW_LOCK_BIAS), \ page_table_lock: SPIN_LOCK_UNLOCKED,\ mmlist: LIST_HEAD_INIT(name.mmlist),\ } --- ./include/linux/mm.h.orgSun Mar 18 09:56:55 2001 +++ ./include/linux/mm.hSun Mar 18 10:27:59 2001 @@ -533,13 +533,13 @@ if (vma->vm_end - address > current->rlim[RLIMIT_STACK].rlim_cur || ((vma->vm_mm->total_vm + grow) << PAGE_SHIFT) > current->rlim[RLIMIT_AS].rlim_cur) return -ENOMEM; - spin_lock(>page_table_lock); + spin_lock(>vm_mm->page_table_lock); vma->vm_start = address; vma->vm_pgoff -= grow; vma->vm_mm->total_vm += grow; if (vma->vm_flags & VM_LOCKED) vma->vm_mm->locked_vm += grow; - spin_unlock(>page_table_lock); + spin_unlock(>vm_mm->page_table_lock); return 0; } ... VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 196k freed Adding Swap: 265064k swap-space (priority 2) VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00058d00 Unused swap offset entry in swap_dup 00011e00 VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00058d00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00011e00 Unused swap offset entry in swap_dup 00058d00 VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00011e00 Unused swap offset entry in swap_dup 00058d00 VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 Unused swap offset entry in swap_dup 006ef700 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_count 00011e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 008f4e00 Unused swap offset entry in swap_dup 006ef700 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap
[PATCH] printk msglevel identification broken since 2.4.2ac13
Hi Andrew & Alan, I noticed that in 2.4.2ac20, all netfilter logs come to the console, whatever the log levels, and the beginning of the line is always prepended with '<4>'. I found in printk.c that a test is done for the length of the message to be strictly larger than 3 chars. But ipt_LOG uses 2 consecutive printk, one with only '<4>' and one with the message. It may be possible that other drivers to the same. Looking back in patches show this is present since 2.4.2ac13. This trivial patch allows a 3-char message to set the message level. Cheers, Willy ___ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com 2.4.2-ac20-printk-fix
Re: changing mm->mmap_sem (was: Re: system call for process information?)
> > The problem is that mmap_sem seems to be protecting the list > of VMAs, so taking _only_ the page_table_lock could let a VMA > change under us while a page fault is underway ... No, that can't happen. VMA changes only happen if both the mmap_sem and the page table lock is acquired. (check insert_vm() at the end of mm/mmap.c) The page fault path uses the map_sem, kswaps uses page_table_lock. << from your patch: --- linux-2.4.2-ac20-vm/mm/vmscan.c.origSat Mar 17 11:30:49 2001 +++ linux-2.4.2-ac20-vm/mm/vmscan.c Sat Mar 17 20:53:10 2001 @@ -231,6 +231,7 @@ * Find the proper vm-area after freezing the vma chain * and ptes. */ + down_read(>mmap_sem); spin_lock(>page_table_lock); Why do you acquire the mmap semaphore in swapout_mm()? The old rule was that kswapd should never sleep on the mmap semaphore. Isn't there a deadlock if mmap sem is already acquired? I don't remember the details. > > The problem is that mmap_sem seems to be protecting the list > of VMAs, so taking _only_ the page_table_lock could let a VMA > change under us while a page fault is underway ... I remember that the pmd_alloc() and pte_alloc() functions need additional locking. -- Manfred - 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] off-by-1 error in ide-probe (2.4.x)
There is a potentially serious bug in ide-probe.c in which max_sectors
is set to 256 instead of 255. I am surprised that this hasn't bit anyone
else yet. Perhaps because you need a disk that is slow in comparison to
the host in order for the queue to climb up to and then hit the 256, at
which point it then falls over.
For example, with an old 700MB Maxtor on a "fast" 486, VL-bus, PIO,
hdparm -c1 -m8 -u1, I could pretty much on demand generate the following
error by multiple builds, or by the final linking of any big project:
hdc: lost interrupt
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
(Note that nothing in the status is really an error). With the following
patch, everything works as it should & no errors even under high load.
Patch is against 2.4.3pre2.
Paul.
--- drivers/ide/ide-probe.c~Sat Mar 17 16:50:14 2001
+++ drivers/ide/ide-probe.c Sat Mar 17 16:58:33 2001
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/ide-probe.c Version 1.06June 9, 2000
+ * linux/drivers/ide/ide-probe.c Version 1.07March 18, 2001
*
* Copyright (C) 1994-1998 Linus Torvalds & authors (see below)
*/
@@ -25,6 +25,8 @@
* allowed for secondary flash card to be detectable
* with new flag : drive->ata_flash : 1;
* Version 1.06stream line request queue and prep for cascade project.
+ * Version 1.07max_sect <= 255; slower disks would get behind and
+ * then fall over when they get to 256.Paul G.
*/
#undef REALLY_SLOW_IO /* most systems can safely undef this */
@@ -772,10 +774,10 @@
for (unit = 0; unit < minors; ++unit) {
*bs++ = BLOCK_SIZE;
#ifdef CONFIG_BLK_DEV_PDC4030
- *max_sect++ = ((hwif->chipset == ide_pdc4030) ? 127 : 256);
+ *max_sect++ = ((hwif->chipset == ide_pdc4030) ? 127 : 255);
#else
/* IDE can do up to 128K per request. */
- *max_sect++ = 256;
+ *max_sect++ = 255;
#endif
*max_ra++ = MAX_READAHEAD;
}
-
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] blocking w/ spinlock or interrupt's disabled
>> enclosed are 163 potential bugs in 2.4.1 where blocking functions are > > called with either interrupts disabled or a spin lock held. The > > checker works by: > > Here's the file manifest. Apologies. > > drivers/atm/idt77105.c > [...] > drivers/char/cyclades.c Unortunately schedule() with disabled interrupts is a feature, it's needed for the old (deprecated and waiting for termination in 2.5) sleep_on() functions. Is it difficult to split it into "interrupts disabled" and "spin lock held"? -- Manfred - 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: changing mm-mmap_sem (was: Re: system call for process information?)
The problem is that mmap_sem seems to be protecting the list of VMAs, so taking _only_ the page_table_lock could let a VMA change under us while a page fault is underway ... No, that can't happen. VMA changes only happen if both the mmap_sem and the page table lock is acquired. (check insert_vm() at the end of mm/mmap.c) The page fault path uses the map_sem, kswaps uses page_table_lock. from your patch: --- linux-2.4.2-ac20-vm/mm/vmscan.c.origSat Mar 17 11:30:49 2001 +++ linux-2.4.2-ac20-vm/mm/vmscan.c Sat Mar 17 20:53:10 2001 @@ -231,6 +231,7 @@ * Find the proper vm-area after freezing the vma chain * and ptes. */ + down_read(mm-mmap_sem); spin_lock(mm-page_table_lock); Why do you acquire the mmap semaphore in swapout_mm()? The old rule was that kswapd should never sleep on the mmap semaphore. Isn't there a deadlock if mmap sem is already acquired? I don't remember the details. The problem is that mmap_sem seems to be protecting the list of VMAs, so taking _only_ the page_table_lock could let a VMA change under us while a page fault is underway ... I remember that the pmd_alloc() and pte_alloc() functions need additional locking. -- Manfred - 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] off-by-1 error in ide-probe (2.4.x)
There is a potentially serious bug in ide-probe.c in which max_sectors
is set to 256 instead of 255. I am surprised that this hasn't bit anyone
else yet. Perhaps because you need a disk that is slow in comparison to
the host in order for the queue to climb up to and then hit the 256, at
which point it then falls over.
For example, with an old 700MB Maxtor on a "fast" 486, VL-bus, PIO,
hdparm -c1 -m8 -u1, I could pretty much on demand generate the following
error by multiple builds, or by the final linking of any big project:
hdc: lost interrupt
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
user space sees binary cruft in source files, etc etc...
(Note that nothing in the status is really an error). With the following
patch, everything works as it should no errors even under high load.
Patch is against 2.4.3pre2.
Paul.
--- drivers/ide/ide-probe.c~Sat Mar 17 16:50:14 2001
+++ drivers/ide/ide-probe.c Sat Mar 17 16:58:33 2001
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/ide-probe.c Version 1.06June 9, 2000
+ * linux/drivers/ide/ide-probe.c Version 1.07March 18, 2001
*
* Copyright (C) 1994-1998 Linus Torvalds authors (see below)
*/
@@ -25,6 +25,8 @@
* allowed for secondary flash card to be detectable
* with new flag : drive-ata_flash : 1;
* Version 1.06stream line request queue and prep for cascade project.
+ * Version 1.07max_sect = 255; slower disks would get behind and
+ * then fall over when they get to 256.Paul G.
*/
#undef REALLY_SLOW_IO /* most systems can safely undef this */
@@ -772,10 +774,10 @@
for (unit = 0; unit minors; ++unit) {
*bs++ = BLOCK_SIZE;
#ifdef CONFIG_BLK_DEV_PDC4030
- *max_sect++ = ((hwif-chipset == ide_pdc4030) ? 127 : 256);
+ *max_sect++ = ((hwif-chipset == ide_pdc4030) ? 127 : 255);
#else
/* IDE can do up to 128K per request. */
- *max_sect++ = 256;
+ *max_sect++ = 255;
#endif
*max_ra++ = MAX_READAHEAD;
}
-
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] blocking w/ spinlock or interrupt's disabled
enclosed are 163 potential bugs in 2.4.1 where blocking functions are called with either interrupts disabled or a spin lock held. The checker works by: Here's the file manifest. Apologies. drivers/atm/idt77105.c [...] drivers/char/cyclades.c Unortunately schedule() with disabled interrupts is a feature, it's needed for the old (deprecated and waiting for termination in 2.5) sleep_on() functions. Is it difficult to split it into "interrupts disabled" and "spin lock held"? -- Manfred - 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] printk msglevel identification broken since 2.4.2ac13
Hi Andrew Alan, I noticed that in 2.4.2ac20, all netfilter logs come to the console, whatever the log levels, and the beginning of the line is always prepended with '4'. I found in printk.c that a test is done for the length of the message to be strictly larger than 3 chars. But ipt_LOG uses 2 consecutive printk, one with only '4' and one with the message. It may be possible that other drivers to the same. Looking back in patches show this is present since 2.4.2ac13. This trivial patch allows a 3-char message to set the message level. Cheers, Willy ___ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com 2.4.2-ac20-printk-fix
Re: changing mm-mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Rik van Riel wrote: On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: Right, I'm not suggesting removing that: making the mmap_sem read/write is fine, but yes, we still need that semaphore. Initial patch (against 2.4.2-ac20) is available at http://www.surriel.com/patches/ But as for the "page faults would use an extra lock to protect against each other" bit --- we already have another lock, the page table lock, which can be used in this way, so ANOTHER lock should be unnecessary. Tomorrow I'll take a look at the various -nopage functions and do_swap_page to see if these functions would be able to take simultaneous faults at the same address (from multiple threads). If not, either we'll need to modify these functions, or we could add a (few?) extra lock to prevent these functions from faulting at the same address at the same time in multiple threads. Hi Rik, I gave this patch a try, and the initial results are extremely encouraging. Not only do I have vmstat (SCHED_RR) info in realtime with zero delays :)) I also have a _nice_ throughput improvement. There are some worrisome warnings below along with the compile changes I made here, but for an initial patch, things look pretty darn wonderful. Cheers, -Mike --- ./include/linux/sched.h.org Sun Mar 18 10:20:42 2001 +++ ./include/linux/sched.h Sun Mar 18 10:27:48 2001 @@ -238,7 +238,7 @@ mm_users: ATOMIC_INIT(2), \ mm_count: ATOMIC_INIT(1), \ map_count: 1, \ - mmap_sem: __MUTEX_INITIALIZER(name.mmap_sem), \ + mmap_sem: __RWSEM_INITIALIZER(name.mmap_sem, RW_LOCK_BIAS), \ page_table_lock: SPIN_LOCK_UNLOCKED,\ mmlist: LIST_HEAD_INIT(name.mmlist),\ } --- ./include/linux/mm.h.orgSun Mar 18 09:56:55 2001 +++ ./include/linux/mm.hSun Mar 18 10:27:59 2001 @@ -533,13 +533,13 @@ if (vma-vm_end - address current-rlim[RLIMIT_STACK].rlim_cur || ((vma-vm_mm-total_vm + grow) PAGE_SHIFT) current-rlim[RLIMIT_AS].rlim_cur) return -ENOMEM; - spin_lock(mm-page_table_lock); + spin_lock(vma-vm_mm-page_table_lock); vma-vm_start = address; vma-vm_pgoff -= grow; vma-vm_mm-total_vm += grow; if (vma-vm_flags VM_LOCKED) vma-vm_mm-locked_vm += grow; - spin_unlock(mm-page_table_lock); + spin_unlock(vma-vm_mm-page_table_lock); return 0; } ... VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 196k freed Adding Swap: 265064k swap-space (priority 2) VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00058d00 Unused swap offset entry in swap_dup 00011e00 VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00058d00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00011e00 Unused swap offset entry in swap_dup 00058d00 VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00011e00 Unused swap offset entry in swap_dup 00058d00 VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 Unused swap offset entry in swap_dup 006ef700 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_count 00011e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 008f4e00 Unused swap offset entry in swap_dup 006ef700 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700 Unused swap offset entry in swap_dup 008f4e00 VM: Bad swap entry 006ef700 VM: Bad swap entry 008f4e00 Unused swap offset entry in swap_dup 006ef700
Re: changing mm-mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Mike Galbraith wrote: I gave this patch a try, and the initial results are extremely encouraging. Not only do I have vmstat (SCHED_RR) info in realtime with zero delays :)) I also have a _nice_ throughput improvement. There are some worrisome warnings below along with the compile changes I made here, but for an initial patch, things look pretty darn wonderful. [snip compile fixes .. integrated] VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 196k freed Adding Swap: 265064k swap-space (priority 2) VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00058d00 Unused swap offset entry in swap_dup 00011e00 VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Heh, I guess do_swap_page isn't too happy when multiple threads of the same program take a page fault at the same address at the same time. I take it you were testing something like mysql, jvm or apache2 ? regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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] 120 potential dereference to invalid pointers errors forlinux 2.4.1
Junfeng Yang wrote: [BUG] dev_alloc_skb can return NULL /u2/acc/oses/linux/2.4.1/drivers/net/3c505.c:619:receive_packet: ERROR:NULL:598:619: Using NULL ptr "skb" illegally! set by 'dev_alloc_skb':598 Fixed. [BUG] init_etherdev could return NULL /u2/acc/oses/linux/2.4.1/drivers/net/3c515.c:604:corkscrew_found_device: ERROR:NULL:603:604: Using unknown ptr "dev" illegally! set by 'init_etherdev':603 Start --- dev = init_etherdev(dev, sizeof(struct corkscrew_private)); Error --- dev-base_addr = ioaddr; dev-irq = irq; init_etherdev is a special case -- It can conditionally take NULL as its first argument. If that is the case, when an allocation is performed, and the return val needed to be checked for NULL. If init_etherdev's first arg is guaranteed to be non-NULL, you do not need to check its return value. 3c515 is one such case. [BUG] init_etherdev can return NULL /u2/acc/oses/linux/2.4.1/drivers/net/aironet4500_card.c:537:awc4500_isa_probe: ERROR:NULL:535:537: Using unknown ptr "dev" illegally! set by 'init_etherdev':535 Fixed. [BUG] /u2/acc/oses/linux/2.4.1/drivers/net/aironet4500_card.c:375:awc4500_pnp_probe: ERROR:NULL:373:375: Using unknown ptr "dev" illegally! set by 'init_etherdev':373 Fixed. [BUG] dev_alloc_skb can return NULL /u2/acc/oses/linux/2.4.1/drivers/net/defxx.c:2719:dfx_rcv_init: ERROR:NULL:2712:2719: Using unknown ptr "newskb" illegally! set by 'dev_alloc_skb':2712 Seems to be fixed already in my 2.4.3-pre4-based tree. [BUG] kmalloc can return NULL /u2/acc/oses/linux/2.4.1/drivers/net/dgrs.c:1258:dgrs_found_device: ERROR:NULL:1256:1258: Using unknown ptr "dev" illegally! set by 'kmalloc':1256 Seems to be fixed already in my 2.4.3-pre4-based tree. [BUG] kmalloc can return NULL /u2/acc/oses/linux/2.4.1/drivers/net/dgrs.c:1297:dgrs_found_device: ERROR:NULL:1294:1297: Using unknown ptr "devN" illegally! set by 'kmalloc':1294 Seems to be fixed already in my 2.4.3-pre4-based tree. [BUG] kmalloc can return NULL /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/aironet4500_cs.c:181:awc_attach: ERROR:NULL:179:181: Using unknown ptr "link" illegally! set by 'kmalloc':179 Start --- link = kmalloc(sizeof(struct dev_link_t), GFP_KERNEL); memset(link, 0, sizeof(struct dev_link_t)); Error --- link-dev = kmalloc(sizeof(struct dev_node_t), GFP_KERNEL); memset(link-dev, 0, sizeof(struct dev_node_t)); Fixed. Your checker missed two other problems of the same sort in the same function... one of the two missed is the link-dev kmalloc you show in your example here. [BUG] kmalloc can return NULL /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:4463:wavelan_attach: ERROR:NULL:4458:4463: Using unknown ptr "dev" illegally! set by 'kmalloc':4458 Seems to be fixed already in my 2.4.3-pre4-based tree. [BUG] kmalloc can return NULL /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:4430:wavelan_attach: ERROR:NULL:4426:4430: Using unknown ptr "link" illegally! set by 'kmalloc':4426 Seems to be fixed already in my 2.4.3-pre4-based tree. [BUG] dev could be NULL, then init_etherdev - init_netdev will alloc a new device -- it could fail. /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:559:tulip_probe1: ERROR:NULL:522:559: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 Fixed, although this driver is going away when Arjan's Xircom driver matures. [BUG] init_etherdev /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:577:tulip_probe1: ERROR:NULL:522:577: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 [BUG] init_etherdev /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:607:tulip_probe1: ERROR:NULL:522:607: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 [BUG] init_etherdev /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:636:tulip_probe1: ERROR:NULL:522:636: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 [BUG] init_etherdev /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/xircom_tulip_cb.c:642:tulip_probe1: ERROR:NULL:522:642: Using unknown ptr "dev" illegally! set by 'init_etherdev':522 Fixed by the above fix. Is this a checker bug... or does the checker spit out each incorrect de-ref? [BUG] function doesn't exit if skb == NULL. just printk /u2/acc/oses/linux/2.4.1/drivers/net/smc9194.c:1356:smc_rcv: ERROR:NULL:1341:1356: Using NULL ptr "skb" illegally! set by 'dev_alloc_skb':1341 Seems to be fixed already in my 2.4.3-pre4-based tree. [BUG] init_etherdev can return NULL if dev is NULL /u2/acc/oses/linux/2.4.1/drivers/net/sunhme.c:2838:happy_meal_pci_init: ERROR:NULL:2806:2838: Using unknown ptr "dev" illegally! set by 'init_etherdev':2806 Fixed. [BUG] dev could be NULL, then init_trdev will call init_netdev to allocate a new device. /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/ibmtr.c:405:ibmtr_probe1: ERROR:NULL:304:405: Using unknown ptr
Re: [CHECKER] 28 potential interrupt errors
Junfeng Yang wrote: [BUG] error path /u2/acc/oses/linux/2.4.1/drivers/net/appletalk/cops.c:776:cops_rx: ERROR:INTR:763:804: Interrupts inconsistent, severity `20':804 Fixed. Request: can the checker check for skb's being freed correctly? The rules: If an skb is in interrupt context, call dev_kfree_skb_irq. If an skb might be in interrupt context, call dev_kfree_skb_any. If an skb is not in interrupt context, call dev_kfree_skb. I also found and fixed an error of this sort on cops.c as well. [BUG] error path. this bug is interesting /u2/acc/oses/linux/2.4.1/drivers/net/pcmcia/wavelan_cs.c:2561:wavelan_get_wireless_stats: ERROR:INTR:2528:2561: Interrupts inconsistent, severity `20':2561 /* Disable interrupts save flags */ Start --- spin_lock_irqsave (lp-lock, flags); if(lp == (net_local *) NULL) return (iw_stats *) NULL; Fixed. I dunno WTF the programmer was thinking here... Your de-ref checker should have caught this too: check 'lp' for NULL after de-referencing lp-lock. [BUG] error path /u2/acc/oses/linux/2.4.1/drivers/net/tokenring/smctr.c:3655:smctr_open_tr: ERROR:INTR:3594:3661: Interrupts inconsistent, severity `20':3661 Seems to be fixed already. -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: USB Mouse Problem in 2.4 Kernels - 2.2.18 Works Fine
On 17 Mar 2001 22:11:29 -0500, Pete Zaitcev wrote: From: Andree Leidenfrost ([EMAIL PROTECTED]) I am experiencing problems with a USB mouse: The machine boots, X starts, I log on, everything works as expected. When I restart X or just change to an alpha terminal and back to x the mouse does not work any more. [...] Hardware is an ASUS K7V motherboard (VIA chip set), [...] T: Bus=01 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 5 Spd=1.5 MxCh= 0 I am working on something similar. After a device reset a hub drops PORT_CONNECTION flag from wPortStatus. The reason is unknown. Unfortunately, I do not have a hardware that exibits this. If would be invaluable someone enabled dbg() in devices/usb/hub.c only, run the test with BOTH working (2.2) and not working (2.4) kernels then sent me dmesg. If you do, please tell me precisely what you were doing to trip this. Here is an example of a change: --- linux-2.4.2-0.1.19/drivers/usb/hub.cTue Mar 13 12:04:05 2001 +++ linux-2.4.2-0.1.19-p3/drivers/usb/hub.c Tue Mar 13 13:49:32 2001 @@ -29,6 +29,10 @@ #include "hub.h" +/* P3 #23670 run01 */ +#undef dbg +#define dbg(format, arg...) printk(KERN_DEBUG __FILE__ ": " format "\n" , ## arg) + /* Wakes up khubd */ static spinlock_t hub_event_lock = SPIN_LOCK_UNLOCKED; static DECLARE_MUTEX(usb_address0_sem); Example output of broken kernel: ub.c: enabling power on all ports hub.c: port 1 connection change hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s hub.c: USB new device connect on bus1/1, assigned device number 2 usb.c: USB device 2 (vend/prod 0x458/0x3) is not claimed by any active driver. usb.c: registered new driver hid input0: USB HID v1.00 Mouse [KYE Genius USB Wheel Mouse] on usb1:2.0 mouse0: PS/2 mouse device for input0 mice: PS/2 mouse device common for all mice [ok, works, pulling the cable] hub.c: port 1 connection change hub.c: port 1, portstatus 100, change 3, 12 Mb/s usb.c: USB disconnect on device 2 hub.c: port 1 enable change, status 100 [cable pulled, putting it back] hub.c: port 1 connection change hub.c: port 1, portstatus 301, change 1, 1.5 Mb/s hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: port 1, portstatus 100, change 0, 12 Mb/s hub.c: port 1 of hub 1 not enabled, trying reset again... hub.c: Cannot enable port 1 of hub 1, disabling port. hub.c: Maybe the USB cable is bad? Now I need something like that for a working kernel on the same hardware. I'll let folks know if I find anything. If anyone wants to investigate in parallel, it would be appreciated too. -- Pete Here is the output of a 2.2.18 kernel with the above patch: Mar 18 22:40:18 aurich kernel: usb.c: usb_mouse driver claimed interface cdbc1960 Mar 18 22:40:26 aurich kernel: hub.c: port 3 connection change Mar 18 22:40:26 aurich kernel: hub.c: portstatus 100, change 1, 12 Mb/s Mar 18 22:40:26 aurich kernel: usb.c: USB disconnect on device 4 Mar 18 22:40:43 aurich kernel: hub.c: port 3 connection change Mar 18 22:40:43 aurich kernel: hub.c: portstatus 301, change 1, 1.5 Mb/s Mar 18 22:40:43 aurich kernel: hub.c: portstatus 303, change 10, 1.5 Mb/s Mar 18 22:40:43 aurich kernel: usb.c: USB new device connect, assigned device number 4 Mar 18 22:40:43 aurich kernel: usb.c: kmalloc IF cdbc19a0, numif 1 Mar 18 22:40:43 aurich kernel: usb.c: skipped 1 class/vendor specific interface descriptors Mar 18 22:40:43 aurich kernel: usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0 Mar 18 22:40:43 aurich kernel: usb.c: USB device number 4 default language ID 0x409 Mar 18 22:40:43 aurich kernel: Manufacturer: KYE Mar 18 22:40:43 aurich kernel: Product: Genius USB Wheel Mouse Mar 18 22:40:43 aurich kernel: mouse0: PS/2 mouse device for input0 Mar 18 22:40:43 aurich kernel: input0: KYE Genius USB Wheel Mouse on usb1:4.0 Mar 18 22:40:43 aurich kernel: usb.c: usb_mouse driver claimed interface cdbc19a0 [ok, works, pulling the cable] Mar 18 22:41:41 aurich kernel: hub.c: port 3 connection change Mar 18 22:41:41 aurich kernel: hub.c: portstatus 100, change 1, 12 Mb/s Mar 18 22:41:41 aurich kernel: usb.c: USB disconnect on device 4 [cable pulled, putting it back] Mar 18 22:41:53 aurich kernel: hub.c: port 3 connection change Mar 18 22:41:53 aurich kernel: hub.c: portstatus 301, change 1, 1.5 Mb/s Mar 18 22:41:54 aurich kernel: hub.c: portstatus 303, change 10, 1.5 Mb/s Mar 18 22:41:54 aurich kernel: usb.c: USB new device connect,
Re: [CHECKER] 120 potential dereference to invalid pointers errors forlinux 2.4.1
On Sun, 18 Mar 2001 06:29:50 -0500, Jeff Garzik [EMAIL PROTECTED] wrote: Junfeng Yang wrote: Start --- busy = kmalloc(sizeof(erase_busy_t), GFP_KERNEL); Error --- This sizeof() construct may be a special case for your checker, but it's a common one for the kernel... It definitely doesn't de-reference a pointer. IMHO the above line is a bad construct. If the type of the variable changes it is extremely easy to miss the fact that *alloc is now returning the wrong size. I always do busy = kmalloc(sizeof(*busy), GFP_KERNEL); and let the compiler insert the correct type. For the checker, you can also have typeof(). kdb has this line typeof (*ef)local_ef; The type definition of ef is kdb_eframe_t which is "pointer to some arch dependent type" and local_ef is in arch independent code, much easier to do this than use multiple #ifdef. Of course it would have been even easier if kdb had separate types for the struct and the pointer to the struct, then I would not need typeof(). OTOH I am sure that somebody will find a use for typeof(). - 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: changing mm-mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Rik van Riel wrote: VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 196k freed Adding Swap: 265064k swap-space (priority 2) VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00058d00 Unused swap offset entry in swap_dup 00011e00 VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Heh, I guess do_swap_page isn't too happy when multiple threads of the same program take a page fault at the same address at the same time. I take it you were testing something like mysql, jvm or apache2 ? No, this was make -j30 bzImage. (nscd was running though...) -Mike - 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] 28 potential interrupt errors
On Sun, 18 Mar 2001, Andrew Morton wrote:
There's another thing which needs doing to n_r3964.c, BTW - the
abuse of task queues in r3964_close(). This is, I think, the
only client of task queues which needs to poke so deeply into
the implementation internals and Linus has mentioned something about
needing to redesign the task queues in 2.5. So n_r3964 needs
somehow to be redesigned so that it can use standard APIs.
Hmmm. That particular piece of ugliness seems to have been particularly
gratuitous. We had two task queues, each of which would decrement a
countdown value, calling on_timeout() if it reached zero, and stick the
other on the tq_timer list.
Is there anyone out there that can test this and save me the trouble of
trying to remember how to drive it?
Index: drivers/char/n_r3964.c
===
RCS file: /inst/cvs/linux/drivers/char/Attic/n_r3964.c,v
retrieving revision 1.1.2.7
diff -u -r1.1.2.7 n_r3964.c
--- drivers/char/n_r3964.c 2001/02/24 19:01:19 1.1.2.7
+++ drivers/char/n_r3964.c 2001/03/18 13:02:49
@@ -13,6 +13,12 @@
* L. Haag
*
* $Log: n_r3964.c,v $
+ * Revision 1.10 2001/03/18 13:02:24 dwmw2
+ * Fix timer usage, use spinlocks properly.
+ *
+ * Revision 1.9 2001/03/18 12:52:14 dwmw2
+ * Merge changes in 2.4.2
+ *
* Revision 1.8 2000/03/23 14:14:54 dwmw2
* Fix race in sleeping in r3964_read()
*
@@ -110,8 +116,6 @@
#define TRACE_Q(fmt, arg...) /**/
#endif
-static void on_timer_1(void*);
-static void on_timer_2(void*);
static void add_tx_queue(struct r3964_info *, struct r3964_block_header *);
static void remove_from_tx_queue(struct r3964_info *pInfo, int error_code);
static void put_char(struct r3964_info *pInfo, unsigned char ch);
@@ -120,7 +124,7 @@
static void transmit_block(struct r3964_info *pInfo);
static void receive_char(struct r3964_info *pInfo, const unsigned char c);
static void receive_error(struct r3964_info *pInfo, const char flag);
-static void on_timeout(struct r3964_info *pInfo);
+static void on_timeout(unsigned long priv);
static int enable_signals(struct r3964_info *pInfo, pid_t pid, int arg);
static int read_telegram(struct r3964_info *pInfo, pid_t pid, unsigned char *buf);
static void add_msg(struct r3964_client_info *pClient, int msg_id, int arg,
@@ -217,7 +221,7 @@
{
int status;
- printk ("r3964: Philips r3964 Driver $Revision: 1.8 $\n");
+ printk ("r3964: Philips r3964 Driver $Revision: 1.10 $\n");
/*
* Register the tty line discipline
@@ -247,40 +251,11 @@
* Protocol implementation routines
*/
-static void on_timer_1(void *arg)
-{
- struct r3964_info *pInfo = (struct r3964_info *)arg;
-
- if(pInfo-count_down)
- {
- if(!--pInfo-count_down)
- {
- on_timeout(pInfo);
- }
- }
- queue_task(pInfo-bh_2, tq_timer);
-}
-
-static void on_timer_2(void *arg)
-{
- struct r3964_info *pInfo = (struct r3964_info *)arg;
-
- if(pInfo-count_down)
- {
- if(!--pInfo-count_down)
- {
- on_timeout(pInfo);
- }
- }
- queue_task(pInfo-bh_1, tq_timer);
-}
-
static void add_tx_queue(struct r3964_info *pInfo, struct r3964_block_header *pHeader)
{
unsigned long flags;
- save_flags(flags);
- cli();
+ spin_lock_irqsave(pInfo-lock, flags);
pHeader-next = NULL;
@@ -294,7 +269,7 @@
pInfo-tx_last = pHeader;
}
- restore_flags(flags);
+ spin_unlock_irqrestore(pInfo-lock, flags);
TRACE_Q("add_tx_queue %x, length %d, tx_first = %x",
(int)pHeader, pHeader-length, (int)pInfo-tx_first );
@@ -337,8 +312,7 @@
wake_up_interruptible (pInfo-read_wait);
}
- save_flags(flags);
- cli();
+ spin_lock_irqsave(pInfo-lock, flags);
pInfo-tx_first = pHeader-next;
if(pInfo-tx_first==NULL)
@@ -346,7 +320,7 @@
pInfo-tx_last = NULL;
}
- restore_flags(flags);
+ spin_unlock_irqrestore(pInfo-lock, flags);
kfree(pHeader);
TRACE_M("remove_from_tx_queue - kfree %x",(int)pHeader);
@@ -359,8 +333,7 @@
{
unsigned long flags;
- save_flags(flags);
- cli();
+ spin_lock_irqsave(pInfo-lock, flags);
pHeader-next = NULL;
@@ -375,7 +348,7 @@
}
pInfo-blocks_in_rx_queue++;
- restore_flags(flags);
+ spin_unlock_irqrestore(pInfo-lock, flags);
TRACE_Q("add_rx_queue: %x, length = %d, rx_first = %x, count = %d",
(int)pHeader, pHeader-length,
@@ -396,8 +369,7 @@
TRACE_Q("remove_from_rx_queue: %x, length %d",
(int)pHeader, (int)pHeader-length );
- save_flags(flags);
- cli();
+ spin_lock_irqsave(pInfo-lock, flags);
if(pInfo-rx_first == pHeader)
{
@@ -430,7 +402,7 @@
}
}
- restore_flags(flags);
+ spin_unlock_irqrestore(pInfo-lock, flags);
kfree(pHeader);
TRACE_M("remove_from_rx_queue - kfree %x",(int)pHeader);
@@ -471,17 +443,16 @@
unsigned long flags;
Upgrading to 2.2.19pre to fix do_try_to_free_pages bug
Hi all, I've been running into the do_try_to_free_pages problem on a server running 2.2.18 and I just wish I'd looked at the list earlier to see if it was a known bug. (And I'm relieved that it is a known bug, I'm just surprised that I hadn't hit it earlier!) Now that I know there's a fix in 2.2.19pre*, I need to upgrade. Since I have limited opportunities to reboot (this is a Samba server for student labs, and the coming week is the last week of term with everyone working on their assignments), I need to be reasonably sure that 2.2.19pre17 doesn't have any known showstopper bugs. So, does anyone have any comments on whether or not 2.2.19pre17 is a good move, or should I be looking at an earlier 2.2.19pre? This is a dual PIII/600E, with a Mylex RAID controller, one 3c905B NIC, an on-board Intel EEPro 100 interface, ext2 filesystems and disk quotas. Thanks in advance for comments. Martin -- Martin Radford | "Only wimps use tape backup: _real_ [EMAIL PROTECTED] | men just upload their important stuff -o) Registered Linux user #9257 | on ftp and let the rest of the world /\\ - see http://counter.li.org | mirror it ;)" - Linus Torvalds _\_V - 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] 2.4.2-ac20
hi, i got this oops followed by a freeze aris Gnu C egcs-2.91.66 Gnu make 3.79 binutils 2.9.1.0.25 util-linux 2.10l modutils 2.4.1 e2fsprogs 1.18 pcmcia-cs 3.1.16 Linux C Library2.1.3 ldd: version 1.9.9 Procps 2.0.6 Net-tools 1.55 Kbd0.99 Sh-utils 2.0 Modules Loaded serial isa-pnp nsc-ircc irda apm vfat fat eepro100 esssolo1 ksymoops 2.3.7 on i686 2.4.2-ac20. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.2-ac20/ (default) -m /boot/System.map.2.4.2.ac20 (specified) CPU:0 EIP:0010:[c011645b] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010213 eax: ebx: c290270c ecx: c28f2000 edx: 0015 esi: c28f2000 edi: 0246 ebp: c28f236c esp: 0022be64 Process swapper (pid: 0, stackpage=c021b000) Stack: c01770b4 c28f2020 c016ad00 c28f2000 c28f2768 c28f2368 c28f2568 c021bfa4 c0181d00 c1121d00 20181834 c28f276c 0001 0008 3286 c10ccd84 c10ccd84 c021bedc 0082 c10ccd58 c10ccd80 Call Trace: [c01770b4] [c016ad00] [c0181d00] [c016dfa8] [c016933b] [c0119c60] [c011c0ee] [c0119b7f] [c0119ac0] [c01199ca] [c010a175] [c0107160] [c0108e50] [c0107160] [c0107160] [c0100018] [c0107180] [c01071e2] [c0105000] [c0100192] Code: 0f 0b b9 80 a5 20 c0 ff 0d 80 a5 20 c0 0f 88 6e 76 0c 00 c7 EIP; c011645b acquire_console_sem+f/30 = Trace; c01770b4 con_flush_chars+10/24 Trace; c0119c60 __run_task_queue+50/60 Trace; c011c0ee tqueue_bh+16/1c Trace; c0119b7f bh_action+1b/64 Trace; c0119ac0 tasklet_hi_action+38/5c Trace; c01199ca do_softirq+4a/6c Trace; c010a175 do_IRQ+a1/b4 Trace; c0107160 default_idle+0/28 Trace; c0108e50 ret_from_intr+0/20 Trace; c0107160 default_idle+0/28 Trace; c0107160 default_idle+0/28 Trace; c0100018 startup_32+18/13a Trace; c0107180 default_idle+20/28 Trace; c01071e2 cpu_idle+3a/50 Trace; c0105000 empty_bad_page+0/1000 Trace; c0100192 L6+0/2 Code; c011645b acquire_console_sem+f/30 _EIP: Code; c011645b acquire_console_sem+f/30 = 0: 0f 0b ud2a = Code; c011645d acquire_console_sem+11/30 2: b9 80 a5 20 c0movl $0xc020a580,%ecx Code; c0116462 acquire_console_sem+16/30 7: ff 0d 80 a5 20 c0 decl 0xc020a580 Code; c0116468 acquire_console_sem+1c/30 d: 0f 88 6e 76 0c 00 js c7681 _EIP+0xc7681 c01ddadc stext_lock+18c/10e4 Code; c011646e acquire_console_sem+22/30 13: c7 00 00 00 00 00 movl $0x0,(%eax)
floppy programming
Hi, some body know if exist or is possible to do one driver to makes floppy drive use some type of "balanced" bits distribution? The idea is simple: format a disk doing inner tracks with less bits than in external tracks. Maybe is better think in sectors and not bits banlancing? I want opinions about the idea, pleace. Where can I find information about floppy drivers programming, DMA setup,...? Thanks, Leandro __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. 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/
Re: [CHECKER] big stack variables
[EMAIL PROTECTED] said: ObUML (again): Any estimated time of submission to Linus?! Is this an early v2.5-thing, or are the changes minor enough to the rest of the tree to allow for an v2.4-merge? There are almost no changes to the rest of the tree, and none of those affect any of the other arches, so it's an early 2.4 thing. The reason I've waiting this long to put it in is that UML is not a normal port. With the other ports, few enough people have the relevant hardware that if the port isn't all that great at submission time, not many people will be affected. With UML, the vast majority of Linux users (the i386-using ones) have the relevant platform (we could get a lot closer to 100% if owners of non-i386 boxes would port UML to them, hint, hint :-). I expect that getting it into the pool will be considered something of a stamp of approval for UML, so a lot more people will start using it. If it sucks, it will affect a large number of people, word will get around that it sucks, and lots of people won't give it a second chance. So, my goal for UML when it's submitted is that it make a solid, stable, UP virtual machine. You can see a measure of my progress by my TODO list, which I post to my devel list occasionally. The most recent one is at http://www.geocrawler.com/lists/3/SourceForge/709/25/5339352/ After the 2.4 submission, I'm going to start working on some more radical things, like SMP emulation, clustering, and artifical environments. 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: changing mm-mmap_sem (was: Re: system call for processinformation?)
On Sun, 18 Mar 2001, Mike Galbraith wrote: No, this was make -j30 bzImage. (nscd was running though...) I rebooted, shut down nscd prior to testing and did 5 builds in a row without a single gripe. Started nscd for sixth run and instantly the kernel griped. Yup.. threaded apps pushing swap. OK, I'll write some code to prevent multiple threads from stepping all over each other when they pagefault at the same address. What would be the preferred method of fixing this ? - fixing do_swap_page and all -nopage functions - hacking handle_mm_fault to make sure no overlapping pagefaults will be served at the same time regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com.br/ - 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/
UDMA 100 / PIIX4 question
Hi, This question is much the same as one I posted a couple of months ago, at which time I was using the stock 2.2.18 kernel supplied with my SuSE distro. Some people suggested that I should upgrade, and since then I have been learning my way around kernel compilation and following this list. I am now running 2.4.2, but my problem remains, so I thought I might reasonably ask again. I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller. The drive is properly cabled and correctly recognised. I have, I think, set the right options in my kernel config (I have quoted the relevant part below). Lilo.conf includes append="ide0=ata66. Boot.msg includes: 4PIIX4: chipset revision 1 4PIIX4: not 100% native mode: will probe irqs later 4PIIX4: ATA-66/100 forced bit set (WARNING)!! 4ide0: BM-DMA at 0xa800-0xa807, BIOS settings: hda:DMA, hdb:pio 4ide1: BM-DMA at 0xa808-0xa80f, BIOS settings: hdc:DMA, hdd:pio 4hda: IBM-DTLA-307030, ATA DISK drive snip ... 6hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100) According to hdparm -i the drive thinks that it is in UDMA mode 5. My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec. I achieve this when DMA is enabled, - without it I fall back to about 5 Mb /sec. No amount of fiddling with other hdparm settings makes any difference. I do appreciate that there are some issues involving higher UDMA rates and certain hardware. I have read a number of relevant posts, including those passing between Linus, Andre Hedrick, Alan Cox and others on the subject last January, but I cannot understand from what I have read whether or not my particular configuration (in particular the PIIX4),is subject to these problems - or if I am simply screwed up. TIA, Geoff CONFIG_BLK_DEV_IDEDISK=y # CONFIG_IDEDISK_MULTI_MODE is not set # CONFIG_BLK_DEV_IDEDISK_VENDOR is not set # CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set # CONFIG_BLK_DEV_IDEDISK_IBM is not set # CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set # CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set # CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set # CONFIG_BLK_DEV_IDEDISK_WD is not set # CONFIG_BLK_DEV_COMMERIAL is not set # CONFIG_BLK_DEV_TIVO is not set # CONFIG_BLK_DEV_IDECS is not set CONFIG_BLK_DEV_IDECD=y # CONFIG_BLK_DEV_IDETAPE is not set # CONFIG_BLK_DEV_IDEFLOPPY is not set # CONFIG_BLK_DEV_IDESCSI is not set # CONFIG_BLK_DEV_CMD640 is not set # CONFIG_BLK_DEV_CMD640_ENHANCED is not set # CONFIG_BLK_DEV_ISAPNP is not set CONFIG_BLK_DEV_RZ1000=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_IDEPCI_SHARE_IRQ=y CONFIG_BLK_DEV_IDEDMA_PCI=y # CONFIG_BLK_DEV_OFFBOARD is not set CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y # CONFIG_IDEDMA_PCI_WIP is not set # CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_AEC62XX_TUNING is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_WDC_ALI15X3 is not set # CONFIG_BLK_DEV_AMD7409 is not set # CONFIG_AMD7409_OVERRIDE is not set # CONFIG_BLK_DEV_CMD64X is not set # CONFIG_BLK_DEV_CY82C693 is not set # CONFIG_BLK_DEV_CS5530 is not set # CONFIG_BLK_DEV_HPT34X is not set # CONFIG_HPT34X_AUTODMA is not set # CONFIG_BLK_DEV_HPT366 is not set CONFIG_BLK_DEV_PIIX=y CONFIG_PIIX_TUNING=y # CONFIG_BLK_DEV_NS87415 is not set # CONFIG_BLK_DEV_OPTI621 is not set # CONFIG_BLK_DEV_PDC202XX is not set # CONFIG_PDC202XX_BURST is not set # CONFIG_BLK_DEV_OSB4 is not set # CONFIG_BLK_DEV_SIS5513 is not set # CONFIG_BLK_DEV_SLC90E66 is not set # CONFIG_BLK_DEV_TRM290 is not set # CONFIG_BLK_DEV_VIA82CXXX is not set # CONFIG_IDE_CHIPSETS is not set CONFIG_IDEDMA_AUTO=y CONFIG_IDEDMA_IVB=y # CONFIG_DMA_NONPCI is not set CONFIG_BLK_DEV_IDE_MODES=y _ Do You Yahoo!? Get your free @yahoo.com address at http://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/
[OT] man-pages-1.35 released
A moment ago I put man-pages-1.35 the usual places (e.g. on ftp://ftp.win.tue.nl/pub/linux-local/manpages). David Mosberger expressed his worry that especially man page Section 2 is out-dated and x86 specific, with no indication that other architectures even exist. No doubt he is right. So, request to all: (i) point out which man pages are outdated or missing, and if possible (ii) supply patches or entirely new pages. Send contributions to [EMAIL PROTECTED], not (only) to some mailing list or bug list. 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/
pselect
For people who prefer programming above documenting, here is a simple small thing to do: POSIX.1g and Austin document a pselect() call intended to remove the race condition that is present when one wants to wait on either a signal or some file descriptor. (See also Stevens, Unix Network Programming, Volume 1, 2nd Ed., 1998, p. 168 and the pselect.2 man page released today.) Glibc 2.0 has a bad version (wrong number of parameters) and glibc 2.1 a better version, but the whole purpose of pselect is to avoid the race, and glibc cannot do that, one needs kernel support. So, probably someone should make a system call pselect almost identical to the present select, adding a sigmask parameter. (Or something more general.) 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: [CHECKER] 28 potential interrupt errors
On Sun, 18 Mar 2001, Andrew Morton wrote:
I'm planning on poking through everything which has been
identified as a posible problem. But I won't start for
several weeks - give the maintainers (if any) time to
address these things.
I took a look at the ISDN issues, here's a patch which should fix most of
it (sleeping in IRQ, and unchecked user access still missing).
I'ld appreciate it if somebody felt like looking through it. The patch is
against current CVS, but applies against current 2.4.3-pre.
--Kai
diff -ur isdn-HEAD/drivers/isdn/avmb1/capi.c isdn-h/drivers/isdn/avmb1/capi.c
--- isdn-HEAD/drivers/isdn/avmb1/capi.c Thu Mar 15 22:19:21 2001
+++ isdn-h/drivers/isdn/avmb1/capi.cSat Mar 17 18:21:23 2001
@@ -1082,6 +1082,8 @@
return -ENODEV;
skb = alloc_skb(count, GFP_USER);
+ if (!skb)
+ return -ENOMEM;
if ((retval = copy_from_user(skb_put(skb, count), buf, count))) {
kfree_skb(skb);
@@ -1501,6 +1503,8 @@
return -EINVAL;
skb = alloc_skb(CAPI_DATA_B3_REQ_LEN+count, GFP_USER);
+ if (!skb)
+ return -ENOMEM;
skb_reserve(skb, CAPI_DATA_B3_REQ_LEN);
if ((retval = copy_from_user(skb_put(skb, count), buf, count))) {
Only in isdn-h/drivers/isdn/avmb1: capi.c%
diff -ur isdn-HEAD/drivers/isdn/avmb1/capidrv.c isdn-h/drivers/isdn/avmb1/capidrv.c
--- isdn-HEAD/drivers/isdn/avmb1/capidrv.c Thu Mar 15 17:05:56 2001
+++ isdn-h/drivers/isdn/avmb1/capidrv.c Sat Mar 17 18:23:33 2001
@@ -2065,8 +2065,8 @@
__u16 datahandle;
if (!card) {
- printk(KERN_ERR "capidrv-%d: if_sendbuf called with invalid driverId
%d!\n",
- card-contrnr, id);
+ printk(KERN_ERR "capidrv: if_sendbuf called with invalid driverId
+%d!\n",
+ id);
return 0;
}
if (debugmode 1)
@@ -2137,8 +2137,8 @@
__u8 *p;
if (!card) {
- printk(KERN_ERR "capidrv-%d: if_readstat called with invalid driverId
%d!\n",
- card-contrnr, id);
+ printk(KERN_ERR "capidrv: if_readstat called with invalid driverId
+%d!\n",
+ id);
return -ENODEV;
}
Only in isdn-h/drivers/isdn/avmb1: capidrv.c%
diff -ur isdn-HEAD/drivers/isdn/hisax/config.c isdn-h/drivers/isdn/hisax/config.c
--- isdn-HEAD/drivers/isdn/hisax/config.c Thu Mar 15 22:19:21 2001
+++ isdn-h/drivers/isdn/hisax/config.c Sat Mar 17 18:07:41 2001
@@ -925,13 +925,12 @@
save_flags(flags);
cli();
- if (!(cs = (struct IsdnCardState *)
- kmalloc(sizeof(struct IsdnCardState), GFP_ATOMIC))) {
+ cs = kmalloc(sizeof(struct IsdnCardState), GFP_ATOMIC)
+ if (!cs) {
printk(KERN_WARNING
"HiSax: No memory for IsdnCardState(card %d)\n",
cardnr + 1);
- restore_flags(flags);
- return (0);
+ goto out;
}
memset(cs, 0, sizeof(struct IsdnCardState));
card-cs = cs;
@@ -950,241 +949,235 @@
#endif
cs-protocol = card-protocol;
- if ((card-typ 0) (card-typ = ISDN_CTYPE_COUNT)) {
- if (!(cs-dlog = kmalloc(MAX_DLOG_SPACE, GFP_ATOMIC))) {
- printk(KERN_WARNING
- "HiSax: No memory for dlog(card %d)\n",
- cardnr + 1);
- restore_flags(flags);
- return (0);
- }
- if (!(cs-status_buf = kmalloc(HISAX_STATUS_BUFSIZE, GFP_ATOMIC))) {
- printk(KERN_WARNING
- "HiSax: No memory for status_buf(card %d)\n",
- cardnr + 1);
- kfree(cs-dlog);
- restore_flags(flags);
- return (0);
- }
- cs-stlist = NULL;
- cs-status_read = cs-status_buf;
- cs-status_write = cs-status_buf;
- cs-status_end = cs-status_buf + HISAX_STATUS_BUFSIZE - 1;
- cs-typ = card-typ;
- strcpy(cs-iif.id, id);
- cs-iif.channels = 2;
- cs-iif.maxbufsize = MAX_DATA_SIZE;
- cs-iif.hl_hdrlen = MAX_HEADER_LEN;
- cs-iif.features =
- ISDN_FEATURE_L2_X75I |
- ISDN_FEATURE_L2_HDLC |
- ISDN_FEATURE_L2_HDLC_56K |
- ISDN_FEATURE_L2_TRANS |
- ISDN_FEATURE_L3_TRANS |
+ if (card-typ = 0 || card-typ ISDN_CTYPE_COUNT) {
+ printk(KERN_WARNING
+ "HiSax: Card Type %d out of range\n",
+ card-typ);
+ goto outf_cs;
+ }
+ if (!(cs-dlog = kmalloc(MAX_DLOG_SPACE, GFP_ATOMIC))) {
+
Re: changing mm-mmap_sem (was: Re: system call for processinformation?)
In article [EMAIL PROTECTED], Rik van Riel [EMAIL PROTECTED] wrote: OK, I'll write some code to prevent multiple threads from stepping all over each other when they pagefault at the same address. What would be the preferred method of fixing this ? - fixing do_swap_page and all -nopage functions There is no need to fix gthe "nopage" functions. They never see the page table directly anyway. So the only thing that _should_ be needed is to make sure that do_no_page(), do_swap_page() and do_anonymous_page() will re-aquire the mm-page_table_lock and undo their work if it turns out that the page table entry is no longer empty.. (do_wp_page() should already be ok in this regard - it already does this exactly because present pagetable entries can already race with kswapd. What we're adding is that _nonpresent_ page table entries can race with multiple invocations of concurrent page faults) - hacking handle_mm_fault to make sure no overlapping pagefaults will be served at the same time No. The whole reason the rw_semaphores were done in the first place was to allow page faults to happen concurrently to allow threaded applictions to scale up even when faulting. 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/
Where to find -pre releases?
Hello: Where in the ftp sites should I find the 2.4.3 -pre kernels? The instructions from freshmeat are not correct and I just can't remember the location... George George, MR. Tibbs The Beast Kasica Waukesha, WI USA [EMAIL PROTECTED] http://www.netwrx1.com ICQ #12862186 Zz zZ |\ z_,,,---,,_ /,`.-'`'_ ;-;;,_ |,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/
Re: Where to find -pre releases?
ftp://ftp.us.kernel.org/pub/linux/kernel/testing/ On Sun, 18 Mar 2001, George R. Kasica wrote: Hello: Where in the ftp sites should I find the 2.4.3 -pre kernels? The instructions from freshmeat are not correct and I just can't remember the location... George George, MR. Tibbs The Beast Kasica Waukesha, WI USA [EMAIL PROTECTED] http://www.netwrx1.com ICQ #12862186 Zz zZ |\ z_,,,---,,_ /,`.-'`'_ ;-;;,_ |,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/ __ Joel Jaeggli [EMAIL PROTECTED] Academic User Services [EMAIL PROTECTED] ANTC NSRC [EMAIL PROTECTED] -- "On two occasions I have been asked [by members of Parliament!], `Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." -- Charles Babbage - 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: Where to find -pre releases?
"George R. Kasica" wrote: Where in the ftp sites should I find the 2.4.3 -pre kernels? The instructions from freshmeat are not correct and I just can't remember the location... ftp://ftp.??.kernel.org/pub/linux/kernel/testing/ ?? == country code: us, de, dk, uk, ... Maybe I'm blind, but I didn't find an answer to this in the FAQ at http://www.tux.org/lkml/ Richard Gooch, FAQ maintainer, is CC'd. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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/
Q: kapm-idled and CPU usage
The message quoted below is from a MandrakeSoft co-worker and friend, in a thread discussing APM's kernel thread, and how the idle function uses CPU time. This thread was in response to yet another Bugzilla bug report about kapm-idled using CPU time. Several months ago, kapmd was renamed to kapm-idled in an attempt to signal users that it was a special process, and that its CPU time wasn't "real CPU time." This hasn't silenced the bug reports and confusion. Is there some way to hack the scheduler statistics so that idle processes are special cases, which do not accumulate CPU time nor contribute to the load average? I agree that it's not pretty to special case idle function process(es), but those idle functions in turn are causing an incorrect picture of the system state to be presented to userland. Jeff -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. Guillaume Cottenceau wrote: On the other hand, you'll agree Jeff that it needs some fixing: it's fucking up many statistics such as load average and instant cpu usage, and is very confusing for people.. On another side, what I don't understand is that its cpu usage is not constant, which makes people things it's sort of a bug: for example my machine is up 1 day, 18:33 with 2.4.2-15mdk, kapm-ideld is reported to have consumed 1355m, but currently it's staying at 0.0% of cpu. Sometimes it gets bigger, sometimes it gets lower. Rather confusing. - 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: Where to find -pre releases?
Em Sun, Mar 18, 2001 at 12:30:45PM -0600, George R. Kasica escreveu: Where in the ftp sites should I find the 2.4.3 -pre kernels? The instructions from freshmeat are not correct and I just can't remember the location... http://www.kernel.org/pub/linux/kernel/testing - 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 retransmit timeout?
How can I set the timeout for retransmitting non-acknowledged packets? I'd like to set linux up to more aggressive about assuming a packet didn't make it. Thanks! Mordy - 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 panic: Aiee, killing interrupt handler!
Hi, I got this machine, which I use for my research groups file (samba) and printing (lpd over samba) needs. This is the second time it has gone down for me, as shown below. There's really nothing to say about it; it has worked fine for about two weeks, and then an unprovoked panic. As you might see, it went down on a saturday, and this is the only thing in the log on that day; it's been standing idle for the whole day. The spec. is, as I'm sure you can see from the dmesg+lspci attachment: Pentium 90MHz 32Mb RAM SiS 85C501/2 CMD640 IDE SMC-Ultra 8216C IBM Deskstar DTLA-305040 41Gb, 128Mb swap, 2Gb ext2, and the rest one big reiserfs. linux-2.4.2 RedHat 6.2 I have to use setmax (from LARGE-HDD-HOWTO) in order to get the deskstar to mount. An oddity is this; We didn't have enough network points in our office, so I made a bridge (the bridging code is compiled into the kernel), using a second (SMC-Ultra) network card. And all of a sudden, I didn't have to use setmax any more. The kernel took care of the disk fine. As we got new points installed, I stopped using the bridge, and, once again I had to use setmax. Strange. I must add, I've used this machine for about a year to run an instrument, without any problems, only with linux-2.2 and a 6Gb harddrive instead of the deskstar. I've also added an extra ISA card parport for a second printer. I hope something of this helps. And if someone could tell me what is wrong here, I would be much obliged. I've had much resistance within the university for using linux as it is, and, if it starts going down every now and again, they'll chuck it out without a doubt. If I can do somthing else, in order to help, plese let me know. Cheeres, /Chris Kernel panic: Aiee, killing interrupt handler! In interrupt handler not syncing Unable to handle kernel NULL pointer dereference at virtual address 000b printing eip: c01104c3 *pde = Oops: CPU: 0 EIP: 0010: [c01104c3] EFLAGS: 00010013 eax: epx: 000b ecx: c10a6000 edx: c02108dc esi: c0210c18 edi: 0003 ebp: c10a5eb0 esp: c10a5e94 Process kreclaimd pid:4, stackpage = c10a5000 Stack: c02109c0 c0210c18 c02108dc 0001 0286 0001 0002 c0128335 0020 0002 c10af124 0002 0002 c0210c10 c012850c c012532a c10af124 0246 0002 0021 0003 c0125467 Call trace: [c0128335] [c012850c] [c012532a] [c01254bf] [c019eb02] [c0185719] [c018526e] [c0109fdf] [c010a13e] [c0108e60] [c0112270] Code: 8b 1b 8b 4f 04 8b 01 85 45 fc 74 51 31 c0 9c 5e fa c7 01 00 Kernel panic: Aiee, killing interrupt handler! In interrupt handler not syncing -- Christer Bckstrm Optoelectronic Materials Chemistry Group Department of Chemistry University of Wales, Bangor Bangor, Gwynedd LL57 2UW Wales, UK E-mail : [EMAIL PROTECTED] Telephone Office: +44(0)1248 388302 Telephone Laboratory: +44(0)1248 388304 Linux version 2.4.2 ([EMAIL PROTECTED]) (gcc version 2.95.3 19991030 (prerelease)) #23 Thu Feb 22 22:03:19 GMT 2001 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: 00018000 @ 000e8000 (reserved) BIOS-e820: 01f0 @ 0010 (usable) BIOS-e820: 0001 @ (reserved) On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=2 ro root=302 hda=79780,16,63 ide_setup: hda=79780,16,63 Initializing CPU#0 Detected 90.001 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 179.40 BogoMIPS Memory: 30320k/32768k available (846k kernel code, 2060k reserved, 286k data, 180k init, 0k highmem) Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) CPU: Before vendor init, caps: 01bf , vendor = 0 Intel Pentium with F0 0F bug - workaround enabled. CPU: After vendor init, caps: 01bf CPU: After generic, caps: 01bf CPU: Common caps: 01bf CPU: Intel Pentium 75 - 200 stepping 04 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.00 entry at 0xfc920, last bus=0 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Unable to handle 64-bit address for device 00:00.0 PCI: Unable to handle 64-bit address for device 00:00.0 PCI: Unable to handle 64-bit address for device 00:00.0 PCI: Failed to allocate resource 1 for Silicon Integrated Systems [SiS] 85C501/2 PCI: Failed to allocate resource 3 for Silicon Integrated Systems [SiS] 85C501/2 PCI: Failed to allocate resource 5 for Silicon Integrated Systems [SiS] 85C501/2 isapnp: Scanning for Pnp cards... isapnp: No
Re: [PATCH] off-by-1 error in ide-probe (2.4.x)
On Sun, Mar 18 2001, Paul Gortmaker wrote: There is a potentially serious bug in ide-probe.c in which max_sectors is set to 256 instead of 255. I am surprised that this hasn't bit anyone else yet. Perhaps because you need a disk that is slow in comparison to the host in order for the queue to climb up to and then hit the 256, at which point it then falls over. You don't need a slow disk, it's trivial to provoke 256 sector sized request on even the fastest disk available. People hit it all the time, just with working drives... For example, with an old 700MB Maxtor on a "fast" 486, VL-bus, PIO, hdparm -c1 -m8 -u1, I could pretty much on demand generate the following error by multiple builds, or by the final linking of any big project: The 256 is _not_ a bug in the driver, it's more likely a bug in your drive. 256 is a perfectly legal transfer size. That said, maybe it is a good idea to leave it at 255 just for safety on drives not handling 0 sectors == 128kB transfer. -- 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: [OT] how to catch HW fault
Hi, I tried memtest86 for 24 hours also and that didn't gave a clue. When bad ram was really involved I'd expected to find things like: failing fsck's, failing kernel compiles and such. But none of them the system runs perfect if it doesn't freeze(lockup). So yes, only the CPU's and the mobo are at question. What I was looking for was a tool like memtest86 but now for motherboards. regards Kees On Sat, 17 Mar 2001, Aaron Lunansky wrote: Sounds like the only thing you haven't swapped out of your machine is the ram/cpu. It could very well be your ram (I don't suspect the cpu). If you can, try a different stick of ram. - 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/
