[00:33] <milan_h> ok I am now running 2.6.16.20 with slob
[00:33] <milan_h> I get the full speed of the WAN connection, but SSH performance to the OpenWRT box from the LAN is horrible
[00:33] <milan_h> the latter was good with 2.6.16.7 + slab
[00:34] <milan_h> (SSH performance when there is an 690 KByte/s stream from WAN to LAN)
[00:35] <weggpod> hy all
[00:36] <milan_h> @Kaloz do you want my to test sth on 2.6.16.20 + slob or can I go back to slab? :)
[00:37] <weggpod> exist a new package for openvpn ?
[00:44] <[mbm]> milan_h: test slob on the newer kernels to see if the problem got fixed
[00:44] <weggpod> there are a problem with openvpn
[00:45] <weggpod> i cannot use PKSC file
[00:45] <weggpod> http://pastebin.com/763494
[00:46] <weggpod> and the same command works fine on debian
[00:46] <[mbm]> weggpod: don't repeat yourself
[00:47] <weggpod> sorry
[00:48] <milan_h> [mbm]: you mean 2.6.17-xx? can I do that without changes to patches etc?
[00:48] <weggpod> but i search the solution on openvpn
[00:49] <[mbm]> milan_h: yes (kaloz already told you that)
[00:49] <weggpod> and on other distrib there are bo problem
[00:49] <[mbm]> weggpod: stop repeating
[00:50] <milan_h> [mbm]: I only read Kaloz wanting me to test 2.6.16.19 or 20, which I did. did I miss sth while testing..?
[00:50] <[mbm]> weggpod: there's nobody here that can help you right now
[00:50] <[mbm]> milan_h: it was reported fixed in 2.6.16.19 so verify that the newer kernels fixed it
[00:52] <milan_h> [mbm]: ? I did test on 2.6.16.20. LAN<->WAN performance is good (better than .7), but SSH lags horribly while transferring ~ 690 KByte/s from WAN to LAN (which slab doesn't)
[00:52] <[mbm]> ah ok..
[00:54] <blux> So. to everone who has heard of my Flash Chip mod: IT Faild finaly . . . :-(
[00:54] <[mbm]> blux: what happened?
[00:54] <blux> I broke on Adress wire
[00:54] <blux> so it will not fail at all
[00:54] <[mbm]> heh, now you only have half the capacity
[00:55] <blux> somthing like that
[00:56] <blux> but only on the second footprint for the flash chip, I solderd back the Intel one and it boots again, but I have no neves to solder the SST again
[00:56] <blux> and the wires ar now very . .. er.. . instabile
[00:57] <[mbm]> you don't solder surface mount stuff; you basically just set it in place and bake it on
[00:57] <blux> so the Mod will work in generall, if you do not brake wires!
[00:58] <blux> yes , its very fine stuff
[00:58] <[mbm]> trying to solder the individual pins would be impossible
[00:58] <blux> but now im very well with that :-)
[00:59] <blux> oh, no I used an small solder Iron an an 0.3 mm "solder-wire"
[00:59] <[mbm]> you use a heat pencil
[00:59] <blux> if it is so called
[00:59] <[mbm]> set the chip in place, and just blow hot air at the pins until they solder themselves
[01:00] <blux> did not work here, untill you us an flux spray
[01:01] <blux> but I will not solder on this device anymore! the intel is back in place, my nerves ar runed, an It boots again
[01:01] <[mbm]> I hear the sd mod is much easier
[01:02] <blux> yes
[01:03] <blux> perhaps I will do that now. . . or use another Linksys, now my soldering experiance incresed, an I will lnot breake wires
[01:04] <blux> Is openwrt in failsave if the DMz is burning?
[01:05] <blux> ohh its not DMZ its WLAN!
[01:05] <blux> sry, did not see it without the cover
[01:07] <blux> ok, I will go to bed now, good N8 and Good luck to everybody, and thanks for help. You will here fram me, if I do the mod to another Linksys :-D
[16:59] <common> nbd?
[17:00] <common> the wrv54 is much better than the wrt
[17:00] <common> *much* better radio
[17:00] <common> more cou power
[17:37] <frop> common what's its price?
[17:37] <common> 150e new, got mine for ~80 on ebay
[17:46] <florian> what is the radio chipset ?
[17:47] <common> minipci prism54
[17:47] <common> and you can solder in a 2nd minipci slot
[17:47] <common> http://www.phj.hu/wrv54g/
[17:48] <common> http://openixp.phj.hu/cgi-bin/trac.cgi
[17:48] <common> openixp is a 2.6 port of openwrt to support ixp
[17:48] <florian> ok
[17:49] <florian> Kaloz merged ixp support few weeks ago
[17:49] <common> not really
[17:49] <wigyori> not complete yet, ixp400eth still has to be tested
[17:49] <wigyori> and ixp400osal will be reworked a bit
[17:49] <common> i added the entry for the wrv yesterday to the wiki
[17:50] <florian> great
[17:50] <common> if openwrt wants to support it, i will add all i know
[17:50] <common> for now its just a dummy entry which is empty
[19:17] <common> where are the stamp files for kamikaze?
[19:19] <wigyori> hm, anyone interested in looking into a wl500gp? i could get one
[19:20] <nbd> i am interested
[19:21] <wigyori> k, i'll get one then
[20:12] <common> http://phpfi.com/122473 wrv <-> wrt
[20:12] <common> seems like channelhopping is borked on the wrv
[21:40] <tziOm> [mbm], Im having problems with the mini_fo .. hmm.. as I said yesterday, I dont see the mini_fo patches beeing applied to the initscripts when looking in root...
[21:40] <[mbm]> the patches should already be applied .. I'll ask you the same damned question - which branch are you using?
[21:42] <tziOm> not I am sure I am using kamikaze, atleast if the info on dev.openwrt.org is correct!
[21:43] <[mbm]> ? you're not sure?
[21:43] <tziOm> I see it building and-so-on the mini_fo..
[21:44] <tziOm> How can I check it for sure? I know the svn command I cut-and-pasted was the svn co https://svn.openwrt.org/openwrt/trunk/
[21:44] <tziOm> and that says "kamikaze" on the dev page..
[21:44] <[mbm]> right, that's kamikaze
[21:45] <[mbm]> earlier you said "not I am sure" which doesn't make any sense
[21:45] <tziOm> Im using 2.5 brcm tho.. should that matter? (need the wireless)
[21:45] <tziOm> 2.4
[21:45] <[mbm]> why are you using kamikaze?
[21:45] <[mbm]> webif and mini_fo are in whiterussian, not kamikaze
[21:46] <tziOm> bah..
[21:49] <tziOm> so the patches are not in kamikaze?
[21:50] <tziOm> Im frustrated by what You say!
[21:50] <tziOm> yesterday I understood you the other way around
[21:55] <nbd> [mbm]: when porting the lzma loader to the aruba thingie: did you ever encounter the problem of getting random garbage on the terminal when booting the image?
[21:55] <nbd> [mbm]: well, not exactly random garbage. it seems to be the same every time
[21:55] <[mbm]> nbd: doesn't sound like you're booting the image, sounds like you're just executing random garbage
[21:56] <[mbm]> btw, you know that I patched the entry point, right?
[21:57] <nbd> patched? where?
[21:57] <common> are all devels subscribed to -users ml?
[21:57] <nbd> there's no user mailing list currently in use
[21:57] <common> i just mailed it
[21:58] <[mbm]> nbd: the 007-boot.patch .. the base address of the kernel is different than the actual kernel entry point so normally you can't just jump directly to the spot you decompressed the kernel
[21:58] <nbd> ah
[21:58] <tziOm> Does it exist a trx with mini_fo for brcm?
[21:58] <nbd> hmm... before i experiment with the kernel stuff, i'll try to see if it actually decompresses the image
[22:02] <nbd> [mbm]: no. it's not the entry point
[22:03] <[mbm]> meaning? ... you already patched the entry point?
[22:03] <nbd> no, i replaced the jump to the entry point with a printf("Hello World");
[22:03] <nbd> and i added the uart,print,printf code
[22:03] <[mbm]> and you still got garbage?
[22:03] <nbd> yes
[22:03] <nbd> the same
[22:04] <nbd> i'll check if it even reaches the entry function at all
[22:04] <nbd> maybe the copy stuff in head.S is wrong...
[22:04] <[mbm]> hmm are you decomrpessing the image ontop of the serial registers? :)
[22:04] <nbd> it's the code that copies the compressed image to another memory location
[22:05] <tziOm> nbd, Could you please answer me? Should mini_fo work in kamikaze branch? I enable it (brcm 2.4) .. it compiles and configures and everything, but I see no changes to firstboot/mount_root .. whats wrong, and what can I do to make it work as designed?
[22:05] <nbd> tziOm: no, sorry
[22:06] <tziOm> nbd, what?
[22:06] <nbd> answer to the first question
[22:07] <tziOm> Why are you so nice all the time? Are these questions abnormal in some way?
[22:07] <common> afaik you called the devs asslickers
[22:07] <common> so .. whats your point?
[22:07] <nbd> i don't feel like being bugged with lots of questions right now
[22:07] <nbd> i'm busy doing other stuff
[22:07] <tziOm> its a yes or no, isnt it?
[22:09] Action: [mbm] hasn't been able to understand any of tzi0m's questions
[22:10] <nbd> ok. it's not the memory copy itself that crashes it
[22:11] <florian__> I would like to make an OpenWrt presentation during, the french RMLL 2006, anyone opposed, interested ?
[22:11] <florian__> http://www.rmll.info/
[22:11] <tziOm> [mbm], for mini_fo to work it needs changes to the mount_root and firstboot scripts in bin and sbin, rite? I dont see these changes beeing made to the files even tho I enable mini_fo and it compiles.. wth can I do to make this work?
[22:12] <[mbm]> tziOm: the patch isn't conditional, and it isn't even in kamikaze
[22:12] <tziOm> [mbm], How can I use whiterussian, and make it patch the files mentioned above then?
[22:13] <florian__> {Nico}: RMLL 2006 ?
[22:13] Action: [mbm] gives up trying to explain it
[22:13] <tziOm> I havent been explained anything!
[22:13] <nbd> [mbm]: ah, figured it out. the linker doesn't put the functions of the second stage loader in the right order
[22:14] <[mbm]> nbd: ouch .. although if I remember right there's an asm macro that forces a strict order
[22:23] <nbd> ah
[22:23] <nbd> -ffunction-sections
[22:23] <nbd> that was the missing piece
[22:24] <nbd> because i used a section entry in the linker script to tell it where the entry function is supposed to go
[22:25] <nbd> yay
[22:25] <nbd> jumping to kernel code
[22:25] <nbd> Hello, World!
[22:25] <[mbm]> :)
[22:27] <nbd> [mbm]: can i move the 007-boot.patch to generic-2.6/patches?
[22:28] <[mbm]> sure, although the broadcom code is already patched
[22:29] <nbd> fixed that
[22:29] <nbd> any other patched platform?
[22:30] <[mbm]> think one of the platforms florian was working on got a similar patch
[22:31] <nbd> k
[22:31] <nbd> btw. i also have a change in my tree that makes the ramdisk stuff generic for linux 2.6
[22:32] <[mbm]> cool .. did you ever do anything with that busybox patch from the other day?
[22:32] <nbd> not yet
[22:48] <frop> ehi, what's the prodecure to add a netfileter extension?
[22:49] <frop> ...or the procedure to require that?
[22:52] <frop> i'd like to see this:
[22:52] <frop> http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3427
[23:11] <nbd> [mbm]: hmm... now i get garbage when executing the kernel image
[23:19] <Kaloz> nbd: but hello world works, right?
[23:19] <nbd> i did not have a hello world image
[23:19] <nbd> i just put hello world in front of the jump to KERNEL_ENTRY
[23:20] <Kaloz> well, for me the hello world thing worked with the lzma loader on the atheros boards, but the kernel didn't
[23:21] <nbd> did you add mbm's boot patch?
[23:23] <Kaloz> i've added serial support to the loader as well :p
[23:23] <Kaloz> the loader was crashing with the kernel, but worked with a smaller image
[23:23] <Kaloz> and i'm pretty sure the memory rnages were right
[23:24] <Kaloz> wondering if watchdog or something can kick in
[23:24] <Kaloz> or
[23:24] <Kaloz> hmz.. that was an older buggy redboot
[23:25] <Kaloz> it even foobar'ed the kernel when you started it with "exec" (as you should), but worked flawlessly with "go" (which is for simply elf programs)
[23:25] <Kaloz> imho i retest it with this one
[23:53] <nbd> grr. why does it have to crap out like that?
[23:55] <crazy_imp> is there any know problem with ide under kamikaze (r3907)? it doesn't find my disk :/
[23:55] <nbd> it looks like it's booting with the serial console being totally screwed up
[00:00] --- Thu Jun 8 2006
[00:33] <milan_h> I get the full speed of the WAN connection, but SSH performance to the OpenWRT box from the LAN is horrible
[00:33] <milan_h> the latter was good with 2.6.16.7 + slab
[00:34] <milan_h> (SSH performance when there is an 690 KByte/s stream from WAN to LAN)
[00:35] <weggpod> hy all
[00:36] <milan_h> @Kaloz do you want my to test sth on 2.6.16.20 + slob or can I go back to slab? :)
[00:37] <weggpod> exist a new package for openvpn ?
[00:44] <[mbm]> milan_h: test slob on the newer kernels to see if the problem got fixed
[00:44] <weggpod> there are a problem with openvpn
[00:45] <weggpod> i cannot use PKSC file
[00:45] <weggpod> http://pastebin.com/763494
[00:46] <weggpod> and the same command works fine on debian
[00:46] <[mbm]> weggpod: don't repeat yourself
[00:47] <weggpod> sorry
[00:48] <milan_h> [mbm]: you mean 2.6.17-xx? can I do that without changes to patches etc?
[00:48] <weggpod> but i search the solution on openvpn
[00:49] <[mbm]> milan_h: yes (kaloz already told you that)
[00:49] <weggpod> and on other distrib there are bo problem
[00:49] <[mbm]> weggpod: stop repeating
[00:50] <milan_h> [mbm]: I only read Kaloz wanting me to test 2.6.16.19 or 20, which I did. did I miss sth while testing..?
[00:50] <[mbm]> weggpod: there's nobody here that can help you right now
[00:50] <[mbm]> milan_h: it was reported fixed in 2.6.16.19 so verify that the newer kernels fixed it
[00:52] <milan_h> [mbm]: ? I did test on 2.6.16.20. LAN<->WAN performance is good (better than .7), but SSH lags horribly while transferring ~ 690 KByte/s from WAN to LAN (which slab doesn't)
[00:52] <[mbm]> ah ok..
[00:54] <blux> So. to everone who has heard of my Flash Chip mod: IT Faild finaly . . . :-(
[00:54] <[mbm]> blux: what happened?
[00:54] <blux> I broke on Adress wire
[00:54] <blux> so it will not fail at all
[00:54] <[mbm]> heh, now you only have half the capacity
[00:55] <blux> somthing like that
[00:56] <blux> but only on the second footprint for the flash chip, I solderd back the Intel one and it boots again, but I have no neves to solder the SST again
[00:56] <blux> and the wires ar now very . .. er.. . instabile
[00:57] <[mbm]> you don't solder surface mount stuff; you basically just set it in place and bake it on
[00:57] <blux> so the Mod will work in generall, if you do not brake wires!
[00:58] <blux> yes , its very fine stuff
[00:58] <[mbm]> trying to solder the individual pins would be impossible
[00:58] <blux> but now im very well with that :-)
[00:59] <blux> oh, no I used an small solder Iron an an 0.3 mm "solder-wire"
[00:59] <[mbm]> you use a heat pencil
[00:59] <blux> if it is so called
[00:59] <[mbm]> set the chip in place, and just blow hot air at the pins until they solder themselves
[01:00] <blux> did not work here, untill you us an flux spray
[01:01] <blux> but I will not solder on this device anymore! the intel is back in place, my nerves ar runed, an It boots again
[01:01] <[mbm]> I hear the sd mod is much easier
[01:02] <blux> yes
[01:03] <blux> perhaps I will do that now. . . or use another Linksys, now my soldering experiance incresed, an I will lnot breake wires
[01:04] <blux> Is openwrt in failsave if the DMz is burning?
[01:05] <blux> ohh its not DMZ its WLAN!
[01:05] <blux> sry, did not see it without the cover
[01:07] <blux> ok, I will go to bed now, good N8 and Good luck to everybody, and thanks for help. You will here fram me, if I do the mod to another Linksys :-D
[16:59] <common> nbd?
[17:00] <common> the wrv54 is much better than the wrt
[17:00] <common> *much* better radio
[17:00] <common> more cou power
[17:37] <frop> common what's its price?
[17:37] <common> 150e new, got mine for ~80 on ebay
[17:46] <florian> what is the radio chipset ?
[17:47] <common> minipci prism54
[17:47] <common> and you can solder in a 2nd minipci slot
[17:47] <common> http://www.phj.hu/wrv54g/
[17:48] <common> http://openixp.phj.hu/cgi-bin/trac.cgi
[17:48] <common> openixp is a 2.6 port of openwrt to support ixp
[17:48] <florian> ok
[17:49] <florian> Kaloz merged ixp support few weeks ago
[17:49] <common> not really
[17:49] <wigyori> not complete yet, ixp400eth still has to be tested
[17:49] <wigyori> and ixp400osal will be reworked a bit
[17:49] <common> i added the entry for the wrv yesterday to the wiki
[17:50] <florian> great
[17:50] <common> if openwrt wants to support it, i will add all i know
[17:50] <common> for now its just a dummy entry which is empty
[19:17] <common> where are the stamp files for kamikaze?
[19:19] <wigyori> hm, anyone interested in looking into a wl500gp? i could get one
[19:20] <nbd> i am interested
[19:21] <wigyori> k, i'll get one then
[20:12] <common> http://phpfi.com/122473 wrv <-> wrt
[20:12] <common> seems like channelhopping is borked on the wrv
[21:40] <tziOm> [mbm], Im having problems with the mini_fo .. hmm.. as I said yesterday, I dont see the mini_fo patches beeing applied to the initscripts when looking in root...
[21:40] <[mbm]> the patches should already be applied .. I'll ask you the same damned question - which branch are you using?
[21:42] <tziOm> not I am sure I am using kamikaze, atleast if the info on dev.openwrt.org is correct!
[21:43] <[mbm]> ? you're not sure?
[21:43] <tziOm> I see it building and-so-on the mini_fo..
[21:44] <tziOm> How can I check it for sure? I know the svn command I cut-and-pasted was the svn co https://svn.openwrt.org/openwrt/trunk/
[21:44] <tziOm> and that says "kamikaze" on the dev page..
[21:44] <[mbm]> right, that's kamikaze
[21:45] <[mbm]> earlier you said "not I am sure" which doesn't make any sense
[21:45] <tziOm> Im using 2.5 brcm tho.. should that matter? (need the wireless)
[21:45] <tziOm> 2.4
[21:45] <[mbm]> why are you using kamikaze?
[21:45] <[mbm]> webif and mini_fo are in whiterussian, not kamikaze
[21:46] <tziOm> bah..
[21:49] <tziOm> so the patches are not in kamikaze?
[21:50] <tziOm> Im frustrated by what You say!
[21:50] <tziOm> yesterday I understood you the other way around
[21:55] <nbd> [mbm]: when porting the lzma loader to the aruba thingie: did you ever encounter the problem of getting random garbage on the terminal when booting the image?
[21:55] <nbd> [mbm]: well, not exactly random garbage. it seems to be the same every time
[21:55] <[mbm]> nbd: doesn't sound like you're booting the image, sounds like you're just executing random garbage
[21:56] <[mbm]> btw, you know that I patched the entry point, right?
[21:57] <nbd> patched? where?
[21:57] <common> are all devels subscribed to -users ml?
[21:57] <nbd> there's no user mailing list currently in use
[21:57] <common> i just mailed it
[21:58] <[mbm]> nbd: the 007-boot.patch .. the base address of the kernel is different than the actual kernel entry point so normally you can't just jump directly to the spot you decompressed the kernel
[21:58] <nbd> ah
[21:58] <tziOm> Does it exist a trx with mini_fo for brcm?
[21:58] <nbd> hmm... before i experiment with the kernel stuff, i'll try to see if it actually decompresses the image
[22:02] <nbd> [mbm]: no. it's not the entry point
[22:03] <[mbm]> meaning? ... you already patched the entry point?
[22:03] <nbd> no, i replaced the jump to the entry point with a printf("Hello World");
[22:03] <nbd> and i added the uart,print,printf code
[22:03] <[mbm]> and you still got garbage?
[22:03] <nbd> yes
[22:03] <nbd> the same
[22:04] <nbd> i'll check if it even reaches the entry function at all
[22:04] <nbd> maybe the copy stuff in head.S is wrong...
[22:04] <[mbm]> hmm are you decomrpessing the image ontop of the serial registers? :)
[22:04] <nbd> it's the code that copies the compressed image to another memory location
[22:05] <tziOm> nbd, Could you please answer me? Should mini_fo work in kamikaze branch? I enable it (brcm 2.4) .. it compiles and configures and everything, but I see no changes to firstboot/mount_root .. whats wrong, and what can I do to make it work as designed?
[22:05] <nbd> tziOm: no, sorry
[22:06] <tziOm> nbd, what?
[22:06] <nbd> answer to the first question
[22:07] <tziOm> Why are you so nice all the time? Are these questions abnormal in some way?
[22:07] <common> afaik you called the devs asslickers
[22:07] <common> so .. whats your point?
[22:07] <nbd> i don't feel like being bugged with lots of questions right now
[22:07] <nbd> i'm busy doing other stuff
[22:07] <tziOm> its a yes or no, isnt it?
[22:09] Action: [mbm] hasn't been able to understand any of tzi0m's questions
[22:10] <nbd> ok. it's not the memory copy itself that crashes it
[22:11] <florian__> I would like to make an OpenWrt presentation during, the french RMLL 2006, anyone opposed, interested ?
[22:11] <florian__> http://www.rmll.info/
[22:11] <tziOm> [mbm], for mini_fo to work it needs changes to the mount_root and firstboot scripts in bin and sbin, rite? I dont see these changes beeing made to the files even tho I enable mini_fo and it compiles.. wth can I do to make this work?
[22:12] <[mbm]> tziOm: the patch isn't conditional, and it isn't even in kamikaze
[22:12] <tziOm> [mbm], How can I use whiterussian, and make it patch the files mentioned above then?
[22:13] <florian__> {Nico}: RMLL 2006 ?
[22:13] Action: [mbm] gives up trying to explain it
[22:13] <tziOm> I havent been explained anything!
[22:13] <nbd> [mbm]: ah, figured it out. the linker doesn't put the functions of the second stage loader in the right order
[22:14] <[mbm]> nbd: ouch .. although if I remember right there's an asm macro that forces a strict order
[22:23] <nbd> ah
[22:23] <nbd> -ffunction-sections
[22:23] <nbd> that was the missing piece
[22:24] <nbd> because i used a section entry in the linker script to tell it where the entry function is supposed to go
[22:25] <nbd> yay
[22:25] <nbd> jumping to kernel code
[22:25] <nbd> Hello, World!
[22:25] <[mbm]> :)
[22:27] <nbd> [mbm]: can i move the 007-boot.patch to generic-2.6/patches?
[22:28] <[mbm]> sure, although the broadcom code is already patched
[22:29] <nbd> fixed that
[22:29] <nbd> any other patched platform?
[22:30] <[mbm]> think one of the platforms florian was working on got a similar patch
[22:31] <nbd> k
[22:31] <nbd> btw. i also have a change in my tree that makes the ramdisk stuff generic for linux 2.6
[22:32] <[mbm]> cool .. did you ever do anything with that busybox patch from the other day?
[22:32] <nbd> not yet
[22:48] <frop> ehi, what's the prodecure to add a netfileter extension?
[22:49] <frop> ...or the procedure to require that?
[22:52] <frop> i'd like to see this:
[22:52] <frop> http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=3427
[23:11] <nbd> [mbm]: hmm... now i get garbage when executing the kernel image
[23:19] <Kaloz> nbd: but hello world works, right?
[23:19] <nbd> i did not have a hello world image
[23:19] <nbd> i just put hello world in front of the jump to KERNEL_ENTRY
[23:20] <Kaloz> well, for me the hello world thing worked with the lzma loader on the atheros boards, but the kernel didn't
[23:21] <nbd> did you add mbm's boot patch?
[23:23] <Kaloz> i've added serial support to the loader as well :p
[23:23] <Kaloz> the loader was crashing with the kernel, but worked with a smaller image
[23:23] <Kaloz> and i'm pretty sure the memory rnages were right
[23:24] <Kaloz> wondering if watchdog or something can kick in
[23:24] <Kaloz> or
[23:24] <Kaloz> hmz.. that was an older buggy redboot
[23:25] <Kaloz> it even foobar'ed the kernel when you started it with "exec" (as you should), but worked flawlessly with "go" (which is for simply elf programs)
[23:25] <Kaloz> imho i retest it with this one
[23:53] <nbd> grr. why does it have to crap out like that?
[23:55] <crazy_imp> is there any know problem with ide under kamikaze (r3907)? it doesn't find my disk :/
[23:55] <nbd> it looks like it's booting with the serial console being totally screwed up
[00:00] --- Thu Jun 8 2006