Messages in this thread | | | Date | Mon, 7 Sep 1998 20:29:08 -0400 (EWT) | From | "Nicholas J. Leon" <> | Subject | 2.1.120 report [misc. stuff/longish] |
| |
Okay,
There are a few things I wish to point out about 2.1.120 on my P6DBE, SMP box ...
1. modules
root(5)@neko [103 /usr2/root] # depmod -ae /lib/modules/2.1.120/fs/nfs.o: unresolved symbol(s) checksignals /lib/modules/2.1.120/misc/sunrpc.o: unresolved symbol(s) checksignals /lib/modules/2.1.120/ipv4/ip_gre.o: unresolved symbol(s) icmpv6_send ipv6_addr_type
I've seen the patch for checksignals(), so that's easy. But not for the ip_gre unresolvables.
2. sluggishness
This is about as unprofessional as possible, but 2.1.120 feels _VERY_ sluggish compared to almost any other 2.1.x version. I _used_ to be able to "make MAKE='make -j4'" on one VC and burn a 2x cd on the other. No longer. In fact, even running PINE is difficult. There just isn't any responsiveness. Even backing up to my scsi tape (as I am doing now) causes minor delays while typing even though top shows nothing out of the ordinary:
1151 root 17 0 608 608 392 wait_on_b D 14.6 0.3 1:03 0 tar cRvl --totals -f /dev/tape / /usr/local
3. 3c59x driver
I put today a 3c905 into my box hoping to replace the 3c509 that I current have. The 3c509 would constantly get timeouts
09/07/1998 00:17:21 neko kernel: eth0: transmit timed out, Tx_status 00 status 2000 Tx FIFO room 4092. 09/07/1998 00:18:16 neko kernel: eth0: transmit timed out, Tx_status a0 status 2004 Tx FIFO room 1260. 09/07/1998 00:18:56 neko kernel: eth0: transmit timed out, Tx_status a0 status 2004 Tx FIFO room 340. 09/07/1998 00:29:46 neko kernel: eth0: transmit timed out, Tx_status a0 status 2004 Tx FIFO room 1464.
I reported this problem before, but was 100% ignored (or told "welcome to ethernet"). Even though, in testing, I only had two machines on my net. The box I'm talking about and another. There are no collisions or attempts to transmit at the same time (at least not to excess). Copying the linux 2.1.120 source tree from one box to another took well over 30m with well over 500+ timeouts. Completely unusable.
So I put the 3c905 in to see if it makes any difference. Unfortunately, when I load the module for it, I get:
c59x.c:v0.99F 8/7/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html The PCI BIOS has not enabled this device! Updating PCI command 0000->0005. eth1: 3Com 3c905 Boomerang 100baseTx at 0xef00, 00:60:97:7b:34:41, IRQ 5 8K word-wide RAM 3:5 Rx:Tx split, MII interface. MII transceiver found at address 24, status 7849. Enabling bus-master transmits and whole-frame receives.
And it doesn't work. I'm not sure what the above statement means, I have "plug-n-play aware OS" turned off, I used the configuration utility that came with the card to set it up and test it (all went OK). But the card is dead (not even the little indicator lights on the back of it turn on).
It also seems to say "100baseTx" which is wrong. And by looking through the 3c59x.c file, I noticed comments about passing media types to the module when loading, but couldn't locate the exact syntax (help anyone?)
4. unmounting / at shutdown/reboot doesn't work.
I've heard mention of this on the list, but haven't heard any solutions for it yet. So this is just a "me too!".
5. autofs
When trying to expire my /auto/boot automount point (set up via:
floppy -fstype=auto :/dev/fd0 boot -fstype=ext2 :/dev/hda1 zip -fstype=auto :/dev/sda4 cd -fstype=auto :/dev/hdd cdr -fstype=auto :/dev/sr0 madi -rw,soft,intr madi:/ pico -rw,soft,intr pico:/ )
autofs generates:
09/07/1998 20:20:53 neko kernel: autofs: negative dentry on expiry queue: boot
but unmounts the filesystem anyway.
-----
And that's about it. But I have an additional, perhaps non-kernel related question. I was fooling around with the different versions today and booted into 2.1.116. I noticed that it got my drive geometry wrong. S'ok. I rebooted back into 2.1.120 and SURPRISE!
LIL
instead of my lilo prompt. Fine. Kernel-on-a-disk. But when my machine rebooted AGAIN, I got a S.M.A.R.T error on my first HD (WD36400) from my BIOS "Drive C is damaged. Backup and replace." :-O ???
So, ummmm, was this pure coincidence? That seems rather odd. And, exactly how reliable is SMART? Is my drive truly dying (it doesn't _seem_ to be, I'm using it just fine) or did booting into 2.1.116 do something odd to it?? (Which I doubt).
I _am_ backing it up currently, but unless my BIOS coughs up some money to make its suggestion real, it isn't going to happen soon.
G'day!
-- n i c h o l a s j l e o n / elegance through simplicity / / good fortune through truth / http://mrnick.binary9.net / simplicity is elegant / mailto:nicholas@binary9.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/faq.html
| |