lkml.org 
[lkml]   [1998]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subject2.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

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.067 / U:0.368 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site