another package, this certainly in the public interest, of which lacks the ppc (pegasos) binary is 'Adobe Flash Player plugin and standalone'

the sources are in 'openSUSE-11.1-Update': <flash-player-10.0.15.3-1.1.noarch>

do you agree?

Obviously, I agree, just I don't have the flash-player sources to recompile :-(

Banshee: reproduced the bug...

Just a simple question which may bore you:

To recompile ( and slightly modify) the kernel, I do:

make mrproper
make cloneconfig
make all
make modules_install
.. and than I make the zImage ready for boot.

Is this correct ?
( I ask this question, because I ran into trouble with ATA-drives ... )

BTW: Is there a way to disable udev ? It's very annoying that my eth1 is now named "eth1_rename...."

That would work, yes.

There is a clever way of generating a zImage with the right kernel version appended (so that you may keep them around) using the /sbin/get_kernel_version script;



You should modify some of the paths to the correct ones for your system (you did not install the kernel with make install, so no system.map etc. will be in your /boot - you may not NEED to do this though).



The correct, correct way would be to install the kernel-source RPM, and use the rpm "build" script - in /usr/src/RPM/ you will find the scripts to achieve this, and in /usr/src/linux-version-obj there are some directories with the default configuration which is built using the RPM scripts.

That way you get a nice, fancy kernel RPM and all the special toys SuSE wants to build for you.

One day I think we're going to have to write this up, since I have to produce a custom kernel at some point to support 8610/8641D from kernel-source, I will probably do it while I am going through the process myself to make sure I pick up all the mistakes and breakages as I hit them.



There are two scripts in /etc/udev/rules.d/ or some subdirectory called 70-persistent-net.rules and a companion script to generate THIS script.

If you wish to disable it completely, delete the "generate" script and the rules for persistent naming. What might be better is to simply modify the persistent-net.rules script and delete all the lines you don't like, and make sure it only refers to the devices you want - eth0 and eth1 (or you can change them to, I like to use the FreeBSD device names because it's more descriptive, like rl0 for old Realtek cards or vr0 for the Via port on your Pegasos)

Thanks for the udev-hints.

My major problem I decovered recently is the broken marvell-gigabitdriver on 11.1.
Using this LAN-interface, I get responsetimes up to 1000ms with lots of losses. ( The via responds within 5ms.)

From 10.1 to 10.2, the driver was broken, too. But it worked well in 10.3.
(As I'm doing raw-image harddisk-backup by gigabit to one of my pegs, I might be some of the stress-testers.)
Unfortunately, I'll revert my backup-peg back to 10.3. (.. but still 2 Peg2 left to mess with 11.1 ;-)

Okay. There was some work on this driver but I don't know exactly what went into 2.6.27 - there were definitely changes to 2.6.28 but they should never have made it back into the SuSE kernel.

My Pegasos is still running 11.0 and probably will until next week sometime, as I'm waiting on some stuff on order so that I can do some backups first. Then I'll look into it and also give the Marvell code a bit of a review in the meantime, just to see what actually changed.

I am sure Peter Czanik uses the Marvell port more regularly than I do (I only have a 100Mbit switch so I don't bother, also a firmware quirk sometimes nukes the MAC address which causes some freakish interaction with my ADSL router.. so it's not really a priority in the lab to keep it working). I am curious though, is it gigabit with jumbo packets you're using? Does a standard, forced 100Mbit or forced half-duplex link work any better?

Did not yet test for 11.1, as I also lack a gigabit switch. When I tested it with 11.0 using a cross link cable to another gigabit port, it worked without any troubles.

I never ran into this problem...

It happens with the 1.2 (20040811) firmware, which is as high as you can go on the 2B3 motherboard I have here..

Sometimes on a reboot the MAC address is set to something like 00:02:bf:00:de:ad - my router only allows one IP address per MAC (in which case it will basically flip-flop IP addresses when it gets it's preassigned address via DHCP) so this is really rather annoying. Coupled with the fact that the Marvell Gigabit has always been pretty poorly supported (10.x SUSE and lots of problems in Debian up to 2006 - plus it never worked properly in Ubuntu) I never thought about using it except when I was considering doing a performance test of the MPC8641D.

Since I've not managed to find time to boot anything more than test kernels and U-Boot builds on the MPC8641D, and have been spending time on the Efika support more and more recently, along with the lab work at Trinity, Marvell drivers are the last thing on my mind.

Marvell DiscoveryII ethernet 10/100/1000 [mv643xx_eth] support in kernel 2.6.27.x is broken.

There is a rewritten driver in 2.6.28:
http://lists.openwall.net/netdev/2008/09/14/37



greetz,
Acrux

You're good at patching things, does that patch cleanly apply to 2.6.27 or did the network subsystem change more?

We really need someone to watch these changes and actively do testing on them.. it's complicated by requirements to keep SuSE/Fedora etc. kernels happy though :(

after some quick tests the new driver mv643xx_eth (in kernel linux-2.6.28) compiles fine and loads without error too but is broken again or maybe it doesn't work the only sram one (from PegasosII).

Did you compile a complete 2.6.28 kernel or did you just replace the mv643xx_eth within the 2.6.27-tree ?
( I was about to testcompile the 28', but if you allready got the results, I'll try something different.)

Okay what I found basically was this, from some testing today;

You need to be wary of /etc/udev/rules.d/70-persistent-net.rules - you should change the items in here to match your ethernet names you want. I changed mine to vr0 and mv0.

Then go to /etc/sysconfig/network and make sure there is an ifcfg-ethN script for each one you had, and rename them appropriately. My Via port had the name "ifcfg" which is kind of weird, but anyway I changed it to ifcfg-vr0 filename and edited the name to say "Via Rhine II" just so it pops up in NetworkManager properly.

You can't just restart udev for some reason, or restart the network scripts (/etc/rc.d/network restart) to get it to pick things up.. or at least I did not find the correct way to do it, but a reboot really worked here.

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. 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).

*

It is uploaded now. Please let me know, if you run into any trouble, I did not test it yet...

A few more packages upgraded last week and today. Finally Packman for 11.1 seems to stabilize as a lot more people use it after release :-)