Posts by bnut

bnut · Help & Support (Stable)

what is the impact/effect of acpi=off on a workstation? Will that affect HD spin down?

bnut · Help & Support (Stable)

The intel card works perfectly. I need to figure out how to best permanently disable the eth0 after reboots now and be sure the default routes are persistent, but my network performance is working as expected atm. Any assistance in that arena would be welcome.

While I had the case cracked I went ahead and threw in an extra G of RAM I found lying around in my boneyard. All in all, I supposed it worked out in the positive.

Still, if anyone knows the proper resolution for the VT6102 [Rhine-II] it would be worth knowing.

bnut · Help & Support (Stable)

well, I have some more information.... so incidentally I was seeing somthing similar to gman's post which suggested some lack of BIOS support. I disabled acpi in my menu.lst which brought the cpu speed up. Nice. Then onto additional testing of the eth0

I did

lspci -vv

00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
        Subsystem: Elitegroup Computer Systems Device 0102
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32 (750ns min, 2000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 23
        Region 0: I/O ports at e400 [size=256]
        Region 1: Memory at ec102000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [40] 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-
        Kernel driver in use: via-rhine
        Kernel modules: via-rhine


root@kitchen:/# uname -a
Linux kitchen 2.6.28-17-generic #58-Ubuntu SMP Tue Dec 1 18:57:07 UTC 2009 i686 GNU/Linux

root@kitchen:/lib/modules/2.6.28-17-generic/kernel/drivers/net#  ls -la |grep via-rhine
-rw-r--r--  1 root root  44144 2009-12-01 15:05 via-rhine.ko

root@kitchen:/# lsmod |grep via_rhine
via_rhine              30856  0
mii                    13312  1 via_rhine

ok...and then

root@kitchen:/# dmesg |grep via-rhine
[    4.214544] via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
[    4.214549] via-rhine: Broken BIOS detected, avoid_D3 enabled.
root@kitchen:/#

so....it looks like a BIOS issue? I don't understand. Mobo BIOS? I'm running sk21s10c.bin and the newest is sk21s10e.bin (from 2007). bios link. I don't see anything about the ethernet in the changelog notes. Obviously, they're not going to update the BIOS at this point.

*edit* turns out the Broken BIOS message is common and avoid_D3 addresses this 'bug', so I'm disregarding this for now. However, what's the correct method for me to identify that the via-rhine driver is functioning as expected? I get no results using "locate via-rhine.c". Should I?

Surely this controller isn't unusable, is it? Do I need to dig out an old intel ethernet card?

bnut · Help & Support (Stable)

Hi all. I've been using #! for several months now (I commited to the switch about the time ext4 received support, iirc). Anyway, I've got it running on this machine my wife uses in the kitchen for looking up recipes and it's become unbearably slow lately for her to pull up sites in the browser. I don't believe this behavior was originally present.

Additionally, I'm getting alot of timeouts on connections (inbound scp, smb and https). Package updates time out, too. I'm presuming this is network related. I'm not having any luck figuring it out though. I'm hoping someone can set me on the right path.

Here's some of the relevant output, I think.

lspci:
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)

dmsg:
 eth0: link up, 100Mbps, full-duplex, lpa 0x45E1

ifconfig:
eth0      Link encap:Ethernet  HWaddr 00:30:1b:40:5e:64
          inet addr:192.168.0.101  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::230:1bff:fe40:5e64/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:159758 errors:0 dropped:0 overruns:0 frame:81329
          TX packets:152032 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:211984375 (211.9 MB)  TX bytes:16743947 (16.7 MB)
          Interrupt:23 Base address:0x8000

route:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
default         192.168.0.1     0.0.0.0         UG    100    0        0 eth0

I'm not seeing collisions (which I expected based on the behavior). No other devices on this router are giving me problems. I don't see anything obviously wonky in /var/log/messages. Also, I ran some tcpdumps and nothing jumped out at me there either.

This ping is to the directly attached switch:

 ping 192.168.0.3
PING 192.168.0.3 (192.168.0.3) 56(84) bytes of data.
64 bytes from 192.168.0.3: icmp_seq=1 ttl=64 time=2003 ms
64 bytes from 192.168.0.3: icmp_seq=2 ttl=64 time=997 ms
64 bytes from 192.168.0.3: icmp_seq=3 ttl=64 time=0.581 ms
64 bytes from 192.168.0.3: icmp_seq=4 ttl=64 time=0.653 ms
64 bytes from 192.168.0.3: icmp_seq=6 ttl=64 time=0.692 ms
64 bytes from 192.168.0.3: icmp_seq=7 ttl=64 time=0.700 ms
64 bytes from 192.168.0.3: icmp_seq=8 ttl=64 time=0.615 ms
64 bytes from 192.168.0.3: icmp_seq=9 ttl=64 time=0.640 ms
^C
--- 192.168.0.3 ping statistics ---
9 packets transmitted, 8 received, 11% packet loss, time 8004ms
rtt min/avg/max/mdev = 0.581/375.658/2003.682/696.527 ms, pipe 2

So, the question becomes....
What's the best way to troubleshoot this?

Thanks in advance.

CrunchBang Linux

SEARCH

#1 Re: Help & Support (Stable) » CPU Permanently Underclocked » 2010-01-07 17:10:38

#2 Re: Help & Support (Stable) » network degradation » 2010-01-07 01:11:46

#3 Re: Help & Support (Stable) » network degradation » 2010-01-06 21:01:02

#4 Help & Support (Stable) » network degradation » 2010-01-04 19:06:31

Board footer