null pointer dereference in ibmtr
When inserting the ibmtr.o module in any of the 2.4 series kernels, I get a null pointer crash. Latest try was 2.4.4. Ksymoops: Unable to handle kernel paging request at virtual address 7a18 c012861e *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 0170 ebx: 0001 ecx: 0170 edx: esi: c1321080 edi: c13210dc ebp: c9ca3800 esp: c0203ee8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0203) Stack: c0188efd c1321080 c0188f37 c1321080 c1321080 c0189067 c1321080 c1321080 c1321080 c01905c3 c1321080 c1321080 c9ff8ca0 c01903bb c1321080 c9ca3800 c01ff12c c1321080 c01ff12c c0189067 c1321080 c9ca3800 c01ff12c Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 41 18 85 c0 7c 11 ff 49 14 0f 94 c0 84 c0 74 07 89 c8 e8 >>EIP; c012861e <__free_pages+2/1c> <= Trace; c0188efd Trace; c0188f37 Trace; c0189067 <__kfree_skb+e7/f0> Trace; c01905c3 Trace; c01903bb Trace; c018c219 Trace; c018c3f5 Trace; c0115b7e Trace; c0107ef9 Trace; c0105160 Trace; c0106be0 Trace; c0105160 Trace; c0100018 Trace; c0105183 Trace; c01051de Trace; c0105000 Trace; c0100198 Code; c012861e <__free_pages+2/1c> <_EIP>: Code; c012861e <__free_pages+2/1c> <= 0: 8b 41 18 movl 0x18(%ecx),%eax <= Code; c0128621 <__free_pages+5/1c> 3: 85 c0 testl %eax,%eax Code; c0128623 <__free_pages+7/1c> 5: 7c 11 jl 18 <_EIP+0x18> c0128636 <__free_pages+1a/1c> Code; c0128625 <__free_pages+9/1c> 7: ff 49 14 decl 0x14(%ecx) Code; c0128628 <__free_pages+c/1c> a: 0f 94 c0 sete %al Code; c012862b <__free_pages+f/1c> d: 84 c0 testb %al,%al Code; c012862d <__free_pages+11/1c> f: 74 07 je 18 <_EIP+0x18> c0128636 <__free_pages+1a/1c> Code; c012862f <__free_pages+13/1c> 11: 89 c8 movl %ecx,%eax Code; c0128631 <__free_pages+15/1c> 13: e8 00 00 00 00call 18 <_EIP+0x18> c0128636 <__free_pages+1a/1c> Cpu info: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Pentium II (Klamath) stepping: 4 cpu MHz : 299.946316 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov mmx bogomips: 299.01 The token ring card is ISA, not pci. It has worked fine for years under 2.2.* Any ideas? -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
null pointer dereference in ibmtr
When inserting the ibmtr.o module in any of the 2.4 series kernels, I get a null pointer crash. Latest try was 2.4.4. Ksymoops: Unable to handle kernel paging request at virtual address 7a18 c012861e *pde = Oops: CPU:0 EIP:0010:[c012861e] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 0170 ebx: 0001 ecx: 0170 edx: esi: c1321080 edi: c13210dc ebp: c9ca3800 esp: c0203ee8 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0203) Stack: c0188efd c1321080 c0188f37 c1321080 c1321080 c0189067 c1321080 c1321080 c1321080 c01905c3 c1321080 c1321080 c9ff8ca0 c01903bb c1321080 c9ca3800 c01ff12c c1321080 c01ff12c c0189067 c1321080 c9ca3800 c01ff12c Call Trace: [c0188efd] [c0188f37] [c0189067] [c01905c3] [c01903bb] [c018c219] [c018c3f5] [c0115b7e] [c0107ef9] [c0105160] [c0106be0] [c0105160] [c0100018] [c0105183] [c01051de] [c0105000] [c0100198] Code: 8b 41 18 85 c0 7c 11 ff 49 14 0f 94 c0 84 c0 74 07 89 c8 e8 EIP; c012861e __free_pages+2/1c = Trace; c0188efd skb_release_data+3d/6c Trace; c0188f37 kfree_skbmem+b/54 Trace; c0189067 __kfree_skb+e7/f0 Trace; c01905c3 snap_rcv+9b/a4 Trace; c01903bb p8022_rcv+6b/98 Trace; c018c219 deliver_to_old_ones+71/80 Trace; c018c3f5 net_rx_action+11d/200 Trace; c0115b7e do_softirq+4a/6c Trace; c0107ef9 do_IRQ+a1/b4 Trace; c0105160 default_idle+0/28 Trace; c0106be0 ret_from_intr+0/20 Trace; c0105160 default_idle+0/28 Trace; c0100018 startup_32+18/a5 Trace; c0105183 default_idle+23/28 Trace; c01051de cpu_idle+36/4c Trace; c0105000 init+0/150 Trace; c0100198 L6+0/2 Code; c012861e __free_pages+2/1c _EIP: Code; c012861e __free_pages+2/1c = 0: 8b 41 18 movl 0x18(%ecx),%eax = Code; c0128621 __free_pages+5/1c 3: 85 c0 testl %eax,%eax Code; c0128623 __free_pages+7/1c 5: 7c 11 jl 18 _EIP+0x18 c0128636 __free_pages+1a/1c Code; c0128625 __free_pages+9/1c 7: ff 49 14 decl 0x14(%ecx) Code; c0128628 __free_pages+c/1c a: 0f 94 c0 sete %al Code; c012862b __free_pages+f/1c d: 84 c0 testb %al,%al Code; c012862d __free_pages+11/1c f: 74 07 je 18 _EIP+0x18 c0128636 __free_pages+1a/1c Code; c012862f __free_pages+13/1c 11: 89 c8 movl %ecx,%eax Code; c0128631 __free_pages+15/1c 13: e8 00 00 00 00call 18 _EIP+0x18 c0128636 __free_pages+1a/1c Cpu info: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 3 model name : Pentium II (Klamath) stepping: 4 cpu MHz : 299.946316 cache size : 512 KB fdiv_bug: no hlt_bug : no sep_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov mmx bogomips: 299.01 The token ring card is ISA, not pci. It has worked fine for years under 2.2.* Any ideas? -dennis T - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: Oscillations in disk write compaction, poor interactive performance
On Mon, 16 Apr 2001, Pavel Machek wrote: > Hi! > > > It also seems that in the 2.4 kernels, we can get into a sort of > > oscillation mode, where we can have long periods of disk activity > > where nothing can get done - the low points, where only 2-3 writes > > per second can occur, so completely screw up the interactive > > performance that you simply have to take your hands off the > > keyboard and go get coffee until the disk writes complete. I know > > we get better performance overall this way, but it can be > > frustrating when this occurs in the middle of video capture. > > I see oscilation even in 2.2.X case > > Can you try running while true; do sync; sleep 1; done? It should help. > > If it helps, try playing with bdflush/kupdate or how is it called/ parameters. > > -- > Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, > details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. > The problem isn't that it oscillates, at least the oscillations shouldn't cause any problems - though we probably shouldn't see large scale oscillations like this anyway. The problem is that at the low point in the cycle, the machine is unusable. It is utterly unresponsive until the writes complete, which can take a very long time (in the case of the ppc machine, several minutes!) Anything that does disk I/O will block for a long time - having 'ls' take two minutes is not a good thing. 2.2 does not exhibit this behaviour. On the plus side, it appears that several other people are reporting this problem in 2.4, so I don't think I'm totally out to lunch. -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Oscillations in disk write compaction, poor interactive performance
On Mon, 16 Apr 2001, Pavel Machek wrote: Hi! It also seems that in the 2.4 kernels, we can get into a sort of oscillation mode, where we can have long periods of disk activity where nothing can get done - the low points, where only 2-3 writes per second can occur, so completely screw up the interactive performance that you simply have to take your hands off the keyboard and go get coffee until the disk writes complete. I know we get better performance overall this way, but it can be frustrating when this occurs in the middle of video capture. I see oscilation even in 2.2.X case Can you try running while true; do sync; sleep 1; done? It should help. If it helps, try playing with bdflush/kupdate or how is it called/ parameters. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. The problem isn't that it oscillates, at least the oscillations shouldn't cause any problems - though we probably shouldn't see large scale oscillations like this anyway. The problem is that at the low point in the cycle, the machine is unusable. It is utterly unresponsive until the writes complete, which can take a very long time (in the case of the ppc machine, several minutes!) Anything that does disk I/O will block for a long time - having 'ls' take two minutes is not a good thing. 2.2 does not exhibit this behaviour. On the plus side, it appears that several other people are reporting this problem in 2.4, so I don't think I'm totally out to lunch. -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oscillations in disk write compaction, poor interactive performance
Subject: Oscillations in disk write compaction The following data sets are the output of a small program that reads a random 4k block from a large data file, makes a trivial alteration to the block, and writes the block back into the file (in place). In all three cases the file is larger than the physical memory of the machine. In the first two cases, the file is the exact same. It appears that in 2.4, we are much more aggressive about ordering and combining writes to disk - which is probably a good thing, as it helps increase disk throughput. But it is also a bad thing, as it seems that this ties up the disk and rest of the system for long periods of time. It also seems that in the 2.4 kernels, we can get into a sort of oscillation mode, where we can have long periods of disk activity where nothing can get done - the low points, where only 2-3 writes per second can occur, so completely screw up the interactive performance that you simply have to take your hands off the keyboard and go get coffee until the disk writes complete. I know we get better performance overall this way, but it can be frustrating when this occurs in the middle of video capture. More notes below. Anyone got any ideas? Or have I done something horribly stupid here? -dennis T 2.2.14 - 160 meg intel PII. Relatively slow ide drive, 6 MB/sec --- File size: 209715200 Blocks: 51200 57.10 writes/second (10 second average, 4096 byte blocks). 57.10 writes/second (10 second average, 4096 byte blocks). 56.70 writes/second (10 second average, 4096 byte blocks). 57.30 writes/second (10 second average, 4096 byte blocks). 60.40 writes/second (10 second average, 4096 byte blocks). 64.30 writes/second (10 second average, 4096 byte blocks). 65.70 writes/second (10 second average, 4096 byte blocks). 60.90 writes/second (10 second average, 4096 byte blocks). 44.60 writes/second (10 second average, 4096 byte blocks). 45.30 writes/second (10 second average, 4096 byte blocks). 56.40 writes/second (10 second average, 4096 byte blocks). 67.60 writes/second (10 second average, 4096 byte blocks). 69.40 writes/second (10 second average, 4096 byte blocks). 66.80 writes/second (10 second average, 4096 byte blocks). 70.80 writes/second (10 second average, 4096 byte blocks). 18.80 writes/second (10 second average, 4096 byte blocks). 74.90 writes/second (10 second average, 4096 byte blocks). 76.00 writes/second (10 second average, 4096 byte blocks). 75.70 writes/second (10 second average, 4096 byte blocks). 59.60 writes/second (10 second average, 4096 byte blocks). 42.70 writes/second (10 second average, 4096 byte blocks). 73.00 writes/second (10 second average, 4096 byte blocks). 50.60 writes/second (10 second average, 4096 byte blocks). 102.80 writes/second (10 second average, 4096 byte blocks). 64.10 writes/second (10 second average, 4096 byte blocks). 91.30 writes/second (10 second average, 4096 byte blocks). 29.70 writes/second (10 second average, 4096 byte blocks). 28.80 writes/second (10 second average, 4096 byte blocks). 95.60 writes/second (10 second average, 4096 byte blocks). 58.50 writes/second (10 second average, 4096 byte blocks). 131.90 writes/second (10 second average, 4096 byte blocks). 6.80 writes/second (10 second average, 4096 byte blocks). 118.00 writes/second (10 second average, 4096 byte blocks). 3.10 writes/second (10 second average, 4096 byte blocks). 73.70 writes/second (10 second average, 4096 byte blocks). 30.00 writes/second (10 second average, 4096 byte blocks). 87.80 writes/second (10 second average, 4096 byte blocks). 97.80 writes/second (10 second average, 4096 byte blocks). 54.60 writes/second (10 second average, 4096 byte blocks). 64.60 writes/second (10 second average, 4096 byte blocks). 6.40 writes/second (10 second average, 4096 byte blocks). 126.20 writes/second (10 second average, 4096 byte blocks). 23.50 writes/second (10 second average, 4096 byte blocks). 88.00 writes/second (10 second average, 4096 byte blocks). 85.00 writes/second (10 second average, 4096 byte blocks). 90.70 writes/second (10 second average, 4096 byte blocks). 12.90 writes/second (10 second average, 4096 byte blocks). 40.90 writes/second (10 second average, 4096 byte blocks). 2.4.3 - 160 meg intel PII. Same machine as above, dual boot --- File size: 209715200 Blocks: 51200 57.40 writes/second (10 second average, 4096 byte blocks). 69.20 writes/second (10 second average, 4096 byte blocks). 84.90 writes/second (10 second average, 4096 byte blocks). 58.70 writes/second (10 second average, 4096 byte blocks). 52.60 writes/second (10 second average, 4096 byte blocks). 36.60 writes/second (10 second average, 4096 byte blocks). 35.10 writes/second (10 second average, 4096 byte blocks). 65.80 writes/second (10 second average, 4096 byte blocks). 74.70 writes/second (10 second average, 4096 byte blocks). 88.90 writes/second
Oscillations in disk write compaction, poor interactive performance
Subject: Oscillations in disk write compaction The following data sets are the output of a small program that reads a random 4k block from a large data file, makes a trivial alteration to the block, and writes the block back into the file (in place). In all three cases the file is larger than the physical memory of the machine. In the first two cases, the file is the exact same. It appears that in 2.4, we are much more aggressive about ordering and combining writes to disk - which is probably a good thing, as it helps increase disk throughput. But it is also a bad thing, as it seems that this ties up the disk and rest of the system for long periods of time. It also seems that in the 2.4 kernels, we can get into a sort of oscillation mode, where we can have long periods of disk activity where nothing can get done - the low points, where only 2-3 writes per second can occur, so completely screw up the interactive performance that you simply have to take your hands off the keyboard and go get coffee until the disk writes complete. I know we get better performance overall this way, but it can be frustrating when this occurs in the middle of video capture. More notes below. Anyone got any ideas? Or have I done something horribly stupid here? -dennis T 2.2.14 - 160 meg intel PII. Relatively slow ide drive, 6 MB/sec --- File size: 209715200 Blocks: 51200 57.10 writes/second (10 second average, 4096 byte blocks). 57.10 writes/second (10 second average, 4096 byte blocks). 56.70 writes/second (10 second average, 4096 byte blocks). 57.30 writes/second (10 second average, 4096 byte blocks). 60.40 writes/second (10 second average, 4096 byte blocks). 64.30 writes/second (10 second average, 4096 byte blocks). 65.70 writes/second (10 second average, 4096 byte blocks). 60.90 writes/second (10 second average, 4096 byte blocks). 44.60 writes/second (10 second average, 4096 byte blocks). 45.30 writes/second (10 second average, 4096 byte blocks). 56.40 writes/second (10 second average, 4096 byte blocks). 67.60 writes/second (10 second average, 4096 byte blocks). 69.40 writes/second (10 second average, 4096 byte blocks). 66.80 writes/second (10 second average, 4096 byte blocks). 70.80 writes/second (10 second average, 4096 byte blocks). 18.80 writes/second (10 second average, 4096 byte blocks). 74.90 writes/second (10 second average, 4096 byte blocks). 76.00 writes/second (10 second average, 4096 byte blocks). 75.70 writes/second (10 second average, 4096 byte blocks). 59.60 writes/second (10 second average, 4096 byte blocks). 42.70 writes/second (10 second average, 4096 byte blocks). 73.00 writes/second (10 second average, 4096 byte blocks). 50.60 writes/second (10 second average, 4096 byte blocks). 102.80 writes/second (10 second average, 4096 byte blocks). 64.10 writes/second (10 second average, 4096 byte blocks). 91.30 writes/second (10 second average, 4096 byte blocks). 29.70 writes/second (10 second average, 4096 byte blocks). 28.80 writes/second (10 second average, 4096 byte blocks). 95.60 writes/second (10 second average, 4096 byte blocks). 58.50 writes/second (10 second average, 4096 byte blocks). 131.90 writes/second (10 second average, 4096 byte blocks). 6.80 writes/second (10 second average, 4096 byte blocks). 118.00 writes/second (10 second average, 4096 byte blocks). 3.10 writes/second (10 second average, 4096 byte blocks). 73.70 writes/second (10 second average, 4096 byte blocks). 30.00 writes/second (10 second average, 4096 byte blocks). 87.80 writes/second (10 second average, 4096 byte blocks). 97.80 writes/second (10 second average, 4096 byte blocks). 54.60 writes/second (10 second average, 4096 byte blocks). 64.60 writes/second (10 second average, 4096 byte blocks). 6.40 writes/second (10 second average, 4096 byte blocks). 126.20 writes/second (10 second average, 4096 byte blocks). 23.50 writes/second (10 second average, 4096 byte blocks). 88.00 writes/second (10 second average, 4096 byte blocks). 85.00 writes/second (10 second average, 4096 byte blocks). 90.70 writes/second (10 second average, 4096 byte blocks). 12.90 writes/second (10 second average, 4096 byte blocks). 40.90 writes/second (10 second average, 4096 byte blocks). 2.4.3 - 160 meg intel PII. Same machine as above, dual boot --- File size: 209715200 Blocks: 51200 57.40 writes/second (10 second average, 4096 byte blocks). 69.20 writes/second (10 second average, 4096 byte blocks). 84.90 writes/second (10 second average, 4096 byte blocks). 58.70 writes/second (10 second average, 4096 byte blocks). 52.60 writes/second (10 second average, 4096 byte blocks). 36.60 writes/second (10 second average, 4096 byte blocks). 35.10 writes/second (10 second average, 4096 byte blocks). 65.80 writes/second (10 second average, 4096 byte blocks). 74.70 writes/second (10 second average, 4096 byte blocks). 88.90 writes/second
[QUESTION] 2.4.x nice level
I too have noticed that nicing processes does not work nearly as effectively as I'd like it to. I run on an underpowered machine, and have had to stop running things such as seti because it steals too much cpu time, even when maximally niced. As an example, I can run mpg123 and a kernel build concurrently without trouble; but if I add a single maximally niced seti process, mpg123 runs out of gas and will start to skip while decoding. Is there any way we can make nice levels stronger than they currently are in 2.4? Or is this perhaps a timeslice problem, where once seti gets cpu time it runs longer than it should since it makes relatively few system calls? -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[QUESTION] 2.4.x nice level
I too have noticed that nicing processes does not work nearly as effectively as I'd like it to. I run on an underpowered machine, and have had to stop running things such as seti because it steals too much cpu time, even when maximally niced. As an example, I can run mpg123 and a kernel build concurrently without trouble; but if I add a single maximally niced seti process, mpg123 runs out of gas and will start to skip while decoding. Is there any way we can make nice levels stronger than they currently are in 2.4? Or is this perhaps a timeslice problem, where once seti gets cpu time it runs longer than it should since it makes relatively few system calls? -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Prevent OOM from killing init
On Fri, 23 Mar 2001, Martin Dalecki wrote: > SodaPop wrote: > > > > Rik, is there any way we could get a /proc entry for this, so that one > > could do something like: > > I will respond; NO there is no way for security reasons this is not a > good idea. > > > cat /proc/oom-kill-scores | sort +3 Oh, you mean like /proc/kcore is a bad idea for security reasons? Duh, make its permission bits 400. -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Prevent OOM from killing init
Rik, is there any way we could get a /proc entry for this, so that one could do something like: cat /proc/oom-kill-scores | sort +3 to get a process list (similar to ps) with a field for the current oom scores? It would likely be very useful to be able to dump the current scores and see what will be the first thing to die, and may help people tune the killer for specific uses. Part of the current problem with the OOM killer is that people only know what it's going to kill after it's too late. -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Only 10 MB/sec with via 82c686b - FIXED
Thanks Alan, but no dice. Most of the stuff on the board is autodetect anyway, but even after a reset it exhibited the same behaviour. Windows, however, continues to run fine. It's not properly set up with all the various drivers installed though, so its probably running with the equivalent of a 486 kernel as well. I tried rebuilding with K6-II as the cpu type instead of K7, that works fine. Is there any data in particular you'd like me to collect or experiments you'd like me to try? -dennis T On Fri, 23 Mar 2001, Alan Cox wrote: > > Wonder of wonders, I flashed the bios to the latest and greatest version. > > Current data transfer rates are 35.7 MB/sec on both udma drives, exactly > > as expected and darn close to the continuous read limits of the disks. > > The audio also started working, flawlessly. > > > > There are other issues however - the athlon now runs significantly hotter > > at idle for one, but the most serious is that the K7 kernel optimizations > > cause horrendous kernel panics and crashes. I'm running now on a kernel > > compiled for 386, which seems to be stable. I'll attempt to build other > > kernels to see if I can figure out whats going on. > > Check the bios update didnt leave some of the other configuration values > wrong. A 'reset to factory defaults' and resetting the stuff you need might > be a good idea. Could be it now has voltages wrong or something like that > > Alan > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Only 10 MB/sec with via 82c686b - FIXED
Thanks Alan, but no dice. Most of the stuff on the board is autodetect anyway, but even after a reset it exhibited the same behaviour. Windows, however, continues to run fine. It's not properly set up with all the various drivers installed though, so its probably running with the equivalent of a 486 kernel as well. I tried rebuilding with K6-II as the cpu type instead of K7, that works fine. Is there any data in particular you'd like me to collect or experiments you'd like me to try? -dennis T On Fri, 23 Mar 2001, Alan Cox wrote: Wonder of wonders, I flashed the bios to the latest and greatest version. Current data transfer rates are 35.7 MB/sec on both udma drives, exactly as expected and darn close to the continuous read limits of the disks. The audio also started working, flawlessly. There are other issues however - the athlon now runs significantly hotter at idle for one, but the most serious is that the K7 kernel optimizations cause horrendous kernel panics and crashes. I'm running now on a kernel compiled for 386, which seems to be stable. I'll attempt to build other kernels to see if I can figure out whats going on. Check the bios update didnt leave some of the other configuration values wrong. A 'reset to factory defaults' and resetting the stuff you need might be a good idea. Could be it now has voltages wrong or something like that Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Prevent OOM from killing init
Rik, is there any way we could get a /proc entry for this, so that one could do something like: cat /proc/oom-kill-scores | sort +3 to get a process list (similar to ps) with a field for the current oom scores? It would likely be very useful to be able to dump the current scores and see what will be the first thing to die, and may help people tune the killer for specific uses. Part of the current problem with the OOM killer is that people only know what it's going to kill after it's too late. -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Prevent OOM from killing init
On Fri, 23 Mar 2001, Martin Dalecki wrote: SodaPop wrote: Rik, is there any way we could get a /proc entry for this, so that one could do something like: I will respond; NO there is no way for security reasons this is not a good idea. cat /proc/oom-kill-scores | sort +3 Oh, you mean like /proc/kcore is a bad idea for security reasons? Duh, make its permission bits 400. -dennis T - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Only 10 MB/sec with via 82c686b - FIXED
Further note - kernels built with K6-2 support seem to be just fine. But all athlon/K7 kernels die horribly, with greatly varying death messages. Most commonly I get bogus pointer/dereference errors and eventually init gets killed, other times it just locks up, sometimes I get things like 'cannot exec syslogd: Out of memory'. It looks like the memory registers are horked up somehow. I could try to copy some of this out by hand if anyone thought it worthwhile. Either way, I think IWill has some work to do yet on their system bios. -dennis T On Wed, 21 Mar 2001 [EMAIL PROTECTED] wrote: > On 20 Mar, SodaPop wrote: > > > I have an IWill KK-266R motherboard with an athlon-c 1200 > > processor in it, and for the life of me I can't get more than > > 10 MB/sec through the on-board ide controller. Yes, all the > > appropriate support is turned on in the kernel to enable dma > > and specific chipset support, and yes, I think I have all > > relevant patches and a reasonable kernel. > > Yes, actually I'm seeing the same on a KT133 board from Elitegroup. > Although here I get a bit more: 15 MB/s > > > I noted a number of other interesting things; one, that -X33, > > -X34, and -X64 through -X69 all have the same 10 MB/sec transfer > > rate, and two, that the 10 MB/sec transfer rate can be linearly > > increased to 12 MB/sec by raising the system bus from 100 mhz to > > 120 mhz (all components are safely rated at 133, no overclocking > > involved.) > > Duh, before making such a claim you should consider the fact that > this is overclocking your PCI/AGP bus and I have yet to see any > graphic cards/IDE controllers/other devices which are rated for > 37MHz PCI bus speed. > > -- > > Servus, >Daniel > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Only 10 MB/sec with via 82c686b - FIXED
Regarding the overclocking of the PCI bus, I was not aware of this. The documentation led me to believe the pci clock was fixed, however further experimentation indicates that's clearly not the case. Thanks. Regarding the fix: I installed an Ensonique AudioPci sound card, and experienced horrible distortion, crackling, and high pitched chirps any time I tried to use the device. I noticed that various interrupts were causing chunks of the real audio to sometimes slip through; on a whim I tried ping flooding a nearby machine and the sound quality improved greatly. Putting two and two together, it occurred to me that the motherboard was having irq/interrupt routing problems. The disks could not get reasonable throughput because the interrupts were getting choked or held up, and the sound card couldn't properly function either. Wonder of wonders, I flashed the bios to the latest and greatest version. Current data transfer rates are 35.7 MB/sec on both udma drives, exactly as expected and darn close to the continuous read limits of the disks. The audio also started working, flawlessly. There are other issues however - the athlon now runs significantly hotter at idle for one, but the most serious is that the K7 kernel optimizations cause horrendous kernel panics and crashes. I'm running now on a kernel compiled for 386, which seems to be stable. I'll attempt to build other kernels to see if I can figure out whats going on. Net result: IWill KK266 motherboards have bios problems, it may be a good idea to upgrade the bios. -dennis T On Wed, 21 Mar 2001 [EMAIL PROTECTED] wrote: > On 20 Mar, SodaPop wrote: > > > I have an IWill KK-266R motherboard with an athlon-c 1200 > > processor in it, and for the life of me I can't get more than > > 10 MB/sec through the on-board ide controller. Yes, all the > > appropriate support is turned on in the kernel to enable dma > > and specific chipset support, and yes, I think I have all > > relevant patches and a reasonable kernel. > > Yes, actually I'm seeing the same on a KT133 board from Elitegroup. > Although here I get a bit more: 15 MB/s > > > I noted a number of other interesting things; one, that -X33, > > -X34, and -X64 through -X69 all have the same 10 MB/sec transfer > > rate, and two, that the 10 MB/sec transfer rate can be linearly > > increased to 12 MB/sec by raising the system bus from 100 mhz to > > 120 mhz (all components are safely rated at 133, no overclocking > > involved.) > > Duh, before making such a claim you should consider the fact that > this is overclocking your PCI/AGP bus and I have yet to see any > graphic cards/IDE controllers/other devices which are rated for > 37MHz PCI bus speed. > > -- > > Servus, >Daniel > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Only 10 MB/sec with via 82c686b - FIXED
Regarding the overclocking of the PCI bus, I was not aware of this. The documentation led me to believe the pci clock was fixed, however further experimentation indicates that's clearly not the case. Thanks. Regarding the fix: I installed an Ensonique AudioPci sound card, and experienced horrible distortion, crackling, and high pitched chirps any time I tried to use the device. I noticed that various interrupts were causing chunks of the real audio to sometimes slip through; on a whim I tried ping flooding a nearby machine and the sound quality improved greatly. Putting two and two together, it occurred to me that the motherboard was having irq/interrupt routing problems. The disks could not get reasonable throughput because the interrupts were getting choked or held up, and the sound card couldn't properly function either. Wonder of wonders, I flashed the bios to the latest and greatest version. Current data transfer rates are 35.7 MB/sec on both udma drives, exactly as expected and darn close to the continuous read limits of the disks. The audio also started working, flawlessly. There are other issues however - the athlon now runs significantly hotter at idle for one, but the most serious is that the K7 kernel optimizations cause horrendous kernel panics and crashes. I'm running now on a kernel compiled for 386, which seems to be stable. I'll attempt to build other kernels to see if I can figure out whats going on. Net result: IWill KK266 motherboards have bios problems, it may be a good idea to upgrade the bios. -dennis T On Wed, 21 Mar 2001 [EMAIL PROTECTED] wrote: On 20 Mar, SodaPop wrote: I have an IWill KK-266R motherboard with an athlon-c 1200 processor in it, and for the life of me I can't get more than 10 MB/sec through the on-board ide controller. Yes, all the appropriate support is turned on in the kernel to enable dma and specific chipset support, and yes, I think I have all relevant patches and a reasonable kernel. Yes, actually I'm seeing the same on a KT133 board from Elitegroup. Although here I get a bit more: 15 MB/s I noted a number of other interesting things; one, that -X33, -X34, and -X64 through -X69 all have the same 10 MB/sec transfer rate, and two, that the 10 MB/sec transfer rate can be linearly increased to 12 MB/sec by raising the system bus from 100 mhz to 120 mhz (all components are safely rated at 133, no overclocking involved.) Duh, before making such a claim you should consider the fact that this is overclocking your PCI/AGP bus and I have yet to see any graphic cards/IDE controllers/other devices which are rated for 37MHz PCI bus speed. -- Servus, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Only 10 MB/sec with via 82c686b - FIXED
Further note - kernels built with K6-2 support seem to be just fine. But all athlon/K7 kernels die horribly, with greatly varying death messages. Most commonly I get bogus pointer/dereference errors and eventually init gets killed, other times it just locks up, sometimes I get things like 'cannot exec syslogd: Out of memory'. It looks like the memory registers are horked up somehow. I could try to copy some of this out by hand if anyone thought it worthwhile. Either way, I think IWill has some work to do yet on their system bios. -dennis T On Wed, 21 Mar 2001 [EMAIL PROTECTED] wrote: On 20 Mar, SodaPop wrote: I have an IWill KK-266R motherboard with an athlon-c 1200 processor in it, and for the life of me I can't get more than 10 MB/sec through the on-board ide controller. Yes, all the appropriate support is turned on in the kernel to enable dma and specific chipset support, and yes, I think I have all relevant patches and a reasonable kernel. Yes, actually I'm seeing the same on a KT133 board from Elitegroup. Although here I get a bit more: 15 MB/s I noted a number of other interesting things; one, that -X33, -X34, and -X64 through -X69 all have the same 10 MB/sec transfer rate, and two, that the 10 MB/sec transfer rate can be linearly increased to 12 MB/sec by raising the system bus from 100 mhz to 120 mhz (all components are safely rated at 133, no overclocking involved.) Duh, before making such a claim you should consider the fact that this is overclocking your PCI/AGP bus and I have yet to see any graphic cards/IDE controllers/other devices which are rated for 37MHz PCI bus speed. -- Servus, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Only 10 MB/sec with via 82c686b chipset?
Only 10 MB/sec with via 82c686b chipset? I have an IWill KK-266R motherboard with an athlon-c 1200 processor in it, and for the life of me I can't get more than 10 MB/sec through the on-board ide controller. Yes, all the appropriate support is turned on in the kernel to enable dma and specific chipset support, and yes, I think I have all relevant patches and a reasonable kernel. I started out with stock kernel 2.4.2. I later added Hedrick's ide.2.4.3-p4.all.03132001.patch, which did not change the behaviour other than to include messages in the dmesg output. I have even tried removing the via-specific chipset support from the kernel, only to find that enabling dma with generic support leaves me at the same 10 MB/sec as the specific support does. I noted a number of other interesting things; one, that -X33, -X34, and -X64 through -X69 all have the same 10 MB/sec transfer rate, and two, that the 10 MB/sec transfer rate can be linearly increased to 12 MB/sec by raising the system bus from 100 mhz to 120 mhz (all components are safely rated at 133, no overclocking involved.) It is also quite strange that I have been able to run 'hdparm -t /dev/hda' and 'hdparm -t /dev/hdb' concurrently and can still get the full 10 MB/sec on both, for a sum total of 20 MB/sec. I would have expected that the drives would clobber each other given that they are on the same ide bus. >From the /proc data and other information below, it seems to me that this is some kind of screwball tuning issue between linux and the chipset, not the chipset and the drives. As near as I can tell, the chipset is talking to the drives at a much higher data rate than 10 MB/sec, but for some reason linux isn't able to process the data any faster than that. Running hdparm -t in parallel and observing a speed increase from raising the cpu clock leads me in that direction. (Also note that hdparm -t only uses a few percent of cpu. It's not like the machine doesn't have enough processing power.) I'm really baffled at this point. I can't rule out that I have done something dumb, but for the life of me I can't think of anything else. I've been to a number of web pages, but the general consensus seems to be that this chipset should just work, and work beautifully without any trouble. There aren't any fixes because I seem to be the only one having this problem. Does anyone have any other ideas? -dennis T Misc hardware information: The board has raid hardware on it, but its currently disabled with jumpers. Cables are high quality 80 wire/40 pin cables. Both drives are the same, but currently hdb has the 32 gig clip jumper attached. Putting the drives on separate ide busses does not change the 10 MB/sec throughput. Removing hdb from the chain does not raise the throughput of hda. Both drives are rated at 37 MB/sec continuous DTR. Hdd is a cheap 8x cdrom. Hdb, when installed in a nearby machine, has a 17 MB/sec data rate. The machine is an AMD K6-II 500, 100 MHz bus, with via 82c586 chipset, running kernel 2.4.1 (via chipset support enabled.) Various miscellaneous data, and dmesg output: root@gurney:~# cat /proc/ide/via --VIA BusMastering IDE Configuration Driver Version: 3.20 South Bridge: VIA vt82c686b Revision: ISA 0x40 IDE 0x6 BM-DMA base:0xd000 PCI clock: 33MHz Master Read Cycle IRDY:0ws Master Write Cycle IRDY:0ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit ---Primary IDE---Secondary IDE-- Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: yes yes Post Write Buffer:yes no Enabled: yes yes Simplex only: no no Cable Type: 80w 40w ---drive0drive1drive2drive3- Transfer Mode: UDMA UDMA PIO PIO Address Setup: 30ns 30ns 120ns 60ns Cmd Active: 90ns 90ns 90ns 90ns Cmd Recovery:30ns 30ns 90ns 90ns Data Active: 90ns 90ns 330ns 240ns Data Recovery: 30ns 30ns 270ns 240ns Cycle Time: 20ns 20ns 50ns 90ns Transfer Rate: 100.0MB/s 100.0MB/s 40.0MB/s 22.2MB/s root@gurney:~# hdparm /dev/hda /dev/hda: multcount= 0 (off) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 5606/255/63, sectors
Only 10 MB/sec with via 82c686b chipset?
Only 10 MB/sec with via 82c686b chipset? I have an IWill KK-266R motherboard with an athlon-c 1200 processor in it, and for the life of me I can't get more than 10 MB/sec through the on-board ide controller. Yes, all the appropriate support is turned on in the kernel to enable dma and specific chipset support, and yes, I think I have all relevant patches and a reasonable kernel. I started out with stock kernel 2.4.2. I later added Hedrick's ide.2.4.3-p4.all.03132001.patch, which did not change the behaviour other than to include messages in the dmesg output. I have even tried removing the via-specific chipset support from the kernel, only to find that enabling dma with generic support leaves me at the same 10 MB/sec as the specific support does. I noted a number of other interesting things; one, that -X33, -X34, and -X64 through -X69 all have the same 10 MB/sec transfer rate, and two, that the 10 MB/sec transfer rate can be linearly increased to 12 MB/sec by raising the system bus from 100 mhz to 120 mhz (all components are safely rated at 133, no overclocking involved.) It is also quite strange that I have been able to run 'hdparm -t /dev/hda' and 'hdparm -t /dev/hdb' concurrently and can still get the full 10 MB/sec on both, for a sum total of 20 MB/sec. I would have expected that the drives would clobber each other given that they are on the same ide bus. From the /proc data and other information below, it seems to me that this is some kind of screwball tuning issue between linux and the chipset, not the chipset and the drives. As near as I can tell, the chipset is talking to the drives at a much higher data rate than 10 MB/sec, but for some reason linux isn't able to process the data any faster than that. Running hdparm -t in parallel and observing a speed increase from raising the cpu clock leads me in that direction. (Also note that hdparm -t only uses a few percent of cpu. It's not like the machine doesn't have enough processing power.) I'm really baffled at this point. I can't rule out that I have done something dumb, but for the life of me I can't think of anything else. I've been to a number of web pages, but the general consensus seems to be that this chipset should just work, and work beautifully without any trouble. There aren't any fixes because I seem to be the only one having this problem. Does anyone have any other ideas? -dennis T Misc hardware information: The board has raid hardware on it, but its currently disabled with jumpers. Cables are high quality 80 wire/40 pin cables. Both drives are the same, but currently hdb has the 32 gig clip jumper attached. Putting the drives on separate ide busses does not change the 10 MB/sec throughput. Removing hdb from the chain does not raise the throughput of hda. Both drives are rated at 37 MB/sec continuous DTR. Hdd is a cheap 8x cdrom. Hdb, when installed in a nearby machine, has a 17 MB/sec data rate. The machine is an AMD K6-II 500, 100 MHz bus, with via 82c586 chipset, running kernel 2.4.1 (via chipset support enabled.) Various miscellaneous data, and dmesg output: root@gurney:~# cat /proc/ide/via --VIA BusMastering IDE Configuration Driver Version: 3.20 South Bridge: VIA vt82c686b Revision: ISA 0x40 IDE 0x6 BM-DMA base:0xd000 PCI clock: 33MHz Master Read Cycle IRDY:0ws Master Write Cycle IRDY:0ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit ---Primary IDE---Secondary IDE-- Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: yes yes Post Write Buffer:yes no Enabled: yes yes Simplex only: no no Cable Type: 80w 40w ---drive0drive1drive2drive3- Transfer Mode: UDMA UDMA PIO PIO Address Setup: 30ns 30ns 120ns 60ns Cmd Active: 90ns 90ns 90ns 90ns Cmd Recovery:30ns 30ns 90ns 90ns Data Active: 90ns 90ns 330ns 240ns Data Recovery: 30ns 30ns 270ns 240ns Cycle Time: 20ns 20ns 50ns 90ns Transfer Rate: 100.0MB/s 100.0MB/s 40.0MB/s 22.2MB/s root@gurney:~# hdparm /dev/hda /dev/hda: multcount= 0 (off) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 5606/255/63, sectors =
