| View previous topic :: View next topic |
| Author |
Message |
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
 Posted: Mon Nov 06, 2006 11:18 am Post subject: |
 |
|
| TheJackal wrote: |
Just as a side note, have you got one of the original NSLU2 (clocked at 133MHz) or the newer models which are already factory de-underclocked (@ 266MHz) ? |
I have a brand new one with 266MHz factory settings. It has a sticker "Manufactured 07/2007". |
|
| Back to top |
|
 |
TheJackal
n00b
Joined: 29 Jul 2003
Posts: 73
Location: In front of the keyboard :)
|
| Posted: Mon Nov 06, 2006 11:58 am Post subject: |
|
|
| wazow wrote: | | I have a brand new one with 266MHz factory settings. It has a sticker "Manufactured 07/2007". |
I've also got one of the newer ones (I'll check the manufacturing date when I get home) and I floated this idea when I spoke to jake1981 but I wonder if something has changed between the pre-266MHz versions and the newer ones?
Although this still doesn't explain how OpenSLUG gets around this problem...
I thought of adding some debug parameters to the module loading but our problem seems to be even before the module gets loaded.
| Code: | root@slug:/dev/.udev/failed# modinfo ixp400
filename: /lib/modules/2.6.16/kernel/drivers/ixp400/ixp400.ko
depends:
vermagic: 2.6.16 preempt ARMv5 gcc-3.4
parm: livelock_dispatcher:If non-zero, use the livelock prevention qmgr dispatcher (i)
root@slug:/dev/.udev/failed# modinfo ixp400_eth
filename: /lib/modules/2.6.16/kernel/drivers/net/ixp400_eth.ko
author: Intel Corporation
license: GPL
description: IXP400 NPE Ethernet driver
depends: ixp400
vermagic: 2.6.16 preempt ARMv5 gcc-3.4
parm: ixp400_netdev_max_backlog:Should be set to the value of /proc/sys/net/core/netdev_max_backlog (perf affecting) (i)
parm: datapath_poll:If non-zero, use polling method for datapath instead of interrupts (i)
parm: npe_learning:If non-zero, NPE MAC Address Learning & Filtering feature will be enabled (i)
parm: log_level:Set log level: 0 - None, 1 - Verbose, 2 - Debug (i)
parm: no_ixp400_sw_init:If non-zero, do not initialise Intel IXP400 Software Release core components (i)
parm: no_phy_scan:If non-zero, use hard-coded phy addresses (i)
parm: phy_reset:If non-zero, reset the phys (i)
parm: dev_max_count:Number of devices to initialize (i) |
_________________
"Expect nothing. That way you will be ready for anything - Virginia Viadura"
Black Mesa Research Facility |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Mon Nov 06, 2006 1:25 pm Post subject: |
|
|
| TheJackal wrote: | I thought of adding some debug parameters to the module loading but our problem seems to be even before the module gets loaded.
|
Why do you think so? nslu2init loads the ixp400 module first, then it tries to do the firmware stuff (AFAIR), and only after that it loads ixp400_eth module. None of the loads seems to produce traceable errors on my machine. In fact the module loading done later by /etc/init.d/modules should not matter with this nslu2init. |
|
| Back to top |
|
|
TheJackal
n00b
Joined: 29 Jul 2003
Posts: 73
Location: In front of the keyboard :)
|
| Posted: Mon Nov 06, 2006 2:15 pm Post subject: |
|
|
Success! Well, as far as success will get without a proper explanation for this bug.
| Code: | Nov 6 14:40:13 localhost ixp400: module license 'unspecified' taints kernel.
Nov 6 14:40:13 localhost ixp400: Module init.
Nov 6 14:40:13 localhost ixp400_eth: Initializing IXP400 NPE Ethernet driver software v. 1.5
Nov 6 14:40:13 localhost Warning : log_level == 2 and TRACE is disabled
Nov 6 14:40:13 localhost ixp400_eth: CPU clock speed (approx) = 266 MHz
Nov 6 14:40:13 localhost ixp400_eth: Initialising Queue Manager...
Nov 6 14:40:13 localhost [message] ixEthMiiPhyScan, Mii 1: Mii PHY ID 00008201
Nov 6 14:40:13 localhost ixp400_eth: Found PHY 0 at address 1
Nov 6 14:40:13 localhost ixp400_eth: Configuring PHY 0
Nov 6 14:40:13 localhost ixp400_eth: Speed 100 Duplex FULL Autonegotiation ON
Nov 6 14:40:13 localhost ixp400_eth: ethernet 0 using NPEB and the PHY at address 1
Nov 6 14:40:13 localhost ixp400_eth: Use default MAC address 00:02:b3:01:01:01 for port 0
Nov 6 14:40:13 localhost ixp400_eth: MAC address now set to 00:18:39:8a:6f:e0 for port 0
Nov 6 14:40:24 localhost rc-scripts: network interface eth0 does not exist
Nov 6 14:40:24 localhost rc-scripts: Please verify hardware or kernel module (driver)
Nov 6 14:40:25 localhost rc-scripts: network interface eth0 does not exist
Nov 6 14:40:25 localhost rc-scripts: Please verify hardware or kernel module (driver)
Nov 6 14:40:35 localhost ixp400_eth: port_enable()
Nov 6 14:40:35 localhost port_enable(eth2) |
Ok, so here's what I did:
* Booted into OpenSLUG-3.10-beta without my external HDD connected
* Connected my external HDD and mounted the necessary partitions (/dev proc) and chrooted into the Gentoo/SLUG environment
* Edited /etc/conf.d/net and replicated the config for eth0, but changed the device to eth2
* Symlinked /etc/init.d/net.eth2 to /etc/init.d/net.lo
* Added net.eth2 to the default runlevel
* Unmounted everything, rebooted and prayed (I'm working remotely from the NSLU2
To my amazement after a while the NSLU2 came up with an IP address via DHCP and I SSHed into the box....having added "log_level=2" to the ixp400_eth module seems to make no difference at all but for some reason it seems to create an eth2 device and not an eth0!
When I get home I'm going to tinker around with it a bit more....maybe try removing the "alias ath0" stuff and see if ixp400_eth defaults to eth0 and not eth2.
_________________
"Expect nothing. That way you will be ready for anything - Virginia Viadura"
Black Mesa Research Facility |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Mon Nov 06, 2006 3:21 pm Post subject: |
|
|
| TheJackal wrote: | Success! Well, as far as success will get without a proper explanation for this bug.
| Code: | Nov 6 14:40:13 localhost ixp400: module license 'unspecified' taints kernel.
Nov 6 14:40:13 localhost ixp400: Module init.
Nov 6 14:40:13 localhost ixp400_eth: Initializing IXP400 NPE Ethernet driver software v. 1.5
Nov 6 14:40:13 localhost Warning : log_level == 2 and TRACE is disabled
Nov 6 14:40:13 localhost ixp400_eth: CPU clock speed (approx) = 266 MHz
Nov 6 14:40:13 localhost ixp400_eth: Initialising Queue Manager...
Nov 6 14:40:13 localhost [message] ixEthMiiPhyScan, Mii 1: Mii PHY ID 00008201
Nov 6 14:40:13 localhost ixp400_eth: Found PHY 0 at address 1
Nov 6 14:40:13 localhost ixp400_eth: Configuring PHY 0
Nov 6 14:40:13 localhost ixp400_eth: Speed 100 Duplex FULL Autonegotiation ON
Nov 6 14:40:13 localhost ixp400_eth: ethernet 0 using NPEB and the PHY at address 1
Nov 6 14:40:13 localhost ixp400_eth: Use default MAC address 00:02:b3:01:01:01 for port 0
Nov 6 14:40:13 localhost ixp400_eth: MAC address now set to 00:18:39:8a:6f:e0 for port 0
Nov 6 14:40:24 localhost rc-scripts: network interface eth0 does not exist
Nov 6 14:40:24 localhost rc-scripts: Please verify hardware or kernel module (driver)
Nov 6 14:40:25 localhost rc-scripts: network interface eth0 does not exist
Nov 6 14:40:25 localhost rc-scripts: Please verify hardware or kernel module (driver)
Nov 6 14:40:35 localhost ixp400_eth: port_enable()
Nov 6 14:40:35 localhost port_enable(eth2) |
Ok, so here's what I did:
* Booted into OpenSLUG-3.10-beta without my external HDD connected
* Connected my external HDD and mounted the necessary partitions (/dev proc) and chrooted into the Gentoo/SLUG environment
* Edited /etc/conf.d/net and replicated the config for eth0, but changed the device to eth2
* Symlinked /etc/init.d/net.eth2 to /etc/init.d/net.lo
* Added net.eth2 to the default runlevel
* Unmounted everything, rebooted and prayed (I'm working remotely from the NSLU2
To my amazement after a while the NSLU2 came up with an IP address via DHCP and I SSHed into the box....having added "log_level=2" to the ixp400_eth module seems to make no difference at all but for some reason it seems to create an eth2 device and not an eth0!
|
This is roughly what I have done above, but in my case this was insufficient to get an shh service. I guess the debug flag has nothing to do this (I was not touching this yet). My slug also goes on the nete with a DHCP address. But still dropbear would not start, claiming that net.eth0 has failed (sure, I want it to use eth2). Could it be because eth2 is actually started with some delay?
At the moment something bad happened to my openslug. Even this guy is refusing to go on the net now... |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Mon Nov 06, 2006 7:55 pm Post subject: New interesting finding |
|
|
Things look a bit different than I expected. I am now sure that /etc/init.d/nslu2init was *not* loading the modules on my machine. At this point the modules are already loaded on my slug (I dumped the output of lsmod from within /etc/init.d/nslu2init, just before the first modprobe). It seems that the modules are loaded before this init is run (contrary to what I assumed). So the contents of my /etc/modules.autoload.d/kernel-2.6 takes precendence.
I believe this file was empty on the initial image, but I might have added the ixp modules to it following howto's on wikis. Normally adding modules twice does not hurt, so I though I can do it without testing (at least I guess I could have thought that). Obviously this is bad if we need to load firmware before the ixp400_eth modules is load (do we?).
I removed the two modules from autoload and I think this should solve the problem of error message in line 27. Jackal, can you check what is in your /etc/modules.autoload.d/kernel-2.6 file, remove ixp modules if found, and report whether the error in firmware uploading has disappeared (using your serial console)?
However this still does not help with getting eth0 to work on my slug. Still eth2 is the only interface that shows up in ifconfig. |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Mon Nov 06, 2006 8:30 pm Post subject: A digression |
|
|
Another anomaly, which is definitely less annoying than lack of the network connection, is that disk leds on my slug are interchanged. Turning on disk-1 actually turns on the led labeled "disk 2".
This happens obviously with OpenSlug, and to the extent I can guess also with gentoslug (after boot "disk 2" is on, while my rootfs is in disk1 slot). Is anybody else seeing this?
EDIT: This eth2 thing and swapped leds make me think more and more that newer slugs are differ from the normal ones slightly. |
|
| Back to top |
|
|
red-nammoc
n00b
Joined: 21 Oct 2006
Posts: 4
|
| Posted: Mon Nov 06, 2006 9:42 pm Post subject: Re: A digression |
|
|
Hi,
thanks for debugging so far. I tried the eth2 thing and it works!! Thanks!
| wazow wrote: | Another anomaly, which is definitely less annoying than lack of the network connection, is that disk leds on my slug are interchanged. Turning on disk-1 actually turns on the led labeled "disk 2".
This happens obviously with OpenSlug, and to the extent I can guess also with gentoslug (after boot "disk 2" is on, while my rootfs is in disk1 slot). Is anybody else seeing this?
EDIT: This eth2 thing and swapped leds make me think more and more that newer slugs are differ from the normal ones slightly. |
I have the same "problem" with the leds. I had to deunderclock my slug (Manufactured 10/2005), so it should be an old one.
red-nammoc |
|
| Back to top |
|
|
jake1981
n00b
Joined: 02 Feb 2006
Posts: 61
Location: Finland
|
| Posted: Mon Nov 06, 2006 9:52 pm Post subject: |
|
|
| TheJackal wrote: | Hi,
I'm having the same problem as above....seems eth0 isn't brought up as it should be because the ixp400 device (in /dev) can't be found after its been created. This is a shame because I've just bought an NSLU2 with Gentoo/SLUG in mind...
Also, where is the "openslug-3.1-beta.bin" on jake1981's website that he mentions? |
It's the same binary which is on nslu2-linux's download site. I had to remove it due to licensing issues, or put a same license which is for gentooslug image for there. Thought that I'd rather remove it, as that file also can be download from slug-firmwares.. |
|
| Back to top |
|
|
jake1981
n00b
Joined: 02 Feb 2006
Posts: 61
Location: Finland
|
| Posted: Mon Nov 06, 2006 9:57 pm Post subject: Re: A digression |
|
|
| red-nammoc wrote: | Hi,
thanks for debugging so far. I tried the eth2 thing and it works!! Thanks!
| wazow wrote: | Another anomaly, which is definitely less annoying than lack of the network connection, is that disk leds on my slug are interchanged. Turning on disk-1 actually turns on the led labeled "disk 2".
This happens obviously with OpenSlug, and to the extent I can guess also with gentoslug (after boot "disk 2" is on, while my rootfs is in disk1 slot). Is anybody else seeing this?
EDIT: This eth2 thing and swapped leds make me think more and more that newer slugs are differ from the normal ones slightly. |
I have the same "problem" with the leds. I had to deunderclock my slug (Manufactured 10/2005), so it should be an old one.
red-nammoc |
Hmm.. You could check if this is the issue for you, switch your harddisk to another usb slot on behind. I noticed this behaviour when I made my nslu2events ebuild, when I want it to turn on led for disk-1, it turns on led for disk-2. Order of leds has changed for newer full speed versions of slug (I'm running original one, expect that I turbo slugged it)..
But to change this behaviour, there's a file for configuring nslu2events in config folder in etc.. And to lid light for disk-1 is in local.start or something like that in init.d.. Can't check right now since I'm @ my gf's apartment and she's not gonna be happy if I turn her laptop into a board of development  |
|
| Back to top |
|
|
jake1981
n00b
Joined: 02 Feb 2006
Posts: 61
Location: Finland
|
| Posted: Mon Nov 06, 2006 10:10 pm Post subject: Re: New interesting finding |
|
|
| wazow wrote: | Things look a bit different than I expected. I am now sure that /etc/init.d/nslu2init was *not* loading the modules on my machine. At this point the modules are already loaded on my slug (I dumped the output of lsmod from within /etc/init.d/nslu2init, just before the first modprobe). It seems that the modules are loaded before this init is run (contrary to what I assumed). So the contents of my /etc/modules.autoload.d/kernel-2.6 takes precendence.
I believe this file was empty on the initial image, but I might have added the ixp modules to it following howto's on wikis. Normally adding modules twice does not hurt, so I though I can do it without testing (at least I guess I could have thought that). Obviously this is bad if we need to load firmware before the ixp400_eth modules is load (do we?).
I removed the two modules from autoload and I think this should solve the problem of error message in line 27. Jackal, can you check what is in your /etc/modules.autoload.d/kernel-2.6 file, remove ixp modules if found, and report whether the error in firmware uploading has disappeared (using your serial console)?
However this still does not help with getting eth0 to work on my slug. Still eth2 is the only interface that shows up in ifconfig. |
How about you try to remove references to eth0 completely and swap it to eth2?
You know it ain't requirement to call it eth0, on my slug, it originally is called ixp4xx_eth0, so that's why I aliased it as eth0, I could had aliased it eth2 or eth99 But for clarity I named it eth0.. But as you know, name doesn't blame man..
But dropbear, and other servers might be failing as there are references to eth0 and it has failed to start. I am pretty sure, that if you check dropbear file under /etc/init.d, you WILL notice that it says that it's dependant of /etc/init.d/net.eth0, change that in there to eth2 too... Actually, don't change first anything else expect requirement for dropbear. Keep your SYSTEM files as they are if they load up eth2 and it gets ip from dhcp..
Then if this lets you get in with ssh, check your other files under /etc/init.d and check if these files REQUIRE net.eth0 and change this.. once again to net.eth2, do NOT change everything too fast, I know it's pain in the ass to boot it again and again, but to take gentooslug working on these older slugs.. It took almost year for me to success this far and it's been a huge project.. But speeding up things in this phase isn't a good thing as human mind propably won't remember all changes it wanted to made.. Baby steps.. One step takes you closer to success on every boot. Good luck.. |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Mon Nov 06, 2006 10:19 pm Post subject: Re: New interesting finding |
|
|
| jake1981 wrote: |
How about you try to remove references to eth0 completely and swap it to eth2?
You know it ain't requirement to call it eth0, on my slug, it originally is called ixp4xx_eth0, so that's why I aliased it as eth0, I could had aliased it eth2 or eth99 But for clarity I named it eth0.. But as you know, name doesn't blame man.. |
I kind of know that and exactly this makes me worried about this eth2 business. Aliases and all references are to eth0 as in your image (this is your image!). No single mention of eth2 anywhere and still it shows up, while eth0 does not. I can't sleep if I see things like that 
Where is it that this naming is done. Is it in /etc/modules.d/eth0? |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Mon Nov 06, 2006 10:46 pm Post subject: Re: New interesting finding |
|
|
| jake1981 wrote: |
But dropbear, and other servers might be failing as there are references to eth0 and it has failed to start. I am pretty sure, that if you check dropbear file under /etc/init.d, you WILL notice that it says that it's dependant of /etc/init.d/net.eth0, change that in there to eth2 too... Actually, don't change first anything else expect requirement for dropbear. Keep your SYSTEM files as they are if they load up eth2 and it gets ip from dhcp..
|
Actually dropbear has no references to net.eth0. It has "need net" instead... |
|
| Back to top |
|
|
int2str
Guru
Joined: 29 Sep 2003
Posts: 362
|
| Posted: Mon Nov 06, 2006 10:56 pm Post subject: |
|
|
FWIW, the network interface on my NSLU2 is called "ixp0". Not sure if that makes any difference for you guys.
| Code: | atlantis ~ # lsmod
Module Size Used by
iptable_filter 2304 0
ip_tables 20960 1 iptable_filter
ixp400_eth 28092 0
ixp400 1028580 1 ixp400_eth
atlantis ~ # ifconfig
ixp0 Link encap:Ethernet HWaddr 00:02:B3:01:01:01
inet addr:192.168.0.250 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:30589100 errors:41 dropped:0 overruns:0 frame:41
TX packets:10878792 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:256
RX bytes:1180851479 (1126.1 Mb) TX bytes:1159449624 (1105.7 Mb) |
_________________
Adpot an unanswered post today! |
|
| Back to top |
|
|
TheJackal
n00b
Joined: 29 Jul 2003
Posts: 73
Location: In front of the keyboard :)
|
| Posted: Tue Nov 07, 2006 1:57 pm Post subject: Re: New interesting finding |
|
|
| wazow wrote: | | Jackal, can you check what is in your /etc/modules.autoload.d/kernel-2.6 file, remove ixp modules if found, and report whether the error in firmware uploading has disappeared (using your serial console)? |
Unfortunately I haven't got a serial console on my NSLU2 but my /etc/modules.autoload.d/kernel-2.6 is empty (no modules being loaded)!
I'll have a go at removing "alias eth0" when I get the time, at the moment I'm sluggishly compiling things on my NSLU2...
_________________
"Expect nothing. That way you will be ready for anything - Virginia Viadura"
Black Mesa Research Facility |
|
| Back to top |
|
|
jake1981
n00b
Joined: 02 Feb 2006
Posts: 61
Location: Finland
|
| Posted: Tue Nov 07, 2006 4:59 pm Post subject: |
|
|
| int2str wrote: | FWIW, the network interface on my NSLU2 is called "ixp0". Not sure if that makes any difference for you guys.
|
This sounds normal. My alias is supposed to rename this to eth0 to clarify users meaning of this device... |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Wed Nov 08, 2006 7:28 pm Post subject: |
|
|
| jake1981 wrote: | | int2str wrote: | FWIW, the network interface on my NSLU2 is called "ixp0". Not sure if that makes any difference for you guys.
|
This sounds normal. My alias is supposed to rename this to eth0 to clarify users meaning of this device... |
But where is it that you set this alias? |
|
| Back to top |
|
|
jake1981
n00b
Joined: 02 Feb 2006
Posts: 61
Location: Finland
|
| Posted: Wed Nov 08, 2006 8:04 pm Post subject: |
|
|
| wazow wrote: | | jake1981 wrote: | | int2str wrote: | FWIW, the network interface on my NSLU2 is called "ixp0". Not sure if that makes any difference for you guys.
|
This sounds normal. My alias is supposed to rename this to eth0 to clarify users meaning of this device... |
But where is it that you set this alias? |
in where it's normally
/etc/modules.d/aliases |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Wed Nov 08, 2006 8:09 pm Post subject: |
|
|
| jake1981 wrote: |
in where it's normally
/etc/modules.d/aliases |
Hmm... just asking because something must rename it to eth2 and I can see enything like that in /etc/modules.d/aliases.
In fact I have removed contents of the whole directory, which should give me vanilla not renamed device names. Somehow it does not help. I still see eth2 instead of ixp0. Really puzzled.
Misteriously my slug has booted now with eth2 and the ssh server went up for the first time. I am afraid to reboot it though as I fear that the result is random. Probably it depends on whether dropbear is activated before eth2 finished initialization, or while it is still doing it. I am annoyed by so much nondeterminism. |
|
| Back to top |
|
|
TheJackal
n00b
Joined: 29 Jul 2003
Posts: 73
Location: In front of the keyboard :)
|
| Posted: Wed Nov 08, 2006 8:44 pm Post subject: |
|
|
Just had the time to have a play around with some config files...
I removed the alias of the module ixp400_eth to eth0 (in /etc/modules.d/eth0), rebooted and it made no difference at all. Somehow ixp400_eth maps itself to eth2 regardless of any options given to it when loading the modules. I did notice that when I had "alias eth0 ixp400_eth", dmesg output reported something along the lines of "ixp400_eth: Activating Interface (eth2)" (can't be sure now as it now doesn't show up).
I can also confirm that my NSLU2 hasn't got the LEDs for both disks switched, I've got my external HDD plugged into the lower USB port and the "Disk 2" LED lights up as it should.
Btw, my NSLU2 was manufactured 05/2006.
Is it just me or does the NSLU2 takge ages to boot?
_________________
"Expect nothing. That way you will be ready for anything - Virginia Viadura"
Black Mesa Research Facility |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Wed Nov 08, 2006 9:28 pm Post subject: |
|
|
| TheJackal wrote: | | I removed the alias of the module ixp400_eth to eth0 (in /etc/modules.d/eth0), rebooted and it made no difference at all. Somehow ixp400_eth maps itself to eth2 regardless of any options given to it when loading the modules. I did notice that when I had "alias eth0 ixp400_eth", dmesg output reported something along the lines of "ixp400_eth: Activating Interface (eth2)" (can't be sure now as it now doesn't show up). |
This is also my experience. It is weird though, as Jake seems to be using the very same module.
| Quote: | I can also confirm that my NSLU2 hasn't got the LEDs for both disks switched, I've got my external HDD plugged into the lower USB port and the "Disk 2" LED lights up as it should.
|
Interesting: lower port on my slug is definitely labeled "Disk 1" . I also have my drive plugged into this lower port, and the disk-2 label is on, so may be labeling of ports has been messed up on my slug?
| Quote: | | Is it just me or does the NSLU2 takge ages to boot? |
It does. However I have not looked into optimizing the boot process yet. |
|
| Back to top |
|
|
jake1981
n00b
Joined: 02 Feb 2006
Posts: 61
Location: Finland
|
| Posted: Thu Nov 09, 2006 11:40 am Post subject: |
|
|
| wazow wrote: | | TheJackal wrote: | | I removed the alias of the module ixp400_eth to eth0 (in /etc/modules.d/eth0), rebooted and it made no difference at all. Somehow ixp400_eth maps itself to eth2 regardless of any options given to it when loading the modules. I did notice that when I had "alias eth0 ixp400_eth", dmesg output reported something along the lines of "ixp400_eth: Activating Interface (eth2)" (can't be sure now as it now doesn't show up). |
This is also my experience. It is weird though, as Jake seems to be using the very same module.
| Quote: | I can also confirm that my NSLU2 hasn't got the LEDs for both disks switched, I've got my external HDD plugged into the lower USB port and the "Disk 2" LED lights up as it should.
|
Interesting: lower port on my slug is definitely labeled "Disk 1" . I also have my drive plugged into this lower port, and the disk-2 label is on, so may be labeling of ports has been messed up on my slug?
| Quote: | | Is it just me or does the NSLU2 takge ages to boot? |
It does. However I have not looked into optimizing the boot process yet. |
This led issue is actually a filed bug in kernel by nslu2-linux/slugos/openslug team. There's a lot of interested information in nslu2-linux yahoo groups, this will also be fixed to openslug4..
What about changing files to use eth2 instead of eth0 in init.d? (rename net.eth0 to net.eth2 and so on)
Is eth2 able to get ip from dhcp? Can dropbear use eth2 instead of eth0? |
|
| Back to top |
|
|
TheJackal
n00b
Joined: 29 Jul 2003
Posts: 73
Location: In front of the keyboard :)
|
| Posted: Thu Nov 09, 2006 1:04 pm Post subject: |
|
|
| jake1981 wrote: | What about changing files to use eth2 instead of eth0 in init.d? (rename net.eth0 to net.eth2 and so on)
Is eth2 able to get ip from dhcp? Can dropbear use eth2 instead of eth0? |
In fact I've just symlinked net.eth2 to net.lo and removed net.eth0 from the default runlevel! Dropbear uses net.eth2 without any problem whatsoever as dropbear requires "net" which net.eth2 provides as its a symlink to "net.lo".
_________________
"Expect nothing. That way you will be ready for anything - Virginia Viadura"
Black Mesa Research Facility |
|
| Back to top |
|
|
wazow
Apprentice
Joined: 08 Jan 2004
Posts: 182
Location: Rødovre, Denmark
|
| Posted: Thu Nov 09, 2006 7:45 pm Post subject: |
|
|
| TheJackal wrote: | | jake1981 wrote: | What about changing files to use eth2 instead of eth0 in init.d? (rename net.eth0 to net.eth2 and so on)
Is eth2 able to get ip from dhcp? Can dropbear use eth2 instead of eth0? |
In fact I've just symlinked net.eth2 to net.lo and removed net.eth0 from the default runlevel! Dropbear uses net.eth2 without any problem whatsoever as dropbear requires "net" which net.eth2 provides as its a symlink to "net.lo". |
This is only partly true. I did the same and the outcome is nondeterministic. Dropbear refuses to work when the net is not up at the point it is started. I do not understand why the rc system attempts this before the net script has completed. I checked that the parallel startup is off.
As for using this as a permanent solution: sorry, I am not satisfied. There is a bug somewhere in the image. Openslug has no problem with this interface, running the same kernel. I can't just ignore the fact that there is a bug that we cannot diagnose |
|
| Back to top |
|
|
TheJackal
n00b
Joined: 29 Jul 2003
Posts: 73
Location: In front of the keyboard :)
|
| Posted: Fri Nov 10, 2006 9:59 am Post subject: |
|
|
One other thing, I frequently get I/O errors when attempting to write to my USB HDD, which means the root filesystem gets re-mounted as read-only....this usually means shutting down the NSLU2, running fsck on the affected partition (/dev/sda1) and then booting into Gentoo/SLUG again.
This only happens when compiling some packages, for example distcc, courier-authlib and iptables. Although, several frustated attempts at compiling indicate that this happens at random within a compile.
Would this indicate overheating of the USB enclosure's bridge, the HDD or would it be just the NSLU2 not being able to cope with the high stresses of compiling?
_________________
"Expect nothing. That way you will be ready for anything - Virginia Viadura"
Black Mesa Research Facility |
|
| Back to top |
|
|
|
|
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
You cannot vote in polls in this forum
|
|
Gentoo on Alternative Architectures
