Re: Linux 2.4.5-ac15
On Tue, 19 Jun 2001, Walter Hofmann wrote: > On Sun, 17 Jun 2001, Walter Hofmann wrote: > > > I had already two crashes with ac15. The system was still ping-able, but > > login over the network didn't work anymore. > > > > The first crash happened after I started xosview and noticed that the > > system almost used up the swap (for no apparent reason). The second > > crash happened shortly after I started fsck on a crypto-loop device. > > > > This does not happen with ac14, even under heavy load. > > > > I noticed a second problem: Sometimes the system hangs completely for > > approximately ten seconds, but continues just fine after that. I have > > seen this with ac14 and ac15, but not with ac12. > > FWIW, here is the vmstat output for the second (short) hang. Taken with > ac14, vmstat 1 was started (long) before the hang and interrupted about > five seconds after it. The machine has 128MB RAM and 256MB swap. > > >procs memoryswap io system cpu > r b w swpd free buff cache si sobibo incs us sy id > 1 1 0 77332 1584 15632 67740 44 0 448 0 496 932 84 15 1 > 1 2 0 77456 1848 15944 66960 0 0 372 724 625 2296 62 20 18 > 3 0 1 77456 1780 16208 67044 72 0 33680 584 1695 20 20 61 > 2 0 0 77404 1464 16672 66652 0 0 572 0 530 2649 26 19 55 > 3 1 0 77344 1464 17000 66480 124 0 656 0 419 879 12 16 72 > 0 3 0 77344 1468 17076 66388 184 0 1080 0 561 654 8 8 84 > 0 5 0 77892 1464 17184 66892 176 128 800 396 415 1050 14 11 74 > 0 5 0 77892 1600 17216 66868 16 068 1020 508 295 5 5 90 > 0 3 0 77892 1464 17316 66784 56 0 37268 464 1287 22 14 64 > 2 3 0 77892 1464 17524 66828 76 0 440 0 398 987 8 12 79 > 1 3 0 77892 1464 17780 66680 32 0 512 0 367 1061 10 10 79 > 1 1 0 77880 1464 18020 66392 224 0 756 0 394 1579 43 12 44 > 2 1 0 77784 2172 18324 64820 16 0 992 0 529 1745 37 19 44 > 0 4 0 77936 1848 18428 65180 124 0 252 920 570 451 23 9 69 > 0 2 0 77888 1680 18564 65656 84 0 744 0 532 721 21 12 67 > 3 0 0 77876 1464 18700 65564 4 0 1176 0 487 804 26 16 58 > 0 3 1 77496 1468 18712 65700 424 100 1296 384 401 532 70 10 20 > 2 0 0 77920 1508 18804 65504 72 248 968 260 525 709 40 9 51 > 2 2 0 77908 1728 18788 65388 0 120 1000 568 568 608 41 8 51 > 0 4 0 77908 1620 18828 65548 0 0 172 356 545 420 22 8 69 > 1 1 0 77904 1712 18472 65464 36 0 1600 0 485 621 52 15 33 >procs memoryswap io system cpu > r b w swpd free buff cache si sobibo incs us sy id > 2 1 0 78124 1528 18496 64940 116 20 884 288 545 604 54 16 30 > 4 0 0 78124 1468 18548 64260 4 0 468 0 449 663 49 6 46 > 3 0 0 77844 3416 18492 63932 100 0 304 0 431 1915 80 16 4 > 1 2 0 77844 2892 18536 64204 60 0 284 820 583 917 64 13 23 > 1 0 0 77844 2824 18544 64236 0 04068 591 550 36 6 58 > 3 0 0 77844 2604 18568 64372 0 0 120 0 455 474 64 13 23 > 1 0 0 77844 2472 18572 64440 0 056 0 399 617 35 9 56 > 1 0 0 77844 2456 18572 64460 0 0 0 0 515 721 8 6 87 > 0 0 0 77844 2448 18572 64468 0 0 4 0 469 655 8 8 83 > 1 0 0 77844 2384 18572 64528 0 0 0 428 538 641 7 10 83 > 0 0 0 77844 2388 18572 64528 0 0 0 0 492 733 3 9 89 > 0 0 0 77844 2368 18572 64548 0 0 0 0 520 804 11 7 82 > 0 0 0 77844 2336 18572 64580 0 0 0 0 473 680 6 6 89 > 1 0 0 77844 2276 18584 64608 0 012 0 490 966 30 13 56 > 2 0 0 77844 2228 18584 64648 0 0 0 344 539 589 47 7 47 > 3 0 0 77844 2228 18588 64692 0 0 4 0 381 455 29 11 60 > 2 0 1 77844 2180 18588 64700 0 0 0 0 453 781 33 9 58 > 1 0 0 77844 2160 18604 64708 0 016 0 390 852 18 5 77 > 2 0 1 77844 1940 18616 64912 124 0 212 0 318 756 40 8 52 > 3 0 0 77844 1680 18620 65180 240 0 244 576 492 1632 87 13 0 > 2 0 1 77844 1528 18540 65540 584 0 592 0 352 2466 90 10 0 >procs memoryswap io system cpu > r b w swpd free buff cache si sobibo incs us sy id > 2 0 0 77844 1800 18516 65588 40 040 0 357 675 89 11 0 > 3 5 2 77844 1464 18536 65916
ide-floppy fails on ApolloPro 133A-based MB
hello, a few days ago I replaced my old MB by a QDI Advance 10F-board (VT82C694X + VT82C686B). Since that time I am running into trouble when writing on my IDE-Floppy (/dev/hdb), read-access is ok, all other IDE-devices are working fine. /var/log/messages reports: cosanostra kernel: hdb: ATAPI reset complete Jun 20 14:45:29 cosanostra kernel: hdb: lost interrupt Jun 20 14:45:29 cosanostra kernel: ide-floppy: CoD != 0 in idefloppy_pc_intr These problems occurr running 2.4.5-ac15 as well as W98. QDI seems to know about this problem because they recommend to upgrade to the latest VIA-chipset-drivers, which did not help (W98). At this point I am not sure wether the "ide-floppy"-issue is MB-specific or chipset-related. Could anyone familiar with the VIA-chipset-driver comment on that, maybe its a development-aspect for the via-driver ? Thanks in advance J. Stroettchen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: harddisk support
In article <[EMAIL PROTECTED]> you wrote: > How can I access more than 16 harddisks? Create the Device File with: cd /dev ; MAKEDEV sdq -or- cd /dev ; mknod sdq b 65 0 mknod sdq1 b 65 1 ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: harddisk support
Daljeet writes: > In the '/dev' tree, the device file entries for SCSI harddisks ranges from > '/dev/sda' to '/dev/sdp'. If I attach 17 scsi harddisks to a system, the > 17th harddisk is shown as '/dev/sdq' in '/proc/partitions' but there is no > entry in the '/dev' tree. If I try to access '/dev/sdq' either through > fdisk or through any other simple C programs, it gives error saying, can > not open device '/dev/sdq'. > > How can I access more than 16 harddisks? Use the MAKEDEV script to make the extra /dev/sd* entries. Like: cd /dev; MAKEDEV sdq sdr sds sdt sdu sdv sdw sdx sdy sdz sdaa ... You can make up to 128 SCSI disks, all the way to /dev/sddx. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RPC vs Socket
hi all I am in the way of building a new remote file system. Presently I decided to use sockets for remote communication. Lately I understood that RPC is used in coda and nfs file systems(is it so). I want to know the fessibility in using RPC in the new file system. by Blesson Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: how to display proxy arp addresses using "ip neigh" from iproute2
In article <[EMAIL PROTECTED]> you wrote: > 47.129.82.116 * * MPeth0 the asteriks simply show you, that the new linuix kernel will not be able to remeber any mac address for a proxy arp entry. It will always respond with the device' own MAC address. Can't find a way to display it with ip, "ip neigh show nud all" will not show them, too. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
harddisk support
Hi, I do not know whether I should ask this question on this mailing list, but it definitely has to do either with the kernel confiuration or kernel support. In the '/dev' tree, the device file entries for SCSI harddisks ranges from '/dev/sda' to '/dev/sdp'. If I attach 17 scsi harddisks to a system, the 17th harddisk is shown as '/dev/sdq' in '/proc/partitions' but there is no entry in the '/dev' tree. If I try to access '/dev/sdq' either through fdisk or through any other simple C programs, it gives error saying, can not open device '/dev/sdq'. How can I access more than 16 harddisks? Regards, Daljeet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
Russell Leighton wrote: > The lack of a good operating system _dependent_ interface > makes running fast hard in Java when you need to do IO... > yes, there is always JNI so you can add a little C to mmap a file or whatever, JDK 1.4 beta comes with a way to memory-map files, and various other I/O improvements (like poll(); see http://www.jcp.org/jsr/detail/51.jsp). Chris Smith will have some nio benchmarks up on http://www.jlinux.org/ next week or so showing how well their nonblocking network I/O performs. Sun is slowly getting their act together on the I/O front with java. Still, the competition from C# and for that matter gcj will probably be a good thing, keep 'em on their toes. (Disclaimer: I served on the JSR-51 expert group, representing the linux point of view, kinda.) - Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Avoid !__GFP_IO allocations to eat from memory reservations
Linus, I just read pre3<->pre4 diff and it seems you missed this patch... here it goes again. In pre3/4, GFP_BUFFER allocations can eat from the "emergency" memory reservations in case try_to_free_pages() fails for those allocations in __alloc_pages(). Here goes the (tested) patch to fix that: --- linux/mm/page_alloc.c.orig Thu Jun 14 11:00:14 2001 +++ linux/mm/page_alloc.c Thu Jun 14 11:32:56 2001 @@ -453,6 +453,12 @@ int progress = try_to_free_pages(gfp_mask); if (progress || gfp_mask & __GFP_IO) goto try_again; + /* +* Fail in case no progress was made and the +* allocation may not be able to block on IO. +*/ + else + return NULL; } } } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.2 PATCH: check return from copy_*_user in fs/pipe.c
Linus Torvalds wrote: > If somebody passes in a bad pointer to a system call, you've just > invoced the rule of "the kernel _may_ be nice to you, but the kernel > might just consider you a moron and tell you it worked". > > There is no "lost data" or anything else. You've screwed yourself, and > you threw the data away. Don't blame the kernel. > > And before you say "it has to return EFAULT", check the standards, and > think about the case of libraries vs system calls - and how do you tell > them apart? My reading of the standard is that it has to either return EFAULT or raise SIGSEGV. But I am not expert in XPG4-ese. Whether or not the standard requires anything, I would much rather that the kernel not silently discard error conditions. zw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
> Then again JavaOS was an abortion on top of Slowaris. [...] This is a false statemenet, Rob. It was an abortion, all right, but not related to Solaris in any way at all. JavaOS existed in two flavours minimum, which had very little in common. The historically first of them (Luna), was a home-made executive with pretty rudimentary abilities. I must admit I am not intimately familiar with its genesis. A part of it was related to the JavaOS running on Sun 701 chip, but what came first, I cannot tell. Second flavour of JavaOS was made on top of Chorus, and, _I think_, used large parts of Luna in the the JVM department, but it had decent kernel, with such novations as a device driver interface :) > make a DPMI DOS port with an SVGA AWT and say "hey, we're done, and it boots > off a single floppy", I'll never know. Such a thing existed. I do not remember its proper name, but I remember that it booted from hard disk. Floppy was too small for it. > Porting half of Solaris to Power PC for JavaOS has got to be one of the most > peverse things I've seen in my professional career. I never heard of PPC port of either of JavaOSes, although Chorus runs on PPC. Perhaps this is what you mean. Solaris for PPC existed, but never was widespread. It did not have JVM bundled. > I'm upset that Red Hat 7.1 won't install on that old laptop because it only > has 24 megs of ram and RedHat won't install in that. [...] You blew adding a swap partition, I suspect... -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: aic7xxx oops with 2.4.5-ac13
On Thu, Jun 21, 2001 at 02:08:17AM +, Trevor Hemsley wrote: Ditto. I am also seeing this oops calling the sg driver for a robotic tape library, and it also seems to happen on 2.4.4. Jeff > Just upgraded from 2.4.3 to 2.4.5-ac13 and get an aiee, killing interrupt > handler on boot as aic7xxx.o is loaded. I have an Adaptec 2906 PCI card > with a Nikon CoolscanIII and an HP optical drive attached. Works ok on > aic7xxx_old. Works with an initial bus reset on 2.4.3. Dies a horrible death > on 2.4.5-ac13. > > trevor@trevor4:/tmp > /sbin/lspci > 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) > 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) > 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) > 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) > 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) > 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) > 00:09.0 SCSI storage controller: Adaptec AHA-7850 (rev 03) > 00:0a.0 SCSI storage controller: Initio Corporation 360P (rev 02) > 00:0b.0 Network controller: Compaq Computer Corporation Netelligent 10/100 (rev 10) > 00:0c.0 Ethernet controller: 3Com Corporation 3c900 Combo [Boomerang] > 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) > > On 2.4.3 I get the following errors when aic7xxx loads > > ahc_pci:0:9:0: WARNING no command for scb 0 (cmdcmplt) > QOUTPOS = 0 > scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.5 > > aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs > > scsi1:0:2:0: Attempting to queue an ABORT message > (scsi1:A:2:0): Queuing a recovery SCB > scsi1:0:2:0: Device is disconnected, re-queuing SCB > Recovery code sleeping > (scsi1:A:2:0): Abort Message Sent > (scsi1:A:2:0): SCB 3 - Abort Completed. > Recovery SCB completes > Recovery code awake > aic7xxx_abort returns 8194 > > It then carries on and works. > > Ksymoops output follows but may not be entirely reliable > because it's from a hand written file and /proc/ksyms and /proc/modules are > from 2.4.3. > trevor@trevor4:/tmp > more decoded-245-ksymoops > ksymoops 2.4.0 on i686 2.4.3. Options used > -V (default) > -k /proc/ksyms (default) > -l /proc/modules (default) > -o /lib/modules/2.4.5-ac13/ (specified) > -m /l243/System.map-2.4.5-ac13 (specified) > > Unable to handle kernel NULL pointer dereference at virtual address 0004 > c018d250 > *pde = > Oops: > CPU: 0 > EIP: 0010:[] > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010057 > eax: ebx: 0012 ecx: 0001 edx: > esi: edi: d74f0600 ebp: esp: c0233dc0 > ds: 0018 es: 0018 ss: 0018 > Process swapper (pid 0, stackpage=c0233000) > Stack: d9133058 0012 d74f0600 414f0600 >d74f0600 0001 0001 d91356ee d74f0600 d74f0690 >0003 d913e18f d74f0600 0012 d74f0600 0010 > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] > Code: 8b 40 04 85 c0 74 15 3b 90 6c 00 00 00 75 07 80 88 fc 00 00 > > >>EIP; c018d250<=
Re: ip_tables/ipchains
I had a similar problem with this yesterday. Try moving your .config file to a safe place, making mrproper, then moving your .config back and rebuilding. I did this and all was well. HTH, pete On Wed, 20 Jun 2001, Ted Gervais wrote: > Wondering something.. > I ran insmod to bring up ip_tables.o and I received the following error: > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > symbol nf_unregister_sockopt > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > symbol nf_register_sockopt > > This is with kernel 2.4.5 and Slackware 7.1 is the distribution. > Does anyone know what these unresolved symbols are about?? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is there a linux running on jvm arch ?
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > The JVM is very very bad from a C language point of view. You can convert C > code to it and there have been some very experimental demos of this. However > it is a very non trivial problem > Note that PicoJava is basically the JVM with a few extensions to run C code reasonably. It might be a better target. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: freeze with 2.4.5-ac16
On Wed, 20 Jun 2001, Marcelo Tosatti wrote: > > happened again (vt1 and 2 echo but shells are unresponsive, vt3+ don't > > echo) only active process was the program allocating 192mb and writing to > > it, no find this time. > > Can you get the backtrace of this process? the offending process is memeat (allocates 192*1024*1024 bytes, then memsets it to 0, then sleeps forever, though apparently it never gets to that part). It has to be in memset(ptr, 0, 192*1024*1024). ksymoops from sysrq-m attached, and vmstat from just before the hang and just after. justin freesibling task PCstack pid father child younger older init R current 0 1 0 1312 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] keventd S 0 2 1 3 (L-TLB) Call Trace: [] [] kswapdR C1451FA8 0 3 1 4 2 (L-TLB) Call Trace: [] [] [] [] [] kreclaimd S 0286 0 4 1 5 3 (L-TLB) Call Trace: [] [] [] bdflush S 0282 0 5 1 6 4 (L-TLB) Call Trace: [] [] [] kupdated S C1479FC8 0 6 1 8 5 (L-TLB) Call Trace: [] [] [] [] kreiserfsdS CFAB9FB4 0 8 112 6 (L-TLB) Call Trace: [] [] [] [] [] devfsdS CF706000 812 122 8 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] klogd S 7FFF 022 12712 (NOTLB) Call Trace: [] [] [] [] [] [] [] syslogd R 027 13022 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] kapm-idledS CF23FF94 030 15327 (L-TLB) Call Trace: [] [] [] [] [] [] [] [] [] cardmgr S 7FFF 481253 17230 (NOTLB) Call Trace: [] [] [] [] [] sshd S 7FFF 072 17453 (NOTLB) Call Trace: [] [] [] [] xfs S CE65FF2C 074 17872 (NOTLB) Call Trace: [] [] [] [] [] zsh S CF94FFB0 078 1 1338 7974 (NOTLB) Call Trace: [] [] [] agettyS 7FFF 117279 18178 (NOTLB) Call Trace: [] [] [] [] [] zsh S 7FFF 081 1 12279 (NOTLB) Call Trace: [] [] [] [] [] zsh S CF1BDFB0 0 122 1 138 14881 (NOTLB) Call Trace: [] [] [] zsh S C30FFFB0 4708 138122 150 (NOTLB) Call Trace: [] [] [] gpm S C32D3F2C 4640 148 1 151 122 (NOTLB) Call Trace: [] [] [] [] [] [] ssh S 7FFF 0 150138 (NOTLB) Call Trace: [] [] [] [] agettyS 7FFF 0 151 1 1312 148 (NOTLB) Call Trace: [] [] [] [] [] zsh S C9BCDFB024 1312 1 1431 151 (NOTLB) Call Trace: [] [] [] zsh S C1AB2000 0 1319 78 14321338 (NOTLB) Call Trace: [] [] [] [] tail S CE86FF8C24 1338 781319 (NOTLB) Call Trace: [] [] [] [] memeatR 376 1431 1312 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] zsh R 4600 1432 1319 (NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] ksymoops 2.4.1 on i686 2.4.5-ac16. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac16/ (default) -m /boot/System.map (specified) Call Trace: [] [] [] [] [] [] [] [] [] [] Call Trace: [] [] Call Trace: [] [] [] [] [] Call Trace: [] [] [] Call Trace: [] [] [] Call Trace: [] [] [] [] Call Trace: [] [] [] [] [] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Call Trace: [] [] [] [] [] [] [] Call Trace: [] [] [] [] [] [] [] [] Call Trace: [] [] [] [] [] [] [] [] [] Call Trace: [] [] [] [] [] Call Trace: [] [] [] [] Call Trace: [] [] [] [] [] Call Trace: [] [] [] Call Trace: [] [] [] [] [] Call Trace: [] [] [] [] [] Call Trace: [] [] [] Call Trace: [] [] [] Call Trace: [] [] [] [] [] [] Call Trace: [] [] [] [] Call Trace: [] [] [] [] [] Call Trace: [] [] [] Call Trace: [] [] [] [] Call Trace: [] [] [] [] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Call Trace: [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c01279a1 Trace; c0127b06 Trace; c012863a <__alloc_pages+1b2/240> Trace; c01286dc <__get_free_pages+14/20> Trace; c012588b Trace; c0125a1f Trace; c0136ca9 Trace; c0137bbd <__user_walk+11/58>
RE: Why use threads ( was: Alan Cox quote?)
> On Wed, Jun 20, 2001 at 03:18:58PM -0700, David Schwartz wrote: > > As I said, you don't want to use one thread for each > > client. You use, say, > > 10 threads for the 16,000 clients. That way, if an occasional client > > ambushes a thread (say by reading a file off an NFS server or > > by using some > > infrequently used code that was swapped to a busy disk), your > > server will > > keep on humming. > This same approach can easily be used by multiple processes. Theoretically, pretty much everything you can do with a thread pool architecture can be done with a process pool architecture. Sharing file descriptors can be much harder. Some thread architectures (notably pthreads) go out of their way to make some things hard for thread pools (like try implementing Samba, since all the threads share there uids). But this is more about bad threading specifications and implementations than threading itself. > I don't see what is gained by using threads over processes for such an > architecture. I'll flip this back at you and ask you what's gained by using processes over threads. It's certainly more difficult to implement a process pool architecture than a thread pool architecture. Theoretically, performance for a thread pool architecture will be slightly better (on some architectures at least) due to the identical vm views. With a process pool architecture, you might have more control over what you share. But this doesn't actually gain you anything because as long as you share more than a small amount, you still have to consider your entire environment tainted if one execution vehicle goes out of control. I would be very interested in seeing, for example, a web server based on a 'process pool' design. Does anybody know of any? DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: freeze with 2.4.5-ac16
On Wed, 20 Jun 2001, Justin Guyett wrote: > On Wed, 20 Jun 2001, Justin Guyett wrote: > > > I got it to freeze in console (two generic find / -type f / type d), one > > process allocating and writing 0 to 192mb > > > > machine responds to pings, switching VTs works > > > > (256 physical, 512 swap) > > happened again (vt1 and 2 echo but shells are unresponsive, vt3+ don't > echo) only active process was the program allocating 192mb and writing to > it, no find this time. Can you get the backtrace of this process? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Wednesday 20 June 2001 20:42, D. Stimits wrote: > Rob Landley wrote: > ...snip... > > > The patches-linus-actuall-applies mailing list idea is based on how Linus > > says he works: he appends patches he likes to a file and then calls patch > > -p1 < thatfile after a mail reading session. It wouldn't be too much > > work for somebody to write a toy he could use that lets him work about > > the same way but forwards the messages to another folder where they can > > go out on an otherwise read-only list. (No extra work for Linus. This > > is EXTREMELY important, 'cause otherwise he'll never touch it.) > > What if the file doing patches from is actually visible on a web page? > Or better yet, if the patch command itself was modified such that at the > same time it applies a patch, the source and the results were added to a > MySQL server which in turn shows as a web page? His patch file already has a bunch of patches glorped together. In theory they could be separated again by parsing the mail headers. I suppose that would be less work for Linus... The point is, the difference between the patches WE get and the patches LINUS gets is the granularity. He's constantly extorting other people to watch the granularity of what they send him (small patches, each doing one thing, with good documentation as to what they do and why, in seperate messages), but what WE get is a great big diff about once a week. So what I'm trying to figure out is if we can impose on Linus to cc: a mailing list on the stream of individual patch messages he's applying to his tree, so we can follow it better. And he IS willing to do a LITTLE work for us. He's issuing changelogs now. This would be significantly less effort than that... MySQL is overkill, and since these things started as mail messages why should they be converted into a foriegn format? There's threaded archivers for mailing lists and newsgroups and stuff already, why reinvent the wheel? Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Wednesday 20 June 2001 11:33, Alexander Viro wrote: > On 20 Jun 2001, Jes Sorensen wrote: > > Not to mention how complex it is to get locking right in an efficient > > manner. Programming threads is not that much different from kernel SMP > > programming, except that in userland you get a core dump and retry, in > > the kernel you get an OOPS and an fsck and retry. > > Arrgh. As long as we have that "SMP makes locking harder" myth floating > around we _will_ get problems. Kernel UP programming is not different > from SMP one. It is multithreaded. And amount of genuine SMP bugs is > very small compared to ones that had been there on UP since way back. > And yes, programming threads is the same thing. No arguments here. Hopefully in 2.5 we'll get the pre-emptive UP patch in that enables the SMP locks on UP and finally clean it all out by exposing the bugs to the main user base. As for multi-threaded programming being hard, people are unfamiliar with it. Any programming is hard the first time. And almost anybody's first attempt at it is going to suck. (Dig out the linux kernel 0.02 sources sometime and compare them with what we have today.) The more experience you get with it, the better you are. Encouraging people to stay away from it rather than learn to do it RIGHT is the wrong attitude. People will figure out that using 1000 threads when you need 3 isn't the best way to go, that locking is an expense but failing to lock is worse, how to spot race conditions (the same old "security" mindset except you don't need a malicious third party to get bitten by it.) And they'll learn it the way I did, and the way everybody does. Do it wrong repeatedly. Make every mistake there is, hard. Get burned, rewrite it from scratch four times until you figure out how to design it right, spend long weekends looking for subtle little EVIL bugs you can't reproduce but which bite you the instant you stop looking for them, learn to play "hot potato" with volatile data you have to manipulate atomically... Everybody starts as a bad programmer. Some of us get it out of our systems when we're 12. Others decide programming is lucrative when they're 35 and inflict their "hello world" opus upon their coworkers. Me, I wrote a disk editor and a bunch of bbses in 5th and 6th grade back on the C64 that will never see the light of day. And yes they sucked. But I'm still proud of them. And I wrote awful multithreaded code back on OS/2, and can now write decent threading code because I've learned a large number of things to avoid doing. And I take proper care because I know how hard it is to FIND one of these if you do wind up doing it. I've done it. Once for two consecutive weeks on the same
aic7xxx oops with 2.4.5-ac13
Just upgraded from 2.4.3 to 2.4.5-ac13 and get an aiee, killing interrupt handler on boot as aic7xxx.o is loaded. I have an Adaptec 2906 PCI card with a Nikon CoolscanIII and an HP optical drive attached. Works ok on aic7xxx_old. Works with an initial bus reset on 2.4.3. Dies a horrible death on 2.4.5-ac13. trevor@trevor4:/tmp > /sbin/lspci 00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02) 00:09.0 SCSI storage controller: Adaptec AHA-7850 (rev 03) 00:0a.0 SCSI storage controller: Initio Corporation 360P (rev 02) 00:0b.0 Network controller: Compaq Computer Corporation Netelligent 10/100 (rev 10) 00:0c.0 Ethernet controller: 3Com Corporation 3c900 Combo [Boomerang] 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 AGP (rev 01) On 2.4.3 I get the following errors when aic7xxx loads ahc_pci:0:9:0: WARNING no command for scb 0 (cmdcmplt) QOUTPOS = 0 scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.5 aic7850: Single Channel A, SCSI Id=7, 3/255 SCBs scsi1:0:2:0: Attempting to queue an ABORT message (scsi1:A:2:0): Queuing a recovery SCB scsi1:0:2:0: Device is disconnected, re-queuing SCB Recovery code sleeping (scsi1:A:2:0): Abort Message Sent (scsi1:A:2:0): SCB 3 - Abort Completed. Recovery SCB completes Recovery code awake aic7xxx_abort returns 8194 It then carries on and works. Ksymoops output follows but may not be entirely reliable because it's from a hand written file and /proc/ksyms and /proc/modules are from 2.4.3. trevor@trevor4:/tmp > more decoded-245-ksymoops ksymoops 2.4.0 on i686 2.4.3. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5-ac13/ (specified) -m /l243/System.map-2.4.5-ac13 (specified) Unable to handle kernel NULL pointer dereference at virtual address 0004 c018d250 *pde = Oops: CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010057 eax: ebx: 0012 ecx: 0001 edx: esi: edi: d74f0600 ebp: esp: c0233dc0 ds: 0018 es: 0018 ss: 0018 Process swapper (pid 0, stackpage=c0233000) Stack: d9133058 0012 d74f0600 414f0600 d74f0600 0001 0001 d91356ee d74f0600 d74f0690 0003 d913e18f d74f0600 0012 d74f0600 0010 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 04 85 c0 74 15 3b 90 6c 00 00 00 75 07 80 88 fc 00 00 >>EIP; c018d250<= Trace; d9133058 <[serial].bss.end+18d5/18dd> Trace; d91356ee <[aic7xxx]ahc_filter_command+20a/2a4> Trace; d913e18f <[aic7xxx]ahc_reset+37/470> Trace; d913e4fd <[aic7xxx]ahc_reset+3a5/470>
Re: The latest Microsoft FUD. This time from BillG, himself.
On Wednesday 20 June 2001 18:31, Daniel Phillips wrote: > On Wednesday 20 June 2001 23:33, Rik van Riel wrote: > > On 20 Jun 2001, Miles Lane wrote: > > > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html > > > > Yes, he sure knows how to bring Linux to the attention > > of people ;) > > Not to mention the GPL, which I can guarantee you, before today my mom had > *never* heard of. > > -- > Daniel Ooh, do I get to say "I told you so"? (LinuxToday buried my submission way back under a blurb about caldera, but still...) http://linuxtoday.com/news_story.php3?ltsn=2001-05-10-002-20-PS Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Threads FAQ entry incomplete
J.D. Bakker <[EMAIL PROTECTED]> wrote: > At 13:42 -0600 20-06-2001, Charles Cazabon wrote: > >Rodrigo Ventura <[EMAIL PROTECTED]> wrote: > > > BTW, I have a question: Can the availability of dual-CPU boards for > > > intel and amd processors, rather then tri- or quadra-CPU boards, be > > > explained with the fact that the performance degrades significantly for > > > three or more CPUs? Or is there a technological and/or comercial reason > > > behind? > > > >Commercial reasons. Cost per motherboard/chipset goes way up as the number > >of CPUs supported goes up. For each CPU that a chipset supports, it has to > >add a lot of pins/lands, and chipsets are already typically land-limited. > > That's not quite accurate. Most modern SMP-able processors have a common > bus, where going from 1->2 CPUs adds just a handful of extra nets (usually > bus request, bus grant and some IRQs). The actual issues are threefold. Low-end Intel multi-CPU chipsets are like this (typical 2-CPU configurations, and low-end 4-CPU configurations). Higher-end systems (8-way, etc) typically have multiple processor busses, with only one, two, or four processors per bus. Processor bus contention costs performance even in 2-way systems, and at 4-way and above, it becomes a serious bottleneck. High end chipsets do the cache coherency and snooping control between the busses. Other N-way chipsets (i.e., non-Intel) have point-to-point links between each CPU and the chipset. The new AMD 760 chipset for Athlon is like this; so are N-way Alpha chipsets. I can't swear to other hardware. > First, most commodity chipsets simply support no more than two CPUs at best; > most CPUs don't support having more (or any) siblings. Adding more is cheap > on the ASIC level, but nobody bothers because there is no demand. Ask ServerWorks about this. They make 16-way Intel chipsets. It's possible, just not cheap. > Third, the more CPUs a bus holds, the higher the capacitance on the bus > lines. Higher capacitance means lower maximum bus speed, which aggravates > point two. Which is one of the reasons for a pont-to-point "bus" with Alpha and Athlon CPUs. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ My opinions are just that -- my opinions. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Threads FAQ entry incomplete
"J.D. Bakker" wrote: > > At 13:42 -0600 20-06-2001, Charles Cazabon wrote: > >Rodrigo Ventura <[EMAIL PROTECTED]> wrote: > > > BTW, I have a question: Can the availability of dual-CPU boards for intel > >> and amd processors, rather then tri- or quadra-CPU boards, be explained with > >> the fact that the performance degrades significantly for three or more CPUs? > >> Or is there a technological and/or comercial reason behind? > > > >Commercial reasons. Cost per motherboard/chipset goes way up as the number of > >CPUs supported goes up. For each CPU that a chipset supports, it has to add a > >lot of pins/lands, and chipsets are already typically land-limited. > > That's not quite accurate. Most modern SMP-able processors have a > common bus, where going from 1->2 CPUs adds just a handful of extra > nets (usually bus request, bus grant and some IRQs). The actual > issues are threefold. Some SMP chipset/cpu combos allow direct cache-to-cache update when a dirty cache line is found through snooping, while the lower performance ones don't. Wouldn't any kind of cache-to-cache direct update that bypasses the main bus also add physical complexity (extra traces)? And wouldn't that become more important as the number of cpu's goes up? > > First, most commodity chipsets simply support no more than two CPUs > at best; most CPUs don't support having more (or any) siblings. > Adding more is cheap on the ASIC level, but nobody bothers because > there is no demand. > > Second, adding more CPUs on a shared bus decreases the bus bandwidth > that is available per CPU. This is comparable with having Ethernet > hubs vs switches. The really expensive multi-CPU boards have crossbar > switches between CPUs, memory and PCI. Future stuff like RapidIO may > mitigate this. > > Third, the more CPUs a bus holds, the higher the capacitance on the > bus lines. Higher capacitance means lower maximum bus speed, which > aggravates point two. > > >Motherboard trace complexity (and therefore number of layers) goes up. Add to > >that that the potential market goes down as CPUs goes up. > > True enough. > > Regards, > > JDB > [working on a SMP PowerPC design] > -- > LART. 250 MIPS under one Watt. Free hardware design files. > http://www.lart.tudelft.nl/ > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
Rob Landley wrote: ...snip... > The patches-linus-actuall-applies mailing list idea is based on how Linus > says he works: he appends patches he likes to a file and then calls patch -p1 > < thatfile after a mail reading session. It wouldn't be too much work for > somebody to write a toy he could use that lets him work about the same way > but forwards the messages to another folder where they can go out on an > otherwise read-only list. (No extra work for Linus. This is EXTREMELY > important, 'cause otherwise he'll never touch it.) What if the file doing patches from is actually visible on a web page? Or better yet, if the patch command itself was modified such that at the same time it applies a patch, the source and the results were added to a MySQL server which in turn shows as a web page? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Wed, Jun 20, 2001 at 03:33:45PM -0700, Larry McVoy wrote: > You can scream all you want that "it isn't free software" but the fact > of the matter is that you all scream that and then go do your slides for > your Linux talks in PowerPoint. I think this is an unfair generalization. I'm not even all that clear about what PowerPoint is (I've never seen it, ever). I'm guessing that it lets you display slides in sequence, but that's just from what I've seen of MagicPoint, which someone said at a user meet was a clone of PowerPoint. (And yes, the talk given that day was in fact done with MagicPoint) -- Michael Bacarella <[EMAIL PROTECTED]> Technical Staff / System Development, New York Connect.Net, Ltd. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
One more ZDNet article with BillG hammering Linux and Open Source.
http://www.zdnet.com/zdnn/stories/news/0,4586,2777283,00.html (an excerpt) Linux and open source ZDNet -- Can you clarify Microsoft's position on Linux and open source? There has been a lot written about it in the last week. What's Microsoft's objection to open source and Linux? BillG -- I don't want to dwell on this. Craig Mundie (Microsoft's senior vice president of advanced strategies) is the expert. There is this whole history that free software is developed often in the academic environment, where basically government money funded that work. And then commercial work is done. TCP/IP came out of the university environment. Now, 90 percent of the implementations you buy are commercially tuned and supported. And then the companies that do that commercial work pay taxes, create jobs, so the government keeps funding more research, primarily in universities. So that ecosystem where you have free software and commercial software, and customers always get to decide which they use, that's a very important and healthy ecosystem. ZDNet -- How does the GPL (GNU General Public License) factor in? BillG -- There is a part of open source called GPL that breaks that cycle--that is, it makes it impossible for a commercial company to use any of that work or build on any of that work. So what you saw with TCP/IP or (e-mail technology) Sendmail or the browser could never happen. We believe there should be free software and commercial software; there should be a rich ecosystem that works around that. There are people who believe that commercial software should not exist at all--that there should be no jobs or taxes around commercial software at all. And that's a small group, but the GPL was created with that goal in mind. And so people should understand the GPL. When people say open source they often mean the GPL. When someone asks a question, "So what about open source?" do they mean open source or do they mean the GPL? We believe in that ecosystem and having the mix of free and commercial software. ZDNet -- What's your position on publishing source code? BillG -- We have no objection to people publishing source codes. We do that ourselves under certain terms. Some of our source codes are out there and very available, like Windows CE. Some generally require a license, like Windows itself. We have no objection to free software, which has been around forever. But we do think there are problems for commercial users relative to the GPL, and we are just making sure people understand the GPL. Unfortunately, that has been misconstrued in many ways. It's a topic that you can leap on and say, "Microsoft doesn't make free software." Hey, we have free software; the world will always have free software. I mean, if you characterize it that way, that's not right. But if you say to people, "Do you understand the GPL?" And they'll say, "Huh?" And they're pretty stunned when the Pac-Man-like nature of it is described to them. ZDNet -- Does Microsoft plan to make more of its source code available to customers? You already do that with Windows; do you plan to expand that in any way to the applications? BillG -- We keep making it easier and easier, and anything people want source code for, we'll figure out a way to get it to them. It's kind of a strange thing in a way because most commercial customers don't want to recompile kernels or things like that. But they want to be able to know that things can be supported. We have some very cool tools now where we don't have to ship you the source. You can debug online, through the Internet. So it means you don't have to get a bunch of CDs. If you really want it for debugging and patching things, we can do that through the Internet. That's a real breakthrough in terms of simple source access. I don't know that anyone has ever asked for the source code for Word. If they did, we would give it to them. But it's not a typical request. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
On Wednesday 20 June 2001 18:07, J . A . Magallon wrote: > On 20010620 Rob Landley wrote: > What do you worry about caches if every bytecode turns into a jump and more > code ? 'cause the jump may be overlappable with extra execution cores in RISC and VLIW? I must admit, I've never actually seen somebody try to assembly-level optimize a non-JIT java VM before. JIT always struck me as a bit of a kludge... > And that native code is not in a one-to-one basis with respect to > bytecode, but many real machine code instructions to exec a bytecode op ? Sure. But if they're honestly doing real work, that's ok then. (If they're setting up and tearing down unnecessary state, that's bad. I must admit the friction between register and stack based programming models was pretty bad in the stuff I saw back around JavaOS, which was long enough ago I can't say I remember the details as clearly as I'd like...) Then again JavaOS was an abortion on top of Slowaris. Why they didn't just make a DPMI DOS port with an SVGA AWT and say "hey, we're done, and it boots off a single floppy", I'll never know. I mean, they were using green threads and a single task for all threads ANYWAY... (Actually, I know exactly why. Sun thinks in terms of Solaris, even when it's totally the wrong tool for the job. Sigh...) Porting half of Solaris to Power PC for JavaOS has got to be one of the most peverse things I've seen in my professional career. > I have seen school projects with interfaces done in java (to be 'portable') > and you could go to have a coffee while a menu pulled down. Yeah, but the slowness there comes from the phrase "school project" and not the phrase "done in java". I've seen menuing interfaces on a 1 mhz commodore 64 that refreshed faster than the screen retrace, and I've WRITTEN java programs that calculated animated mathematical function plots point by point in realtime on a 486. > Would you implement a search funtion into a BIG BIG database in java ? You mean spitting out an SQL request that goes to a backend RDMS? I've done it. (Via MQSeries to DB2.) Interestingly, a rather large chunk of DB2 itself seems to be implemented in Java Dunno how much, though. Probably not the most performance critical sections. But it uses a heck of a lot of it... > No, you give a java interface to C or C++ code. A large part of this is "not reinventing the wheel". Also, I'd like to point out that neither Java 1.0 nor Java 1.1 had an API to truncate an existing file. (I pointed that out to Mark English at Sun back when I worked at IBM, and apparently nobody'd ever noticed it before me. Fixed in 1.2, I'm told.) > Until java can be efficiently compiled, it is no more than a toy. I haven't played with Jikes. > Then why do you use Java ? If you just write few objects with many methods > you are writing VisualBasic. That was below the belt. I'm trying to figure out if you've just violated a corolary of Godwin's law with regards to language discussions, but I'll let it pass and answer seriously. Because used that way, Java doesn't suck nearly as badly as visual basic does? (My cumulative life experience trying to program in visual basic adds up to about three hours, so I don't consider myself an authority on it. But I've had enough exposure to say it sucks based on actually trying to use it.) That and it was developed on OS/2 to be deployed on (at least) windows 95, 98, and power macintosh? I still had threading inherent in the language. The graphics() class is actually a fairly nice API for doing simple 2d line drawing stuff in a portable way. (It is too, except for fonts. If you don't use any heavyweight AWT objects, and you're religious about using fontmetrics to measure your text, you can actually get pretty portable displays.) I still had the GOOD bits of C++ syntax without having to worry about conflicting virtual base classes. It's TRULY object oriented, with metaclasses and everything. > See above. Traversing a list of objects to draw is not time consuming, > implementing a zbuffer or texturing is. Try to implement a zbuffer in java. I'll top that, I tried to implement "deflate" in java 1.0. (I was porting info-zip to java when java 1.1 came out. Yeah, the performance sucked. But the performance of IBM's OS/2 java 1.0 jdk sucked compared to anything anybody's using today (even without JIT). > The problem with java is that people tries to use it as a general purpose > programming language, and it is not efficient. It can be used to organize > your program and to interface to low-level libraries written in C. But > do not try to implement any fast path in java. I once wrote an equation parser that took strings, substituted values for variables via string search and replace, and performed the calculation the string described. It did this for ever
Re: eepro100: wait_for_cmd_done timeout
No..that was pretty much what i saw in the logs. I see wait_for_cmd_done timeout being the only one being repeated in the logs -Wilson ` * Andrey Savochkin ([EMAIL PROTECTED]) wrote: > What was the first error message from the driver? > NETDEV WATCHDOG report went before wait_for_cmd_done timeout and is more > important. I wonder if you had some other messages before the watchdog one. > > Andrey > > On Wed, Jun 20, 2001 at 04:31:34PM -0700, Dionysius Wilson Almeida wrote: > > And this is the log when the card hangs : > > = > > Jun 20 16:10:18 debianlap kernel: NETDEV WATCHDOG: eth0: transmit timed out > > Jun 20 16:10:18 debianlap kernel: eth0: Transmit timed out: status 0050 0c80 at >314/342 command 000c. > > Jun 20 16:10:18 debianlap kernel: eth0: Tx ring dump, Tx queue 342 / 314: > > Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout! > > Jun 20 16:14:38 debianlap last message repeated 5 times -- Eat shit -- billions of flies can't be wrong. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP_ALIAS in 2.4.x gone?
Hi, > "Alan Olsen" == Alan Olsen <[EMAIL PROTECTED]> writes: Alan Olsen> I found the problem... Alan Olsen> IP_ALIAS is no longer needed in the config. [...] Alan Olsen> The documentation does not reflect that the alias Alan Olsen> behaviour is on by default. yes and sorry, you are absolutely right. Alan Olsen> I will submit a patch for the docs that reflects this so Alan Olsen> others will not get confused by that. great, this will surely help. i've appended a first try how the changes could be clarified. please take this as a hopefully helpful proposal (HHP for short ;-). Erik --- linux-2.4.5/Documentation/networking/alias.txt-245 Tue Apr 28 23:22:04 1998 +++ linux-2.4.5/Documentation/networking/alias.txt Thu Jun 21 01:41:45 2001 @@ -2,40 +2,43 @@ IP-Aliasing: +IP-aliases are additional IP-adresses/masks hooked up to a base +interface by adding a colon and a string when running ifconfig. +This string is usually numeric, but this is not a must. + +IP-Aliases are avail if CONFIG_INET (`standard' IPv4 networking) +is configured in the kernel. -o For IP aliasing you must have IP_ALIAS support included by static - linking. o Alias creation. - Alias creation is done by 'magic' iface naming: eg. to create a + Alias creation is done by 'magic' interface naming: eg. to create a 200.1.1.1 alias for eth0 ... # ifconfig eth0:0 200.1.1.1 etc,etc ~~ -> request alias #0 creation (if not yet exists) for eth0 -and routing stuff also ... -# route add -host 200.1.1.1 dev eth0:0 (if same IP network as - main device) - -# route add -net 200.1.1.0 dev eth0:0 (if completely new network wanted - for eth0:0) + +The corresponding route is also set up by this command. +Please note: The route always points to the base interface. + o Alias deletion. - Also done by shutting the interface down: + The alias is removed by shutting the alias down: # ifconfig eth0:0 down ~~ -> will delete alias -Alias (re-)configuring +o Alias (re-)configuring - Aliases are not real devices, but programs` should be able to configure and + Aliases are not real devices, but programs should be able to configure and refer to them as usual (ifconfig, route, etc). -Relationship with main device -- - - the main device is an alias itself like additional aliases and can -be shut down without deleting other aliases. +o Relationship with main device + + If the base device is shut down the added aliases will be deleted + too. + Contact --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: eepro100: wait_for_cmd_done timeout
What was the first error message from the driver? NETDEV WATCHDOG report went before wait_for_cmd_done timeout and is more important. I wonder if you had some other messages before the watchdog one. Andrey On Wed, Jun 20, 2001 at 04:31:34PM -0700, Dionysius Wilson Almeida wrote: > And this is the log when the card hangs : > = > Jun 20 16:10:18 debianlap kernel: NETDEV WATCHDOG: eth0: transmit timed out > Jun 20 16:10:18 debianlap kernel: eth0: Transmit timed out: status 0050 0c80 at >314/342 command 000c. > Jun 20 16:10:18 debianlap kernel: eth0: Tx ring dump, Tx queue 342 / 314: > Jun 20 16:14:07 debianlap kernel: eepro100: wait_for_cmd_done timeout! > Jun 20 16:14:38 debianlap last message repeated 5 times - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac16 kernel panic
On Wednesday 20 June 2001 21:33, Gary White (Network Administrator) wrote: > 2.4.5-ac16 patch applied to clean 2.4.5 tree. 2.4.5-ac15 boots > with no problem. > > model name : AMD Athlon(tm) Processor > > Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 3). > > > PnP: PNP BIOS installation structure at 0xc00fc2b0 > PnP: PNP BIOS version 1.0, entry at f:c2e0, dseg at f > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > invalid operand: > CPU:0 > EIP:0010:[] > EFLAGS: 00010286 > eax: 007ec000 ebx: e080 ecx: 3f7ec000 edx: c0101000 > esi: 1ffec000 edi: 1ffec000 ebp: esp: dffe3f54 > ds: 0018 es: 0018 ss: 0018 > Process swapper (pid: 1, stackpage=dffe3000) > Stack: e080 1ffec000 1ffec000 0246 1ffec000 1ffec000 > 1ffec000 c0126384 0010 007ec000 c0101e08 1ffec000 3f7ec000 c0111521 > e080 1ffec000 1ffec000 1ffec000 c00f6ed8 0014 000f6ed0 > 3ffd7fff Call Trace: [] [] [] [] > [] [] [] > > Code: 0f 0b e9 40 01 00 00 8b 44 24 28 8b 54 24 2c 8b 4c 24 34 8b > <0>Kernel panic: Attempted to kill init > -- > Gary White Network Administrator > [EMAIL PROTECTED] Internet Pathway > Voice 601-776-3355Fax 601-776-2314 > Same here Gary. While starting kswapd "Kernel BUG at ioremap.c:73! Invalid operand:" etc AMD Athlon 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Capabilities: [c0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- -- Regards, Gavin Baker - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5-ac16 -- Still getting unresolved gameport_register_port and gameport_unregister_port symbols in joystick drivers.
I have attached my .config file.
find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia
if [ -r System.map ]; then /sbin/depmod -ae -F System.map 2.4.5-ac16; fi
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac16/kernel/drivers/char/joystick/cs461x.o
depmod: gameport_register_port
depmod: gameport_unregister_port
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac16/kernel/drivers/char/joystick/emu10k1-gp.o
depmod: gameport_register_port
depmod: gameport_unregister_port
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac16/kernel/drivers/char/joystick/lightning.o
depmod: gameport_register_port
depmod: gameport_unregister_port
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac16/kernel/drivers/char/joystick/ns558.o
depmod: gameport_register_port
depmod: gameport_unregister_port
depmod: *** Unresolved symbols in
/lib/modules/2.4.5-ac16/kernel/drivers/char/joystick/pcigame.o
depmod: gameport_register_port
depmod: gameport_unregister_port
#
# Automatically generated by make menuconfig: don't edit
#
CONFIG_X86=y
CONFIG_ISA=y
# CONFIG_SBUS is not set
CONFIG_UID16=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
CONFIG_M686=y
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MCYRIXIII is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_PGE=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
# CONFIG_TOSHIBA is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
CONFIG_X86_UP_APIC=y
# CONFIG_X86_UP_IOAPIC is not set
CONFIG_X86_LOCAL_APIC=y
#
# General setup
#
CONFIG_NET=y
# CONFIG_VISWS is not set
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_NAMES=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
CONFIG_HOTPLUG=y
#
# PCMCIA/CardBus support
#
CONFIG_PCMCIA=m
CONFIG_CARDBUS=y
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_SYSVIPC=y
# CONFIG_BSD_PROCESS_ACCT is not set
CONFIG_SYSCTL=y
CONFIG_KCORE_ELF=y
# CONFIG_KCORE_AOUT is not set
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PM=y
# CONFIG_ACPI is not set
CONFIG_APM=y
# CONFIG_APM_IGNORE_USER_SUSPEND is not set
CONFIG_APM_DO_ENABLE=y
CONFIG_APM_CPU_IDLE=y
# CONFIG_APM_DISPLAY_BLANK is not set
# CONFIG_APM_RTC_IS_GMT is not set
CONFIG_APM_ALLOW_INTS=y
CONFIG_APM_REAL_MODE_POWER_OFF=y
#
# Memory Technology Devices (MTD)
#
# CONFIG_MTD is not set
#
# Parallel port support
#
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
CONFIG_PARPORT_PC_CML1=m
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
CONFIG_PARPORT_PC_PCMCIA=m
# CONFIG_PARPORT_AMIGA is not set
# CONFIG_PARPORT_MFC3 is not set
# CONFIG_PARPORT_ATARI is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_SUNBPP is not set
# CONFIG_PARPORT_OTHER is not set
CONFIG_PARPORT_1284=y
#
# Plug and Play configuration
#
CONFIG_PNP=y
CONFIG_ISAPNP=m
CONFIG_PNPBIOS=y
#
# Block devices
#
CONFIG_BLK_DEV_FD=m
# CONFIG_BLK_DEV_XD is not set
CONFIG_PARIDE=m
CONFIG_PARIDE_PARPORT=m
CONFIG_PARIDE_PD=m
CONFIG_PARIDE_PCD=m
CONFIG_PARIDE_PF=m
CONFIG_PARIDE_PT=m
CONFIG_PARIDE_PG=m
# CONFIG_PARIDE_ATEN is not set
# CONFIG_PARIDE_BPCK is not set
# CONFIG_PARIDE_BPCK6 is not set
# CONFIG_PARIDE_COMM is not set
# CONFIG_PARIDE_DSTR is not set
# CONFIG_PARIDE_FIT2 is not set
# CONFIG_PARIDE_FIT3 is not set
# CONFIG_PARIDE_EPAT is not set
# CONFIG_PARIDE_EPIA is not set
# CONFIG_PARIDE_FRIQ is not set
# CONFIG_PARIDE_FRPW is not set
# CONFIG_PARIDE_KBIC is not set
# CONFIG_PARIDE_KTTI is not set
# CONFIG_PARIDE_ON20 is not set
# CONFIG_PARIDE_ON26 is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_NBD=m
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set
#
# Multi-device support (RAID and LVM)
#
# CONFIG_MD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID5 is
eepro100: wait_for_cmd_done timeout
Hi, I'm running Linux 2.4.5 from kernel.org on my Sony VAIO PCG-FX140 notebook. I'm runing it on Debian Sid. The problem i'm facing is that the ethernet card hangs after every 2 minutes or so and this is consistent. I've to bring down the interface and bring it back up and then it works for another 2 minutes before freezing. When i run Redhat 7.1 using redhat supplied intel's e100 driver, everything works fine. I tried compiling and loading this driver under Debian, but it does not work (i.e. does not recognize any adapter). I tried downloading the e100 driver from Intel site and loading that too.. but that too loads but does not find my adapter. Further the sources which came with redhat 7.1 does not compile under Debian Sid. I tried looking for specific info but i've not been sucessful so far. Here's what lspci outputs : 00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 11) 00:02.0 VGA compatible controller: Intel Corporation: Unknown device 1132 (rev 11) 00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 03) 00:1f.0 ISA bridge: Intel Corporation: Unknown device 244c (rev 03) 00:1f.1 IDE interface: Intel Corporation: Unknown device 244a (rev 03) 00:1f.2 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) (rev 03) 00:1f.3 SMBus: Intel Corporation 82820 820 (Camino 2) Chipset SMBus (rev 03) 00:1f.4 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub B) (rev 03) 00:1f.5 Multimedia audio controller: Intel Corporation: Unknown device 2445 (rev 03) 00:1f.6 Modem: Intel Corporation: Unknown device 2446 (rev 03) 01:00.0 FireWire (IEEE 1394): Texas Instruments: Unknown device 8021 (rev 02) 01:02.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) 01:02.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) 01:08.0 Ethernet controller: Intel Corporation 82820 820 (Camino 2) Chipset Ethernet (rev 03) And this is the log when the card hangs : = Jun 20 16:10:18 debianlap kernel: NETDEV WATCHDOG: eth0: transmit timed out Jun 20 16:10:18 debianlap kernel: eth0: Transmit timed out: status 0050 0c80 at 314/342 command 000c. Jun 20 16:10:18 debianlap kernel: eth0: Tx ring dump, Tx queue 342 / 314: Jun 20 16:10:18 debianlap kernel: eth0: 0 200c. Jun 20 16:10:18 debianlap kernel: eth0: 1 000c. Jun 20 16:10:18 debianlap kernel: eth0: 2 000c. Jun 20 16:10:18 debianlap kernel: eth0: 3 000c. Jun 20 16:10:18 debianlap kernel: eth0: 4 000c. Jun 20 16:10:18 debianlap kernel: eth0: 5 000c. Jun 20 16:10:18 debianlap kernel: eth0: 6 000c. Jun 20 16:10:18 debianlap kernel: eth0: 7 000c. Jun 20 16:10:18 debianlap kernel: eth0: 8 200c. Jun 20 16:10:18 debianlap kernel: eth0: 9 000c. Jun 20 16:10:18 debianlap kernel: eth0:10 000c. Jun 20 16:10:18 debianlap kernel: eth0:11 000c. Jun 20 16:10:18 debianlap kernel: eth0:12 000c. Jun 20 16:10:18 debianlap kernel: eth0:13 000c. Jun 20 16:10:18 debianlap kernel: eth0:14 000c. Jun 20 16:10:18 debianlap kernel: eth0:15 000c. Jun 20 16:10:18 debianlap kernel: eth0:16 200c. Jun 20 16:10:18 debianlap kernel: eth0:17 000c. Jun 20 16:10:18 debianlap kernel: eth0:18 000c. Jun 20 16:10:18 debianlap kernel: eth0:19 000c. Jun 20 16:10:18 debianlap kernel: eth0:20 000c. Jun 20 16:10:18 debianlap kernel: eth0:21 400c. Jun 20 16:10:18 debianlap kernel: eth0: =22 000ca000. Jun 20 16:10:18 debianlap kernel: eth0:23 000ca000. Jun 20 16:10:18 debianlap kernel: eth0:24 200ca000. Jun 20 16:10:18 debianlap kernel: eth0:25 000ca000. Jun 20 16:10:18 debianlap kernel: eth0: * 26 000c. Jun 20 16:10:18 debianlap kernel: eth0:27 000c. Jun 20 16:10:18 debianlap kernel: eth0:28 000c. Jun 20 16:10:18 debianlap kernel: eth0:29 000c. Jun 20 16:10:18 debianlap kernel: eth0:30 000c. Jun 20 16:10:18 debianlap kernel: eth0:31 000c. Jun 20 16:10:18 debianlap kernel: eth0: Printing Rx ring (next to receive into 977, dirty index 977). Jun 20 16:10:18 debianlap kernel: eth0: 0 0001. Jun 20 16:10:18 debianlap kernel: eth0: 1 0001. Jun 20 16:10:18 debianlap kernel: eth0: 2 0001. Jun 20 16:10:18 debianlap kernel: eth0: 3 0001. Jun 20 16:10:18 debianlap kernel: eth0: 4 0001. Jun 20 16:10:18 debianlap kernel: eth0: 5 0001. Jun 20 16:10:18 debianlap kernel: eth0: 6 0001. Jun 20 16:10:18 debianlap kernel: eth0: 7 0001. Jun 20 16:10:18 debianlap kernel: eth0: 8 0001. Jun 20 16:10:18 debianlap kernel: eth0: 9 0001. Jun 20 16:10:18 debianlap kernel: eth0:10 0001. Jun 20 16:10:18 debianlap kernel: eth0:11 0001. Jun 20 16:10:18 debianlap kernel: eth0:12 0001. Jun 20 16:10:18 debianlap kernel: eth0:13 0001. Jun 20 16:10:18 debianlap kernel: eth0:14 0001. Jun 20 16:10:18
Re: Alan Cox quote? (was: Re: accounting for threads)
export IFS=$'\n'
> lines=`ls -l | awk '{print "\""$0"\""}'`
> for i in $lines
> do
> echo line:$i
> done
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
NFS insanity
I've got an NFS server, version 2.4.4, using reiserfs with trond's NFS patches and the reiser-2.4.4 nfs patch. On a client running 2.4.5 with trond's patches and the corresponding reiser patches, I get the wierdest behaviour: # on client cp libgkcontent.so libgkcontent.so.x diff libgkcontent.so libgkcontent.so.x # no diff # on server diff libgkcontent.so libgkcontent.so.x Binary files libgkcontent.so and libgkcontent.so.x differ It _only_ happens in this file of all files I've tried out so far. I'm trying to get xdelta to show me what's differing so I can see if there's a pattern or something, but it's awful - data corruption not only possibly but happening. :-) I haven't tried remounting yet to see what I get, but I don't see the problems on unpatched 2.4.2. I'll wait a bit to see if anyone has seen this. Anyone? Take care, -- /\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil ~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac16 kernel panic
Sorry I was so long getting back. I had to step out of the office for a minute. Here is the debug message. Initializing RT netlink socket kernel BUG at ioremap.c:73 invalid operand: > > 2.4.5-ac16 patch applied to clean 2.4.5 tree. 2.4.5-ac15 boots > > with no problem. > > Yes I screwed up the bootflag handling > > > EIP:0010:[] > > EFLAGS: 00010286 > > eax: 007ec000 ebx: e080 ecx: 3f7ec000 edx: c0101000 > > Can you build with kernel debug enabled and then say Y to all the debug options > and give me the BUG() message where that next build dies. I think I know whats > up I want to be sure > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Gary White Network Administrator [EMAIL PROTECTED] Internet Pathway Voice 601-776-3355Fax 601-776-2314 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] disk_index weirdness
Hi,
I suggest the follwoing patch to make /proc/stat work as expected in 2.4.
I noted that "gkrellm" erroneously reported my disk hdc as hde. the reason
is that (a relict from the 2.2 series, I suppose) disk_index adds 2 to
the disk number for IDE controller 1. This is IMO wrong, because in 2.4
the disks are indexed by major and minor number.
I also added more major numbers to the routine and tried to order the
majors such that the "right" results are found quickly.
Regards,
Martin
PS: I'm not subscribed to this list, but I read the archives regularly.
--- include/linux/genhd.h.orig Tue Mar 27 01:48:11 2001
+++ include/linux/genhd.h Wed Jun 20 19:17:09 2001
@@ -248,21 +248,30 @@
unsigned int index;
switch (major) {
- case DAC960_MAJOR+0:
- index = (minor & 0x00f8) >> 3;
- break;
case SCSI_DISK0_MAJOR:
index = (minor & 0x00f0) >> 4;
break;
case IDE0_MAJOR:/* same as HD_MAJOR */
case XT_DISK_MAJOR:
+ case IDE1_MAJOR:
+ case IDE2_MAJOR:
+ case IDE3_MAJOR:
+ case IDE4_MAJOR:
+ case IDE5_MAJOR:
index = (minor & 0x0040) >> 6;
break;
- case IDE1_MAJOR:
- index = ((minor & 0x0040) >> 6) + 2;
+ case SCSI_CDROM_MAJOR:
+ index = minor & 0x000f;
break;
default:
- return 0;
+ if (major >= SCSI_DISK1_MAJOR && major <= SCSI_DISK7_MAJOR)
+ index = (minor & 0x00f0) >> 4;
+ else if (major >= DAC960_MAJOR && major <= DAC960_MAJOR + 7)
+ index = (minor & 0x00f8) >> 3;
+ else if (major >= IDE6_MAJOR && major <= IDE9_MAJOR)
+ index = (minor & 0x0040) >> 6;
+ else
+ return 0;
}
return index;
}
--
Martin Wilck <[EMAIL PROTECTED]>
Inst. for Tropospheric Research, Permoserstr. 15, 04303 Leipzig, Germany
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Thursday 21 June 2001 00:33, Larry McVoy wrote: > You can scream all you want that "it isn't free software" but the fact > of the matter is that you all scream that and then go do your slides for > your Linux talks in PowerPoint. Bad example Larry, most of us do our talks with MagicPoint. I'll probably use KPresenter for the next one, it's pretty slick. I haven't booted Window in almost 2 years, not because I'm forcing myself to stay away, but because I haven't had the need. And yes, I do word processing, make spreadsheets, charts, send emails, you name it. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
Larry McVoy writes: > On Wed, Jun 20, 2001 at 11:09:10PM +0100, Alan Cox wrote: > > > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html > > > > > Of course the URL that goes with that is : > > http://www.microsoft.com/windows2000/interix/features.asp > > > > Yes., Microsoft ship GNU C (quite legally) as part of their offerings... > > Which brings up an interesting question for us all. Let's postulate, for > the sake of discussion, that we agree on the following: > > a) Linux (or just about any Unix) is a better low level OS than NT > b) Microsoft's application infrastructure is better (the COM layer, >the stuff that lets apps talk to each, the desktop, etc). > > I know we can argue that KDE/GNOME/whatever is going to get there or is > there or is better, etc., but for the time being lets just pretend that > the Microsoft stuff is better. > > What would be wrong with Microsoft/Linux? It would be: > > a) the Linux kernel > b) the Microsoft API ported to X > c) Microsoft apps > d) Linux apps > > Since Microsoft is all about making money, it doesn't matter if they > charge for the dll's or the OS, either one is fine, you can't run Word > without them. If you don't need the Microsoft apps, you could strip > them off and strip off the dlls and ship all the rest of it without > giving Microsoft a dime. If you do need the apps or you want the app > infrastructure, you have to give Microsoft exactly what you have to give > them today - money - but you can run Word side by side with Ghostview > or whatever. Microsoft could charge exactly the same amount for the > dll's as they charge for the OS, none of the end users can tell the > difference anyway. > > I'm unimpressed with what Microsoft calls an operating system and > I'm equally unimpressed with what Unix calls an application layer. > For the last 10 years, Unix has gotten the OS right and the apps wrong > and Microsoft has gotten the apps right and the OS wrong. Seems like > there is potential for a win-win. > > You can scream all you want that "it isn't free software" but the > fact of the matter is that you all scream that and then go do your > slides for your Linux talks in PowerPoint. Actually, it wouldn't bother me at all if they did that. If they didn't violate the GPL (i.e. didn't make proprietary changes to the kernel and libc and various utilities). I guess they could make proprietary hacks to X, which I wouldn't want, otherwise I expect that normal X apps would become 2nd class citizens. If people want to pay for M$ office I'd much rather see them using Linux underneath. That way they have a decent OS and the chances of them being slowly weaned away from M$ products as free alternatives become available (or they get comfortable with the idea of free alternatives). Trying to get people to change wholesale is a lot harder. I suspect M$ doesn't want to do this, because while they could keep flogging Office for a long time (I hear it's better than the alternatives), they would find it harder to flog all the smaller ancillary programmes, as there would be more viable alternatives. I expect M$ will hang on to the bitter end. There's also a lot of emotional attachment to their OS which is driving their policy, I bet. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
On Wednesday 20 June 2001 17:20, Albert D. Cahalan wrote:
> Rob Landley writes:
> > My only real gripe with Linux's threads right now [...] is
> > that ps and top and such aren't thread aware and don't group them
> > right.
> >
> > I'm told they added some kind of "threadgroup" field to processes
> > that allows top and ps and such to get the display right. I haven't
> > noticed any upgrades, and haven't had time to go hunting myself.
>
> There was a "threadgroup" added just before the 2.4 release.
> Linus said he'd remove it if he didn't get comments on how
> useful it was, examples of usage, etc. So I figured I'd look at
> the code that weekend, but the patch was removed before then!
Can we give him feedback now, asking him to put it back?
> Submit patches to me, under the LGPL please. The FSF isn't likely
> to care. What, did you think this was the GNU system or something?
I've stopped even TRYING to patch bash. try a for loop calling "echo $$&",
eery single process bash forks off has the PARENT'S value for $$, which is
REALLY annoying if you spend an afternoon writing code not knowing that and
then wonder why the various process's temp file sare stomping each other...
Oh, and anybody who can explain this is welcome to try:
lines=`ls -l | awk '{print "\""$0"\""}'`
for i in $lines
do
echo line:$i
done
> How about a filesystem filter to spit out patches, or a filesystem
> interface to version control?
Explain please?
The patches-linus-actuall-applies mailing list idea is based on how Linus
says he works: he appends patches he likes to a file and then calls patch -p1
< thatfile after a mail reading session. It wouldn't be too much work for
somebody to write a toy he could use that lets him work about the same way
but forwards the messages to another folder where they can go out on an
otherwise read-only list. (No extra work for Linus. This is EXTREMELY
important, 'cause otherwise he'll never touch it.)
The advantage of this way is:
1) We know who sent the patches. (We get the message with the "from" headers
intact.)
2) Patch mails have descriptions in them most of the time, at least saying
why, if not what they do.
3) This way, we know (more or less in realtime) that Linus has gotten a patch
and applied it to his tree. (What version and everything.) It may be backed
out again later, but we could give him another tool that can do that and
notify the list...
This way, no mucking about with version control, no extra work for Linus, and
in fact he doesn't have to worry about keeping track of what patches he's
applied and when because he has a place he can go check if he forgets.
Now everybody tell me why this won't work. (Sure, all at once, why not...)
Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Wed, 20 Jun 2001, Larry McVoy wrote: > For the last 10 years, Unix has gotten the OS right and the apps wrong > and Microsoft has gotten the apps right and the OS wrong. Seems like > there is potential for a win-win. I've been hoping for this ever since the rumors of "Microsoft Linux" started popping up. The thing is that it'll probably never happen because Microsoft wouldn't be able to stand having any portion of the system out of their control. We have VMWare, I doubt you'll ever do any better than that... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
Larry McVoy wrote: > > You can scream all you want that "it isn't free software" but the fact > of the matter is that you all scream that and then go do your slides for > your Linux talks in PowerPoint. At the Linux SuperClusters 2000 Conference, MadDog and I were the the only ones with slides done on Linux. Pretty sad! Khalid Aziz Linux Development Laboratory (970)898-9214Hewlett-Packard [EMAIL PROTECTED]Fort Collins, CO - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
>You can scream all you want that "it isn't free software" but the fact >of the matter is that you all scream that and then go do your slides for >your Linux talks in PowerPoint. Or AppleWorks (Mac), in my case. Or, if I wanted to be flashy, I'd make the slides up in CorelXARA (which originated on the Acorn and would probably run under WINE today) and move them to GraphicConvertor (Mac) for display. I daresay it's possible to do all that under Linux, but I haven't found such readily-available solutions staring me in the face yet. Incidentally, you don't need a flashy presentation to make an impact. I won a prize this month largely based on a presentation I did - the content was king, the slides were white-on-black text, and I stammered my way through the actual presentation (I'm not good at public speaking). The close runner-up had done a big flashy PowerPoint presentation, was better at public speaking, but hadn't researched his material quite so thoroughly. I use Linux for programming and servers. I still use my Macs for regular day-to-day workstation duty. That's the status quo, and it will only change slowly and with much effort. -- -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) website: http://www.chromatix.uklinux.net/vnc/ geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) tagline: The key to knowledge is not to rely on people to teach you it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Threads FAQ entry incomplete
At 13:42 -0600 20-06-2001, Charles Cazabon wrote: >Rodrigo Ventura <[EMAIL PROTECTED]> wrote: > > BTW, I have a question: Can the availability of dual-CPU boards for intel >> and amd processors, rather then tri- or quadra-CPU boards, be explained with >> the fact that the performance degrades significantly for three or more CPUs? >> Or is there a technological and/or comercial reason behind? > >Commercial reasons. Cost per motherboard/chipset goes way up as the number of >CPUs supported goes up. For each CPU that a chipset supports, it has to add a >lot of pins/lands, and chipsets are already typically land-limited. That's not quite accurate. Most modern SMP-able processors have a common bus, where going from 1->2 CPUs adds just a handful of extra nets (usually bus request, bus grant and some IRQs). The actual issues are threefold. First, most commodity chipsets simply support no more than two CPUs at best; most CPUs don't support having more (or any) siblings. Adding more is cheap on the ASIC level, but nobody bothers because there is no demand. Second, adding more CPUs on a shared bus decreases the bus bandwidth that is available per CPU. This is comparable with having Ethernet hubs vs switches. The really expensive multi-CPU boards have crossbar switches between CPUs, memory and PCI. Future stuff like RapidIO may mitigate this. Third, the more CPUs a bus holds, the higher the capacitance on the bus lines. Higher capacitance means lower maximum bus speed, which aggravates point two. >Motherboard trace complexity (and therefore number of layers) goes up. Add to >that that the potential market goes down as CPUs goes up. True enough. Regards, JDB [working on a SMP PowerPC design] -- LART. 250 MIPS under one Watt. Free hardware design files. http://www.lart.tudelft.nl/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unknown PCI Net Device
> > 00:0b.0 Ethernet controller: MYSON Technology Inc: Unknown device 0803 > > Subsystem: MYSON Technology Inc: Unknown device 0803 > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > > Add the PCI vendor ID and device ID (0803) to drivers/net/8139too.c, in > the rtl8139_pci_tbl[] and board_info[] and if it works, send a patch to > Jeff (CC'd). The myson is a beastie of its own not afaik a rtl8139 chip. 2.4.x has a driver for it (fealnx) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unknown PCI Net Device
Andreas Dilger wrote: > > Greg writes: > > I picked up a network card that claims to use the "most reliable Realtek > > LAN chip". The big chip is labelled "LAN-8139" so naturally I tried the > > 8139too driver. It doesn't find the device. I'm wondering if maybe it's > > just something in the device ID tables. Here's some info: > > > > 00:0b.0 Ethernet controller: MYSON Technology Inc: Unknown device 0803 > > Subsystem: MYSON Technology Inc: Unknown device 0803 > > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > > Add the PCI vendor ID and device ID (0803) to drivers/net/8139too.c, in > the rtl8139_pci_tbl[] and board_info[] and if it works, send a patch to > Jeff (CC'd). See my other reply, it uses the fealnx driver, adding 2.4.4 or 2.4.5 or so :) > Jeff, is there a reason why you have numeric vendor and device IDs instead > of using the definitions in ? Not a good one :) Not using those constants makes the table nice and uniform, with one entry per line. Using those constants tends to bloat up [in the src] the pci_device_id table quite a bit. Jeff -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On 06/20/2001 at 05:33:45 PM Larry McVoy <[EMAIL PROTECTED]> wrote: >You can scream all you want that "it isn't free software" but the fact >of the matter is that you all scream that and then go do your slides for >your Linux talks in PowerPoint. Not I. The slides for my last meeting were done as TIFF files and I used xv to display them. Plus, the most recent documentation I wrote for one of our mainframe applications was done with vi and LaTeX. "What, in addition to the printed copies, you want a copy of the Word document? There is no Word document. But I'll convert it to Rich Text for you and you can take it from there." If my employer didn't require me to use them occasionally, I'd delete every Microsoft product on my laptop. It's not that I have anything against proprietary software. It's just Microsoft that I despise. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
On Wednesday 20 June 2001 15:53, Martin Dalecki wrote: > Mike Harrold wrote: > > Well the transmeta cpu isn't cheap actually. Any processor's cheap once it's got enough volume. That's an effect not a cause. > And if you talk about > super computing, hmm what about some PowerPC CPU variant - they very > compettetiv in terms of cost and FPU performance! Transmeta isn't the > adequate choice here. You honestly think you can fit 142 PowerPC processors in a single 1U, air cooled? Liquid air cooled, maybe... > Well both of those concepts fail in terms of optimization due > to the same reason: much less information is present about > the structure of the code then during source code compilation. LESS info? Anybody wanna explain to me how it's possible to do branch prediction and speculative execution at compile time? (Ala iTanium?) I've heard a few attempts at an explanation, but nothing by anybody who was sober at the time... You have less time to work, but you actually have MORE info about how it's actually running... > Additionaly there may be some performance wins due to the > ability of runtime profiling (anykind thereof), however it still remains > to be shown that this performs better then statically analyzed code. Okay, I'll bite. Why couldn't a recompiler (like MetroWerks stuff) do the same static analysis on large code runs that GCC or some such could do if you give it -Oinsane and let it think for five minutes about each file? Obviously the run-time version isn't going to spend the TIME to do that. But claiming the information to perform these actions isn't available just because your variables no longer have english names... > > /Mike - who doesn't work for Transmeta, in case anyone was wondering... > > :-) > > /Marcin - who doesn't bet a penny on Transmeta /Rob, who still owns stock in Intel of all things. Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Unknown PCI Net Device
Greg writes: > I picked up a network card that claims to use the "most reliable Realtek > LAN chip". The big chip is labelled "LAN-8139" so naturally I tried the > 8139too driver. It doesn't find the device. I'm wondering if maybe it's > just something in the device ID tables. Here's some info: > > 00:0b.0 Ethernet controller: MYSON Technology Inc: Unknown device 0803 > Subsystem: MYSON Technology Inc: Unknown device 0803 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- Add the PCI vendor ID and device ID (0803) to drivers/net/8139too.c, in the rtl8139_pci_tbl[] and board_info[] and if it works, send a patch to Jeff (CC'd). Jeff, is there a reason why you have numeric vendor and device IDs instead of using the definitions in ? Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
> What would be wrong with Microsoft/Linux? It would be: > > a) the Linux kernel > b) the Microsoft API ported to X > c) Microsoft apps > d) Linux apps Providing they follow the standards, the GPL and work with the community I certainly have no problems with it. Its not really any different to using Wine. It is clearly possible for a company to reform over time. IBM were the microsoft of a past age, and they seem to have somewhat improved since. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[QUESTION]: sk->data_ready/state_change callbacks in struct sock
I've got a couple of questions about TCP code that I'm hoping someone
could answer. I have a kernel thread with a struct sock waiting for a
state_change callback, but the callback is never getting, well, called
back.
When I setup the socket, I do the following steps
sock_create (new_socket, ...)
setup the sin structure
new_socket->ops->bind (new_socket, (struct sockaddr_in *) sin, ...)
new_socket->ops->listen (new_socket, ...)
I then setup the callbacks:
new_socket->sk->state_change = foo;
new_socket->sk->data_ready = bar;
At this point, everything in new_socket and new_socket->sk looks OK to me.
When I try and send data to the socket from the other end, however,
neither of these callbacks is ever activated.
So, here are my questions:
- My understanding from the code is that sk->state_change is called when a
struct sock transits from SYN_RCVD to ESTABLISHED and from ESTABLISHED to
{CLOSE_WAIT,FIN_WAIT_1}. Is this correct?
- sk->data_ready is called whenever any new data is deposited in the
associated sk_buff. Is this correct?
Bob
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
On Wednesday 20 June 2001 15:27, Mike Harrold wrote: > Martin Dalecki wrote:> > > > Blah blah blah. The performance of the Transmeta CPU SUCKS ROCKS. No > > matter > > what they try to make you beleve. A venerable classical desing like > > the Geode outperforms them in any terms. There is simple significant >[root@mobile1 /root]# cat /proc/cpuinfo >processor : 0 >vendor_id : CyrixInstead >cpu family : 5 >model : 7 >model name : Cyrix MediaGXtm MMXtm Enhanced >stepping: 4 >fdiv_bug: no >hlt_bug : no >sep_bug : no >f00f_bug: no >coma_bug: no >fpu : yes >fpu_exception : yes >cpuid level : 2 >wp : yes >flags : fpu msr cx8 cmov 16 mmx cxmmx >bogomips: 46.89 Let's just say I haven't exactly been thrilled with the performance of the geode samples we've been using at work. I have a 486 at home that outperforms this sucker. Maybe it's clocking itself down for heat reasons, but it really, really sucks. (Especially since I'm trying to get it to do ssl.) And yes, we're thinking about transmeta as a potential replacement for the next generation hardware. We're also looking around for other (x86 compatable) alternatives... > > Well the actual paper states that the theorethical performance was "just" > > 20% worser then a comparable normal design. Well "just 20%" is a half > > universe diameter for CPU designers. In the case of transmeta, that's in exchange for a third processor core, which is probably worth something. 20% is only about 3 months of moore's law. 90% of processor speed improvements over the past few years have been die size shrinks. You could clock a 486 at several hundred mhz with current manufacturing techniques, and get better performance out of it than low end pentiums. (Somebody did it with a bottle of frozen alcohol and got themselves injured, but was managing a quite nice quake frame rate before the bottle exploded.) And that's not counting the fact a pentium has twice as many pins to suck data through... And I repeat, if you're clocking the processor over 10x the memory bus rate, your cache size and your memory bus become fairly important limiting factors. (Modern processors are much more efficient about using the memory bus, doing bursts and predictive prefetches and all. But that's a seperate issue.) Look at pentium 4. Almost all the work done there was simply so they could clock the sucker higher, because Intel uses racy logic in their designs and had to break everything down into really small pipeline stages to get the timing tolerances into something they could manufacture above 1 ghz. It's AT LEAST 20% slower per clock than a PIII or Athlon. It's all noise compared to manufacturing advances shrinking die sizes and reducing trace lengths and capacitance and all that fun stuff... > So what? Crusoe isn't designed for use in supercomputers. It's designed > for use in laptops where the user is running an email reader, a web Not just that, think "cluster density". 142 processors per 1U, air cooled, running around 600 mhz each. The winner hands down in mips per square foot. (Well, I suppose you could do the same thing with arm, but I haven't seen it on the market yet. I may not have been paying attention...) > browser, a word processor, and where the user couldn't give a cr*p about > performance as long as it isn't noticeable (20% *isn't* for those types > of apps), but where the user does give a cr*p about how long his or her > battery lasts (ie, the entire business day, and not running out of power > at lunch time). Our mobiles aren't (currently) battery powered, but a processor that doesn't clock itself down to 46 bogomips when it's running without a fan is a GOOD thing if you're trying to pump encrypted bandwidth through it at faster than 350 kilobytes per second. (The desktop units are getting 3.5 megs/second running the same code...) > Yes, it *can* be used in a supercomputer (or more preferably, a cluster > of Linux machines), or even as a server where performance isn't the > number one concern and things like power usage (read: anywhere in > California right now ;-) ), and rack size are important. You can always > get faster, more efficient hardware, but you'll pay for it. It's still not power, it''s heat. You can run some serious voltage into a rack pretty easily, but it'll melt unless you bury the thing in fluorinert, which is expensive. (Water cooling of an electrical applicance is NOT something you want to be anywhere near when anything goes wrong.) Processors in a 1U are tied together by a PCI bus or some such. The latency going from one to another is very low. Processors in different racks are tied together by cat 5 or myrinet or some such, and have a much higher latency due to speed of light concerns. A tightly enough coupled cluster can act like NUMA, which can deal with a lot
Re: Why use threads ( was: Alan Cox quote?)
On Wed, Jun 20, 2001 at 03:18:58PM -0700, David Schwartz wrote:
> As I said, you don't want to use one thread for each client. You use, say,
> 10 threads for the 16,000 clients. That way, if an occasional client
> ambushes a thread (say by reading a file off an NFS server or by using some
> infrequently used code that was swapped to a busy disk), your server will
> keep on humming.
This same approach can easily be used by multiple processes.
I don't see what is gained by using threads over processes for such an
architecture.
mrc
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Wed, Jun 20, 2001 at 11:09:10PM +0100, Alan Cox wrote: > > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html > > > Of course the URL that goes with that is : > http://www.microsoft.com/windows2000/interix/features.asp > > Yes., Microsoft ship GNU C (quite legally) as part of their offerings... Which brings up an interesting question for us all. Let's postulate, for the sake of discussion, that we agree on the following: a) Linux (or just about any Unix) is a better low level OS than NT b) Microsoft's application infrastructure is better (the COM layer, the stuff that lets apps talk to each, the desktop, etc). I know we can argue that KDE/GNOME/whatever is going to get there or is there or is better, etc., but for the time being lets just pretend that the Microsoft stuff is better. What would be wrong with Microsoft/Linux? It would be: a) the Linux kernel b) the Microsoft API ported to X c) Microsoft apps d) Linux apps Since Microsoft is all about making money, it doesn't matter if they charge for the dll's or the OS, either one is fine, you can't run Word without them. If you don't need the Microsoft apps, you could strip them off and strip off the dlls and ship all the rest of it without giving Microsoft a dime. If you do need the apps or you want the app infrastructure, you have to give Microsoft exactly what you have to give them today - money - but you can run Word side by side with Ghostview or whatever. Microsoft could charge exactly the same amount for the dll's as they charge for the OS, none of the end users can tell the difference anyway. I'm unimpressed with what Microsoft calls an operating system and I'm equally unimpressed with what Unix calls an application layer. For the last 10 years, Unix has gotten the OS right and the apps wrong and Microsoft has gotten the apps right and the OS wrong. Seems like there is potential for a win-win. You can scream all you want that "it isn't free software" but the fact of the matter is that you all scream that and then go do your slides for your Linux talks in PowerPoint. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Wednesday 20 June 2001 23:33, Rik van Riel wrote: > On 20 Jun 2001, Miles Lane wrote: > > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html > > Yes, he sure knows how to bring Linux to the attention > of people ;) Not to mention the GPL, which I can guarantee you, before today my mom had *never* heard of. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: freeze with 2.4.5-ac16
On Wed, 20 Jun 2001, Justin Guyett wrote: > I got it to freeze in console (two generic find / -type f / type d), one > process allocating and writing 0 to 192mb > > machine responds to pings, switching VTs works > > (256 physical, 512 swap) happened again (vt1 and 2 echo but shells are unresponsive, vt3+ don't echo) only active process was the program allocating 192mb and writing to it, no find this time. SysRq : Show Memory Mem-info: Free pages:1524kB ( 0kB HighMem) ( Active: 22717, inactive_dirty: 18852, inactive_clean: 0, free: 381 (383 766 1149) ) 1*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB = 508kB) 2*4kB 0*8kB 1*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB = 1016kB) = 0kB) Swap cache: add 241834, delete 202609, find 1028/3579 Free swap: 369532kB 65520 pages of RAM 0 pages of HIGHMEM 1595 reserved pages 1633 pages shared 39225 pages swap cached 0 pages in page table cache Buffer memory: 5544kB gSysRq : SAK justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: filldir() function
Hello, > Please someone tell me what is the function of filldir() function. I > could not understand it from the code. Just give me an outline of what it > will do. This function is used in foo_readdir() (ie. ext2_readdir()). Purpose of this function is to copy given data to buffer supplied by user. Honza -- Jan Kara <[EMAIL PROTECTED]> SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Wed, 20 Jun 2001, Alan Cox wrote: > > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html > > > Of course the URL that goes with that is : > http://www.microsoft.com/windows2000/interix/features.asp > > Yes., Microsoft ship GNU C (quite legally) as part of their offerings... As well as: http://www.microsoft.com/presspass/press/2000/Apr00/WinUNIXPR.asp where they announce distributing ActiveState's Perl 5.6 as part of their toolset. (Which they funded the development of...) Seems they are willing to use Open Source if it suits their purposes... [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "All power is derived from the barrel of a gnu." - Mao Tse Stallman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove null register_disk
> Some, rather different, form will come back. > For now I would prefer throwing out as much as possible. Ok it looks like a 2.5 thing, and something for Al Viro and you to figure out so I'll ignore the change for 2.4 and go away - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Threads are processes that share more
I thought one only refers to LWPs when talking about kernel level threads not user-space ones? Ognen On Wed, 20 Jun 2001, Stephen Satchell wrote: > By the way, I'm surprised no one has mentioned that a synonym for "thread" > is "lightweight process". > > Satch -- Ognen Duzlevski Plant Biotechnology Institute National Research Council of Canada Bioinformatics team - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove null register_disk
> Is it worth keeping these so we can build things like nice > /proc files or use them later ? Some, rather different, form will come back. For now I would prefer throwing out as much as possible. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac16 kernel panic
> 2.4.5-ac16 patch applied to clean 2.4.5 tree. 2.4.5-ac15 boots > with no problem. Yes I screwed up the bootflag handling > EIP:0010:[] > EFLAGS: 00010286 > eax: 007ec000 ebx: e080 ecx: 3f7ec000 edx: c0101000 Can you build with kernel debug enabled and then say Y to all the debug options and give me the BUG() message where that next build dies. I think I know whats up I want to be sure - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Threads are processes that share more
At 08:48 PM 6/20/01 +0200, Martin Devera wrote: >BTW is not possible to implement threads as subset of process ? >Like thread list pointed to from task_struct. It'd contain >thread_structs plus another scheduler's data. >The thread could be much smaller than process. > >Probably there is another problem I don't see, I'm just >currious whether can it work like this .. Threads would then run, as a group, at the priority of the process, and then by priority within the process thread group. To be truely useful, threads need to be able to have their run priority divorced from the priority of the spawning process. By the way, I'm surprised no one has mentioned that a synonym for "thread" is "lightweight process". Satch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is there a linux running on jvm arch ?
> I 've tested the User Mode Linux a few times ago, and it gave me an > idea: given the fact that we had a GCC which > produce bytecode from C, it would be possible to produce a port of > linux(a new directory "jvm" in the arch dir) which > would run in a Java Virtual Machine. (after some inquiries such compiler > does not exist :-( ) > I'm dreaming of a linux booting in a browser applet(imagine sending such > thing in a mail to MS peoples ) The JVM is very very bad from a C language point of view. You can convert C code to it and there have been some very experimental demos of this. However it is a very non trivial problem Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
> http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html > Of course the URL that goes with that is : http://www.microsoft.com/windows2000/interix/features.asp Yes., Microsoft ship GNU C (quite legally) as part of their offerings... Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ip_tables/ipchains
try to delete those two modules, and repit depmod -a then try to load the modules. ipchain and ipfwadm modules do have symbols inside that are confusing depmode/modprobe dor dependency of actual netfilter modules. On Wed, 20 Jun 2001, Ted Gervais wrote: > On Wed, 20 Jun 2001, Luigi Genoni wrote: > > > Have you also compiled modules for ipchains and ipfwadm support?? > > > Yes. Is this a mistake?? > > > > > > > On Wed, 20 Jun 2001, Ted Gervais wrote: > > > > > Wondering something.. > > > I ran insmod to bring up ip_tables.o and I received the following error: > > > > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > > > symbol nf_unregister_sockopt > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > > > symbol nf_register_sockopt > > > > > > This is with kernel 2.4.5 and Slackware 7.1 is the distribution. > > > Does anyone know what these unresolved symbols are about?? > > > > > > --- > > > Doubt is not a pleasant condition, but certainty is absurd. > > > -- Voltaire > > > > > > Ted Gervais <[EMAIL PROTECTED]> > > > 44.135.34.201 linux.ve1drg.ampr.org > > > > > > > > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > > --- > Doubt is not a pleasant condition, but certainty is absurd. > -- Voltaire > > Ted Gervais <[EMAIL PROTECTED]> > 44.135.34.201 linux.ve1drg.ampr.org > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
> This is exactly the reason why Transmetians love to > showcase DVD playing and other performance related > stuff - it is where they beat Geode. Geode's performance > is quite adequate for kiosk/POS app and it's a formiddable Geode is jut about capable of MPEG1. The VIA processors are extremely interesting in the price/performance positioning. Neither of them are going to win a power consumption battle with an ARM - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Early flush (was: spindown)
On Wednesday 20 June 2001 22:58, Tom Sightler wrote: > Quoting Daniel Phillips <[EMAIL PROTECTED]>: > > I originally intended to implement a sliding flush delay based on disk > > load. > > This turned out to be a lot of work for a hard-to-discern benefit. So > > the > > current approach has just two delays: .1 second and whatever the bdflush > > > > delay is set to. If there is any non-flush disk traffic the longer > > delay is > > used. This is crude but effective... I think. I hope that somebody > > will run > > this through some benchmarks to see if I lost any performance. > > According to > > my calculations, I did not. I tested this mainly in UML, and also ran > > it > > briefly on my laptop. The interactive feel of the change is immediately > > > > obvious, and for me at least, a big improvement. > > Well, since a lot of this discussion seemed to spin off from my original > posting last week about my particular issue with disk flushing I decided to > try your patch with my simple test/problem that I experience on my laptop. > > One note, I ran your patch against 2.4.6-pre3 as that is what currently > performs the best on my laptop. It seems to apply cleanly and compiled > without problems. > > I used this kernel on my laptop kernel on my laptop all day for my normal > workload which consist ofa Gnome 1.4 desktop, several Mozilla instances, > several ssh sessions with remote X programs displayed, StarOffice, VMware > (running Windows 2000 Pro in 128MB). I also preformed several compiles > throughout the day. Overall the machine feels slightly more sluggish I > think due to the following two things: > > 1. When running a compile, or anything else that produces lots of small > disk writes, you tend to get lots of little pauses for all the little > writes to disk. These seem to be unnoticable without the patch. OK, this is because the early flush doesn't quit when load picks up again. Measuring only the io backlog, as I do now, isn't adequate for telling the difference between load initiated by the flush itself and other load, such as cpu bound process proceding to read another file, so that's why the flush doesn't stop flushing when other IO starts happening. This has to be fixed. In the mean time, you could try this simple tweak: just set the lower bound, currently 1/10th second a little higher: - unsigned check_interval = HZ/10, ... + unsigned check_interval = HZ/5, ... This may be enough to bridge the little pauses in the the compiler's disk access pattern so the flush isn't triggered. (This is not by any means a nice solution.) If you set check_interval to HZ*5, you *should* get exactly the old behaviour, I'd be very interested to hear if you do. Also, could you do your compiles with 'time' so you can quantify the results? > 2. Loading programs when writing activity is occuring (even light activity > like during the compile) is noticable slower, actually any reading from > disk is. Hmm, let me think why that may be. The loader doesn't actually read the program into memory, it just maps it and lets the pages fault in as they're called for. So if readahead isn't perfect (it isn't) the io backlog may drop to 0 briefly just as the kflush decides to sample it, and it initiates a flush. This flush cleans the whole dirty list out, stealing bandwidth from the reads. > I also ran my simple ftp test that produced the symptom I reported earlier. > I transferred a 750MB file via FTP, and with your patch sure enough disk > writing started almost immediately, but it still didn't seem to write > enough data to disk to keep up with the transfer so at approximately the > 200MB mark the old behavior still kicked in as it went into full flush > mode, during the time network activity halted, just like before. The big > difference with the patch and without is that the patched kernel never > seems to balance out, without the patch once the initial burst is done you > get a nice stream of data from the network to disk with the disk staying > moderately active. With the patch the disk varies from barely active > moderate to heavy and back, during the heavy the network transfer always > pauses (although very briefly). > > Just my observations, you asked for comments. Yes, I have to refine this. The inner flush loop has to know how many io submissions are happening, from which it can subtract its own submissions and know sombebody else is submitting IO, at which point it can fall back to the good old 5 second buffer age limit. False positives from kflush are handled as a fringe benefit, and flush_dirty_buffers won't do extra writeout. This is easy and cheap. I could get a lot fancier than this and caculate IO load averages, but I'd only do that after mining out the simple possibilities. I'll probably have something new for you to try tomorrow, if you're willing. By the way, I'm not addressing your fundamental problem, that's Rik's job
Re: [PATCH] remove null register_disk
> showing that register_disk is void when its first argument is NULL. > This allows one to remove some dead code. > Can be applied to 2.4. No behaviour is changed. Is it worth keeping these so we can build things like nice /proc files or use them later ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IP_ALIAS in 2.4.x gone?
I found the problem... IP_ALIAS is no longer needed in the config. I screwed up the init script configs for it so it did not work as expected. The documentation does not reflect that the alias behaviour is on by default. I will submit a patch for the docs that reflects this so others will not get confused by that. On Wed, 20 Jun 2001, Alan Olsen wrote: > > Has the IP_ALIAS functionality been replaced by something else in the > 2.4.x kernels? > > Documentation/networking/alias.txt seems to imply that it still does, but > the string IP_ALIAS does not exist anywhere else in the entire source > tree. (Unless you count the default configs for non-i86 architectures. > > There is a "virtual server" option in the kernel that ships with Redhat, > but I assume that this is a patch for something Redhat specific. (It is > not an option in 2.4.5, unless I am missing something.) > > How is binding multiple IPs to a single ethernet card *supposed* to be > handled under 2.4.x? If the IP_ALIAS option is no longer valid, then the > alias.txt doc should be changed to reflect the new option. > > Thanks! > > [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply > Alan Olsen| to my mail, just hit the ctrl, alt and del keys. > "All power is derived from the barrel of a gnu." - Mao Tse Stallman > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "All power is derived from the barrel of a gnu." - Mao Tse Stallman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
freeze with 2.4.5-ac16
I got it to freeze in console (two generic find / -type f / type d), one process allocating and writing 0 to 192mb machine responds to pings, switching VTs works (256 physical, 512 swap) Mem-info Free pages: 1524kB (0kB High) ( Active: 39586, inactive_dirty: 18590, inactive_clean: 0, free: 381 (383 766 1149) ) 1 1 1 1 1 1 1 0 0 0 = 508kB 2 0 1 1 1 1 1 1 0 0 = 1016kB Swap cache: add 152715, delete 98195, find 775/1918 Free swap: 307720kB 65520 pages of RAM 0 pages of HIGHMEM 1595 reserved pages 1146 pages shared 54520 pages swap cached 0 pages in page table cache Buffer memory: 12444kB find x/y seemed to be increasing y very slowly (5 minutes ago was at 1916, free was at 380 I think) justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Any gain to supporting only a single PCMCIA slot?
Hello. PCMCIA/Cardbus controllers typically (always?) support 2 slots, and system resources are allocated to support those slots. When you build PCMCIA support into your kernel, you are implicitly asking for both slots to be supported. I'm wondering if it would be worthwhile to let the user opt out of supporting one of the slots. Compaq, in their finite wisdom, only provides a single Type2 Cardbus slot on my Presario 1260 notebook. The controller (a TI PCI1131, see below) can handle 2 slots, of course, but only a single physical connector is present on this machine. Therefore I will never get the use of half of the controller, including the I/O address, etc. that the kernel has allocated for it. Would it be worth the savings in system resources to allow support for only a single slot? Thank you. --- # cat /proc/iomem -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-09ff : System RAM 0010-001d1aad : Kernel code 001d1aae-0021083f : Kernel data 1000-1fff : Texas Instruments PCI1131 10001000-10001fff : Texas Instruments PCI1131 (#2) 1040-107f : PCI CardBus #01 1040-1041 : PCI device 10b7:6564 1080-10bf : PCI CardBus #01 1080-1080007f : PCI device 10b7:6564 10800080-108000ff : PCI device 10b7:6564 10800100-108001ff : PCI device 10b7:6565 10800200-1080027f : PCI device 10b7:6565 10c0-10ff : PCI CardBus #05 1100-113f : PCI CardBus #05 fd00-fdff : Neomagic Corporation NM2160 [MagicGraph 128XD] fea0-febf : Neomagic Corporation NM2160 [MagicGraph 128XD] fecff000-fecf : OPTi Inc. 82C861 fed0-fedf : Neomagic Corporation NM2160 [MagicGraph 128XD] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: is there a linux running on jvm arch ?
>I 've tested the User Mode Linux a few times ago, and it gave me an >idea: given the fact that we had a GCC which >produce bytecode from C, it would be possible to produce a port of >linux(a new directory "jvm" in the arch dir) which >would run in a Java Virtual Machine. (after some inquiries such compiler >does not exist :-( ) >I'm dreaming of a linux booting in a browser applet(imagine sending such >thing in a mail to MS peoples ) While I am not sure if this is possible with Linux, something like this has already been done with Inferno. Check out: http://www.vitanuova.com/inferno/pidoc/index.html B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On 20 Jun 2001, Miles Lane wrote: > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html Yes, he sure knows how to bring Linux to the attention of people ;) Rik -- Executive summary of a recent Microsoft press release: "we are concerned about the GNU General Public License (GPL)" http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove null register_disk
> We will need register_disk(). > Reinserting it into the right places in 2.5 is a unnecessary PITA. (i) today this is dead code (ii) I am slowly restructuring all blockdev code, mainly with the purpose of freeing partition code from the bowels of the various drivers. In the process register_disk() changes prototype, and grok_partitions() disappears. For example, patch 06 that I made an hour or so ago deletes the "minors" parameter of both. What, if anything, will be reinserted later will be rather different from what is there today. Indeed, these cdrom drivers do not need a register_disk(). Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
is there a linux running on jvm arch ?
I 've tested the User Mode Linux a few times ago, and it gave me an idea: given the fact that we had a GCC which produce bytecode from C, it would be possible to produce a port of linux(a new directory "jvm" in the arch dir) which would run in a Java Virtual Machine. (after some inquiries such compiler does not exist :-( ) I'm dreaming of a linux booting in a browser applet(imagine sending such thing in a mail to MS peoples ) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac16 kernel panic
2.4.5-ac16 patch applied to clean 2.4.5 tree. 2.4.5-ac15 boots with no problem. model name : AMD Athlon(tm) Processor Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 3). PnP: PNP BIOS installation structure at 0xc00fc2b0 PnP: PNP BIOS version 1.0, entry at f:c2e0, dseg at f Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket invalid operand: CPU:0 EIP:0010:[] EFLAGS: 00010286 eax: 007ec000 ebx: e080 ecx: 3f7ec000 edx: c0101000 esi: 1ffec000 edi: 1ffec000 ebp: esp: dffe3f54 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=dffe3000) Stack: e080 1ffec000 1ffec000 0246 1ffec000 1ffec000 1ffec000 c0126384 0010 007ec000 c0101e08 1ffec000 3f7ec000 c0111521 e080 1ffec000 1ffec000 1ffec000 c00f6ed8 0014 000f6ed0 3ffd7fff Call Trace: [] [] [] [] [] [] [] Code: 0f 0b e9 40 01 00 00 8b 44 24 28 8b 54 24 2c 8b 4c 24 34 8b <0>Kernel panic: Attempted to kill init -- Gary White Network Administrator [EMAIL PROTECTED] Internet Pathway Voice 601-776-3355Fax 601-776-2314 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.20-pre4
On Tue, 19 Jun 2001, Alan Cox wrote: > > Is it mean now kernel 2.2 with prepatch is (or will be) gcc 3.0 ready ? > > If not what must be fixed/chenged to be ready ? > > It wont build with gcc 3.0 yet. To start with gcc 3.0 will assume it can > insert calls to 'memcpy' I tried it, but didn't run into problems (apart from the volatile xtime thing) Linux version 2.2.18 (eric@andredvb) (gcc version 3.0 (Debian)) #1 Wed Jun 20 23:15:46 CEST 2001 (Tons of warnings, though) Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
Rob Landley writes: > My only real gripe with Linux's threads right now [...] is > that ps and top and such aren't thread aware and don't group them > right. > > I'm told they added some kind of "threadgroup" field to processes > that allows top and ps and such to get the display right. I haven't > noticed any upgrades, and haven't had time to go hunting myself. There was a "threadgroup" added just before the 2.4 release. Linus said he'd remove it if he didn't get comments on how useful it was, examples of usage, etc. So I figured I'd look at the code that weekend, but the patch was removed before then! There is nothing that ps and top can do about this problem. I've certainly looked into the matter; much of the code is mine. BTW, the version in debian-unstable is the most stable. :-) These options might help a little bit: --forest -H f > (Ever tried to sumit a patch to the FSF? They want you to sign > legal documents. That's annoying. I usually just send the bug > reports to red hat and let THEM deal with it...) Submit patches to me, under the LGPL please. The FSF isn't likely to care. What, did you think this was the GNU system or something? > Linus's job is to keep code OUT of the kernel. He has veto power, > nothing else. I suspect he's pre-emptively vetoing some stuff to > keep the flood down to a level he can deal with. Maybe someday > we'll convince him to use some variant of source control (not > necessarily CVS, how about just a seperate mailing list of the > individual patches as he applies them? One linus can post to and > that is read-only to everybody else? HE always wants patches > seperated down nicely into individual messages with explanations, > but WE have to get pre2-pre3 as one big patch lump. With a > patches-from-linus mailing list that he forwarded posts to, we'd > know exactly when a patch went in and who it was from without > bothering Linus. :) How about a filesystem filter to spit out patches, or a filesystem interface to version control? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ip_tables/ipchains
On Wed, 20 Jun 2001, Jonathan Brugge wrote: > > > > Wondering something.. > > > > I ran insmod to bring up ip_tables.o and I received the following > >error: > > > > > > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > > > > symbol nf_unregister_sockopt > > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > > > > symbol nf_register_sockopt > > > > > > > > This is with kernel 2.4.5 and Slackware 7.1 is the distribution. > > > > Does anyone know what these unresolved symbols are about?? > > What if you do a modprobe ip_tables instead? I did. Sorry about saying ip_tables.o. I meant just ip_tables.. --- Doubt is not a pleasant condition, but certainty is absurd. -- Voltaire Ted Gervais <[EMAIL PROTECTED]> 44.135.34.201 linux.ve1drg.ampr.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IP_ALIAS in 2.4.x gone?
Has the IP_ALIAS functionality been replaced by something else in the 2.4.x kernels? Documentation/networking/alias.txt seems to imply that it still does, but the string IP_ALIAS does not exist anywhere else in the entire source tree. (Unless you count the default configs for non-i86 architectures. There is a "virtual server" option in the kernel that ships with Redhat, but I assume that this is a patch for something Redhat specific. (It is not an option in 2.4.5, unless I am missing something.) How is binding multiple IPs to a single ethernet card *supposed* to be handled under 2.4.x? If the IP_ALIAS option is no longer valid, then the alias.txt doc should be changed to reflect the new option. Thanks! [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "All power is derived from the barrel of a gnu." - Mao Tse Stallman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
On Wed, Jun 20, 2001 at 08:12:29AM -0700, Ben Greear wrote: > When was the last time you wrote a large cross-platform GUI that just > worked on other platforms, without any additional tweaking, after you > developed it on your Linux machine? I'd say that would be the last time I wrote something in GTK. SDL has similar portability. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE:Why use threads ( was: Alan Cox quote?)
> Nobody is arguing that having more than one thread of execution in an > application is a bad idea. On an SMP machine, having the same number of > processes/threads as there are CPUs is a requirement to get the scaling > if that app is all you are running. That's fine. But on a uniprocessor, > threads are basically stupid. The only place that I know of where it is > necessary is for I/O which blocks. And even there you only need enough > to overlap the I/O such that it streams. And processes will, and do, > work fine for that. It's very hard to use processes for this purpose. Consider, for example, a web server. You don't want to use one process for each client because that would limit your scalability (16,000 clients would become difficult, and with threads it's trivial). You don't want to use one thread for each client for obvious reasons. The risk with a poll loop type single-process design is that one client might perform an expensive operation and you can't afford to have your whole server stall. A worst-case kind of example would be reading a file from a slow NFS server. But more common are page faults from slow disks when a piece of code in the web server that handles some obscure feature needs to fault in. This can theoretically be handled by a process pool architecture with suitable shared memory, but that's much more difficult to get right than threads. And there's no advantage gained from the extra effort. Another case where threads can be extremely useful is for special tasks with timing requirements. Consider, for example, time and timer management. Many programs have requirements for a monotonic timer that can provide reasonable guarantee that intervals will be accurately measured so that future events will trigger at the right time. For example, if you need to idle out a connection if it's not used for, say, 30 seconds it may be unacceptable to have all your connections stay around for an hour if the clock jumps backwards. This is very easy to do if you have a thread monitor the clock and wake up every second. If the clock jumps forward, it can let virtual time run a bit faster until it catches up. If it jumps backwards, it can slow virtual time down keeping it always monotonic. This can provide a reasonable guarantee that no matter what the system time does (short of jumping every second!) your 30 second timer will be between, say, 25 and 35 seconds. This can also provide a good way to measure elapsed time that is well-protected from system clock issues. Without a separate thread, it's very hard to assure that the the clock monitoring code runs often enough to keep its timebase. If it doesn't run for 6 seconds, it would think the time had jumped. As a separate thread, you can write this time monitoring timer management code one time and it will work with any other code regardless of how it blocks. The two things I have found threads most useful for (in fact, indispensable for) are ambush avoidance and dedicated threads for 'special' tasks that can't easily be done another way. Both of these things can, at least theoertically, by done using processes and shared memory or other IPC mechanisms, but threads is easier and cleaner. This is especially true for ambush avoidance. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Client receives TCP packets but does not ACK
> Btw: can the aplication somehow ask the tcp/ip stack what was > actualy acked? > (ie. how many bytes were acked). No, and you shouldn't want to know. Even if the other end ACKed the data, that doesn't mean that the application on the other end didn't crash. So it won't tell you what you want to know, which is 'did the application on the other end process the data?'. Application-level guarantees can only be provided by application-level code. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Early flush (was: spindown)
Quoting Daniel Phillips <[EMAIL PROTECTED]>: > I originally intended to implement a sliding flush delay based on disk > load. > This turned out to be a lot of work for a hard-to-discern benefit. So > the > current approach has just two delays: .1 second and whatever the bdflush > > delay is set to. If there is any non-flush disk traffic the longer > delay is > used. This is crude but effective... I think. I hope that somebody > will run > this through some benchmarks to see if I lost any performance. > According to > my calculations, I did not. I tested this mainly in UML, and also ran > it > briefly on my laptop. The interactive feel of the change is immediately > > obvious, and for me at least, a big improvement. Well, since a lot of this discussion seemed to spin off from my original posting last week about my particular issue with disk flushing I decided to try your patch with my simple test/problem that I experience on my laptop. One note, I ran your patch against 2.4.6-pre3 as that is what currently performs the best on my laptop. It seems to apply cleanly and compiled without problems. I used this kernel on my laptop kernel on my laptop all day for my normal workload which consist ofa Gnome 1.4 desktop, several Mozilla instances, several ssh sessions with remote X programs displayed, StarOffice, VMware (running Windows 2000 Pro in 128MB). I also preformed several compiles throughout the day. Overall the machine feels slightly more sluggish I think due to the following two things: 1. When running a compile, or anything else that produces lots of small disk writes, you tend to get lots of little pauses for all the little writes to disk. These seem to be unnoticable without the patch. 2. Loading programs when writing activity is occuring (even light activity like during the compile) is noticable slower, actually any reading from disk is. I also ran my simple ftp test that produced the symptom I reported earlier. I transferred a 750MB file via FTP, and with your patch sure enough disk writing started almost immediately, but it still didn't seem to write enough data to disk to keep up with the transfer so at approximately the 200MB mark the old behavior still kicked in as it went into full flush mode, during the time network activity halted, just like before. The big difference with the patch and without is that the patched kernel never seems to balance out, without the patch once the initial burst is done you get a nice stream of data from the network to disk with the disk staying moderately active. With the patch the disk varies from barely active moderate to heavy and back, during the heavy the network transfer always pauses (although very briefly). Just my observations, you asked for comments. Later, Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
The latest Microsoft FUD. This time from BillG, himself.
http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ip_tables/ipchains
> > On Wed, 20 Jun 2001, Ted Gervais wrote: > > > > > Wondering something.. > > > I ran insmod to bring up ip_tables.o and I received the following >error: > > > > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > > > symbol nf_unregister_sockopt > > > /lib/modules/2.4.5/kernel/net/ipv4/netfilter/ip_tables.o: unresolved > > > symbol nf_register_sockopt > > > > > > This is with kernel 2.4.5 and Slackware 7.1 is the distribution. > > > Does anyone know what these unresolved symbols are about?? What if you do a modprobe ip_tables instead? _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
> This [code morphing and binary tranlation] > was set off to provide compensation for the biggest hurdle > of VLIW design - insane code size and partially huge memmory > bus bandwidth designs due to this. (Why do you think the itanim > sucks on integer performance?) First, Merced does not suck on integer performance. It does about 300 SPEC CPU2000 at 733MHz, give or take, subject to compiler improvements. That blows all RISCs out of the water (except Alpha, yet. The best result they submitted is 511 base 533 peak at 833MHz). > [...] Well but in relity underclocked modern > design optimized for power consumtions beat the transmeta > chip easly: Geode, and the recently announced VIA chip to name a few. Man, where do you get this falsehood. TM-5400 is way, way faster than Geode (several times for any benchmark). This is exactly the reason why Transmetians love to showcase DVD playing and other performance related stuff - it is where they beat Geode. Geode's performance is quite adequate for kiosk/POS app and it's a formiddable competitor for anything that needs no performance. > In comparision to chip design esp. targetted at low power consumtion > the transmeta chip is laughable: this ARM please! My psion > beats *ANY* chip from them by huge magnitude. "Beats" by what metric? Sucks harder? -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
Don't forget the linux-kernel favorite, "Debuggers are for bad programmers". } Here are more from the same basket you obviously got the first quote from: } } } Virtual memory is only for unskilled programmers who don't know how to use } overlays. } } Protected memory is a constant 10% CPU hog needed only by undisciplined } programmers who can't keep their memory writes in their own process space. } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How to compile on one machine and install on another?
On Tue, Jun 19, 2001 at 04:55:10PM -0400, Tom Diehl wrote:
> On Tue, 19 Jun 2001, Alan Cox wrote:
>
> > Other than making sure you configure it for the box it will eventually run
> > on - nope you have it all sorted. If you use modules you'll want to install
> > the modules on the target machine too
>
> What is the best way to install the modules? Is there a directory _all_ of
> the modules exist in b4 you do "make modules_install". I usually end up
> setting EXTRAVERSION to something unique and doing a make modules_install.
> That way it does not hose up the modules for the build machine.
> Is there a better way?
Change MODLIB in $(TOPDIR)/Makefile (e.g. /usr/src/linux/Makefile). I do this
to compile the kernel and modules without root priviledges at all. make
modules_install will fail at the end when trying to run 'depmod', but that's
okay - you can do that yourself:
(TOPDIR=${HOME}/linux, MODLIB=${HOME}/kernel//modules)
cd $TOPDIR
make config dep clean bzImage modules && cp arch/i386/boot/bzImage System.map \
${MODLIB}/../ && make modules_install || echo modules_install failed as expected
cd ${MODLIB}/../
mkdir -p lib/modules
ln -s ${PWD}/modules lib/modules/`uname -r`
depmod -F System.map -C /dev/null -b $PWD -r -a
Note that Joe Average user can do all of this, root need not be involved at
all.
Then fix up the resulting modules.dep with sed, I don't remember what depmod
gives you exactly so I can't type out the exact command.. then clean up:
rm lib/modules/`uname -r` ; rmdir lib/modules lib
Now you have a nice kernel package ready to go in $HOME/kernel. Don't forget
to copy $MODLIB into the right spot (rename the directory to the kernel's
revision) and chown -R root or modutils will pout, unless you are making a
romfs or such where the only user is root :-) nfs will work just fine without
security qualms since the kernel installation is non-root owned. (for
large-scale deployment, you probably can't beat having machines booting from
a server and fetching new romfs images each boot.)
btw, the abuse of depmod in this way isn't very nice, but afaics there is no
other way. I would personally like depmod to dump dependency information for
any valid module tree, expanding the definition of valid to include trees not
prefixed by /lib/modules/`uname -r`, but oh well, it gets by in the end as so
many other things do ;-)
Maciek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove null register_disk
On Wed, 20 Jun 2001 [EMAIL PROTECTED] wrote:
> In fs/partitions/check.c we read
>
> void register_disk(struct gendisk *gdev, kdev_t dev, unsigned minors,
> struct block_device_operations *ops, long size)
> {
> if (!gdev)
> return;
> grok_partitions(gdev, MINOR(dev)>>gdev->minor_shift, minors, size);
> }
>
> showing that register_disk is void when its first argument is NULL.
> This allows one to remove some dead code.
> Can be applied to 2.4. No behaviour is changed.
That's simply wrong. We will need register_disk(). Reinserting it into the
right places in 2.5 is a unnecessary PITA.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] remove null register_disk
In fs/partitions/check.c we read
void register_disk(struct gendisk *gdev, kdev_t dev, unsigned minors,
struct block_device_operations *ops, long size)
{
if (!gdev)
return;
grok_partitions(gdev, MINOR(dev)>>gdev->minor_shift, minors, size);
}
showing that register_disk is void when its first argument is NULL.
This allows one to remove some dead code.
Can be applied to 2.4. No behaviour is changed.
(I sent patch 01, adding set blocksize ioctls - hope you applied it.
And patch 02, adding blkdev_get_size_in_bytes - hope you didnt,
ftp.kernel.org has the right version but I mailed a version with typo.
This is patch 05, independent of earlier ones, an attempt to break 1+MB
of patch into meaningful small fragments that each improve something.)
Andries
diff -u --recursive --new-file ../linux-2.4.6-pre3/linux/arch/m68k/atari/stram.c
./linux/arch/m68k/atari/stram.c
--- ../linux-2.4.6-pre3/linux/arch/m68k/atari/stram.c Fri Feb 9 20:29:44 2001
+++ ./linux/arch/m68k/atari/stram.c Wed Jun 20 21:35:56 2001
@@ -1067,8 +1067,6 @@
blksize_size[STRAM_MAJOR] = stram_blocksizes;
stram_sizes[STRAM_MINOR] = (swap_end - swap_start)/1024;
blk_size[STRAM_MAJOR] = stram_sizes;
- register_disk(NULL, MKDEV(STRAM_MAJOR, STRAM_MINOR), 1, _fops,
- (swap_end-swap_start)>>9);
return( 0 );
}
diff -u --recursive --new-file ../linux-2.4.6-pre3/linux/drivers/block/floppy.c
./linux/drivers/block/floppy.c
--- ../linux-2.4.6-pre3/linux/drivers/block/floppy.cFri Feb 9 20:30:22 2001
+++ ./linux/drivers/block/floppy.c Wed Jun 20 21:35:56 2001
@@ -4268,15 +4268,6 @@
devfs_unregister_blkdev(MAJOR_NR,"fd");
}
- for (drive = 0; drive < N_DRIVE; drive++) {
- if (!(allowed_drive_mask & (1 << drive)))
- continue;
- if (fdc_state[FDC(drive)].version == FDC_NONE)
- continue;
- for (i = 0; i> BLOCK_SIZE_BITS;
- register_disk(NULL, MKDEV(MAJOR_NR,i), 1, _fops,
- nbd_bytesizes[i]>>9);
}
devfs_handle = devfs_mk_dir (NULL, "nbd", NULL);
devfs_register_series (devfs_handle, "%u", MAX_NBD,
diff -u --recursive --new-file ../linux-2.4.6-pre3/linux/drivers/block/paride/pf.c
./linux/drivers/block/paride/pf.c
--- ../linux-2.4.6-pre3/linux/drivers/block/paride/pf.c Sun Feb 4 19:05:29 2001
+++ ./linux/drivers/block/paride/pf.c Wed Jun 20 21:35:56 2001
@@ -415,8 +415,6 @@
for (i=0;idsize;
jsfd_sizes[i] = jsfd_bytesizes[i] >> 10;
- register_disk(NULL, MKDEV(JSFD_MAJOR, i), 1, _fops,
- jsfd_bytesizes[i] >> 9);
set_device_ro(MKDEV(JSFD_MAJOR, i), 1);
}
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac15
On Tue, 19 Jun 2001, Walter Hofmann wrote:
> On Sun, 17 Jun 2001, Walter Hofmann wrote:
>
> > I had already two crashes with ac15. The system was still ping-able, but
> > login over the network didn't work anymore.
> >
> > The first crash happened after I started xosview and noticed that the
> > system almost used up the swap (for no apparent reason). The second
> > crash happened shortly after I started fsck on a crypto-loop device.
>
> FWIW, here is the vmstat output for the second (short) hang. Taken with
> ac14, vmstat 1 was started (long) before the hang and interrupted about
> five seconds after it. The machine has 128MB RAM and 256MB swap.
>procs memoryswap io system cpu
> r b w swpd free buff cache si sobibo incs us sy id
> 1 0 0 77000 1464 18444 67324 8 0 152 224 386 1345 26 19 55
> 2 4 2 77084 1524 18396 66904 0 1876 108 2220 2464 66079 1 98 1
Does the following patch help with this problem, or are
you both experiencing something unrelated to this particular
buglet ?
regards,
Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
--- linux/mm/swapfile.c.~1~ Thu May 3 16:34:46 2001
+++ linux/mm/swapfile.c Thu May 3 16:36:07 2001
@@ -67,8 +67,14 @@
}
/* No luck, so now go finegrined as usual. -Andrea */
for (offset = si->lowest_bit; offset <= si->highest_bit ; offset++) {
- if (si->swap_map[offset])
+ if (si->swap_map[offset]) {
+ /* Any full pages we find we should avoid
+* looking at next time. */
+ if (offset == si->lowest_bit)
+ si->lowest_bit++;
continue;
+ }
+
got_page:
if (offset == si->lowest_bit)
si->lowest_bit++;
@@ -79,6 +85,7 @@
si->cluster_next = offset+1;
return offset;
}
+ si->highest_bit = 0;
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
Mike Harrold wrote: > So what? Crusoe isn't designed for use in supercomputers. It's designed > for use in laptops where the user is running an email reader, a web > browser, a word processor, and where the user couldn't give a cr*p about > performance as long as it isn't noticeable (20% *isn't* for those types > of apps), but where the user does give a cr*p about how long his or her > battery lasts (ie, the entire business day, and not running out of power > at lunch time). I'm just to good in remembering the academing discussion about code morphing beeing a way to get more performance out of a chip design. They where claiming, that due to the fact they could make the underlying chip design much simpler and VLIW, the performance offset by the emulation wouldn't be smaller than the performance win in therms of a suprerior underlying chip architecture. This was set off to provide compensation for the biggest hurdle of VLIW design - insane code size and partially huge memmory bus bandwidth designs due to this. (Why do you think the itanim sucks on integer performance?) After this turned out the be the fact in reality - IBM dropped the developement of code morphing chips. Well transmeta turned to claims that the main advantage of it's design is much smaller power consumption. Well but in relity underclocked modern design optimized for power consumtions beat the transmeta chip easly: Geode, and the recently announced VIA chip to name a few. In comparision to chip design esp. targetted at low power consumtion the transmeta chip is laughable: this ARM please! My psion beats *ANY* chip from them by huge magnitude. > Yes, it *can* be used in a supercomputer (or more preferably, a cluster > of Linux machines), or even as a server where performance isn't the > number one concern and things like power usage (read: anywhere in > California right now ;-) ), and rack size are important. You can always > get faster, more efficient hardware, but you'll pay for it. Well the transmeta cpu isn't cheap actually. And if you talk about super computing, hmm what about some PowerPC CPU variant - they very compettetiv in terms of cost and FPU performance! Transmeta isn't the adequate choice here. > Remember, the whole concept of code-morphing is that the majority of > apps that people run repeat the same slice of code over and over (eg, > a word processor). Once crusoe has translated it once, it doesn't need > to do it again. It's the same concept as a JIT java compiler. Well both of those concepts fail in terms of optimization due to the same reason: much less information is present about the structure of the code then during source code compilation. And therefore usually the performance of any kind of JIT compiler *sucks* in comparision to classical sophisticated compilers. Additionaly there may be some performance wins due to the ability of runtime profiling (anykind thereof), however it still remains to be shown that this performs better then statically analyzed code. > /Mike - who doesn't work for Transmeta, in case anyone was wondering... :-) /Marcin - who doesn't bet a penny on Transmeta - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Threads FAQ entry incomplete
Rodrigo Ventura <[EMAIL PROTECTED]> wrote: > > BTW, I have a question: Can the availability of dual-CPU boards for intel > and amd processors, rather then tri- or quadra-CPU boards, be explained with > the fact that the performance degrades significantly for three or more CPUs? > Or is there a technological and/or comercial reason behind? Commercial reasons. Cost per motherboard/chipset goes way up as the number of CPUs supported goes up. For each CPU that a chipset supports, it has to add a lot of pins/lands, and chipsets are already typically land-limited. Motherboard trace complexity (and therefore number of layers) goes up. Add to that that the potential market goes down as CPUs goes up. You can buy 4-, 8-, and 16-way motherboards for Intel CPUs (don't know about more). But the 16-way ones will cost as much as a house. Charles -- --- Charles Cazabon<[EMAIL PROTECTED]> GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/ Any opinions expressed are just that -- my opinions. --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac15
Walter Hofmann <[EMAIL PROTECTED]> writes: > It hung when I tried to close a browser window after reading the > text in it for quite some time. No swapping was going on. I've just seen this as well (for the first time) with -ac15. I was playing music with madplay at the time, and then did a "find . -type f -print0 | xargs -0 chmod 644" on a large directory tree on a reiserfs partition. A few seconds after I started the command, I got a hang which lasted a few seconds, then another, then another just after the find finished. It hasn't happened again since. All I got in the kernel log was: 2001-06-20 20:15:52.260230500 warning: Sound: DMA (output) timed out - IRQ/DRQ config error? 2001-06-20 20:16:07.472837500 warning: Sound: DMA (output) timed out - IRQ/DRQ config error? which makes sense, since the sound paused at the same time... Memory stats at the moment (i.e. about five minutes after it happened, with exactly the same stuff running): (azz:~) free total used free sharedbuffers cached Mem:288240 286652 1588196 30348 224860 -/+ buffers/cache: 31444 256796 Swap: 1048784 52176 996608 (azz:~) vmstat procs memoryswap io system cpu r b w swpd free buff cache si sobibo incs us sy id 1 0 0 52184 1588 30348 224876 0 25362 153 400 68 10 22 .config available on request. -- Adam Sampson <[EMAIL PROTECTED]> http://azz.us-lot.org/> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Alan Cox quote? (was: Re: accounting for threads)
Hi! It's hard not to reply to this kind of message but there is so much "anti-thread hype" here that someone obviously has to stand up to it. This reply isn't aimed just at Larry but at all the anti-thread-rant people with 0 threads == 0 problems attitude. On Tuesday 19 June 2001 18:09, Larry McVoy wrote: > "If you think you need threads then your processes are too fat" > ``Think of it this way: threads are like salt, not like pasta. You > like salt, I like salt, we all like salt. But we eat more pasta.'' Here are more from the same basket you obviously got the first quote from: Virtual memory is only for unskilled programmers who don't know how to use overlays. Protected memory is a constant 10% CPU hog needed only by undisciplined programmers who can't keep their memory writes in their own process space. > Threads are a really bad idea. I could *say* the same about Alans co-routines and Async IO :-). But it would be foolish of me to criticize something I haven't used. There is more than one way how to skin a dinosaur. And threads are one way of doing it. You don't like it ? FINE. But don't go bashing it. Probably most people bash threads becouse of a silly way POSIX designed (designed is an overstatement) their pthread API and becouse UNIX was around before threads thus probably making every UNIX thread support a hacked and not a designed tool. Other OSes have certainly proven threads to be nice and usable. And here is another one for you quotes page: If you can't stick your head out of your own backyard please... don't go and crtiticize the world... :-) -- best regards, Rok Pape. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
Martin Dalecki wrote:> > Rob Landley wrote: > > > Or if you like the idea of a JIT, think about transmeta writing a code > > morphing layer that takes java bytecodes. Ditch the VM and have the > > processor do it in-cache. > > Blah blah blah. The performance of the Transmeta CPU SUCKS ROCKS. No > matter > what they try to make you beleve. A venerable classical desing like > the Geode outperforms them in any terms. There is simple significant > information > lost between compiled code and source code. Therefore no JIT compiler > in this world will ever match the optimization opportunities of a > classic > C compiler! IBM researched opportunities for code morphing long ago > before > Transmeta come to live - they ditched it for good reasons. Well the > actual > paper states that the theorethical performance was "just" 20% worser > then > a comparable normal design. Well "just 20%" is a half universe diameter > for > CPU designers. So what? Crusoe isn't designed for use in supercomputers. It's designed for use in laptops where the user is running an email reader, a web browser, a word processor, and where the user couldn't give a cr*p about performance as long as it isn't noticeable (20% *isn't* for those types of apps), but where the user does give a cr*p about how long his or her battery lasts (ie, the entire business day, and not running out of power at lunch time). Yes, it *can* be used in a supercomputer (or more preferably, a cluster of Linux machines), or even as a server where performance isn't the number one concern and things like power usage (read: anywhere in California right now ;-) ), and rack size are important. You can always get faster, more efficient hardware, but you'll pay for it. Remember, the whole concept of code-morphing is that the majority of apps that people run repeat the same slice of code over and over (eg, a word processor). Once crusoe has translated it once, it doesn't need to do it again. It's the same concept as a JIT java compiler. /Mike - who doesn't work for Transmeta, in case anyone was wondering... :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Unknown PCI Net Device
I picked up a network card that claims to use the "most reliable Realtek LAN chip". The big chip is labelled "LAN-8139" so naturally I tried the 8139too driver. It doesn't find the device. I'm wondering if maybe it's just something in the device ID tables. Here's some info: # lspci -vv [snip] 00:0b.0 Ethernet controller: MYSON Technology Inc: Unknown device 0803 Subsystem: MYSON Technology Inc: Unknown device 0803 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Threads, inelegance, and Java
On Wed, 20 Jun 2001, Aaron Lehmann wrote: > However, the very concept of Java encourages not caring about > "performance, system-design or any elegance whatsoever". If you cared > about any of those things you would compile to native code (it exists Native code does not help performance much and it doesn't help elegance or system design at all. Programmers put incredible amounts of effort into design with C-related languages because they have to. If they don't their program will not work. Java makes it easy to write bad code that (mostly) works. This might mean that the average quality of Java code is not as good as it might be. But it's not a good reason not to write in Java. Programmers that put the same amount of effort into their Java code that they would have in C/C++ will write better programs faster than they would have in C. The fact that most programmers will not do this is not the fault of the language, but the programmers. > for a reason). Need run-anywhere support? Distribute sources instead. Distributing source gives you run-anywhere support provided that everyone you distribute to has the same compiler that you do and that you haven't missed any platform specific endianness, word size or type definition problems, and that your program doesn't require any I/O that isn't in the standard libraries, especially graphics. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
