**** BEGIN LOGGING AT Wed Oct 07 02:59:57 2009
Oct 07 05:15:09 <tinker-f595> dieter_: it looks like openrd_base is in linux next http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=summary Not sure how complete it is.  No sign of openrd client bits though and no sign of openrd in  mainline uboot
Oct 07 05:20:26 <tinker-f595> dieter_: actually looks like openrd_base bits have been merged into http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=summary
Oct 07 05:24:51 <ron__> uboot upstream is running a backlog by the look of it.  I only just got a ping back about a separate patch I sent at the same time as a bunch of kirkwood changes for them
Oct 07 05:58:53 <dieter_> tinker-f595: hi, hm - I wonder when this happen :)
Oct 07 05:59:22 <dieter_> tinker-f595: I read lkml but never stumbled over some post regarding openrd - but never mind!
Oct 07 05:59:31 <dieter_> tinker-f595: thanks for the hint!
Oct 07 06:00:12 <tinker-f595> dieter_: you need to drill down into /arch/arm/mach_kirkwood
Oct 07 06:00:36 <tinker-f595> not sure how complete it is
Oct 07 06:01:45 <tinker-f595> I wish the client stuff was ready
Oct 07 06:01:45 <tinker-f595> and the uboot stuff for the client
Oct 07 06:01:47 <tinker-f595> history will tell when it happened
Oct 07 06:03:37 <dieter_> tinker-f595: what u-boot stuff do you need for the client?
Oct 07 06:04:40 <tinker-f595> well don't want the pci getting initialized incorrectly cause the video chip uses that
Oct 07 06:05:17 <tinker-f595> plus last I looked the SATA was not being initialized by uboot
Oct 07 06:06:42 <dieter_> oh - ok. Sorry about that. Which u-boot have you tried? The latest one from Prafulla at http://git.denx.de/?p=u-boot/u-boot-arm.git;a=summary ?
Oct 07 06:08:08 <tinker-f595> Think I was looking at that
Oct 07 06:10:04 <tinker-f595> dieter_: I know you are just starting for the day...but I am fading...end of my day and time for sleep.
Oct 07 06:10:38 <dieter_> tinker-f595: Sure - so have a good night! Maybe we see us tomorrow...
Oct 07 06:11:00 <tinker-f595> actually I was looking at the uboot at http://git.denx.de/?p=u-boot/u-boot-marvell.git;a=summary
Oct 07 06:11:26 <tinker-f595> dieter_: have a good morning
Oct 07 06:18:18 <dieter_> tinker-f595: thanks and bye
Oct 07 08:10:32 <dieter_> tinker-f595: yes - as Prafulla said this is the most recent kirkwood tree. So I fear there is no read solution for PCI at the moment.
Oct 07 08:10:52 <dieter_> tinker-f595: as far as I remember the SATA init is allready fixed there.
Oct 07 08:27:34 <ron__> if it is, it's only been the last few weeks.  there was no mv sata support in mainline uboot, but it's in the old one from the devkit
Oct 07 14:26:17 <tinker-f595> ron__: SATA support is broken in the uboot in the devkit.  The second port (eSata) is not supported correctly.  This is due to a general bug in that ancient version of uboot.  I tracked through the history a few weeks ago and confirmed that it had been fixed in the more recent releases.  The uboot code has changed so much over the years from the devkit fork that it does not look like a backport point fix would be easy.
Oct 07 14:27:08 <tinker-f595> eSATA basically crashes in the devkit uboot fork
Oct 07 14:36:41 <ron__> the mv_sata support is 'fine', I've been booting solely off that for a couple of months or more now
Oct 07 14:37:31 <ron__> but I couldn't justify the time to port it forward to mainline uboot right now, and don't know of anyone else doing that yet either
Oct 07 14:41:35 <ron__> that was the only thing that stopped me using the mainline patchset though, it could boot the system fine off other storage
**** BEGIN LOGGING AT Wed Oct 07 14:49:23 2009
Oct 07 16:00:27 <tinker-f595> ron__: ron__ no, the uBoot  sata support is not fine.  eSATA does not work correctly
Oct 07 16:02:26 <tinker-f595> ron__: have you actually attempted to use eSATA from uBoot that comes with the openrd devkit?
Oct 07 16:03:03 <tinker-f595> it does not work correctly.
Oct 07 20:08:24 <eFfeM> timtimred: do you feel involved with kirkwood support in oe ?
Oct 07 20:11:19 <timtimred> hi
Oct 08 01:44:05 <yacoob> Hey there.
Oct 08 01:44:21 <yacoob> I just found most peculiar behavior of sheevaplug's eth0, which I described here: http://plugcomputer.org/plugforum/index.php?topic=811.0
Oct 08 01:44:42 <yacoob> if anyone seen anything like that, I'm all ears.
Oct 08 01:46:40 <ron__> as I said, I'm booting entirely from sata, and didn't need to modify the mv_sata driver to do that, so it's 'fine'.  if you've got problems with the generic sata support in uboot, backport the fix for that, or better, forward port mv_sata to denx
Oct 08 01:47:18 <ron__> it WFM.  if it doesn't for you, you've got the same source I have ...
Oct 08 02:09:36 <darkstar62> yacoob: that's really weird -- I've never seen anything like it.  On mine, it was configured to use dhcp out of the box, and I reconfigured it through /etc/network/interfaces to a static IP. On next reboot, it was using that static IP, so I'm not sure if it was happening but got changed, or what...
Oct 08 02:23:15 <yacoob> darkstar62, thing is, you won't see it normally :)
Oct 08 02:23:24 <yacoob> if it comes back with old ip, it's either there and ready
Oct 08 02:23:29 <yacoob> or will get reconfigured by dhcp
Oct 08 02:24:04 <yacoob> I might have missed something obvious, but it's almost 4 AM and I'm kind of tired of debugging this :)
Oct 08 02:24:13 <darkstar62> have you put anything in the networking scripts to see if they're being called that early in the bootup?
Oct 08 02:25:05 <yacoob> they're not
Oct 08 02:25:13 <darkstar62> weird...
Oct 08 02:25:17 <yacoob> ifup -a is called from /etc/init.d/networking
Oct 08 02:25:24 <yacoob> it sees that interface is already up
Oct 08 02:25:32 <yacoob> and it doesn't call any scripts
Oct 08 02:25:41 <darkstar62> wait a minute...I wonder if that's a red hering
Oct 08 02:25:48 <darkstar62> does ifdown ever get called on shutdown?
Oct 08 02:25:53 <yacoob> yes
Oct 08 02:26:01 <yacoob> well, ifdown -a
Oct 08 02:26:02 <darkstar62> hrm, ok...
Oct 08 02:26:04 <darkstar62> right
Oct 08 02:26:18 <yacoob> http://pastebin.ca/1602866 - this is strace of ifup -a being called from /etc/init.d/networking
Oct 08 02:27:01 <yacoob> and yeah, I thought about the same thing - I've removed the state file from /var/run/network/ifstate, to make sure it's not ifup that's getting confused about state
Oct 08 02:27:28 <darkstar62> you said you're booting off SD card?  Does that mean you have a real /var/run directory, and it isn't a tmpfs?
Oct 08 02:27:56 <yacoob> nah, it's still tmpfs
Oct 08 02:28:07 <darkstar62> hmm...wonder if that could have something to do with it
Oct 08 02:28:18 <darkstar62> if that directory doesn't exist (/var/run/network), does ifup work?
Oct 08 02:28:31 <yacoob> that's common approach nowadays, I'd say
Oct 08 02:28:43 <yacoob> and it's up and mounted before ifup arrives
Oct 08 02:29:12 <darkstar62> hrm, ok
Oct 08 02:29:31 <darkstar62> weird, I'm running out of ideas
Oct 08 02:30:22 <darkstar62> what does your /etc/network/interfaces contain?
Oct 08 02:30:42 <yacoob> auto lo
Oct 08 02:30:42 <yacoob> iface lo inet loopback
Oct 08 02:30:42 <yacoob> auto eth0
Oct 08 02:30:42 <yacoob> iface eth0 inet static
Oct 08 02:30:47 <yacoob> ...plus config for eth0
Oct 08 02:30:54 <yacoob> nothing out of the ordinary
Oct 08 02:31:07 <yacoob> and of course it runs fine when I do /etc/init.d/networking restart or equivalent
Oct 08 02:31:27 <yacoob> that is, mountnfs runs and things Just Work [tm]
Oct 08 02:32:13 <yacoob> if you can reboot your sheeva, you can test something for me
Oct 08 02:32:38 <darkstar62> what do you need?
Oct 08 02:32:43 <yacoob> add 'ifconfig' call, at the beginning of udev script (in /etc/rcS.d) and at the beginning of next script
Oct 08 02:33:08 <yacoob> (next one is S11mountdevsubfs.sh here)
Oct 08 02:33:22 <yacoob> you'd have to look at the console to find the output of that
Oct 08 02:33:48 <yacoob> but I'm very interested to see whether it's only here that it misbehaves, or is to common behavior
Oct 08 02:34:39 <darkstar62> ok, I'm gonna lose IRC when I do this, so I'll be right back
Oct 08 02:40:42 <darkstar62> so the ifconfig only ran once for me, but when it did, the interface was up and configured
Oct 08 02:40:57 <darkstar62> and it happened right after "Loading hardware drivers..."
Oct 08 02:41:18 <yacoob> if you haven't put a comment around ifconfig, it probably ran twice, but first run was silent :)
Oct 08 02:41:33 <yacoob> comment as in 'echo running ifconfig; ifconfig; echo there'
Oct 08 02:41:45 <darkstar62> ah, that makes sense
Oct 08 02:41:54 <yacoob> and looks like it behaves the same way for you
Oct 08 02:42:02 <ron__> ifconfig -a is your friend there too
Oct 08 02:42:04 <yacoob> the moment it appears in system, it's up and configured
Oct 08 02:42:25 <yacoob> ron__, I don't want -a, I only want to see interfaces that are up
Oct 08 02:43:00 <ron__> yes, but you'll see it was run and the interface wasn't configured yet
Oct 08 02:43:45 <ron__> sounds like ubuntu hal/udev/network-manager? magic to me though ...
Oct 08 02:44:07 <darkstar62> maybe hal...
Oct 08 02:44:21 <ron__> someone added something to 'help' you :)  did you grep all the udev and/or fdi scripts?
Oct 08 02:45:03 <yacoob> there's only one rule for eth
Oct 08 02:45:11 <yacoob> and it's for mapping to device names
Oct 08 02:45:13 <yacoob> pretty standard
Oct 08 02:45:16 <yacoob> what's fdi?
Oct 08 02:45:48 <ron__> something you're really never supposed to (have to) touch with a user hat on ...
Oct 08 02:45:52 <yacoob> (and of course there's no hal nor network-manager on that device)
Oct 08 02:45:54 <ron__> hardware descriptions for hal
Oct 08 02:46:11 <yacoob> ok, then it's not involved here
Oct 08 02:46:19 <ron__> you can get rid of hal ;?
Oct 08 02:46:55 <ron__> `dpkg -L udev` and look through everything it has for you
Oct 08 02:48:16 <yacoob> like I said above, no weird rules about eth
Oct 08 02:48:33 <yacoob> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:43:01:d7:08", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Oct 08 02:48:34 <darkstar62> check out /lib/udev/rules.d/85-ifupdown.rules
Oct 08 02:48:36 <yacoob> that's for mapping
Oct 08 02:48:46 <darkstar62> specifically
Oct 08 02:48:50 <darkstar62> SUBSYSTEM=="net", ACTION=="add", RUN+="/sbin/start-stop-daemon --start --background --pidfile /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE}"
Oct 08 02:49:00 <yacoob> holy crap!
Oct 08 02:49:07 <yacoob> who puts config files in /lib :(
Oct 08 02:49:15 * ron__ touches his nose and points at darkstar62 :)
Oct 08 02:49:52 <darkstar62> that's really weird: P
Oct 08 02:49:59 <darkstar62> dpkg -L udev told me about that
Oct 08 02:49:59 <ron__> yacoob: that's why I told you to look at `dpkg -L udev`
Oct 08 02:50:05 <ron__> snap
Oct 08 02:50:17 <yacoob> madness
Oct 08 02:50:19 <darkstar62> I thought it really odd there was practically no udev configuration in /etc/udev
Oct 08 02:50:32 <ron__> udev moves stuff there that it didn't want to let you fix locally anymore
Oct 08 02:50:37 <yacoob> but interesting
Oct 08 02:51:00 <darkstar62>  /lib though?
Oct 08 02:51:10 <darkstar62> what about /etc/udev/dont_touch
Oct 08 02:51:12 <ron__> like the thing that will make sure you don't have an eth0 anymore if you ever change your mac
Oct 08 02:51:14 <darkstar62> or somesuch
Oct 08 02:51:36 <ron__> if it's in /etc debian policy says it _has_ to respect local admin changes
Oct 08 02:51:54 <darkstar62> oh, I see...in /lib they can just replace it willy-nilly
Oct 08 02:52:01 <ron__>  /lib is none of the admins business, it can stomp all over you how it likes
Oct 08 02:52:37 <ron__> if you delete persistent-net-generator, it will just put it back again next time :(
Oct 08 02:53:55 <darkstar62> so yacoob, it seems putting it in ifup.d is only half of it...maybe put a mount command in /etc/rc.local too
Oct 08 02:53:55 <yacoob> that still isn't right, if it runs ifup, it should run scripts
Oct 08 02:54:18 <yacoob> darkstar62, I have a workaround for that, I just want to understand why isn't it working the way I expect
Oct 08 02:54:26 <darkstar62> ah, ok
Oct 08 02:54:33 <yacoob> tadam.wav
Oct 08 02:54:53 <yacoob> (that is, works fine once I removed ADD rule)
Oct 08 02:55:04 <yacoob> now, why doesn't it work in the first place...
Oct 08 02:55:25 <ron__> it probably is running your scripts
Oct 08 02:55:39 <ron__> they're just failing because it's Too Early for them
Oct 08 02:56:01 <darkstar62> do you boot completely from SD or is some internal flash use involved?
Oct 08 02:56:17 <darkstar62> hrm, nevermind, that doesn't make sense
Oct 08 02:56:24 <ron__> (and it's not telling you they are failing)
Oct 08 02:56:34 <yacoob> ron__, yes, I expect that it's something like that
Oct 08 02:56:39 <yacoob> still, they should be fine
Oct 08 02:57:12 <yacoob> I'm not depending on name resolution
**** ENDING LOGGING AT Thu Oct 08 02:59:58 2009