RE: Preliminary observations 2.6.1 kernels both 32 and 64 bit on Cobalt Mips Qube: update
Hi all,
I took the time to remove and reinstall the 2.6.1 DMA (Aurelien J.) kernel
and ran the following tests:
1)Booted system with on-board nic (tulip) and VIA-Rhine PCI card connected
To the network.
Results: System seemed to boot successfully, tulip nic acquired DHCP address
But was using FF:FF:FF:FF:FF:FF as Mac address. 100Mb card also acquired a
DHCP address. I can ping both cards but can't ssh into it, or
Access the apache web server or samba server.
2)Booted system with only on board nic connected to network.
Results: Same as in case one for the 10Mb card.
3)Booted system with only 100Mb nic connected to network.
Results: Successfully booted, acquired address and could access the server
using all network resources.
4) Attempted to reset the 10Mb interface using ifconfig.
Results: used "ifconfig down" successfully. However moments after issuing
an "ifconfig up" command to eth0, the server froze (crashed??): no net i/o,
not LCD response or updates and no perceivable disk i/o.
5) Attempted to boot with 100Mb card removed.
Results: Same as in case 2
Observations:
I have yet to try the 2.6.1 unstable again, but I think the behavior is the
same. I checked the dmesg and messages logs for any clues and from what I
can tell, the tulip chip seems to initialize in an unexpected state. It
also seems the Galileo chip is a bit iffy: Here's snippets of the dmesg log:
---
#OK we know the kernel we're running
Linux version 2.6.16-1-r5k-cobalt (Debian 2.6.16-9+aurel32)
(aurel32@debian.org)
(gcc version 4.0.3 (Debian 4.0.3-1)) #2 Mon Apr 24 23:13:47 CEST 2006
----
# the 2700 cobalt model has known issues with DMA handling, is this a clue?
Galileo: revision 1
Galileo: PCI retry count exceeded (06.0)
---
Activating ISA DMA hang workarounds.
----
# This is where the weirdness starts
de2104x PCI Ethernet driver v0.7 (Mar 17, 2004)
PCI: Enabling device 0000:00:07.0 (0045 -> 0047)
de0: SROM leaf offset 255, default media 10baseT auto
de0: media block #0: 10baseT-HD
de0: media block #1: BNC
eth0: 21041 at 0xb2040100, ff:ff:ff:ff:ff:ff, IRQ 20
----
# So maybe this states the 2700 can't do DMA either
VP_IDE: IDE controller at PCI slot 0000:00:09.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c586a (rev 27) IDE UDMA33 controller on pci0000:00:09.1
ide0: BM-DMA at 0x14a0-0x14a7, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x14a8-0x14af, BIOS settings: hdc:pio, hdd:pio
---
# yay!! The rhine nic initializes, but whats with the PCI retries
via-rhine.c:v1.10-LK1.2.0-2.6 June-10-2004 Written by Donald Becker
PCI: Enabling device 0000:00:0a.0 (0080 -> 0083)
PCI: Setting latency timer of device 0000:00:0a.0 to 64
# this is logged 50 times!!
Galileo: PCI retry count exceeded (0a.0)
eth1: VIA Rhine III at 0xb0001000, 00:40:f4:b1:97:51, IRQ 9.
eth1: MII PHY found at address 1, status 0x7869 advertising 05e1 Link 45e1.
---
# not the same luck on the tulip. this is repeated 20 times
eth0: enabling interface
eth0: set link 10baseT auto
eth0: mode 0x7ffc0040, sia 0x10c4,0xffffef01,0xffffffff,0xffff0008
eth0: set mode 0x7ffc0040, set sia 0xef01,0xffff,0x8
I'll try to duplicate the tests on 2.6.1 unstable tonight. I was wondering
if somebody could offer me a clue on which log file to check into after a
crash. I ask, because I seem to be able to crash the qube at will by
ifconfig-ing the eth0 interface. Perhaps its another clue.
Thanks again,
M.F.
Reply to: