Re: aaaah! complete lockup 2.4.0-test9 SPARC32
* Anton Blanchard [EMAIL PROTECTED] [001004 21:31]:
I just had my box completely lock up under 2.4.0-test9. I had insmodded
the dbri.o audio driver, which for some reason was refusing to work, at
all. So I rmmodded it, and at that point, the screen flickered once and
wham, complete lockup, nothing responds at all, no network, no SysRQ,
anything...Not even an oops printed to the screen.
Machine:
SPARCstation 20, 1xTMS390Z55 50MHz SuperSPARC II w/1MB SuperCACHE
48MB RAM, about 9G total disk space spanned over 3 drives, TGX...
Short answer: don't use the dbri module :)
It is buggy and requires someone to fix it.
Well, while I had Pete Zaitcev over the other day, we looked into
the problem a bit. I captured the oopses and ran it through ksymoops
and got this stack trace...
Trace; f001c6ec do_sparc_fault+308/3ac
Trace; f0010c88 srmmu_fault+58/68
Trace; f001ed28 srmmu_unmapioaddr+a4/b4
Trace; f0016d5c _sparc_free_io+2c/50
Trace; f0016b18 iounmap+34/78
Trace; f0016b88 sbus_iounmap+4/14
Trace; fe311380 [dbri]dbri_detach+1c/48
Trace; fe313e8c [dbri]cleanup_module+30/67
Working our way up, Pete noticed that _sparc_free_io() wasn't aligning
plen properly... problem solved.
While we were there, we noticed a few more problems in the file (misuse
of a #define, and poor renaming of copied code).
At this point, the dbri driver is properly loadable and unloadable...
now it just needs to be fixed... the patch follows...
Index: arch/sparc/kernel/ioport.c
===
RCS file: /cvs/linux/arch/sparc/kernel/ioport.c,v
retrieving revision 1.39
diff -u -r1.39 ioport.c
--- arch/sparc/kernel/ioport.c 2000/06/20 01:10:00 1.39
+++ arch/sparc/kernel/ioport.c 2000/10/09 07:55:15
@@ -244,6 +244,7 @@
unsigned long plen;
plen = res-end - res-start + 1;
+ plen = (plen + PAGE_SIZE-1) PAGE_MASK;
while (plen != 0) {
plen -= PAGE_SIZE;
(*_sparc_unmapioaddr)(res-start + plen);
@@ -323,7 +324,7 @@
return;
}
- if (((unsigned long)p (PAGE_MASK-1)) != 0) {
+ if (((unsigned long)p (PAGE_SIZE-1)) != 0) {
printk("sbus_free_consistent: unaligned va %p\n", p);
return;
}
@@ -496,7 +497,7 @@
if ((res = kmalloc(sizeof(struct resource), GFP_KERNEL)) == NULL) {
free_pages(va, order);
- printk("sbus_alloc_consistent: no core\n");
+ printk("pci_alloc_consistent: no core\n");
return NULL;
}
memset((char*)res, 0, sizeof(struct resource));
@@ -546,18 +547,18 @@
if ((res = _sparc_find_resource(_sparc_dvma,
(unsigned long)p)) == NULL) {
- printk("sbus_free_consistent: cannot free %p\n", p);
+ printk("pci_free_consistent: cannot free %p\n", p);
return;
}
- if (((unsigned long)p (PAGE_MASK-1)) != 0) {
- printk("sbus_free_consistent: unaligned va %p\n", p);
+ if (((unsigned long)p (PAGE_SIZE-1)) != 0) {
+ printk("pci_free_consistent: unaligned va %p\n", p);
return;
}
n = (n + PAGE_SIZE-1) PAGE_MASK;
if ((res-end-res-start)+1 != n) {
- printk("sbus_free_consistent: region 0x%lx asked 0x%lx\n",
+ printk("pci_free_consistent: region 0x%lx asked 0x%lx\n",
(long)((res-end-res-start)+1), (long)n);
return;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Newer motherboards / CPU's / hardware with Linux
Andre Hedrick wrote: On Mon, 9 Oct 2000, Andre Tomt wrote: The fastest ATA drives out that are not public yet are in 39-42mB/s. Also SCSI can not sustain rates much better than maybe 60mB/s. Andre, how are you benchmarking drives ? In context you wrote, I've got rather curious results (maybe due to daulty measurement routines in tar). I've made tar clvf /dev/null --totals and got as follows: for ReiserFS: 53MB/s for ext2fs 27-28 MB/s Hardware used: ASUS P2B, 80MB RAM, P III 500MHz, ASUS PCI Ultra66C card (based on CMD 648U) and 15GB WD153BA 7200rpm drive. Have you any idea did such results are really possible ? Could you sugest me better methods ? Another question: looking through ide driver code I've found that there exists bad drive list with comment saying that it's updated when somebody emails bad words about drive. What you think about preparing test utility and let people around the world check and fill database of drives real "capabilities". This way list will be almost completed now, not after few years. Regards, Blizbor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
[EMAIL PROTECTED] wrote: 8. Fix Exists But Isnt Merged * 2.4.0-test8 has a BUG at ll_rw_blk:711. (Johnny Accot, Steffen Luitz) (Al Viro has a patch) Said patch has already been merged in the test9-pre and -final series and the bug can be considered fixed. -Udo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
OOPS with test9 when plugging an Philips Webcam
Hi there! FIRST: I did NOT load the pwc-driver from nemosoft! (I hope anybody is satisfied now ;-) I got the following kernel oops when plugging the webcam. There wis NO driver installed! Just plugging in. I attach the output form messages send through ksymoops, the USB relevant part of my .config file. It seams to me that when I plug the webcam there is a heavy corruption of memory. Because although the oops is from netscape, it is not always netscape. The next prog with heavy memory usage will produce an oops when starting. The first time I experienced the problem was with test8. If I unplug the webcam I have a working system without any problems. Best wishes Norbert -- ciao norb +---+ | Norbert Preining http://www.logic.at/people/preining | | University of Technology Vienna, Austria[EMAIL PROTECTED] | | DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key | +---+ ksymoops 0.7c on i586 2.4.0-test9. Options used -v /usr/src/linux/vmlinux (specified) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test9/ (default) -m /boot/System.map-2.4.0-test9 (specified) Oct 9 09:51:08 mandala kernel: Unable to handle kernel paging request at virtual address 11010020 Oct 9 09:51:08 mandala kernel: c012ab28 Oct 9 09:51:08 mandala kernel: *pde = Oct 9 09:51:08 mandala kernel: Oops: 0002 Oct 9 09:51:08 mandala kernel: CPU:0 Oct 9 09:51:08 mandala kernel: EIP:0010:[fget+32/40] Oct 9 09:51:08 mandala kernel: EFLAGS: 00210206 Oct 9 09:51:08 mandala kernel: eax: c27d0c00 ebx: c1984000 ecx: 0008 edx: 1101000c Oct 9 09:51:08 mandala kernel: esi: edi: 08dd8000 ebp: 0020 esp: c1985fac Oct 9 09:51:08 mandala kernel: ds: 0018 es: 0018 ss: 0018 Oct 9 09:51:08 mandala kernel: Process netscape (pid: 419, stackpage=c1985000) Oct 9 09:51:08 mandala kernel: Stack: c0129f61 c1984000 08dd8000 bfffd9f4 c0109053 0008 bfffdaac Oct 9 09:51:08 mandala kernel:0020 08dd8000 bfffd9f4 0003 002b 002b 0003 Oct 9 09:51:08 mandala kernel:40276174 0023 00200216 bfffd9dc 002b Oct 9 09:51:08 mandala kernel: Call Trace: [sys_read+17/204] [system_call+51/64] Oct 9 09:51:08 mandala kernel: Code: ff 42 14 89 d0 c3 89 f6 8b 4c 24 04 ff 49 14 0f 94 c0 84 c0 Using defaults from ksymoops -t elf32-i386 -a i386 Code; Before first symbol _EIP: Code; Before first symbol 0: ff 42 14 incl 0x14(%edx) Code; 0003 Before first symbol 3: 89 d0 mov%edx,%eax Code; 0005 Before first symbol 5: c3ret Code; 0006 Before first symbol 6: 89 f6 mov%esi,%esi Code; 0008 Before first symbol 8: 8b 4c 24 04 mov0x4(%esp,1),%ecx Code; 000c Before first symbol c: ff 49 14 decl 0x14(%ecx) Code; 000f Before first symbol f: 0f 94 c0 sete %al Code; 0012 Before first symbol 12: 84 c0 test %al,%al Oct 9 09:51:08 mandala kernel: Unable to handle kernel paging request at virtual address 11010020 Oct 9 09:51:08 mandala kernel: *pde = Oct 9 09:51:08 mandala kernel: Oops: Oct 9 09:51:08 mandala kernel: CPU:0 Oct 9 09:51:08 mandala kernel: EIP:0010:[filp_close+6/100] Oct 9 09:51:08 mandala kernel: EFLAGS: 00210206 Oct 9 09:51:08 mandala kernel: eax: c27d0c00 ebx: 1101000c ecx: edx: 1101000c Oct 9 09:51:08 mandala kernel: esi: edi: c3703d80 ebp: 0001 esp: c1985e80 Oct 9 09:51:08 mandala kernel: ds: 0018 es: 0018 ss: 0018 Oct 9 09:51:08 mandala kernel: Process netscape (pid: 419, stackpage=c1985000) Oct 9 09:51:08 mandala kernel: Stack: 0001 c0116ac8 1101000c c3703d80 c32376e0 c1984000 000b Oct 9 09:51:08 mandala kernel:c1984000 c3703ea0 c01170c1 c3703d80 11010020 c010957c Oct 9 09:51:08 mandala kernel:000b c010f295 c0200a5e c1985f78 0002 c1984000 08dd8000 Oct 9 09:51:08 mandala kernel: Call Trace: [put_files_struct+84/184] [do_exit+185/500] [do_divide_error+0/172] [do_page_fault+789/960] [IRQ0x0f_interrupt+10318/19416] [do_signal+567/636] [sock_write+163/172] Oct 9 09:51:09 mandala kernel: Code: 8b 43 14 85 c0 75 13 68 a2 5d 20 c0 e8 d5 af fe ff 31 c0 83 Code; Before first symbol _EIP: Code; Before first symbol 0: 8b 43 14 mov0x14(%ebx),%eax Code; 0003 Before first symbol 3: 85 c0 test %eax,%eax Code; 0005 Before first symbol 5: 75 13 jne1a _EIP+0x1a 001a Before first symbol Code;
[OOPS][BUG] with 2.4.0-test9
Hi! The following BUG related oopses caused my machine to die (well, X didnt survive...) while just compiling a little program. I dont know if these issues are fixed yet within one of the floating patches, so here goes the report (dmesg stripped a little). Richard. -- Richard Guenther [EMAIL PROTECTED] WWW: http://www.anatom.uni-tuebingen.de/~richi/ The GLAME Project: http://www.glame.de/ Oct 7 11:19:40 localhost kernel: Linux version 2.4.0-test9 (root@mickey) (gcc version 2.95.2 2220 (Debian GNU/Linux)) #15 Mit Okt 4 19:23:28 CEST 2000 Oct 7 11:19:40 localhost kernel: On node 0 totalpages: 8192 Oct 7 11:19:40 localhost kernel: zone(0): 4096 pages. Oct 7 11:19:40 localhost kernel: zone(1): 4096 pages. Oct 7 11:19:40 localhost kernel: zone(2): 0 pages. Oct 7 11:19:40 localhost kernel: Initializing CPU#0 Oct 7 11:19:40 localhost kernel: Detected 99.475 MHz processor. Oct 7 11:19:40 localhost kernel: Memory: 30304k/32768k available (1059k kernel code, 2080k reserved, 81k data, 188k init, 0k highmem) Oct 7 11:19:40 localhost kernel: Dentry-cache hash table entries: 4096 (order: 3, 32768 bytes) Oct 7 11:19:40 localhost kernel: Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Oct 7 11:19:40 localhost kernel: Page-cache hash table entries: 8192 (order: 3, 32768 bytes) Oct 7 11:19:40 localhost kernel: Inode-cache hash table entries: 2048 (order: 2, 16384 bytes) Oct 7 11:19:40 localhost kernel: CPU: Intel Pentium 75 - 200 stepping 05 Oct 7 11:19:40 localhost kernel: Linux video capture interface: v1.00 Oct 7 11:19:40 localhost kernel: Uniform Multi-Platform E-IDE driver Revision: 6.31 Oct 7 11:19:40 localhost kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Oct 7 11:19:40 localhost kernel: PIIX: IDE controller on PCI bus 00 dev 38 Oct 7 11:19:40 localhost kernel: PIIX: chipset revision 2 Oct 7 11:19:40 localhost kernel: Real Time Clock Driver v1.10c Oct 7 11:19:40 localhost kernel: SCSI subsystem driver Revision: 1.00 Oct 7 11:19:40 localhost kernel: sym53c8xx: at PCI bus 0, device 9, function 0 Oct 7 11:19:40 localhost kernel: Soundblaster audio driver Copyright (C) by Hannu Savolainen 1993-1996 Oct 7 11:19:40 localhost kernel: Sound Blaster 16 (4.13) at 0x220 irq 5 dma 1,5 Oct 7 11:19:40 localhost kernel: Adding Swap: 98780k swap-space (priority -1) Oct 7 11:39:38 localhost -- MARK -- Oct 7 11:50:47 localhost kernel: kernel BUG at page_alloc.c:91! Oct 7 11:50:47 localhost kernel: invalid operand: Oct 7 11:50:47 localhost kernel: CPU:0 Oct 7 11:50:47 localhost kernel: EIP:0010:[__free_pages_ok+73/892] Oct 7 11:50:47 localhost kernel: EFLAGS: 00010286 Oct 7 11:50:47 localhost kernel: eax: 001f ebx: c1002a90 ecx: c10a4000 edx: Oct 7 11:50:47 localhost kernel: esi: c1002aac edi: ebp: 002c esp: c10a5f64 Oct 7 11:50:47 localhost kernel: ds: 0018 es: 0018 ss: 0018 Oct 7 11:50:47 localhost kernel: Process kswapd (pid: 2, stackpage=c10a5000) Oct 7 11:50:47 localhost kernel: Stack: c01d4877 c01d4a65 005b c1002a90 c1002aac 00ce 002c 00ce Oct 7 11:50:47 localhost kernel:002b 0003 c0126042 c01278cb c0126229 0004 Oct 7 11:50:47 localhost kernel: 0004 c0126870 0004 Oct 7 11:50:47 localhost kernel: Call Trace: [tvecs+8671/55752] [tvecs+9165/55752] [page_launder+674/1888] [__free_pages+19/20] [page_launder+1161/1888] [do_try_to_free_pages+52/128] [tvecs+7999/55752] Oct 7 11:50:47 localhost kernel:[kswapd+115/288] [kernel_thread+40/56] Oct 7 11:50:47 localhost kernel: Code: 0f 0b 83 c4 0c 89 f6 89 da 2b 15 f8 89 26 c0 89 d0 c1 e0 04 Oct 7 11:50:51 localhost kernel: kernel BUG at vmscan.c:538! Oct 7 11:50:51 localhost kernel: invalid operand: Oct 7 11:50:51 localhost kernel: CPU:0 Oct 7 11:50:51 localhost kernel: EIP:0010:[reclaim_page+897/980] Oct 7 11:50:51 localhost kernel: EFLAGS: 00010282 Oct 7 11:50:51 localhost kernel: eax: 001c ebx: c1002aac ecx: c1636000 edx: 0010 Oct 7 11:50:51 localhost kernel: esi: c1002a90 edi: ebp: 0040 esp: c1637e3c Oct 7 11:50:51 localhost kernel: ds: 0018 es: 0018 ss: 0018 Oct 7 11:50:51 localhost kernel: Process cc1 (pid: 2614, stackpage=c1637000) Oct 7 11:50:51 localhost kernel: Stack: c01d4277 c01d4456 021a c020bb20 c020bdb4 c0127548 Oct 7 11:50:51 localhost kernel:c020bb20 c020bdb8 0001 c0127702 c020bdac Oct 7 11:50:51 localhost kernel: 0001 1000 c03a7d60 0001 c04fe080 0007a746 0005 Oct 7 11:50:51 localhost kernel: Call Trace: [tvecs+7135/55752] [tvecs+7614/55752] [__alloc_pages_limit+124/172] [__alloc_pages+394/756] [do_anonymous_page+57/160] [do_no_page+48/192] [handle_mm_fault+232/340] Oct 7 11:50:51 localhost kernel:
Re: Updated 2.4 TODO List
On Mon, 9 Oct 2000 [EMAIL PROTECTED] wrote: * Writing to tapes 2.4G causes tar to fail with EIO (using 2.4.0-test7-pre5; it works under 2.4.0-test1-ac18 --- Tigran Aivazian) this has now been working since test8 and certainly in test9. Why it failed on test7-pre5? Probably some generic scsi-related problem and st was just "in the way". What is important -- it works now. Regards, Tigran - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Calling current() from interrupt context
On Mon, Oct 09, 2000 at 03:54:21AM +0200, Andi Kleen wrote: On Mon, Oct 09, 2000 at 02:45:54AM +0100, Kenn Humborg wrote: On Mon, Oct 09, 2000 at 02:21:09AM +0100, Kenn Humborg wrote: On Mon, Oct 09, 2000 at 02:20:27AM +0200, Andi Kleen wrote: 2.4 TCP code relies on current being valid in a softirq. And what the hell does TCP need current for anyway? I think the only reference is in tcp_input.c, tcp_data_queue(). This does: [...] It is actually used in two places, in the fast path and there. It isn't as bad as it looks because it is only used in user context and could be fixed by putting a special flag into the sock for the execute in user context case (or just supply an argument that is passed around) The point was just that there are probably other users of current in interrupt context and AFAIK it works currently in all ports so you would need to fix these (mostly buggy) occurrences. OK. I'm convinced. current will be valid in interrupt context. If you ever wanted to do a SMP VAX port you would also need to fix smp_processor_id(). No problem. I've already come up with a couple of ways of doing that. Later, Kenn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Newer motherboards / CPU's / hardware with Linux
On Mon, 9 Oct 2000, blizbor wrote: Andre, how are you benchmarking drives ? Direct access below the driver without any file-system getting in the way. No reorder of requests because of linear seeks. These are kernel level tests because timers get set upon the execution of the command block and terminate upon the interrupt regardless. This is not for the faint of heart and the new method to pump/set the request is now broken and I am try to fix it. Cool tests like forced slip-rev seeks will return zone IO data. They may be a way to test and create drive profiles that are stored and reloaded to the kernel that will add the missing supercharge on Andrea's elevator. Basically creating a physical LBA sector profile. Trust that this will be painful to create because this is the secret of the industry and I can not get access to it for Linux, even under full-disclosure NDA's. Have you any idea did such results are really possible ? Could you sugest me better methods ? Yes, but it will not be available until 2.5. These will be PIO and DMA-PRD chains that will then allow for nibble level verification of what the request sent and the stuff on the drive. It may allow a forced-data recovery suite to be created for when you drive craps out. This is because we will access the media directly and not allow the kernel to get in the way of critical recoveries. Another question: looking through ide driver code I've found that there exists bad drive list with comment saying that it's updated when somebody emails bad words about drive. What you think about preparing test utility and let people around the world check and fill database of drives real "capabilities". This way list will be almost completed now, not after few years. Can not do it until 2.5, without the UI/IOCTL needed one can never do what you are asking for without completely writing an ata-bench-module and not compile in the standard ATA/IDE driver. The rewrite of 2.5 will be based on direct pass-through commands. This will allow for 98%+ of the current IRQ disable/blocking to be removed. Also the possible creation of table-io could return a rocket-driver that is expected to give a 16-20X performance gain. Currently with much of the IO setup being done with interrupts block/masked/disable, we see a blanket system slowdown. Doing the setup/command construction ahead of time allows for reduced total system blocking. If you have not guessed by now that drive-profile and table-io are most-likely identical (caution still learning). You can see that I have a wide margin to cover before I can hit limits that are not driver imposed. This will be needed with the new SerialATA stuff, due to the single ended nature of the beasties. I can only guess that IO will approach orders of magnitude faster than what is known today. I can say no more than that it will be fast. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
(OT -- Partition Magic for Linux?) Re: Newer motherboards / CPU's / hardware with Linux
Andre Hedrick wrote: snip They may be a way to test and create drive profiles that are stored and reloaded to the kernel that will add the missing supercharge on Andrea's elevator. Basically creating a physical LBA sector profile. Trust that this will be painful to create because this is the secret of the industry and I can not get access to it for Linux, even under full-disclosure NDA's. Is this the kind of information required to build an application like Partition Magic? It sure would be nice to have a native version of Partition Magic or an Open Source work-alike. Is anyone aware of a project to implement such an Open Source alternative? Thanks, Miles - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Newer motherboards / CPU's / hardware with Linux
On Mon, 9 Oct 2000, Andre Hedrick wrote: snip You are doing Ultra-66 speeds my friend. The fastest ATA drives out that are not public yet are in 39-42mB/s. Also SCSI can not sustain rates much better than maybe 60mB/s. Actually, my other IBM UDMA33 drive did 20mB/s on a 600mB IDE to SCSI transfer in, oh my gosh, Windows NT4 (copied a ISO file), on a UDMA33 controller (also VIA, busmaster driver). And that was on a p166mmx running nicely at 100Mhz x 2.5 (250Mhz). Using a newer ATA66 IBM 7200rpm drive, on a VIA chipset, I can sustain 24-25mB/s in both UDMA33 and ATA66 mode. This is a Athlon Asus K7M system. Running 2.2.17 on the ATA66 chipset, I get a error claiming that the driver does not yet support UDMA3 and 4 when I enable ATA66 and DMA using hdparm -X68 -d 1 -c 1 -k 1 -K 1. That's even with the linux-ide.org 2.2.17 IDE patches. In 2.4 however, it goes up to ATA66 automaticly, as shown by dmesg. (VT82C586 IDE [Apollo]) Sure I can get 100mB/s in ATA on an analizer as can SCSI do 160mB/s in that environment. I was talking 24-25mB/s - not 100mB/s. Bg difference ;-) The 10k rpm u160scsi drive, yet again a IBM, sustains about 34-38mB/s. Remember, I'm not talking fragmented reads here. Thats is a whole different universe. . snip -- Andre Tomt [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[Bench] Slow tiotest read in Kernel 2.2.16+
Ive been seeing poor read results from tiotest in recent 2.2 kernels since 2.2.16. The performance is fine with 1 thread but slows right down with 8. I include the tiotest results here but I see similar results with iozone -t. Kernel 2.2.15 [robert@testmac25 robert]$ tiotest -f 30 -t 8 -r 0 Tiotest results for 8 concurrent io threads: ,--. | Item | Time | Rate | Usr CPU | Sys CPU | +---+--+--+--+-+ | Write 240 MBs | 20.8 s | 11.533 MB/s | 0.3 % | 14.0 % | | Read 240 MBs | 19.2 s | 12.531 MB/s | 0.3 % | 8.9 % | `--' Kernel 2.2.16 [robert@testmac25 robert]$ tiotest -f 30 -t 8 -r 0 Tiotest results for 8 concurrent io threads: ,--. | Item | Time | Rate | Usr CPU | Sys CPU | +---+--+--+--+-+ | Write 240 MBs | 23.9 s | 10.058 MB/s | 0.0 % | 12.8 % | | Read 240 MBs | 105.4 s | 2.276 MB/s | 0.1 % | 2.5 % | `--' Kernel 2.2.18pre15 [robert@testmac25 robert]$ tiotest -f 30 -t 8 -r 0 Tiotest results for 8 concurrent io threads: ,--. | Item | Time | Rate | Usr CPU | Sys CPU | +---+--+--+--+-+ | Write 240 MBs | 22.5 s | 10.688 MB/s | 0.3 % | 12.5 % | | Read 240 MBs | 98.0 s | 2.450 MB/s | 0.1 % | 2.7 % | `--' Robert Cohen TLTSU Unix Support Australian National University - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: will ip 6 in ip4 tunnelling be fixed anytime soon ?
But you are right, here is a bug nobody reported before. I will take care of it. Hmm, your just a bit off here, I believe Gerhard has posted this bug a number of times, further more I have submitted a fix for this bug, but has still not been accepted. Neither has there been any feedback on why ? attached you will find my patch again. it's trivial but works no the less. I hope you will succeed where I have obvious have failed ... regards, Jorg de Jong Hi, I found that creating an ipv6 tunnel with ifconfig does not work. after some comparing between a 2.2 kernel and 2.4.0.testX I found that the name of the newly created sit device is not passed back to the reqestor. See linux/net/ipv6/addrconf.c and follow the call chain. This seems to be introduced by fact that the parameters in 2.4 are copied while in 2.2 kernels this was not the case. My simple patch fixes this one problem. after applying I can now successfuly create ipv6 tunnels with ifconfig. Please apply this patch. thanks, Jorg -- Jorg de Jong Work : mailto:[EMAIL PROTECTED] Play : mailto:[EMAIL PROTECTED] --- linux-2.4.0-test8/net/ipv6/sit.cMon Aug 28 21:03:11 2000 +++ linux/net/ipv6/sit.cTue Aug 15 22:28:27 2000 @@ -188,7 +188,7 @@ } if (i==100) goto failed; - memcpy(parms-name, dev-name, IFNAMSIZ); + memcpy(nt-parms.name, dev-name, IFNAMSIZ); } if (register_netdevice(dev) 0) goto failed;
Re: Calling current() from interrupt context
Hi, The m68k port which has a interrupt stack solves the problem by loading current into a global register variable on all kernel entries. Not all m68k cpus have an interrupt stack and it can be turned off, so we don't use it. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Newer motherboards / CPU's / hardware with Linux
On Mon, 9 Oct 2000, Andre Tomt wrote: Using a newer ATA66 IBM 7200rpm drive, on a VIA chipset, I can sustain 24-25mB/s in both UDMA33 and ATA66 mode. This is a Athlon Asus This okay, the drive has a physical data IO limit for sustained, not burst. Thus getting 24-25mB/s in both UDMA33/ATA66 falls under the limits of each standard. Now the drives that I have that are 37-42mB/s would exceed the UDMA33. You have to understand that in order to get data out you must issue the seek instruct (build and send) then read/write data. Much of the overhead in drive IO is getting there or building the command to do the data part of the IO. using hdparm -X68 -d 1 -c 1 -k 1 -K 1. That's even with the linux-ide.org If you start muckying with the drive setup after you selected the kernel auto-tune or active programming you could have problems. Not all chipset code reprograms the host when changing the drive rates. Thus you can/will cause an IO sync error. I was talking 24-25mB/s - not 100mB/s. Bg difference ;-) The 10k rpm u160scsi drive, yet again a IBM, sustains about 34-38mB/s. Remember, I'm not talking fragmented reads here. Thats is a whole different universe. . Recall that I told you that there is a physical limit of getting stuff off the drives. The platter density is to low and the rpm's are to slow to get there yet. Remember it took second genration ATA66 drives to fill the ATA33 bandwidth. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. I agree this is a small issue, the OOM killer job isn't "nice" at all anyway. B-) (at OOM time, I'd not even look at the nice of a process at all. But my point here is that you do, and you take it as an hint for process importance as percieved by the user that run it, and I believe it's just wrong guessing). .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ISA PnP (2.4.0-test9)
On Mon, 9 Oct 2000, Keith Owens wrote:
On Sun, 8 Oct 2000 23:50:43 +0200 (MEST),
Jaroslav Kysela [EMAIL PROTECTED] wrote:
this patch contains following fixes and enhancements to export ISA
PnP IDs outside the kernel module:
* module.h - added MODULE_GENERIC_TABLE
* isapnp.h - added 'struct isapnp_device_id' for single devices
- added ISAPNP_CARD_TABLE for complex devices
* isapnp.c - fixed NULL pointer dereference in input routine
- fixed timeout (for old ALS100 card)
- added isapnp_probe_devs() and isapnp_activate_dev()
* serial.c - the ISA PnP table was updated using new structure
- the ISA PnP table is exported as well
I have add support for generating modules.isapnpmap to my modutils
tree, basically a clone of modules.pcimap. ISAPNP_CARD_TABLE is more
of a problem.
struct isapnp_card_id {
unsigned short card_vendor, card_device;
struct {
unsigned short vendor, function;
} devs[ISAPNP_CARD_DEVS]; /* logical devices */
unsigned long driver_data; /* data private to the driver */
};
Modutils and the kernel are compiled from different headers, none of
this #include linux/xxx.h business in modutils. So you must never
assume that the structures in modutils and in the kernel have the same
specification. Since ISAPNP_CARD_DEVS is #defined and can be changed,
that value must be exported to user space. Also putting driver_data
after the array might cause parsing problems if the array size changes,
driver_data should be before the array.
Although ISAPNP_CARD_DEVS is #defined, we may take this value as
a constant. I've never seen the cards with more than five logical
devices. I can add a comment that a change of the constant will
cause compatibility problems with modutils.
Another solution is to change ISAPNP_CARD_TABLE to:
#define ISAPNP_CARD_TABLE(name) \
const int __module_isapnp_card_devs = ISAPNP_CARD_DEVS; \
MODULE_GENERIC_TABLE(isapnp_card, name)
But, I think that we don't need this change at the time. If the situation
arises (we found an ISA PnP card with more than eight logical devices), we
may add a global variable to determine the structure change as well. The
change may be also determined with checking of the kernel version.
Solution 1:
struct isapnp_card_id {
unsigned short card_vendor, card_device;
int isapnp_card_devs;
unsigned long driver_data; /* data private to the driver */
struct {
unsigned short vendor, function;
} devs[ISAPNP_CARD_DEVS]; /* logical devices */
};
Moving of driver_data to top of the structure is a good idea.
I'll proceed.
In either case depmod can print modules.isapnp_cardmap data as
Print 1:
# module cardvendor carddevice driver_data vendor function ...
eepro100 0x8086 0x1229 0x 0x8086 0x1229 ... all
non-zero devs entries on one line
I prefer this solution (everything on one line). I don't think that
this format will cause problems for simple parsers.
or as
Print 2:
# module cardvendor carddevice driver_data vendor function
eepro100 0x8086 0x1229 0x 0x8086 0x1229 one
line per non-zero devs entry
Which solution do you want?
Which print format do you want?
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
SuSE Linuxhttp://www.suse.com
ALSA project http://www.alsa-project.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ISA PnP (2.4.0-test9)
On Mon, 9 Oct 2000 12:29:19 +0200 (MEST), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Mon, 9 Oct 2000, Keith Owens wrote: Modutils and the kernel are compiled from different headers, none of this #include linux/xxx.h business in modutils. So you must never assume that the structures in modutils and in the kernel have the same specification. Since ISAPNP_CARD_DEVS is #defined and can be changed, that value must be exported to user space. Although ISAPNP_CARD_DEVS is #defined, we may take this value as a constant. I've never seen the cards with more than five logical devices. I can add a comment that a change of the constant will cause compatibility problems with modutils. "compatibility problems" is putting it mildly. The moment you change the size of that structure, all the people using older modutils will start getting errors and they will blame me, not the person who changed the structure size. Either ISAPNP_CARD_DEVS is set in concrete and *never* changed or the value is exported to user space right from the start. "Export it later" is not an acceptable option because all the old modutils which do not know about the newly exported variable will fail when the structure changes. People are still running modutils 2.1.121 on 2.4 kernels, they just will not upgrade. Any mismatch between kernel and modutils structures is a disaster waiting to happen, we must preserve a compatible userspace ABI for modules. Another solution is to change ISAPNP_CARD_TABLE to: #define ISAPNP_CARD_TABLE(name) \ const int __module_isapnp_card_devs = ISAPNP_CARD_DEVS; \ MODULE_GENERIC_TABLE(isapnp_card, name) But, I think that we don't need this change at the time. If the situation arises (we found an ISA PnP card with more than eight logical devices), we may add a global variable to determine the structure change as well. The change may be also determined with checking of the kernel version. That only works for people who upgrade to newer modutils. It does nothing for the 50%+ of the population who keep running old modutils on new kernels, they will now fail. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ISA PnP (2.4.0-test9)
On Mon, 9 Oct 2000, Keith Owens wrote: On Mon, 9 Oct 2000 12:29:19 +0200 (MEST), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Mon, 9 Oct 2000, Keith Owens wrote: Modutils and the kernel are compiled from different headers, none of this #include linux/xxx.h business in modutils. So you must never assume that the structures in modutils and in the kernel have the same specification. Since ISAPNP_CARD_DEVS is #defined and can be changed, that value must be exported to user space. Although ISAPNP_CARD_DEVS is #defined, we may take this value as a constant. I've never seen the cards with more than five logical devices. I can add a comment that a change of the constant will cause compatibility problems with modutils. "compatibility problems" is putting it mildly. The moment you change the size of that structure, all the people using older modutils will start getting errors and they will blame me, not the person who changed the structure size. Either ISAPNP_CARD_DEVS is set in concrete and *never* changed or the value is exported to user space right from the start. "Export it later" is not an acceptable option because all the old modutils which do not know about the newly exported variable will fail when the structure changes. People are still running modutils 2.1.121 on 2.4 kernels, they just will not upgrade. Any mismatch between kernel and modutils structures is a disaster waiting to happen, we must preserve a compatible userspace ABI for modules. Another solution is to change ISAPNP_CARD_TABLE to: #define ISAPNP_CARD_TABLE(name) \ const int __module_isapnp_card_devs = ISAPNP_CARD_DEVS; \ MODULE_GENERIC_TABLE(isapnp_card, name) But, I think that we don't need this change at the time. If the situation arises (we found an ISA PnP card with more than eight logical devices), we may add a global variable to determine the structure change as well. The change may be also determined with checking of the kernel version. That only works for people who upgrade to newer modutils. It does nothing for the 50%+ of the population who keep running old modutils on new kernels, they will now fail. I fully understand your point, but I don't want to have a special case for ISA PnP. What about this change: #define MODULE_GENERIC_TABLE(gtype,name)\ const struct gtype##_id * __module_##gtype##_table = name to #define MODULE_GENERIC_TABLE(gtype,name)\ const unsigned long __module_##gtype_size = sizeof(struct gtype##_id); \ const struct gtype##_id * __module_##gtype##_table = name This simple change allows runtime checking for size of the used structures. It's not only related for ISA PnP IDs, but also for PCI IDs. All structures may be freely enhanced in future. The modutils binaries may ignore the new contents and/or recommend upgrade. Comments? Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] SuSE Linuxhttp://www.suse.com ALSA project http://www.alsa-project.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Newer motherboards / CPU's / hardware with Linux
On Mon, 9 Oct 2000, Andre Hedrick wrote: huge snip Recall that I told you that there is a physical limit of getting stuff off the drives. The platter density is to low and the rpm's are to slow to get there yet. Remember it took second genration ATA66 drives to fill the ATA33 bandwidth. Yes, you keep telling me that, but one of us seems to have lost something on the way. I get 20-25mB/s on UDMA33, using a 7200RPM IBM ATA66 drive. This is still lower than the spec for UDMA33, if we're not considering overhead. It is possible. The test was done in Windows NT4, using a real file (600mB), with VIA's own busmaster drivers. In Linux, the results are somewhat lower, even with -march=i686 CFLAGS on the kernel, and VIA chipset drivers. Windows NT even got away with lower CPU usage/overhead. MS's default drivers on the other hand, where slow, even in UDMA33/66 mode. Same disk performs almost the same on ATA66, on a newer motherboard and a faster CPU. Where you got the 42 and 100mB/s from is beyond me. I have never claimed anything above the specs, yet. We are way off topic now :-) Now lets stop this dogfight before it gets messy. It's not really belonging on this list anyhow. -- Greets, Andre Tomt [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
53C1010-33 Linux 2.2.17 driver
I'm still looking for a 2.2.17 driver for my Tekram DC390U3W dual channel scsi card. I found drivers for 2.2.16 and below on the lsi and tekram ftp-sites, but applying them causes rejects, and manually fixing the driver makes sg going into an infinite loop during boot. My C knowledge is very broken indeed, I think I'm getting too old for this :-) The chipset is 53C1010-33, symbios/lsi. Backporting from 2.4 was no success either. I could try patching the 2.2.16 source tree, and moving files over, but I don't think thats a god solution either (it could work - but thats it). The sym53c8xx driver handles this card nicely in u160scsi mode using kernel 2.4testX, but I don't want that kernel on this machine. 2.2.17 does not detect the card, and looking at the source, the chip, nor the speeds are not supported either. Is there any support in 2.2.18pre maybe? I really can't check right now - I converted from cable to ISDN/dialup a few days ago, and a already feel my wallet shrinking at a rapid pace (bastards charge by the second). If anyone has some info - I'm wide open :) -- Greets, Andre Tomt [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (OT -- Partition Magic for Linux?) Re: Newer motherboards / CPU's / hardware with Linux
On Mon, Oct 09, 2000 at 02:08:55AM -0700, Miles Lane wrote: Andre Hedrick wrote: snip They may be a way to test and create drive profiles that are stored and reloaded to the kernel that will add the missing supercharge on Andrea's elevator. Basically creating a physical LBA sector profile. Trust that this will be painful to create because this is the secret of the industry and I can not get access to it for Linux, even under full-disclosure NDA's. Is this the kind of information required to build an application like Partition Magic? It sure would be nice to have a native version of Partition Magic or an Open Source work-alike. Is anyone aware of a project to implement such an Open Source alternative? You mean like gpart? laotzu:~# dpkg -s gpart Package: gpart Status: install ok installed Priority: optional Section: admin Installed-Size: 66 Maintainer: David L. Coe [EMAIL PROTECTED] Version: 0.1f-1 Depends: libc6 (= 2.1.2) Description: Guess PC disk partition table, find lost partitions Gpart is a tool which tries to guess the primary partition table of a PC-type disk in case the primary partition table in sector 0 is damaged, incorrect or deleted. . It is also good at finding and listing the types, locations, and sizes of inadvertently-deleted partitions, both primary and logical. It gives you the information you need to manually re-create them (using fdisk, cfdisk, sfdisk, etc.). . The guessed table can also be written to a file or (if you firmly believe the guessed table is entirely correct) directly to a disk device. . Supported (guessable) filesystem or partition types: . DOS/Windows FAT (FAT 12/16/32) Linux ext2 Linux swap partitions versions 0 and 1 (Linux = v2.2.X) OS/2 HPFS Windows NTFS *BSD disklabels Solaris/x86 disklabels Minix FS Reiser FS LVM physical volumes . Other types may be added relatively easily, as separately compiled modules. /David Weinehall _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire / - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.2.17: CPU features bug for AMD?
Browsing patch-2.2.17.gz I found this: linux/arch/i386/kernel/setup.c: Isn't here an "else" or "break" missing? Otherwise ``x86_cap_flags[16] = "pat"'' is always the case, and extended AMD features are always present. @@ -1029,17 +1130,22 @@ case X86_VENDOR_AMD: if (c-x86 == 5 c-x86_model == 6) x86_cap_flags[10] = "sep"; - x86_cap_flags[16] = "fcmov"; + if (c-x86 6) + x86_cap_flags[16] = "fcmov"; + x86_cap_flags[16] = "pat"; + x86_cap_flags[22] = "mmxext"; + x86_cap_flags[24] = "fxsr"; + x86_cap_flags[30] = "3dnowext"; x86_cap_flags[31] = "3dnow"; break; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Marco Colombo wrote: On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. I agree this is a small issue, the OOM killer job isn't "nice" at all anyway. B-) (at OOM time, I'd not even look at the nice of a process at all. But my point here is that you do, and you take it as an hint for process importance as percieved by the user that run it, and I believe it's just wrong guessing). I agree completely. Friday night I had a talk with a few others at the office, and we all came to a concensus that the 'nice' value really shouldn't be a factor to determine which process gets killed first. The primary point was that 'nice' is most commonly used for background tasks that are meant to run in hidden and unseen with low priority. It would be extremely upsetting if a user decided to log in and browse 50 picture-intensive pages with netscape, racking up the memory over time, and allowing the OOM killer to zap the peaceful, 'nice' process in the background that wasn't causing any harm. Why else would you nice a process? Because you don't want it to interfere with normal cpu usage by those that normally use the system. You expect that process to still be running at the end of the day when everyone's gone home. Regards, Byron -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ISA PnP (2.4.0-test9)
On Mon, 9 Oct 2000 12:55:28 +0200 (MEST),
Jaroslav Kysela [EMAIL PROTECTED] wrote:
I fully understand your point, but I don't want to have a special
case for ISA PnP. What about this change:
#define MODULE_GENERIC_TABLE(gtype,name)\
const struct gtype##_id * __module_##gtype##_table = name
to
#define MODULE_GENERIC_TABLE(gtype,name)\
const unsigned long __module_##gtype_size = sizeof(struct gtype##_id); \
const struct gtype##_id * __module_##gtype##_table = name
Make that
#define MODULE_GENERIC_TABLE(gtype,name)\
static const unsigned long __module_##gtype##_size \
__attribute__ ((unused)) = sizeof(struct gtype##_id); \
static const struct gtype##_id * __module_##gtype##_table = name
and you've got a deal. The _size must be static to avoid name clashes
when two or more objects that use MODULE_GENERIC_TABLE(sametype,..) are
linked together. __attribute__ ((unused)) stops the compiler
complaining about unused static variables; we know that they are used
by modutils, not by the code itself.
Ideally __module_##gtype##_size would be in section .modinfo so it did
not get loaded into memory. However modutils expects all .modinfo
entries to be char[] with contents "variable=value" as a character
string. I cannot see any way for MODULE_GENERIC_TABLE(isapnp,name) to
generate
static const char __module_isapnp_size[] \
__attribute__ ((section(".modinfo"))) = \
"module_isapnp_size=42";
Interpolating gtype is easy, even into the middle of the string.
Getting the number '42' instead of 'sizeof(struct isapnp_id)' appears
to be impossible. Neither the # nor ## operators will replace a string
with its constant value. It's times like this that make me wish that C
had a decent macro preprocessor instead of a glorified string replacer.
Requiring m4 to build the kernel is not an option.
ObWarStory: ICL's assembler for George 2/3 (GIN) had brilliant macro
capabilities. All the Assembler internals were accessible to the code
that was being assembled, including functions for string and number
manipulation. You could even compile code as part of your input that
would be immediately executed as if it was the assembler itself then it
would resume assembling the main code. Sometimes newer is not better.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Newer motherboards / CPU's / hardware with Linux
On Mon, 9 Oct 2000, blizbor wrote: On Mon, 9 Oct 2000, Andre Tomt wrote: The fastest ATA drives out that are not public yet are in 39-42mB/s. Also SCSI can not sustain rates much better than maybe 60mB/s. Andre, how are you benchmarking drives ? In context you wrote, I've got rather curious results (maybe due to daulty measurement routines in tar). I've made tar clvf /dev/null --totals and got as follows: for ReiserFS: 53MB/s for ext2fs 27-28 MB/s 2 words: write caching -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- #[Mike A. Harris bash tip #3 - how to disable core dumps] # Put the following at the bottom of your ~/.bash_profile ulimit -c 0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 2.2.16 in redhat 7.0
The kernel provided with the redhat 7.0 cannot be compiled with ip = masquerading on icmp masquerading on (using gcc and kgcc, I got the = same error). I could not found any information about that. Anyone can help ? Can you put the report in Red Hat bugzilla rather than the main kernel list http;//bugzilla.redhat.com/bugzilla ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
VM: do_try_to_free_memory failed for XXXX, 2.2.17, 2.2.18pre3
Hi, I recently changed the kernel from 2.2.15 to 2.2.17 and added new promise 100 card. During 3 days 2 production servers crashed 4 times and had several lockups when there was zillion messages like VM: do_try_to_free_memmory failed for XXX we then changed the kernel to 2.2.18pre3 + ide + raid patches, ( we couldn't revert to 2.2.15 because we needed promise 100 cards to be working.) The situation persists, we have had two crashes on those servers today. The machines are usually very heavily loaded, 5-50. Please help. Are there any patches to fix this behaviour ? Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI problems with v2.2.16 (as shipped with Redhat v7.0)
all attempts to access the scanner, including running the xsane program, or even probing for attached scanners with "scanimage -L" cause the box to run extremely slowly. CTL-C the program accessing the scanner and the system responsiveness returns to normal. What scsi controller card are you using, and is the kernel/box SMP ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: compiling kernel and modules issues
make xconfig make dep make clean [make bzImage] you need the kernel image here make modules make modules_install edit /etc/lilo.conf and add lilo header. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI problems with v2.2.16 (as shipped with Redhat v7.0)
Alan Cox wrote: all attempts to access the scanner, including running the xsane program, or even probing for attached scanners with "scanimage -L" cause the box to run extremely slowly. CTL-C the program accessing the scanner and the system responsiveness returns to normal. What scsi controller card are you using, and is the kernel/box SMP ? Oct 3 09:47:59 watchman kernel: sym53c416.c: Version 1.0.0 Oct 3 09:47:59 watchman kernel: scsi0 : Symbios Logic 53c416 (rev. 151) at 0x220, irq 4, SCSI-ID 7, fast pio Oct 3 09:47:59 watchman kernel: scsi : 1 host. Oct 3 09:48:00 watchman kernel: Vendor: HPModel: C2520ARev: 3644 Oct 3 09:48:00 watchman kernel: Type: Processor ANSI SCSI revision: 02 Oct 3 09:48:00 watchman kernel: Detected scsi generic sg0 at scsi0, channel 0, id 2, lun 0 The box is an old Pentium 133 machine - single processor. Regards, Graham -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: qestion about tcp_v4_hash
On Mon, Oct 09, 2000 at 09:47:43AM +0200, valery brasseur wrote: I have a Oops in the kernel which say's "tcp_v4_hash: bug, socket state is 1" can someone explain me what's wrong ? Hard to say when you don't send the decoded (=run through ksymoops with correct System.map) oops. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Assembler error (2.4.0t9 gcc-2.97)
linux-2.4.0-test9
gcc-2.97 CVS
configured for Athlon
binutils-2.9.5.0.22-6
Do I need an updated binutils maybe?
as --version
GNU assembler 2.9.5
[...]
gcc -D__KERNEL__ -I/usr/src/linux-2.4.0-test9/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=athlon
-fno-strict-aliasing-c -o mmx.o mmx.c
{standard input}: Assembler messages:
{standard input}:151: Error: bad register name `%%mm0'
make[2]: *** [mmx.o] Error 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Window Scale Option broken in 2.2.x
You need to set your /proc/sys/net/core/{w,r}mem* values large enough
for the window scale to have any reason to have a non-zero value.
Later,
David S. Miller
[EMAIL PROTECTED]
OK. That worked. Thanks! It is worth noting that the 2.4.0-test9-pre9
kernel doesn't care about the {r,w}mem_max value (I installed 2.2.16,
2.2.17, and 2.4.0-test9-pre9 on the same machine). So I don't get
caught again later, is there different parameter that affects this
option on the 2.4.x kernel?
--
Lawrence
~
Lawrence MacIntyre Center for Information Infrastructure Technology
[EMAIL PROTECTED] http://www.ciit.y12.doe.gov/~lpz 865.574.8696
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
On Mon, Oct 09, 2000 at 12:19:26AM -0400, [EMAIL PROTECTED] wrote: Linux 2.4 Status/TODO Page * 2.4.0-test2 breaks the behaviour of the ether=0,0,eth1 boot parameter (dwguest) This has been fixed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2.18pre* + raid +ide patches ??
on 10/8/00 4:23 PM, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: I am looking for a solution for the following problem. We have installed some new promise 100 cards and ibm ata 100 disks on some of the servers, assembled the 2.2.17 + ide + raid kernel. Since then we had several crashes on those machines, we get lots of VM: try_to_free_memory_failed for XXX messages. The situation is terrible, we cannot revert to the older kernel, since there are no ide patches for kernels earlier then 2.2.17 that have promise 100 support, and 2.2.17 proves unstable for us. We are looking for some advice on how to assemble, possibly a 2.2.18pre* kernel, that would have VM errors fixed, and would have mingos raid patches + would recognize our new promise 100 cards. Patch the 2.2.17 kernel with ide and raid and then apply 18pre patches to that. If you get rejected pieces you may have to hand merge some but that's how I've done it in the past. -- Darron [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RAMFS ressource limits
Hi there, there has been a patch, which limits the amount of RAM used by ramfs. I didn't find this in the archives (neither public ones nor private). And no, I do NOT think I just dreamed about it ;-) TIA Regards Ingo Oeser -- Feel the power of the penguin - run [EMAIL PROTECTED] esc:x - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: page-mapping == NULL recreated without vmware...
On 6 Oct 00 at 19:25, Petr Vandrovec wrote:
Hi,
month ago I informed here that VMware causes oops on exit.
After some time, and tons of tweaking I was able to recreate
it without vmmon... 2.4.0-test9, no special patches, no
vmware modules loaded...
Machine is dual PIII/450, 256MB RAM, 18GB IDE disk.
Here it is... Adjust MSIZE so that it is almost all of your
memory, to cause swapping... (0x0E00 is for mine 256MB).
Hi,
it looks much worse - no page locking is required - just create
shared mapping, dirty it from someone else, ftruncate() and look how
kernel oopses...
You do not have to be root, if there is no ulimit on shared memory
for you... Maybe it is severe enough to get listed on 2.4 TODO page?
I received no feedback on this...
I'd say that vmtruncate does not work at all, but I'm sure that
somebody should notice such problem already... Also note, that
currently all dirtying is done before ftruncate, so it is completely
legal code. It looks like that pagetables of other processes which are
attached to this mapping are not consulted at all... and if they were
dirty, you'll get nice oopses in filemap_write_page - either from
filemap_swap_out, or from filemap_unmap-filemap_sync... (and even
if pages were not marked dirty, it is bug to have lying around
pages which have mapping == NULL, I think)
Patch for kernel to get text below instead of oopses is still
available at http://platan.vc.cvut.cz/listit (listit without any dot,
yes *.br...).
Tell me if I should try to cut example down even more...
Best regards,
Petr Vandrovec
[EMAIL PROTECTED]
P.S.: And one complaint: If I was dirtying memory with
read(/dev/zero, mma[mmi-1], mml[mmi-1]) (in addition to loop
currently in code), kernel completely STOPPED for up to
40 secs - only console swithching and ping worked, but no schedule() -
- or at least no schedule visible to f.e. TCP inetd/echo, or to mpg123,
or to typing characters on console to bash... As I have 208MB free before
(and after ;-) ) running code below, I do not see any reason for such
strange behavior... It should not take 40 secs to swap out 24MB...
#include sys/mman.h
#include sys/stat.h
#include sys/types.h
#include errno.h
#include stdio.h
#include unistd.h
#include fcntl.h
#include sys/shm.h
#include sys/ioctl.h
#include sys/raw.h
unsigned char zero;
#define MSIZE 0x0E00
void x4768(void) {
int fd;
pid_t pid;
int x4778_1[2];
int x4778_2[2];
int x4779_1[2];
int x4779_2[2];
int from4778;
int to4778;
int from4779;
int to4779;
char* mma[65536];
unsigned int mml[65536];
unsigned int mmi = 0;
unsigned int ln = 0;
unsigned int x;
#define MAL2(a,l) ftruncate(fd, ln+l); mml[mmi] = l; mma[mmi++] = mmap(a, l,
PROT_READ|PROT_WRITE, MAP_SHARED, fd, ln); ln += l; mma[mmi-1][0] = 99;
#define MAL(l) MAL2(NULL,l)
fd = open("ram0", O_RDWR | O_CREAT, 0600);
unlink("ram0");
MAL(MSIZE);
pipe(x4778_1);
pipe(x4778_2);
pid = fork();
if (!pid) {
int from4768 = x4778_1[0];
int to4768 = x4778_2[1];
close(x4778_1[1]);
close(x4778_2[0]);
close(fd);
read(from4768, zero, 1);
for (x = 0; x mml[mmi - 1]; x += 4096)
mma[mmi-1][x] = 98;
write(to4768, zero, 1);
read(from4768, zero, 1);
#if 0
printf("1a: %02X\n", mma[mmi-1][0]);
fflush(stdout);
mma[mmi-1][0] = 99;
printf("1b: %02X\n", mma[mmi-1][0]);
#endif
exit(0);
} else if (pid 0) {
perror("fork failed");
exit(222);
}
to4778 = x4778_1[1];
from4778 = x4778_2[0];
close(x4778_1[0]);
close(x4778_2[1]);
#if 0
pipe(x4779_1);
pipe(x4779_2);
pid = fork();
if (!pid) {
int from4768 = x4779_1[0];
int to4768 = x4779_2[1];
close(x4779_1[1]);
close(x4779_2[0]);
close(to4778);
close(from4778);
close(fd);
read(from4768, zero, 1);
write(to4768, zero, 1);
read(from4768, zero, 1);
#if 0
printf("2a: %02X\n", mma[mmi-1][0]);
fflush(stdout);
mma[mmi-1][0] = 95;
printf("2b: %02X\n", mma[mmi-1][0]);
#endif
exit(0);
} else if (pid 0) {
perror("fork failed");
exit(222);
}
to4779 = x4779_1[1];
from4779 = x4779_2[0];
close(x4779_1[0]);
close(x4779_2[1]);
#else
/* so that read/write to this fails... */
from4779 = -1;
to4779 = -1;
#endif
{
write(to4778, zero, 1);
write(to4779, zero, 1);
read(from4778, zero, 1);
read(from4779, zero, 1);
write(to4778, zero, 1);
write(to4779, zero, 1);
sleep(5);
ftruncate(fd, 0);
}
Re: qestion about tcp_v4_hash
Andi Kleen wrote: On Mon, Oct 09, 2000 at 02:51:28PM +0200, valery brasseur wrote: Andi Kleen wrote: On Mon, Oct 09, 2000 at 09:47:43AM +0200, valery brasseur wrote: I have a Oops in the kernel which say's "tcp_v4_hash: bug, socket state is 1" can someone explain me what's wrong ? Hard to say when you don't send the decoded (=run through ksymoops with correct System.map) oops. -Andi I can't because I have only the bzImage !!! is there anyway to get ksymoops work with it ? Nope, the symbols are already gone. The vmlinux would still help. -Andi the best I can get for now is this : Oct 5 12:36:06 qmpia1 kernel: tcp_v4_hash: bug, socket state is 1 Oct 5 12:36:06 qmpia1 kernel: Unable to handle kernel NULL pointer dereference at virtual address Oct 5 12:36:06 qmpia1 kernel: current-tss.cr3 = 141a5000, %cr3 = 141a5000 Oct 5 12:36:06 qmpia1 kernel: *pde = Oct 5 12:36:06 qmpia1 kernel: Oops: 0002 Oct 5 12:36:06 qmpia1 kernel: CPU:1 Oct 5 12:36:06 qmpia1 kernel: EIP:0010:[tcp_v4_hash+53/172] Oct 5 12:36:06 qmpia1 kernel: EFLAGS: 00010286 Oct 5 12:36:06 qmpia1 kernel: eax: 0024 ebx: dcd3cbc0 ecx: 004a edx: 0020 Oct 5 12:36:06 qmpia1 kernel: esi: cfa0bf74 edi: c0180160 ebp: d5476d1c esp: cfa0bef0 Oct 5 12:36:06 qmpia1 kernel: ds: 0018 es: 0018 ss: 0018 Oct 5 12:36:06 qmpia1 kernel: Process nc (pid: 22019, process nr: 156, stackpage=cfa0b000) Oct 5 12:36:06 qmpia1 kernel: Stack: dcd3cbc0 c017f61a dcd3cbc0 dcd3cbc0 c01801ca dcd3cbc0 d5476d1c cfa0bf74 Oct 5 12:36:06 qmpia1 kernel:c0163018 d5476d1c cfa0bf74 0027 cfa0bf40 d5476d1c cfa0bf6c d5476ccc Oct 5 12:36:06 qmpia1 kernel:cfa0a000 cfa0bf40 c0180160 cfa0bf40 5603 Oct 5 12:36:06 qmpia1 kernel: Call Trace: [inet_autobind+66/156] [inet_sendmsg+106/144] [sock_sendmsg+136/172] [inet_sendmsg+0/144] [sock_write+146/156] [sys_write+240/292] [sock_write+0/156] Oct 5 12:36:06 qmpia1 kernel:[system_call+52/56] Oct 5 12:36:06 qmpia1 kernel: Code: c7 05 00 00 00 00 00 00 00 00 83 c4 08 8a 43 28 3c 0a 75 17 -- Valery BRASSEUR| Phone # +33 320 60 7982 Atos Branche Multimedia| Fax # +33 320 60 7649 Unix is like a 'hogan' -- no Gates, no Windows, and an Apache inside - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Alan Cox wrote: At this point, I would prefer that we just leave the ordering alone - I don' tknow of any actual problems with it, and I don't think it's worth re-organizing things to make it the exact same thing it used to be.. SCSI has real ordering requirements for drivers. You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver and in the 17xx case data corruption risks You must do scsi before i2o_scsi or AMI Megaraids break My point exactly. The ordering of driver in drivers/scsi is done now, but I don't see a clean way of doing I2O without moving upperlayers into a seperate dir. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 53C1010-33 Linux 2.2.17 driver
On Mon, Oct 09, 2000 at 01:05:10PM +0200, Andre Tomt wrote: The sym53c8xx driver handles this card nicely in u160scsi mode using kernel 2.4testX, but I don't want that kernel on this machine. 2.2.17 does not detect the card, and looking at the source, the chip, nor the speeds are not supported either. Look at Gérard Roudier's [EMAIL PROTECTED] ftp site ftp://ftp.tux.org/pub/tux/roudier/ to find updated sym53c8xx drivers. The sym53c8xx-1.7.1 which supports the 53c1010 just fine was added to 2.2.18pre3, so any later 2.2.18pre shoud do the job for you. Regards, -- Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: Updated 2.4 TODO List
* RTL 8139 cards sometimes stop responding. Both drivers don't handle this quite good enough yet. (reported by Rogier Wolff, tentatively reported as fixed by David Ford.) 2.4.0-test9 Spontaneous reboots under network load with this driver. Sorry, no more info. 2.4.0-t9-p7 No reboots but lots of errors on the interface. But, it does work. A diff between the two 8139too.c files in these kernels reveals no differences. shane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Reiserfs + 2.2.18 + alpha noritake
Anyone tried this combination? I had one small compile problem in the driver (which was a return code, something about HASH, I forget now, but it's only defined for i386) After that, mkfs and attempted to mount didn't work. the driver couldn't find a valid fs on the drive. I have successfully done this on an x86 machine. -- Lab tests show that use of micro$oft causes cancer in lab animals - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, Oct 09, 2000 at 12:12:02PM +0200, Marco Colombo wrote: On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. I could not agree more. Normally, you'd better kill a foreground task (running nice 0) than selecting one of those background jobs for some reasons: * The foreground job can be restarted by the interactive user (Most likely, it will be only netscape anyway) * The background job probably is the more useful one which has been running since a longer time (computations, ...) * If we put any policy like this into the kernel at all, I'd rather encourage the usage of nice instead of discouraging it. I assume here backgrd job == niced job, which mostly is the case in reality. Regards, -- Kurt Garloff [EMAIL PROTECTED] Eindhoven, NL GPG key: See mail header, key servers Linux kernel development SuSE GmbH, Nuernberg, FRG SCSI, Security PGP signature
Re: SCSI problems with v2.2.16 (as shipped with Redhat v7.0)
Graham Leggett wrote: all attempts to access the scanner, including running the xsane program, or even probing for attached scanners with "scanimage -L" cause the box to run extremely slowly. CTL-C the program accessing the scanner and the system responsiveness returns to normal. What scsi controller card are you using, and is the kernel/box SMP ? Oct 3 09:47:59 watchman kernel: sym53c416.c: Version 1.0.0 [snip] Graham, The sg driver used in RH 7.0 [sg version 2.1.38] breaks the sym53c416 driver. Please try sg 2.1.39 (as found in lk 2.2.17) which can be found at: http://www.torque.net/sg and tell me if that fixes it. BTW Read the note at the end of that page. Redhat have backported the RT signal patch which changes the number of parameters to the kill_fasync() call made by sg. It is safe to add a 3rd argument of POLL_IN to that call otherwise the compile breaks . Doug Gilbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
usb and smp problems with 2.4.0-test9/2.2.18-pre15
hello, i haven't been on lkml since vger died, but just subscribed and looked at the archives and was unable to find anything on this... i'm running 2.4.0-test9 and 2.2.18-pre15. for both of these kernels, if i enable usb and smp, i get a lot of usb device timeout errors. if i recompile, just disabling smp, the usb devices work fine. i'm using a tyan tiger 133 (1854d, i believe) mobo (via apollo pro 133a chipset). this is with both redhat 6.2 and 7.0 (thought it might be gcc 2.96, but it seems to happen with both). i also tried both the normal UHCI and JE's UHCI drivers, but there's no change. any ideas? any more information i can provide to help? thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: No SCSI burning problem - ZIP reading problem
Andre Hedrick wrote:
Something like this?
Close but now there is no select.
--- /opt/kernel/linux-2.4.0-test9/drivers/scsi/ide-scsi.c Sat Sep 23
I'm having some serious problems with parallel port ZIP with latest
2.4.0-test9 kernel
Oct 9 16:57:23 dual kernel: Detected scsi removable disk sda at scsi0,
channel
Oct 9 16:57:24 dual kernel: sda : READ CAPACITY failed.
Oct 9 16:57:24 dual kernel: sda : status = 0, message = 00, host = 0,
driver =
Oct 9 16:57:24 dual kernel: sda : extended sense code = 2
Oct 9 16:57:24 dual kernel: sda : block size assumed to be 512 bytes,
disk size
Oct 9 16:57:24 dual kernel: /dev/scsi/host0/bus0/target6/lun0: I/O
error: dev
Oct 9 16:57:24 dual kernel: unable to read partition table
Oct 9 16:57:24 dual kernel: Device not ready. Make sure there is a
disc in the
Oct 9 16:57:24 dual kernel: sda : READ CAPACITY failed.
Oct 9 16:57:24 dual kernel: sda : status = 0, message = 00, host = 0,
driver =
Oct 9 16:57:24 dual kernel: sda : extended sense code = 2
Oct 9 16:57:24 dual kernel: sda : block size assumed to be 512 bytes,
disk size
It is maybe related to the problem with ATAPI CD Writers.
I'm not sure what's causing these problems - all I can say is that
I've no such problem with 2.2.18pre15 booted on the same SMP machine
(BP6)
and ZIP works just fine.
by
--
There are three types of people in the world:
those who can count, and those who can't.
Zdenek Kabelac http://i.am/kabi/ [EMAIL PROTECTED] {debian.org; fi.muni.cz}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver and in the 17xx case data corruption risks You must do scsi before i2o_scsi or AMI Megaraids break My point exactly. The ordering of driver in drivers/scsi is done now, but I don't see a clean way of doing I2O without moving upperlayers into a seperate dir. Link scsi as a whole before i2o ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb and smp problems with 2.4.0-test9/2.2.18-pre15
oh, btw, i also tried an asus p2b-ds mobo with the intel bx chipset with the same results. pete On Mon, 09 Oct 2000, Pete Toscano wrote: hello, i haven't been on lkml since vger died, but just subscribed and looked at the archives and was unable to find anything on this... i'm running 2.4.0-test9 and 2.2.18-pre15. for both of these kernels, if i enable usb and smp, i get a lot of usb device timeout errors. if i recompile, just disabling smp, the usb devices work fine. i'm using a tyan tiger 133 (1854d, i believe) mobo (via apollo pro 133a chipset). this is with both redhat 6.2 and 7.0 (thought it might be gcc 2.96, but it seems to happen with both). i also tried both the normal UHCI and JE's UHCI drivers, but there's no change. any ideas? any more information i can provide to help? thanks, pete -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: [OOPS] unloading ns558 driver in Linux 2.4.0-test9
On Sat, Oct 07, 2000 at 12:42:16PM -0400, Brian Gerst wrote: "Forever shall I be." wrote: I got this OOPS while unloading the ns558 module.. I don't think it did this in 2.4.0-test8, but I don't recall ever unloading it in test8.. I've attached the ksymoops output.. -- Zinx Verituse(See headers for gpg/pgp key info) oops.outName: oops.out Type: Plain Text (text/plain) What kind of game port do you have? I think this bug is already fixed in the input CVS. I've sent a patch to Linus now. -- Vojtech Pavlik SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (OT -- Partition Magic for Linux?) Re: Newer motherboards / CPU's / hardware with Linux
On Mon, Oct 09, 2000 at 02:08:55AM -0700, Miles Lane wrote: like Partition Magic? It sure would be nice to have a native version of Partition Magic or an Open Source work-alike. Is anyone aware of a project to implement such an Open Source alternative? ftp://ftp.gnu.org/gnu/parted -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
i2o_block.c: you don't need EXPORT_NO_SYMBOLS (yes, I know it was there before) I put it there intentionally. It exports no symbols. I dont want the module stuff therefore exporting everything in that file. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Alan Cox wrote: You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver and in the 17xx case data corruption risks You must do scsi before i2o_scsi or AMI Megaraids break My point exactly. The ordering of driver in drivers/scsi is done now, but I don't see a clean way of doing I2O without moving upperlayers into a seperate dir. Link scsi as a whole before i2o ? Yes, that can be done pretty easy, but Then I2O will link core - hosts - upper - I2O and I'm not sure this is okay. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: (OT -- Partition Magic for Linux?) Re: Newer motherboards / CPU's/ hardware with Linux
Miles writes: Is this the kind of information required to build an application like Partition Magic? It sure would be nice to have a native version of Partition Magic or an Open Source work-alike. Is anyone aware of a project to implement such an Open Source alternative? The GNU parted program is a partition-magic work-alike. I think you can find it at parted.gnu.org. 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, 9 Oct 2000, Alan Cox wrote: SCSI has real ordering requirements for drivers. You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver and in the 17xx case data corruption risks Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_ the other ones. Or did that change in the later 2.2.x series? You must do scsi before i2o_scsi or AMI Megaraids break So change the drivers/Makefile to put scsi before i2o and drivers/scsi/Makefile to do the aha17xx thing first, and we're all done. (Not that I think any distribution would come with i2o even enabled at this point, and the scsi ones all tend to be modules too). End of story. No "reorganizations" needed. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, 9 Oct 2000, Torben Mathiasen wrote: My point exactly. The ordering of driver in drivers/scsi is done now, but I don't see a clean way of doing I2O without moving upperlayers into a seperate dir. Why? People would tend to use the i2o ones as modules anyway, so they _have_ to work with them all being after the upper layer stuff anyway. Otherwise they didn't even work before (common case: say 'y' to SCSI, say 'm' to the low-level drivers). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, 9 Oct 2000, Alan Cox wrote: Link scsi as a whole before i2o ? Yup. Also, we should really finalise the host order thing in scsi/Makefile. If it's true that aha17xx must come before aha1542, it's wrong as it stands now. Any other gotchas that were caught in 2.2.x? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb and smp problems with 2.4.0-test9/2.2.18-pre15
On Mon, Oct 09, 2000 at 12:36:46PM -0400, Pete Toscano wrote: any more information i can provide to help? Yes: What kind of timeout errors are you seeing? Kernel debug logs would be helpful. What devices are you trying to use? What is your .config file? What is your BIOS setting for MPS (if it's 1.4, please try 1.1)? There are quite a few broken USB drivers in 2.4.0-test9. See the linux-usb-devel mailing list for the patches, or I can send them to you if you want. I'm successfully running USB on a smp machine for both 2.4.0-test9 (with extra USB patches) and 2.2.18pre15 with no problems. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, 9 Oct 2000, Torben Mathiasen wrote: Link scsi as a whole before i2o ? Yes, that can be done pretty easy, but Then I2O will link core - hosts - upper - I2O and I'm not sure this is okay. Think modules. Remember how it has always worked. The above is pretty much how all the default builds for distributions have been: the "scsi" kernel comes with a few (the most common) host controller drivers built in, and everything else is a module. And a module is basically the same as being dead last in the linking order. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: destroyed shm segments in 2.2
Could we change the behaviour in 2.2 like we did it in 2.3 and make it more compatible with other UN*Xes? The attached (untested) patch should implement the 2.4 behaviour. Maybe, but not for 2.2.18 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Linus Torvalds wrote: On Mon, 9 Oct 2000, Alan Cox wrote: Link scsi as a whole before i2o ? Yup. Also, we should really finalise the host order thing in scsi/Makefile. If it's true that aha17xx must come before aha1542, it's wrong as it stands now. Any other gotchas that were caught in 2.2.x? Okay. I'll wait a few hours for additional host adapter information, and then send a patch with the i2o stuff included. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] console palette fix
I've seen the problem on both of my computers with Creative Riva TNT2. On this card the palette turns darker. On other cards the palette turns to rubbish or corrupted in another fashionable ways. It's a bug in those cards - switching to video mode and back to text mode doesn't preserve the text mode palette so the OS must restore it by itself. Now looking closer to the XFree86 code your right. It is buggy hardware. XFree86 X servers do attempt to reset the VGA palette themselves for all cards. It is basic code and should work on all video cards. about this problem exactly. Read the console.c of 2.4 - Linus already patched it this way (your patch and then my patch), so I suggest we do the same in 2.2. Agree. Alan please patch 2.2.X with both are patches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: usb and smp problems with 2.4.0-test9/2.2.18-pre15
greg, machine's at home and in a bit of a wedged state, so i can't get this info to you right away, but i will if you think it'll help debug the issue. from what you say, the people on the linux-usb-devel list already have patches for these things, so i'm wondering if it'll be useful. anyway, i don't recall all of the usb errors, but i think there was "breadth" in it, it had about four lines of error message produced and they kept repeating until i unplugged all usb devices, and there were timeouts. useful, eh? =8] like i said, i can get this info to you if you think it'd be helpful. i'm using a usb mouse. i have two usb hubs -- one in my keyboard (ms natural pro) and one in my monitor (nokia 446xpro). i also have a usb compact flash card reader and a rio 500. the mouse and the reader are usually plugged into the monitor and the rio is plugged into the keyboard, if at all. i'll send my .config file if you think it'd be helpful. it's set to mps 1.1. linux has issues with 1.4? if it's not a problem, would you please send the patches or point me to where i can pick them up? thanks, pete On Mon, 09 Oct 2000, Greg KH wrote: On Mon, Oct 09, 2000 at 12:36:46PM -0400, Pete Toscano wrote: any more information i can provide to help? Yes: What kind of timeout errors are you seeing? Kernel debug logs would be helpful. What devices are you trying to use? What is your .config file? What is your BIOS setting for MPS (if it's 1.4, please try 1.1)? There are quite a few broken USB drivers in 2.4.0-test9. See the linux-usb-devel mailing list for the patches, or I can send them to you if you want. I'm successfully running USB on a smp machine for both 2.4.0-test9 (with extra USB patches) and 2.2.18pre15 with no problems. thanks, greg k-h -- Pete Toscanop:[EMAIL PROTECTED] w:[EMAIL PROTECTED] GPG fingerprint: D8F5 A087 9A4C 56BB 8F78 B29C 1FF0 1BA7 9008 2736 PGP signature
Re: VM in v2.4.0test9
On Sun, 8 Oct 2000, Linus Torvalds wrote: On Wed, 4 Oct 2000, Rik van Riel wrote: The potential for this bug has been around since 2.3.51, when different balance_ratios for different zones became possible. You must NOT depend on some global "freepages" thing. Don't do this patch. Fix it for real instead. You can use the global amount of free memory for heuristics, but you MUST NOT use it for deciding to not page stuff out etc - because you will _always_ end up with cases where you decide that you globally have enough memory even though locally there is a memory shortage (or the other way around - you end up thinking that there is a global memory shortage even if all local memories are plenty fine, so you end up trying to swap stuff out when it shouldn't be done). Please read mm/vmscan.c::free_shortage() The code honours /both/ global and local shortages. (but indeed, we shouldn't - and in retrospect don't - depend on global values and can make /proc/sys/vm/freepages writable again so the sysadmin can give a balancing hint on how many free pages to keep around ... which may be important for folks doing gigabit routing) regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Calling current() from interrupt context
In article [EMAIL PROTECTED], Kenn Humborg [EMAIL PROTECTED] wrote: I'd just like to confirm that it's illegal to call current() from interrupt-handling code. It's not categorically forbidden. It does indeed happen, think about things like cross-CPU interrupts for TLB invalidations etc. At the very least such interrupts are interested in the "current CPU" - which on most architectures is defined to "current-processor". Also, there's been some work on recursive spinlocks, which also used "current" as the test for recursion. You might be able to avoid it by using other approaches (most of this code tends to be architecture-specific anyway). I think you are right in general, but there are certainly things to look out for, just in case. (And taking a trap in an interrupt handler prints out an oops message: you can expect no end of confusion and debugging problems if "current" is not valid at that point - lots of small details that probably make this fairly painful). Note that there are alternative approaches. For example, you could make the interrupt stack be in the same multi-page as the regular stack, and switch them both at task-switch time - just allocate four pages instead of two, and use "current = esp ~16383" instead or something like that. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4 kernel wiki for October
Sigh... Do a search on Brook's Law, will you? You lose because the project isn't late yet ;-) Brooks' law has certain assumptions in it that are not applicable to a low communication cost, highly parallel environments - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
Alan Cox wrote: 4. Boot Time Failures * IBM Thinkpad 390 won't boot since 2.3.11 (See Decklin Foster for more info) Add Palmax PD1100 hangs during boot since 2.4.0-test9 My Asus P55TP4 (i430FX)/AMD K5 PC also crashes after "Booting the kernel..." and before printing anything else Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Marco Colombo wrote: On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. In that case the time the process has been running and the CPU time used will save the process if it's been running for a long time. Please read the /entire/ algorithm before making rash conclusions like this. If nice is used for important, long-running tasks, the fact that they are long-running will save them (and be honest, would you really care if a simulation would be killed after 5 minutes? it's only inconvenient if it gets killed after a few hours...) But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. This doesn't make ANY sense at all. The objective is to destroy the least amount of work, which means giving a bonus to processes which have used a lot of CPU time already ... regardless of nice value. all. But my point here is that you do, and you take it as an hint for process importance as percieved by the user that run it, and I believe it's just wrong guessing). If you have a better algorithm, feel free to send patches. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Tux 2 patents
For what it's worth, the system was called "Jackdaw" and was written by Mike Challis. It was in extensive use on the University's MVT/MVS/MVSXA mainframe for many years as the database for holding user information. The document Alain's got is probably Computer Laboratory Technical Report no. 1 (yes, One!). If it isn't, and you need it, see http://www.ftp.cl.cam.ac.uk/ftp/papers/reports/TR.txt Jackdaw was phased out when the mainframe was decommissioned about 5 years ago. Mike's still around, but I think he's retired. -- Timothy At 10:00 PM 10/5/00 +, Alain Williams wrote: Hi, I remember when at the University of Cambridge (in England) about 25 years ago seeing some work then about the Jackdaw (or was is Jackard) database system that had the great feature of being immune to OS crashes, it used a phased update mechanism where new blocks were written to disk and the last block written was the one that contained the switched pointer, until this last block had been written the changes had not been made. Since the write of a disk block was atomic the database would never be corrupt. If someone wants I think that I still have a (paper) copy of the report describing this. I can send/fax a copy if wanted. I don't subscribe to this list, so please reply direct if someone wants it. (Please don't request a copy just out of curiosity since I don't want to have to post/fax copies that won't help resolve this case by showing prior art.) Cheers -- Alain Williams - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
Also, we should really finalise the host order thing in scsi/Makefile. If it's true that aha17xx must come before aha1542, it's wrong as it stands now. Any other gotchas that were caught in 2.2.x? Those are the only ones I know Buslogic cards and AHA174x cards both emulate an aha1542 but have a native driver. The 174x has a buggy emulation that can cause corruption. The megaraid and scsi then i2o one comes about because some cards are both scsi native and i2o interfaced and scsi native is the preferred API in all current cases. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver and in the 17xx case data corruption risks Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_ the other ones. Or did that change in the later 2.2.x series? I will double check that with Eric Youngdale. It may be the driver in the 1542 code was changed to detect a 17xx and leave it alone at some point in 2.0 days. The buslogic one the comments still claim is needed You must do scsi before i2o_scsi or AMI Megaraids break So change the drivers/Makefile to put scsi before i2o and drivers/scsi/Makefile to do the aha17xx thing first, and we're all done. Yep. (Not that I think any distribution would come with i2o even enabled at this point, and the scsi ones all tend to be modules too). Actually RH7 does I believe support it, but modular. End of story. No "reorganizations" needed. Agreed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Linus Torvalds wrote: On Mon, 9 Oct 2000, Torben Mathiasen wrote: My point exactly. The ordering of driver in drivers/scsi is done now, but I don't see a clean way of doing I2O without moving upperlayers into a seperate dir. Why? I was referring to Alan's statement about i2o should be the last lowlevel driver before the upper layers. I'm not familar with the i2o code, just thought there was a reason. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Kurt Garloff wrote: I could not agree more. Normally, you'd better kill a foreground task (running nice 0) than selecting one of those background jobs for some reasons: * The foreground job can be restarted by the interactive user (Most likely, it will be only netscape anyway) * The background job probably is the more useful one which has been running since a longer time (computations, ...) Ick. A background job that's been running for a long time will be saved by that, as Rik pointed out. If I've got a background process running for 30 minutes, and a Netscape with 5 windows open that I'm using (for long or not, doesn't matter), guess which one I'd rather died? Not Netscape -- I'm using that and I'll never remember how to find those 5 windows again if it just dies. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
Yes, that can be done pretty easy, but Then I2O will link core - hosts - upper - I2O and I'm not sure this is okay. Thats fine. I2O scsi is the last scsi driver anyway, the rest of i2o registers devices on different majors with no ordering issues - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Andrea Arcangeli wrote: On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote: In the OOM killer, shouldn't there be a check for PID 1 just to enforce that Init can't be killed in 2.2.x latest, the same bugfix should be forward ported to 2.4.x. I believe we should not special-case init in this case. If the OOM would kill init then we *want* to know about it ASAP, because it's either a bug in the OOM code or a memory leak in init. Both things are very bad, and ignoring the kill would just preserve those bugs artificially. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
dvd mounting troubles
I'm having real trouble mounting a dvd (udf filesystem) in my Pioneer 104S drive. It usually failes with: mount: wrong fs type, bad option, bad superblock on /dev/dvd, or too many mounted file systems but it succeeds sometimes. For a while I've been inserting the dvd, waiting until the drive spins up and reads the cd, then mounting right after the drive light goes out and it'll succeed. Other times it'll fail and I can wait until the drive spins back down and try the mount again and it'll succeed. But usually it just errors out. I read somewhere about similar problems and it said to change a TIMEOUT in drivers/scsi/sr.c but this is an IDE drive. Any suggestions? -- Rick ([EMAIL PROTECTED]) http://www.kuroyi.net I think the slogan of the fansubbers puts it best: "Cheaper than crack, and lots more fun." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
On Mon, Oct 09 2000, Alan Cox wrote: Yes, that can be done pretty easy, but Then I2O will link core - hosts - upper - I2O and I'm not sure this is okay. Thats fine. I2O scsi is the last scsi driver anyway, the rest of i2o registers devices on different majors with no ordering issues Excellent. But Alan, you wrote earlier that i2o needed to be the last host adapter and _before_ the upper layers. This is what made me start this patch. -- Torben Mathiasen [EMAIL PROTECTED] Linux ThunderLAN maintainer http://tlan.kernel.dk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH] Re: wasting time on page fault
On Wed, 04 Oct 2000, Brian Gerst wrote: Mikulas Patocka wrote: Hi. arch/i386/kernel/entry.S xchgl %eax, ORIG_EAX(%esp) # orig_eax (get the error code. ) movl %esp,%edx xchgl %ecx, ES(%esp)# get the address and save es. pushl %eax # push the error code xchg with memory operand has implicit lock prefix and is slooow. It is Here is a patch that removes the xchg instructions. As an interesting note, I tested the difference in cycles between one xchgl and two movl instructions on 3 different processors (a Celeron, a K6-2, and an Athlon, all UP). The celeron and K6-2 showed noticable improvements. The real surprise was the the Athlon, where the times were identical. This means that either the Athlon has a really fast lock cycle or it is ignoring it. I also did some testing on the performance of xchgl reg1,(reg2) vs the the equivalent (but non-locked) sequence using 3 moves and a scratch reg: Pentium II/III xchgl takes 19 cycles 3 moves takes just under 3 cycles - xchgl is more than 6 times slower K6-III xchgl takes 77 (!!) cycles 3 moves takes just under 2 cycles - xchgl is more than 38 times slower We could also do the following: 1. Move the error_code block from divide_error to page_fault; this removes one jump from the page_fault path. 2. Apply Brian's patch to replace xchgl with ordinary moves; this is an improvement for all faults. 3. Move the page_fault/error_code block to immediately precede ret_from_exception; this removes one jump from the return path and is an improvement for all faults. The patch below against 2.4.0-test9 implements this. I'm been running with this in place for a while now, with no observable negative effects. I also disassembled arch/i386/kernel/entry.o before and after the patch and verified that it didn't cause any short-offset jumps in frequently executed paths to become long-offset jumps. /Mikael --- linux-2.4.0-test9/arch/i386/kernel/entry.S.~1~ Wed Oct 4 16:03:19 2000 +++ linux-2.4.0-test9/arch/i386/kernel/entry.S Mon Oct 9 16:30:16 2000 @@ -256,7 +256,35 @@ movl $-ENOSYS,EAX(%esp) jmp ret_from_sys_call - ALIGN +ENTRY(page_fault) + pushl $ SYMBOL_NAME(do_page_fault) + ALIGN /* for the benefit of the other exception paths */ +error_code: + pushl %ds + pushl %eax + xorl %eax,%eax + pushl %ebp + pushl %edi + pushl %esi + pushl %edx + decl %eax # eax = -1 + pushl %ecx + pushl %ebx + cld + movl %es,%ecx + movl ORIG_EAX(%esp), %esi # get the error code + movl ES(%esp), %edi # get the function address + movl %eax, ORIG_EAX(%esp) + movl %ecx, ES(%esp) + movl %esp,%edx + pushl %esi # push the error code + pushl %edx # push the pt_regs pointer + movl $(__KERNEL_DS),%edx + movl %edx,%ds + movl %edx,%es + GET_CURRENT(%ebx) + call *%edi + addl $8,%esp ret_from_exception: #ifdef CONFIG_SMP GET_CURRENT(%ebx) @@ -291,32 +319,7 @@ ENTRY(divide_error) pushl $0# no error code pushl $ SYMBOL_NAME(do_divide_error) - ALIGN -error_code: - pushl %ds - pushl %eax - xorl %eax,%eax - pushl %ebp - pushl %edi - pushl %esi - pushl %edx - decl %eax # eax = -1 - pushl %ecx - pushl %ebx - cld - movl %es,%ecx - xchgl %eax, ORIG_EAX(%esp) # orig_eax (get the error code. ) - movl %esp,%edx - xchgl %ecx, ES(%esp)# get the address and save es. - pushl %eax # push the error code - pushl %edx - movl $(__KERNEL_DS),%edx - movl %edx,%ds - movl %edx,%es - GET_CURRENT(%ebx) - call *%ecx - addl $8,%esp - jmp ret_from_exception + jmp error_code ENTRY(coprocessor_error) pushl $0 @@ -408,10 +411,6 @@ ENTRY(alignment_check) pushl $ SYMBOL_NAME(do_alignment_check) - jmp error_code - -ENTRY(page_fault) - pushl $ SYMBOL_NAME(do_page_fault) jmp error_code ENTRY(machine_check) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Link order of drivers outside drivers/scsi
Excellent. But Alan, you wrote earlier that i2o needed to be the last host adapter and _before_ the upper layers. This is what made me start this patch. Sorry. Then I was unclear and I sent you off doing un-needed work. Apologies - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: {PATCH] Re: wasting time on page fault
On Mon, Oct 09, 2000 at 08:37:55PM +0200, Mikael Pettersson wrote: We could also do the following: 1. Move the error_code block from divide_error to page_fault; this removes one jump from the page_fault path. It is not clear that it is worth it. You want to align error_code and page_fault to 16 or 32 bytes bytes at least, and it would need to execute some nops depending on the length for fallthrough The jmp may be actually faster. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Ingo Molnar wrote: If you have a better algorithm, feel free to send patches. yes. Please remove the above part. OK, done. Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, Oct 09, 2000 at 08:42:26PM +0200, Ingo Molnar wrote: ignoring the kill would just preserve those bugs artificially. If the oom killer kills a thing like init by mistake or init has a memleak you'll notice both problems regardless of having a magic for init in a _very_ slow path so I don't buy your point. . For corretness init must not be killed ever, period. So you have two choices: o math proof that the current algorithm without the magic can't end killing init (and I should be able to proof the other way around instead) o have a magic check for init So the magic is _strictly_ necessary at the moment. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Rik van Riel wrote: On Mon, 9 Oct 2000, Marco Colombo wrote: On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. In that case the time the process has been running and the CPU time used will save the process if it's been running for a long time. Please read the /entire/ algorithm before making rash conclusions like this. If nice is used for important, long-running tasks, the fact that they are long-running will save them (and be honest, would you really care if a simulation would be killed after 5 minutes? it's only inconvenient if it gets killed after a few hours...) Main point is that in many enviroments the niced processes are the ones the system exists for in the first place. I.e they are the most important ones. It would be completely unacceptable, say in research enviroment I know, if my computational job will be killed because somebody launches Netscape or some interactive game. The OS which does this is then will not be considered suitable for research. Niced processes are usually the most complex one organizationally, and quite often are fairly complex to launch (not just click a button on your Gnome panel). Moreover background niced processes by definition are typically run unattended so need to relaunch has yet to be detected. I, for example, typically lauch sequence of simulations simultaniously on 20 Alphas running Linux, which then run for 3-4 days. So yes, I do care that simulations are not killed after 5 minutes. because, first I have to notice this (or write and run monitoring program), second I have to find what was exactly run on this specific machine which was killed and so on. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. This doesn't make ANY sense at all. The objective is to destroy the least amount of work, which means giving a bonus to processes which have used a lot of CPU time already ... regardless of nice value. Well, at the given CPU time spent, the niced process used much more real time than unniced. So the loss in terms of human hours is larger when it is killed. It shows quickly when you have some deadline to meet.Believe it is not pleasant to come in the morning and find the simulations you launched overnight disappeared. The day you planned on spending analysis the output results is gone. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Andrea Arcangeli wrote: On Mon, Oct 09, 2000 at 08:42:26PM +0200, Ingo Molnar wrote: ignoring the kill would just preserve those bugs artificially. If the oom killer kills a thing like init by mistake That only happens in the "random" OOM killer 2.2 has ... So you have two choices: o math proof that the current algorithm without the magic can't end killing init (and I should be able to proof the other way around instead) o have a magic check for init So the magic is _strictly_ necessary at the moment. No. It's only needed if your OOM algorithm is so crappy that it might end up killing init by mistake. Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
pppoe and pppox circular dependencies in test9
2.4.0-test9 modules.dep reports that pppox needs pppoe and pppoe needs pppox. modprobe pppo(e|x) segfaults (out of memory???). --- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
pppoe and pppox circular dependencies in test9
Meelis Roos writes: 2.4.0-test9 modules.dep reports that pppox needs pppoe and pppoe needs pppox. modprobe pppo(e|x) segfaults (out of memory???). A fix has been submitted. If you need a quick fix, do not compile as a module, or remove line 158 of pppox.c. Michal Ostrowski [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Rik van Riel wrote: On Mon, 9 Oct 2000, Marco Colombo wrote: On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. In that case the time the process has been running and the CPU time used will save the process if it's been running for a long time. Please base this on more on real time, not CPU time. Netscrape consumes an ungodly amount of CPU time and memory and I'd much rather have it killed before anything else on the system. If it wasn't blatantly obvious, I'd check the argv[0] to see if it was "netscape" and kill it. :] This doesn't make ANY sense at all. The objective is to destroy the least amount of work, which means giving a bonus to processes which have used a lot of CPU time already ... regardless of nice value. But that favors ill written programs if it's based on CPU time. I.e. netscape and all the gnome/kde "tasklets" that take 8 megs w/ 6megs RSS and .9% of a pIII-450 to manage the keyboard and mouse properties. If you have a better algorithm, feel free to send patches. Step A) A heuristic that tags the program or process group consuming the most RAM in the last N real minutes. A run-away process is the highest target here and is most correctly the guilty party. Step B) A sliding scale of the youngest real program or process group consuming the most RAM. Step C) ... -d -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
2.4.0-test9 + Winchip2/2A processor family == hang on boot
Hiya,
Subject says it all... If I select 'Winchip 2' or 'Winchip 2A/Winchip 3' for
'Processor Family' and try to boot the kernel on an iopener with a Winchip 2A,
the show stops right after the 'decompressing the kernel...' line is
displayed. Nothing happens. It just freezes...
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ Hacker for Hire \
\ +31-320-252965/
\[EMAIL PROTECTED]/
-
[ Hacker: http://www.jargon.org/html/entry/hacker.html ]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Here's an idea, farfetched as it may be. Page the entire process out to disk into a user defined area, SIGHALT it and use printk or a kthread/userproc to notify the user that something was kicked out of the sandbox for playing bad. The user can add more swap if desired, then use a userland tool w/ the kthread/userproc to pop it back into memory or destroy it and SIGCONT. This allows the user to make almost all decisions about what gets killed and what remains running. Necessarily if you're out of disk space as well we'll have to resort to simply killing. Hmm, sounds like 2.5. -d Jamie Lokier wrote: Kurt Garloff wrote: I could not agree more. Normally, you'd better kill a foreground task (running nice 0) than selecting one of those background jobs for some reasons: * The foreground job can be restarted by the interactive user (Most likely, it will be only netscape anyway) * The background job probably is the more useful one which has been running since a longer time (computations, ...) Ick. A background job that's been running for a long time will be saved by that, as Rik pointed out. If I've got a background process running for 30 minutes, and a Netscape with 5 windows open that I'm using (for long or not, doesn't matter), guess which one I'd rather died? Not Netscape -- I'm using that and I'll never remember how to find those 5 windows again if it just dies. -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
8139too Abnormal interrupt, status 00000002
8139too Fast Ethernet driver 0.9.10 loaded eth0: RealTek RTL8139 Fast Ethernet at 0xc8859000, 00:c0:df:04:7f:9b, IRQ 11 eth0: Identified 8139 chip type 'RTL-8139B' I routinely (several times an hour) get messages like this: eth0: Abnormal interrupt, status 0002 2.4.0-test9, x86, UP AMD Duron 600, VIA KT133 chipset 100 Mbps network, not too loaded. Haven't noticed networks hangups any more with test9 (those that needed ipdown and ifup). But now I have these messages. --- Meelis Roos e-mail: [EMAIL PROTECTED] www:http://www.cs.ut.ee/~mroos/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: dvd mounting troubles
On Mon, 9 Oct 2000, Rick Haines wrote: I'm having real trouble mounting a dvd (udf filesystem) in my Pioneer 104S drive. It usually failes with: mount: wrong fs type, bad option, bad superblock on /dev/dvd, or too many mounted file systems I suspect that it is a UDF issue and not DVD-ATAPI. Since my two DVD-ROM and DVD-RAM ATAPI now work fine. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Then spam the console loudly with printk, but don't destroy the whole machine. Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg machine tho, the probability of init getting killed is simply too high for comfort. I have never ever seen init start consuming memory like this so I'd rather get spammed on the console a LOT then have my entire machine instantly go dead. We get enough reports about innocuous messages on the console, I'm sure these would get reported to LKML as well...and in short order as is usual. -d Ingo Molnar wrote: On Mon, 9 Oct 2000, Andrea Arcangeli wrote: On Fri, Oct 06, 2000 at 04:19:55PM -0400, Byron Stanoszek wrote: In the OOM killer, shouldn't there be a check for PID 1 just to enforce that Init can't be killed in 2.2.x latest, the same bugfix should be forward ported to 2.4.x. I believe we should not special-case init in this case. If the OOM would kill init then we *want* to know about it ASAP, because it's either a bug in the OOM code or a memory leak in init. Both things are very bad, and ignoring the kill would just preserve those bugs artificially. -- "There is a natural aristocracy among men. The grounds of this are virtue and talents", Thomas Jefferson [1742-1826], 3rd US President - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Weird IP options
[EMAIL PROTECTED] (BERNARD Sebastien) wrote.. Near the test3-4 kernel, I was not able to reach www.linuxtoday.com. After some debug, I find that is because my linux box is emitting syn packet with some really strange options (description of packet follows). Can anyone tell me if this behaviour is normal or not ? Here is the dialog from linuxtoday. 18:55:09.979659 eth0 x.x.x.5.45762 63.236.72.248.www: S [ECN-Echo,CWR] ECN. RFC2481 echo 0 /proc/sys/net/ipv4/tcp_ecn to switch this off. This is becoming an almost weekly asked question, you can find out more about it by reading.. http://lwn.net/2000/0914/kernel.php3 http://lwn.net/2000/1005/kernel.php3 It may be an idea that if you intend to follow development kernels and can't handle the volume of the list, you should at least follow kernel news sites like the above, or kernel-traffic to at least find out what you are letting yourself in for. This will prevent the same questions getting repeatedly asked, and may save you a lot of headaches. regards, Dave. -- | Dave Jones [EMAIL PROTECTED] 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] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Rik van Riel wrote: On Mon, 9 Oct 2000, Marco Colombo wrote: On Fri, 6 Oct 2000, Rik van Riel wrote: [...] They are niced because the user thinks them a bit less important. Please don't, this assumption is quite wrong. I use nice just to be 'nice' to other users. I can run my *important* CPU hog simulation nice +10 in order to let other people get more CPU when the need it. In that case the time the process has been running and the CPU time used will save the process if it's been running for a long time. Please read the /entire/ algorithm before making rash conclusions like this. flame level=+1 What "conclusions"? YOU stated that "They are niced because the user thinks them a bit less important", and I was only commenting on that. I've never said your /entire/ algorithm is failing, the point was on the purpose of the 'nice' level. Users don't use nice to mark less important processes. It's completely orthogonal. And if you really want to correlate nice level and importance, I'd rather say that niced processes tend to be more important that "normal" processes, on average. /flame If nice is used for important, long-running tasks, the fact that they are long-running will save them (and be honest, would you really care if a simulation would be killed after 5 minutes? it's only inconvenient if it gets killed after a few hours...) Ok. Now tell me what's the purpose to run your 'ls' at nice +5 at all. You nice processes that are going to take a while, otherwise nicing them has hardly a measurable effect, if any. But if you put the logic "niced == not important" somewhere into the kernel, nobody will use nice anymore. I'd rather give a bonus to niced processes. This doesn't make ANY sense at all. The objective is to destroy the least amount of work, which means giving a bonus to processes which have used a lot of CPU time already ... regardless of nice value. 'regardless of nice value' is the part I like. all. But my point here is that you do, and you take it as an hint for process importance as percieved by the user that run it, and I believe it's just wrong guessing). If you have a better algorithm, feel free to send patches. No need. Either reverse the weight you give to nice level or just ignore it, which probably is easier. I agree that giving a bonus to niced processed it's nearly useless. As I've written in my previous message, I don't think it's a big issue. OOM should not happen, full stop. OOM killer is a last resort measure, so it needs not to be *too* careful. regards, Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000 http://www.conectiva.com/ http://www.surriel.com/ .TM. -- / / / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _/ _/ _/ [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, Oct 09, 2000 at 04:07:32PM -0300, Rik van Riel wrote: No. It's only needed if your OOM algorithm is so crappy that it might end up killing init by mistake. The algorithm you posted on the list in this thread will kill init if on 4Mbyte machine without swap init is large 3 Mbytes and you execute a task that grows over 1M. So I repeat again: for correctness you should either fix the oom algorithm and demonstrate with math that it can't kill init or fix the bug using a magic check. Since it's not going to be possible to proof that an oom algorithm won't kill init (also considering init isn't always /sbin/init) the magic check is going to be the only bugfix possible. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, 9 Oct 2000, Andrea Arcangeli wrote: No. It's only needed if your OOM algorithm is so crappy that it might end up killing init by mistake. The algorithm you posted on the list in this thread will kill init if on 4Mbyte machine without swap init is large 3 Mbytes and you execute a task that grows over 1M. i think the OOM algorithm should not kill processes that have child-processes, it should first kill child-less 'leaves'. Killing a process that has child processes likely results in unexpected behavior of those child-processes. (and equals to effective killing of those child-processes as well.) But this mechanizm can be abused (a malicious memory hog can create a child-process just to avoid the OOM-killer) - but there are ways to avoid this, eg. to add all the 'MM badness' points to children? Ie. a child which has MM-abuser parent(s) will definitely be killed first. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
On Mon, Oct 09, 2000 at 12:30:20PM -0700, David Ford wrote: Init should only get killed if it REALLY is taking a lot of memory. On a 4 or 8meg Init should never get killed. Killing init can be compared to destroy the TCP stack. Some app can keep to run right for some minute until they run socket() and then they will hang. Same with init, some task may still run right for some time but the machine will die eventually. We simply must not pass the point of not return or we're buggy and after the bug triggered we have to force the user to reboot the machine as only way to recover. Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 8139too Abnormal interrupt, status 00000002
Ditto here - Running 8139too drivers on 2.4.0-test9: 8139too Fast Ethernet driver 0.9.10 loaded eth0: RealTek RTL8139 Fast Ethernet at 0xd1834000, 00:e0:7d:7b:5a:16, IRQ 10 eth0: Identified 8139 chip type 'RTL-8139A' eth1: RealTek RTL8139 Fast Ethernet at 0xd1836000, 00:e0:7d:7b:5a:1d, IRQ 10 eth1: Identified 8139 chip type 'RTL-8139A' eth1: Setting full-duplex based on MII #32 link partner ability of 45e1. Haven't see any hangs, but have messages like these: eth1: Abnormal interrupt, status 0002. eth1: Abnormal interrupt, status 0002. Regards, jjs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
TODO UPDATE: RE: Updated 2.4 TODO List
Ted,
Here are some corrections to the published list.
I'm working on new additions now.
~Randy
6. In Progress
* USB: hotplug (PNP) and module autoloader support
+ Move to "1. Should Be Fixed". We want more testing of it, of course.
9. To Do
* USB: OHCI root-hub-timer does not restart on resume {CRITICAL}
(Paul Mackerras)
+ Move to "1. Should be Fixed".
* USB: add bandwidth allocation support to usb-uhci HCD
+ Move to "1. Should be Fixed".
* USB: Fix differences in UHCI and OHCI HCD behaviors/semantics:
+ Only uhci.c does EARLY_COMPLETE (drop EARLY_COMPLETE ?)
+ Move to "Fixed" (actually deleted).
* USB: usb-ohci needs to null urb-dev to avoid various
reboots/hangs/oopses {CRITICAL} (David Brownell;
[EMAIL PROTECTED])
+ Move to "1. Should be Fixed".
10. To Do But Non Showstopper
* USB: speed up device enumeration (hub driver has large
delays in it)
+ Move to "1. Should be Fixed".
Other updates from linux-usb-devel people?
Thanks,
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: dvd mounting troubles
Andre, Where's the patch for the CD RW/DVD fix you did over the weekend. I need to grab it and see if I can get this drive working on speed=8 on 2.4.0. Jeff Andre Hedrick wrote: On Mon, 9 Oct 2000, Rick Haines wrote: I'm having real trouble mounting a dvd (udf filesystem) in my Pioneer 104S drive. It usually failes with: mount: wrong fs type, bad option, bad superblock on /dev/dvd, or too many mounted file systems I suspect that it is a UDF issue and not DVD-ATAPI. Since my two DVD-ROM and DVD-RAM ATAPI now work fine. Cheers, Andre Hedrick The Linux ATA/IDE guy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] VM fix for 2.4.0-test9 OOM handler
Rik,
what do you think about the attached patch? It increases the effective
priority of a (kernel-) killed process, and initiates a reschedule, so
that it gets selected ASAP. (except if there are RT processes around.)
This should make OOM decisions 'visible' much more quickly.
Ingo
--- linux/kernel/signal.c.orig Mon Oct 9 12:56:45 2000
+++ linux/kernel/signal.c Mon Oct 9 13:00:20 2000
@@ -569,6 +569,14 @@
spin_unlock_irqrestore(t-sigmask_lock, flags);
return -ESRCH;
}
+ /*
+* Special case, kernel is forcing SIGKILL.
+* Decrease signal delivery latency.
+*/
+ if (sig == SIGKILL (t-policy == SCHED_OTHER)) {
+ t-counter = MAX_COUNTER;
+ current-need_resched = 1;
+ }
if (t-sig-action[sig-1].sa.sa_handler == SIG_IGN)
t-sig-action[sig-1].sa.sa_handler = SIG_DFL;
