All times are UTC-06:00




Post new topic  Reply to topic  [ 21 posts ] 
Author Message
PostPosted: Sun Jan 04, 2009 9:42 am 
Offline

Joined: Thu Oct 19, 2006 7:19 am
Posts: 271
Location: Italy/Greece
i've opened a new topic here...
Quote:
It looks like Lennert's patch really broke the Marvell driver, it is basically probably wasn't some problem with the Pegasos SRAM here - my kernel actually reports that it did not see a PHY* - and it did not get "fixed" (only new features added on top) in 2.6.28 - I will coordinate on how this should be fixed.
that's right, there is no PHY* for this nic.
A new Pegasos Device Tree Supplement could not resolve this issue.
Quote:
In the ideal world a device tree entry should be set up or the firmware should be patched with a Forth script to enable this in the device tree but in the real world, nobody in distros cares anymore, so it looks like I may hack a fix for the driver if I can manage to work out EXACTLY why it is failing so badly (it does not get DHCP here, I noticed this during SuSE 11.1 installation testing on an early beta, but I had the same problem with my Via EPIA, and solved that with a router configuration change. Marvell sort of worked for a while but then I simply stopped using it.. I did not think it was a real driver issue).

*
Code:
via-rhine.c:v1.10-LK1.4.3 2007-03-06 Written by Donald Becker
via-rhine 0000:00:0d.0: enabling device (0000 -> 0003)
eth0: VIA Rhine II at 0xff7f1300, 00:0b:2f:41:53:4f, IRQ 9.
eth0: MII PHY found at address 16, status 0x786d advertising 01e1 Link 45e1.
MV-643xx 10/100/1000 ethernet driver version 1.3
: no PHY detected at addr 0
net eth1: port 1 with MAC address 00:2b:2f:de:ad:01
net eth1: scatter/gather enabled
net eth1: tx checksum offload
net eth1: napi enabled
net eth1: configured with sram
eth0 renamed to vr0 by udevd [808]
udev: renamed network interface eth0 to vr0
eth1 renamed to mv0 by udevd [823]
udev: renamed network interface eth1 to mv0
that's from my box with 2.6.28 vanilla:
Code:
MV-643xx 10/100/1000 ethernet driver version 1.4
mv643xx_eth smi: probed
...
via-rhine 0000:00:0d.0: enabling device (0000 -> 0003)
eth0: VIA Rhine II at 0x80000800, 00:0b:2f:4f:65:7b, IRQ 9.
eth0: MII PHY found at address 16, status 0x786d advertising 01e1 Link 45e1.
...
net eth1: port 0 with MAC address 00:00:00:00:00:00
net eth1: configured with sram
eth%d: 0:07 already attached
net eth2: port 1 with MAC address 00:2b:2f:de:ad:01
net eth2: configured with sram
...
eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
...
eth0: no IPv6 routers present

_________________
acrux _at_ linuxmail _dot_ org


Top
   
PostPosted: Mon Jan 05, 2009 9:18 am 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
i've opened a new topic here...
Quote:
It looks like Lennert's patch really broke the Marvell driver, it is basically probably wasn't some problem with the Pegasos SRAM here - my kernel actually reports that it did not see a PHY* - and it did not get "fixed" (only new features added on top) in 2.6.28 - I will coordinate on how this should be fixed.
that's right, there is no PHY* for this nic.
Right but I just realised, there are two ports, and it's weirdly connected port 0 to the gigabit riser and port 1 to the back of the system. So port 0 will always fail.

It looks like the driver initializes fine, but then just doesn't work.

How on earth did you get it to work on yours then? Or did you not?
Quote:
A new Pegasos Device Tree Supplement could not resolve this issue.
Well, there are two ways to look at it

1) this specific problem could not be fixed with a device tree fix
2) the general problem - that the PHY is "not detected" and it does not know what type it is and the SRAM address is hardcoded in the driver - should be stuff in the device tree (check out what Linux or efika.forth does to add one to the Efika).

Basically there should be an ethernet node in /built-in which properly describes the Marvell ethernet, and only one port, the reason it tries both right now is because.. well.. the ethernet node is really terrible and I don't think it formats it the way a driver would want to see it, plus there is no special information about it.

An ethernet node that is disabled could be engineered too so it doesn't even check.

But anyway, eth1 should work for you? Or it doesn't? What is the exact behaviour? I need to tell Lennert something about what is wrong, not just "it doesn't work" or he will not know what to look for..

_________________
Matt Sealey


Top
   
 Post subject:
PostPosted: Wed Jan 07, 2009 12:17 pm 
Offline

Joined: Wed Jan 07, 2009 11:56 am
Posts: 3
Location: Granada, Spain
I've been bisecting the problem today and the regression is indeed with one of Lennert's changes, but I would certainly not have bet on the innocent looking "mv643xx_eth: use longer DMA bursts" patch (git commit identifier cd4ccf76bfd2c36d351e68be7e6a597268f98a1a).

With this commit reverted, Gb ethernet is working again with kernel 2.6.27 on Pegasos.


Top
   
 Post subject:
PostPosted: Fri Jan 09, 2009 8:58 am 
Offline

Joined: Tue Dec 26, 2006 5:13 pm
Posts: 37
Could you post the "reverse patched" mv643xx_eth source here ?

BTW: There's a known problem with gigabit on Peg2:
If you boot into linux after a powercut, gigabit shows up with a strange MAC, which confuses udev. Rebooting the system will bring back a stable MAC again..


Top
   
 Post subject:
PostPosted: Fri Jan 09, 2009 10:01 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
Could you post the "reverse patched" mv643xx_eth source here ?
It's not quite ready. There are a couple of other bugs that turned up. It will be posted when it is ready, and no doubt sent to the linux networking list and linuxppc-dev at the same time or before.
Quote:
BTW: There's a known problem with gigabit on Peg2:
If you boot into linux after a powercut, gigabit shows up with a strange MAC, which confuses udev. Rebooting the system will bring back a stable MAC again..
Something like 00:2b:2f:de:ad:01? :)

It's a known bug in the firmware and the fix is to force the MAC address - on SuSE and Fedora, edit /etc/sysconfig/network/ifcfg-ethX (where ethX is whatever your interface is named. I called my mv0) and add a line

LLADDR='00:0b:2f:aa:bb:cc'

Where the last 3 tuples are anything you like really (the above is also valid :) depending on what other bplan hardware you have around or if you know what the MAC address SHOULD be (00:0b:2f is bplan's OUID)

Since this is done after udev you will have to fiddle around with /etc/udev.d/70-persistent-net.rules somehow too.

_________________
Matt Sealey


Top
   
 Post subject:
PostPosted: Sat Jan 10, 2009 10:00 am 
Offline

Joined: Tue Dec 26, 2006 5:13 pm
Posts: 37
Sounds like you've seen the same effect:
On coldboot, gigabit has this MAC:

00:0b:2f:79:ce:11

( I made some stupid script with rmmod and insmod and ifconfig .. which manages to get the network up without reboot.)

All the next reboots gibt me this MAC, which then remains stable..

00:2B:2F:DE:AD:01


Top
   
 Post subject:
PostPosted: Sat Jan 10, 2009 2:40 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
Sounds like you've seen the same effect:
On coldboot, gigabit has this MAC:

00:0b:2f:79:ce:11

( I made some stupid script with rmmod and insmod and ifconfig .. which manages to get the network up without reboot.)

All the next reboots gibt me this MAC, which then remains stable..

00:2B:2F:DE:AD:01
Try this on SUSE or Fedora. I am not sure about what happens on Debian.. what are you running?

Edit /etc/udev/rules.d/70-persistent-net.rules

Add the lines:
Code:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="via-rhine*", ATTR{type}=="1", KERNEL=="eth*", NAME="vr0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="mv643xx_eth*", ATTR{type}=="1", KERNEL=="eth*", NAME="mv0"
Add /etc/sysconfig/network/ifcfg-mv0 and /etc/sysconfig/network/ifcfg-vr0:
Code:
BOOTPROTO='dhcp4'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NAME='MV64360/64361/64362 System Controller'
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='off'
USERCONTROL='no'
LLADDR='00:0b:2f:79:ce:11'
Code:
BOOTPROTO='dhcp4'
STARTMODE='auto'
NAME='Via Rhine-II'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR=''
MTU=''
NETMASK=''
NETWORK=''
REMOTE_IPADDR=''
USERCONTROL='no'
Get rid of any ifcfg-eth* scripts or back them up.

That seems to work for me.. I didn't test it much though as I don't use Marvell ethernet.

_________________
Matt Sealey


Top
   
 Post subject:
PostPosted: Fri Jan 16, 2009 8:00 pm 
Offline

Joined: Mon Jan 30, 2006 7:24 am
Posts: 43
Location: Budapest, Hungary
Quote:
If you boot into linux after a powercut, gigabit shows up with a strange MAC, which confuses udev. Rebooting the system will bring back a stable MAC again..
Latest, never officially released bPlan firmware update (dated 20061215 or so, IIRC) fixes this problem, among others. I think this firmware was only released as "internal beta" for testers, and for some users, who have explicitly asked for it. Since i have it in my board, GBit eth runs just fine, w/o any MAC quirks on reboots. Note the same board had the problem before i installed this firmware.

Of course, one could still use one of the workarounds, like the one Matt recommended.


Top
   
 Post subject:
PostPosted: Fri Jan 16, 2009 8:54 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
I think this firmware was only released as "internal beta" for testers, and for some users, who have explicitly asked for it. Since i have it in my board, GBit eth runs just fine, w/o any MAC quirks on reboots. Note the same board had the problem before i installed this firmware.
Where did you get that from?
Quote:
Of course, one could still use one of the workarounds, like the one Matt recommended.
Not could, SHOULD. I'd recommend you downgrade..

_________________
Matt Sealey


Top
   
 Post subject:
PostPosted: Sat Jan 17, 2009 3:56 pm 
Offline

Joined: Mon Jan 30, 2006 7:24 am
Posts: 43
Location: Budapest, Hungary
Quote:
Where did you get that from?
I hacked bPlan site, and stole it. (Stupid question, stupid answer.)
Quote:
Not could, SHOULD. I'd recommend you downgrade..
Indeed, how smart idea is to play with the firmware of a machine which works 24/7, without a single problem for 1,5 years... Right.

Any *real* reasons, apart from the fact that in your opinion i shouldn't have this specific version?


Top
   
 Post subject:
PostPosted: Sun Jan 18, 2009 9:08 am 
Offline

Joined: Thu Jul 28, 2005 12:41 am
Posts: 1066
Quote:
Indeed, how smart idea is to play with the firmware of a machine which works 24/7, without a single problem for 1,5 years... Right.
You should not, but I did. Different usage scenario. See below.
Quote:
Any *real* reasons, apart from the fact that in your opinion i shouldn't have this specific version?
I do a lot of software testing and user support, where relying on the improved features of the beta firmware (and different selection of bugs) is a huge disadvantage. You also do some user support, but from the 27/4 I guess, this machine runs as a server, where the fixes are more important than having the same firmware as the rest of the world.

_________________
CzP
http://czanik.blogs.balabit.com/


Top
   
 Post subject:
PostPosted: Sun Jan 18, 2009 11:09 am 
Offline

Joined: Tue Dec 26, 2006 5:13 pm
Posts: 37
What a strange argumentation !

I bought 3 PEG2 and dedicated one to a backup&network server. Unfortunately the OF behaviour (HD and NIC related) was so annoying, that I contacted bplan, which promised a fix with a future firmware.

Not finding any fixed firmware for years, I now started thinking to replace the backup-server with an intel machine to get a relyable solution.

Reading about the existence of a fixed firmware, which is somewhat kept secret, really makes me angry.
This is a information and support policy I cannot stand.

When will be the official release of the fixed OF ?
In 5 years ?


Top
   
 Post subject:
PostPosted: Sun Jan 18, 2009 3:58 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
What a strange argumentation!

This is a information and support policy I cannot stand.
Unfortunately for you it is based on quality assurance and available time.

Each, even minor, change to the firmware needs to be validated and put through a long-winded test suite on EVERY hardware revision to make sure it did not introduce any serious regressions.

Even something very minor like changing the font could cause probems on different framebuffers, different graphics cards (even within the same chipset), different PCI buses.

The simple fact is that given the number of revisions of Pegasos II (4 public) and Efika (1 public) plus all other support contracts, the number of boards which need to be tested is too large to simply offer someone a simple fix for this.

We don't give out the "fixed" firmware because it NEVER got run through those tests. At bplan for 6 months (Sven coming once a month) and a group of us played with the firmware code and made many, many changes. Only the official fixes ever went through testing but this firmware never leaves the office.. it's not ready.

The experimental firmware which seems to have been released was just to see if we COULD do things. As a mere side effect it rolled in the official firmware fixes. There can and will be several, possibly several hundred, weird effects which it may evoke on any hardware revision. I can think of a bunch;

* ISO filesystems may not work under certain circumstanes (also outputs a huge amount of debug code)
* FAT filesystems may not work under certain circumstances
* ATA disks may not detect properly as the timeouts were fudged (by me)
* weird USB problems
* FFS/SFS support may be broken

The idea was to flash that firmware to the Pegasos, see if anyone had problems or if it fixed or broke a specific feature (for instance change to the filesystem code) and then flash it BACK to the original version which was always supplied at exactly the same time.

If you're running it, you forfeited all support for your board, so you can't complain about not liking it.

You may never see an official firmware fix, although the plan is to at least publish the Aura firmware at least for the Efika, PERHAPS for Pegasos, but given the Pegasos is end-of-life and not produced or sold for some 3 years.. I think you would understand why we might not.

In the end this is just a simple MAC address problem which can be easily fixed. It may even POSSIBLY be able to do it with a small script in nvramrc;
Code:
0x0000fe01 0xf1002814 l!
0x000b2f7c 0xf1002818 l!
NOTE: THIS CODE COMES WITHOUT WARRANTY EXPRESS OR IMPLIED AND NO SUPPORT IS OFFERED OTHER THAN ITS PROVISION ON THIS WEBSITE. GENESI DISCLAIMS RESPONSIBILITY FOR RENDERING HARDWARE INOPERABLE AS A RESULT OF THIS CODE.

You've been warned. I'm not really going to work on this further. I have some other ideas for removing the arch/powerpc/platforms/chrp/pegasos_eth.c file and making it generic against device trees but this requires some significant thought (and a generic SRAM driver and some extra magic) which I don't have time to go into right now..

(Edit: note I removed the long code fix as it was broken. I have a better way. Will publish later).

_________________
Matt Sealey


Top
   
 Post subject:
PostPosted: Mon Jan 19, 2009 7:45 pm 
Offline
Site Admin

Joined: Fri Sep 24, 2004 1:39 am
Posts: 1589
Location: Austin, TX
Quote:
In the end this is just a simple MAC address problem which can be easily fixed. It may even POSSIBLY be able to do it with a small script in nvramrc;
Code:
0x0000fe01 0xf1002814 l!
0x000b2f7c 0xf1002818 l!
I just tested this and it works. Who needs a firmware update? Just add these two lines into nvramrc (nvedit, ctrl+c to finish, nvstore) and replace the first value on each line with your MAC when the Pegasos boots the first time. For instance mine says 00:0b:2f:60:bb:35 so the code to fix my Pegasos is;
Code:
0x0000bb35 0xf1002814 l!
0x000b2f60 0xf1002818 l!
In other news 3 patches were just posted to the Linux netdev mailing list which fix all the problems with Pegasos ethernet. Until a patch hits LinuxPPC-dev which fixes the port0/port1 problem (Gabriel already wrote it, it just doesn't enable port0 in the platform code) it might act weird but you can use udev tricks to work around it until then.

I had a thought about a bit of a device-tree hack to fix some extra entries in the device-tree, and add a generic SRAM driver which will allow automatically allocating RX/TX buffers in the Marvell driver itself based on an OF platform device. I might publish it later this month, or February.

_________________
Matt Sealey


Top
   
 Post subject:
PostPosted: Tue Jan 20, 2009 1:31 pm 
Offline

Joined: Tue Dec 26, 2006 5:13 pm
Posts: 37
Hi,

I just tried your nv-script but the result was different to my expectations(Firmware 1.2):

The MAC-part of "0x000b2f60 0xf1002818 l!" showed up in the MAC-address in endianes-changed-order. The other line's data was zero-filled.

So I got a MAC like 60:2f:0b:00:00:00 ..reported by kernel and ifconfig.


BTW: There's nothing wrong about your argumentation about regression tests to prove a level of quality. Nevertheless, the PEGs & Efikas were not designed to serve in airborne or life support applications. The real customers are computer geeks, willing to take part in some development process. Most of the routers, gfxcards, computers I flashed, survived at the end. So if I'd kill my system because of using beta firmware, I'd never come up with the idea to ask for free support.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 21 posts ] 

All times are UTC-06:00


Who is online

Users browsing this forum: No registered users and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
PowerDeveloper.org: Copyright © 2004-2012, Genesi USA, Inc. The Power Architecture and Power.org wordmarks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.
All other names and trademarks used are property of their respective owners. Privacy Policy
Powered by phpBB® Forum Software © phpBB Group