**** BEGIN LOGGING AT Mon Sep 19 02:59:56 2005 Sep 19 03:01:21 dwery: well, it might be interesting to try it out on BE Sep 19 03:01:35 dwery: openslug afaik still uses v1.5, right? Sep 19 03:03:20 Jacmet: 1.4 or 1.5 , yes. Sep 19 03:08:20 i'm not an expert on kernel oopses... what can you understand from the one I pasted? Sep 19 03:16:26 03rpurdie 07org.openembedded.dev * r9081cef3... 10/packages/linux/ (14 files in 2 dirs): linux-oz-2.6: Create a linux-openzaurus.inc containing common metadata. Add 2.6.14-rc1 as our stable kernel. Sep 19 03:17:25 dwery: it's out of my scrollback - can you paste it again please Sep 19 03:18:26 http://rafb.net/paste/results/f5j9Jk83.html Sep 19 03:20:15 dwery: it tries to access an unmapped address - 0xa305000e Sep 19 03:21:07 I'll check the datasheet for the NPE addresses Sep 19 03:21:24 thanks Sep 19 03:21:41 i'm still a bit |-) Sep 19 03:22:40 .. downloading .. Sep 19 03:23:15 it could be everything, isn't it? a stray pointer... Sep 19 03:25:26 dwery: it could, but most likely it's an access to the NPE registers and there's an ioremap missing or something like that Sep 19 03:26:21 ok. i suppose intel tested that code on at least one of their platforms :) Sep 19 03:26:29 so it should be mostly correct :) Sep 19 03:29:15 dwery: ok, the a3 address doesn't correspond to any physical NPE register (they are all in the 0xc8xxxxxx range) - but it's ofcause an ioremapped address Sep 19 03:29:47 NAiL: yes - you know.. "nb_NO.UTF-8... done, nb_NO.ISO-8859-1... done" and so on for like.. 400 language/charset combos :) Sep 19 03:31:24 Jacmet: ok Sep 19 03:31:51 dwery: you could have a look (don't have the sources here) at where the pgd variable gets set up Sep 19 03:32:42 pgd? Sep 19 03:33:17 dwery: yeah, the one mentioned in the dump Sep 19 03:33:20 how? Sep 19 03:35:46 dwery: ehh, by looking the source? I'm at work so I don't have the intel source here to look myself Sep 19 03:36:51 i mean how can identifty which variable it is Sep 19 03:38:30 dwery: isn't there a pgd variable in the source? Sep 19 03:39:34 Jacmet: just did a grep for pgd... no Sep 19 03:40:20 dwery: hmm, then I must be misreading the dump Sep 19 03:41:02 dwery: ok, then put a few debug printks after the line printing the default mac address Sep 19 03:41:12 03rpurdie 07org.openembedded.dev * ra2d3ac01... 10/packages/linux/linux-openzaurus_2.6.14-rc1.bb: linux-oz-2.6: Fix a potential conflict with the tosa-bl patch. Sep 19 03:42:26 Jacmet: it's in the eth_probe function. it returns a few lines later Sep 19 03:43:04 Jacmet: but i can enable tracing in the driver Sep 19 03:43:33 ok Sep 19 03:52:24 Jacmet: is the rtc code working ok for you? Sep 19 03:55:46 it seems tracing has not been enabled :( i'll recheck. same oops, ends with Sep 19 03:55:47 7fe0: 00000000 bec44ad8 00001924 400de540 60000010 00000003 00002031 00002431 Sep 19 03:55:47 Backtrace: invalid frame pointer 0x00000004 Sep 19 03:55:47 Code: eaffffd0 e12fff1e e52de004 e1a0c000 (e1d014be) Sep 19 03:55:47 <0>Kernel panic - not syncing: Aiee, killing interrupt handler! Sep 19 03:57:35 doh.. theres a module parameter |-) Sep 19 04:07:32 * dwery thinks it's crashing in the interrupt Sep 19 04:10:11 i think it has something to do with the pmu timer/interrupt. someone with arm/xscale knowledge is required here. Sep 19 04:11:44 dwery: could you paste the crash? Sep 19 04:13:34 Jacmet: yes Sep 19 04:14:27 http://rafb.net/paste/results/0JnBem81.html Sep 19 04:16:14 03rpurdie 07org.openembedded.dev * r867a0401... 10/packages/hostap/hostap-modules-0.4.4/kernel_updates.patch: Sep 19 04:16:14 hostap: These changes will happen in 2.6.15 but are present in the current -mm Sep 19 04:16:14 series. To get this to work, -mm kernels will have to pretend to be 2.6.15. The Sep 19 04:16:14 only other alternative is to break 2.6.14 series kernels which is unacceptable. Sep 19 04:17:25 dwery: sorry, I didn't had time to try out the rtc code yet, I will give it a go tonight Sep 19 04:18:14 Jacmet: no problem. I asked becuse I know have my rtc in 2002, but I gues ti could be related to my development on the ixp code :) Sep 19 04:18:20 s/know/now/ Sep 19 04:19:16 dwery: does anything interesting happend in init_module from line 3355 onwards? Sep 19 04:19:47 Jacmet: i think there's an interrupt which is enable a little bit before 3355... probably it fires just a few millisecs after Sep 19 04:21:42 dwery: ok, could you stick a printk in the interrupt handler then? Sep 19 04:27:32 Jacmet: i'll try.. but i think there' some kind of handlers conflict Sep 19 04:31:07 03koen 07org.openembedded.dev * r41414d67... 10/packages/gpsd/gpsd.inc: packages/gpsd/gpsd.inc: fix depends Sep 19 04:33:14 Jacmet: it seems the kernel can't be told not to use the PMU int Sep 19 04:36:04 hmm.. Sep 19 04:43:14 given that, the ixp should be modified Sep 19 04:52:16 or maybe i'm missing something... Sep 19 04:54:17 dwery: I'll give it a look tonight Sep 19 05:00:54 Jacmet: thanks. i though i had seen some patches for the old 1.5 ial that were related to the interrupt Sep 19 05:01:04 03freyther 07org.openembedded.dev * r8167de3e... 10/packages/linux-libc-headers/ (3 files): Sep 19 05:01:04 packages/linux-libc-headers: Sep 19 05:01:04 -Use a more compatible command-line argument. -a is compatible Sep 19 05:01:04 to -dpR and -d is the same as -P and -P exist on FreeBSD Sep 19 05:28:28 WHOOOOOOOOOOOOOOOOOOOOOOOOOOAAAAAAAAAAAAAAAAAAAAAAAA YAHOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOo Sep 19 05:28:47 that sounds promising :-) Sep 19 05:28:57 <[g2]> go dwery go dwery Sep 19 05:29:06 it works!!! Sep 19 05:29:14 <[g2]> either that or he just jumped out the window Sep 19 05:29:18 LOL Sep 19 05:29:25 <[g2]> dwery CONGRATS! Sep 19 05:29:53 <[g2]> you've been working hard with yvasilev and Jacmet Sep 19 05:29:56 dwery; what was the missing ingredient? Sep 19 05:30:19 wai wait.. it works but in a strange way... Sep 19 05:31:24 the module loads ok, i passed datapath_poll = 0 Sep 19 05:31:41 which probably bypassed the code that was causing the oops Sep 19 05:31:58 <[g2]> that isolates the problem some :) Sep 19 05:32:24 sigh.. ti oopsed in this exact moment :( Sep 19 05:32:42 I should YAHOO too early :D Sep 19 05:33:12 I should not have YAHOOed ... sound better. Sep 19 05:33:35 <[g2]> dwery it's still a CONGRATS you are making lots of progress and getting _much_ closer Sep 19 05:34:28 th every strange thing is that the nlsu2 responded to pings of its IXP interface on the usbnet interface... Sep 19 05:44:40 still trying... it seems the driver has difficulties in detecting the media.. Sep 19 05:44:45 and refusing to unload itself :) Sep 19 05:46:04 03koen 07org.openembedded.dev * rdaa9aa70... 10/conf/distro/preferred-gpe-versions-2.7.inc: conf/distro/preferred-gpe-versions-2.7.inc: add preferred provider for gnome-vfs-dbus Sep 19 05:52:06 morning Sep 19 05:52:22 dwery: fill me in ;-) Sep 19 05:53:25 I managed to get as close as: http://rafb.net/paste/results/frIa1s13.html Sep 19 05:53:33 <[g2]> ah... slugtime in action, yvasilev wakes up and is ready for the torch Sep 19 05:54:07 yvasilev: hi! Sep 19 05:54:19 yvasilev: you get different errors than mine.. god :) Sep 19 05:54:21 good Sep 19 05:54:45 i have the interfaces up, but no comms Sep 19 05:54:47 ~slugtime Sep 19 05:54:48 I needed to compile the microcode into a different module to make it work Sep 19 05:54:51 it has been said that slugtime is 40 hour days 10 hours in 4 timezones with overlap Sep 19 05:55:05 please send me you modinfo Sep 19 05:56:42 http://rafb.net/paste/results/kgt3uO14.html Sep 19 05:58:50 with respect to your kernel crash, arp virtual addresses are the same as physical adresses, on slug ps atarts at 0x00 (according to kernel command line) so virtual address a305000e was well out of 32Mb it has Sep 19 05:59:00 yvasilev: can you try to build it with DEBUG defined and modprobe with datapath_poll=0 log_level=2 Sep 19 05:59:17 kernel or ial? Sep 19 05:59:39 _eth Sep 19 06:01:57 and about microcode, it looks like all microcodes have to be compiled into ixp400.ko, and then the right one is selected at the time you insert _eth.ko Sep 19 06:02:43 possile. it's quite strange that my ixp400.o has it inside... Sep 19 06:04:46 http://rafb.net/paste/results/SBv6EH17.html Sep 19 06:05:07 let me try enabiling the second interface also Sep 19 06:06:31 your module seems ok, netdev apart... Sep 19 06:06:37 second interface? Sep 19 06:07:20 did you defined any CONFIG_XXX in _eth.c? Sep 19 06:07:47 #define CONFIG_IXP425_COMPONENT_ETHDB 1 Sep 19 06:07:57 ok Sep 19 06:08:11 this was the try 2 Sep 19 06:08:33 dot the same log Sep 19 06:08:51 define also CONFIG_ARCH_IXDP425 Sep 19 06:09:05 and CONFIG_IXP425_IXP_AS_ETH (for completeness) Sep 19 06:09:22 in _eth.c? Sep 19 06:09:31 yes Sep 19 06:11:06 03freyther 07org.openembedded.dev * r59667439... 10/ (23 files in 16 dirs): Sep 19 06:11:06 GNU cp has a nice -a switch, sadly the BSD tools lack it Sep 19 06:11:06 update our descriptions to work with any version of cp. Patches that include Sep 19 06:11:06 cp -a are not changed. They seem to work and I'm too scared busybox cp Sep 19 06:11:06 is more like GNU cp than BSD cp. (e.g do not know about P) Sep 19 06:11:08 03freyther 07org.openembedded.dev * rbe38e619... 10/packages/ (5 files in 4 dirs): Same GNU cp changes... Sep 19 06:11:11 03freyther 07org.openembedded.dev * r01581970... 10/packages/ (21 files in 21 dirs): Make cp invocations BSD compatible Sep 19 06:12:04 dwery: yea! hot a nice kernel memory dump when i issued ifconfig -a Sep 19 06:12:09 :D Sep 19 06:12:58 brb Sep 19 06:14:40 RX packets:0 errors:0 dropped:33554432 overruns:0 frame:0 Sep 19 06:14:45 strange. Sep 19 06:21:05 03rpurdie 07org.openembedded.dev * rfe605f84... 10/conf/distro/openzaurus-3.5.4.conf: openzaurus-3.5.4: Add hostap-modules-0.3.9 as the preferred version as 0.4.4 shows problems Sep 19 06:21:08 03rpurdie 07org.openembedded.dev * r9a1d8045... 10/packages/udev/ (udev-070/udev.rules udev_070.bb): udev: Enable firmware helper in udev to replace hotplug's firmware agent (fixes orinoco firmware issue). Sep 19 06:32:04 Keep up the good work you guys. I can say Im looking forward to the (happy) end result... Sep 19 06:32:59 dwery: does mii-tool detect your cable and when you unplug it? Sep 19 06:34:19 yvasilev: it seems it always give link ok Sep 19 06:34:25 i think Sep 19 06:34:26 <[g2]> ns2:~# mii-tool -w ixp0 Sep 19 06:34:26 <[g2]> 09:34:47 ixp0: negotiated 100baseTx-FD, link ok Sep 19 06:34:26 <[g2]> 09:34:57 ixp0: no link Sep 19 06:34:26 <[g2]> 09:35:02 ixp0: negotiated 100baseTx-FD, link ok Sep 19 06:34:46 <[g2]> this is with the v1.5 on a 2.4 kernel Sep 19 06:34:55 <[g2]> just as a data point Sep 19 06:35:27 [g2]: next time, first say that it is v1.5, THEN paste it , otherwise my heart will have serious injuries :) Sep 19 06:35:32 <[g2]> dwery yvasilev please let me know if I'm interrupting Sep 19 06:35:52 [g2]: no :) Sep 19 06:36:02 [g2]: how could you? ;-) Sep 19 06:36:08 [g2]: just kidding... i thought you were able to compile 2.0 Sep 19 06:36:10 :D Sep 19 06:36:54 <[g2]> there are several ppl following your great efforts Sep 19 06:37:15 thats why i'm feeling observed :D Sep 19 06:37:55 <[g2]> well I hope you feel supported and appreciated by the community Sep 19 06:37:57 yvasilev: i think i'll go back to square one and try to have it integrated in kbuild . I feel not all of the defines are set up correctly. Sep 19 06:38:01 [g2]: yes! Sep 19 06:38:07 hint: jump in into the fight ;-) Sep 19 06:38:07 thanks to you all guys Sep 19 06:38:29 truly speaking, a BE man would be useful Sep 19 06:39:06 <[g2]> there are several around Sep 19 06:39:17 dwery: the defines should probably propagate into ial, there is that module/confih for some reason Sep 19 06:41:04 03freyther 07org.openembedded.dev * r053ac8ef... 10/packages/ (2 files in 2 dirs): GNU cp the last missing files... all cp invocations should be BSD compatible now Sep 19 06:41:46 yvasilev: yes. i'll try to see how to generate it Sep 19 06:43:25 dwery: this is one example: http://rafb.net/paste/results/II8F0261.html Sep 19 06:45:20 yeah Sep 19 06:45:44 created the tree from scratch and applied snappewgear patches over it Sep 19 06:48:23 * yvasilev is getting better killing his kernel! Sep 19 06:49:02 :D Sep 19 06:52:07 bbl (work) Sep 19 07:03:28 anyone know how to use kconfig system to configure those modules? Sep 19 07:06:15 03koen 07org.openembedded.dev * rd8788b6b... 10/packages/rxvt-unicode/ (rxvt-unicode-5.6/xwc.patch rxvt-unicode_5.6.bb): packages/rxvt-unicode/ : add 5.6 + patch Sep 19 07:56:14 03koen 07org.openembedded.dev * r6b9abb15... 10/packages/ (3 files in 2 dirs): packages/gpe-themes/: move foxbox to here and add gpe-theme-clearlooks Sep 19 08:35:29 dwery: had any progress? Sep 19 08:39:21 yvasilev: nope Sep 19 08:39:39 i've generate, manually, a .config and an autoconf.h Sep 19 08:41:12 03koen 07org.openembedded.dev * r04a04d81... 10/packages/abiword/ (abiword-2.3.99/cdump-hack.patch abiword_2.3.99.bb): packages/abiword/: add 2.3.99 + patch Sep 19 08:42:03 Mean wile i am reviewing the code, and it looks like we may need to define CONFIG_IXP425_COMPONENT_ETHDB, the rest (including CONFIG_ARCH_IXDP425) is optional Sep 19 08:42:22 ok Sep 19 08:43:06 maybe we must check if this 2.0 stuff is used by someone else on other arm boards Sep 19 08:43:13 and it looks like it uses only IX_NPEDL_NPEIMAGE_NPEA_ETH and IX_NPEDL_NPEIMAGE_NPEB_ETH microcodes, so there should be no problem in choosing Sep 19 08:43:45 ack Sep 19 08:43:50 dwery: I had found that people where able to build 2.0 on mailing lists, but not the details Sep 19 08:44:05 and it was with montavista's Sep 19 08:44:31 I hope you'll have more luck finding something Sep 19 08:45:13 not yet Sep 19 08:54:51 ixp400_eth: Error reading MII reg 7 on phy 0 Sep 19 08:54:51 SIOCGMIIREG on eth0 failed: Operation not permitted Sep 19 08:54:51 eth0: negotiated 100baseT4 flow-control, link ok Sep 19 08:55:15 will have to check if that ioctl is supported Sep 19 08:56:23 supported, but ixEthAccMiiReadRtn fails. Sep 19 08:56:41 it seems the phy layers is not in a functional state Sep 19 08:59:37 could it be that NPEB/NPEC messes with PHY? (form working be 1.4 dmesg "ixp425_eth: npe0 is using the PHY at address 0" on our 2.0 "ixp400_eth: ixp0 is using NPEB and the PHY at address 0") Sep 19 09:02:33 i think the problem is the mapping between NPEs an PHYs Sep 19 09:02:56 i've just modprobed Sep 19 09:03:02 with no_phy_scan=0 Sep 19 09:03:08 and mii-tool works correctly Sep 19 09:03:51 this is defined strigth Sep 19 09:03:58 forward in static int phyAddresses[IXP425_ETH_ACC_MII_MAX_ADDR] = Sep 19 09:04:59 yes and no_phy_scan defaults to 1 Sep 19 09:05:06 and thus to that table Sep 19 09:06:12 03koen 07org.openembedded.dev * ra49f6a2c... 10/packages/minimix/minimix_0.8.bb: packages/minimix/: add aminimix_0.8.bb Sep 19 09:06:56 thre's at least a wrong comment inthat table Sep 19 09:07:54 the NPE that the slug uses should be NPEB Sep 19 09:08:51 but... read the comment on line 568 of _eth.c Sep 19 09:11:42 the correect mapping should be obtainable from the source of the current 1.4 driver. where can i get it? Sep 19 09:13:49 ehm.. 598 Sep 19 09:14:37 yes, that is wrong Sep 19 09:14:51 * yvasilev looking for 1.4 Sep 19 09:14:58 thanks :) Sep 19 09:15:06 no, that is Ok Sep 19 09:15:11 #ifdef CONFIG_IXP400_ETH_NPEC_ONLY Sep 19 09:15:21 which we should not have Sep 19 09:15:47 I have tried with and w/o Sep 19 09:16:19 but since no_phy_scan=0 gives a result, it seems some mapping is wrong Sep 19 09:17:09 http://www.intel.com/design/network/products/npfamily/ixp400_osc.htm Sep 19 09:17:21 the driver should be in v1.1 Sep 19 09:17:39 IntelĀ® IXP400 Software Linux Ethernet Device Driver v1.1 Sep 19 09:17:53 mm.. i would like to check the version that has been included in openslug.. Sep 19 09:18:09 to see if a patch has been added to correct such an issue Sep 19 09:20:01 there is ixp425_eth.c.patch Sep 19 09:20:34 http://nslu.sourceforge.net/downloads/ixp425_eth.c.patch Sep 19 09:23:08 there are also other patches in openembedded/packages/ixp425-eth/files/, do you have the repository or want me to send them to you? Sep 19 09:24:57 send them please :) Sep 19 09:25:01 but they do not look like they could help with phy working Sep 19 09:26:12 oh.. ok Sep 19 09:27:55 sent Sep 19 09:31:46 ixp400_eth: ixp0 is using NPEB and the PHY at address 1 Sep 19 09:31:47 ixp400_eth: Use default MAC address 00:02:b3:01:01:01 for port 0 Sep 19 09:32:04 since mii-tool is working, I suppose the PHY is correct. What do you think? Sep 19 09:32:56 [g2]: are you there? Sep 19 09:33:10 <[g2]> hello Sep 19 09:33:28 [g2]: I suppose you have schematics of your own board.... Sep 19 09:34:26 <[g2]> dwery it's a custom design, I can get access to the schematics if I need to Sep 19 09:34:53 [g2]: you have two ports iirc.. it would be interesting to know how thy're wired Sep 19 09:34:58 so, then " num_phys_to_set = (sizeof(default_phy_cfg) / sizeof(phy_cfg_t));" is the broken part, as it's the only thing that gets affected by no_phy_scan Sep 19 09:35:54 i think the configuration array is broken Sep 19 09:36:17 [g2]: may we have the messages you get when you load the driver, maybe with log_level=1 or 2? Sep 19 09:36:58 <[g2]> which driver 425_eth, 400 or both ? Sep 19 09:37:54 425_eth Sep 19 09:38:25 coffee break Sep 19 09:40:45 <[g2]> dwery the Redboot loader is running v1.5, it appears the current kernel is running an old version 1.2 Sep 19 09:41:16 <[g2]> the modutils/kernel aren't setup very well Sep 19 09:41:21 [g2]: v1.2 driver is for ial v1.5 Sep 19 09:41:36 <[g2]> cool :) Sep 19 09:42:20 <[g2]> ok... with the v1.2 I can rmmod the driver but when I insmod it I get an error in the init_module Sep 19 09:42:32 <[g2]> ixp425_eth: Error initialising queue manager! Sep 19 09:42:32 <[g2]> insmod: init_module: ixp425_eth: Operation not permitted Sep 19 09:43:17 rmmod ix400 Sep 19 09:43:23 dwery: can you tell me the output w/ and w/o no_phy_scan=0 after this patch http://rafb.net/paste/results/mmOjpD35.txt? Sep 19 09:44:17 <[g2]> dwery, Ok.. that worked Sep 19 09:46:49 yvasilev: just finished to try NPEC and PHY1, same results. Sep 19 09:47:00 yvasilev: i'm goin do add your path Sep 19 09:47:02 pathc Sep 19 09:48:44 well, when you scan you will always found both phys Sep 19 09:49:22 it looks like w/ no_phy_scan=0 phyAddresses gets redefined, there is where you can get the correct array (if the outout is 2 in both cases) Sep 19 09:50:30 <[g2]> http://www.giantshoulderinc.com/pastebin/v1.2-log-level1.txt Sep 19 09:51:56 [g2]: this is your board, right? Sep 19 09:52:02 <[g2]> yes Sep 19 09:52:07 <[g2]> Proto #1 Sep 19 09:52:15 <[g2]> both ethernets work Sep 19 09:52:17 [g2]: yes.. 600MHz :D Sep 19 09:52:26 <[g2]> 533 Sep 19 09:53:07 <[g2]> the original production build is/was targeted at 266 Sep 19 09:53:22 <[g2]> but that may changes it's simply a cost issue Sep 19 09:54:37 On http://www.nslu2-linux.org/wiki/OpenSlug/BootDirectlyToJffs2 it seems npe0 is using phy 0 Sep 19 09:54:47 do we have other boot logs? Sep 19 09:57:38 <[g2]> there are other boot logs around Sep 19 09:57:56 <[g2]> currently I'm working on getting the 2.6.11.12 running on the Loft Sep 19 09:57:59 dwery: with http://rafb.net/paste/results/biQJSS10.txt you can see how and if phyAddresses gets redefined Sep 19 09:58:52 ok Sep 19 10:00:14 [g2]: ok, thanks! Sep 19 10:00:28 <[g2]> dwery np Sep 19 10:00:36 <[g2]> I didn't do anything :) Sep 19 10:01:18 yvasilev: which CONFIG_ and which modprobe params do you want? Sep 19 10:02:47 the ones you are using, just one run with no_phy_scan=0 and one no_phy_scan=1 Sep 19 10:04:14 w/ no_phy_scan=1 -> 0 = 0, 1 = 1 Sep 19 10:06:20 w/ no_phy_scan=0, only 0 = 0 Sep 19 10:07:48 that's the problem, nslu has it's nic 2 diconected, so if the module enables second nic the phy layer dies/malfunctions Sep 19 10:09:18 lets redefine like http://rafb.net/paste/results/NIZoYo52.html, what do you think? Sep 19 10:10:41 with that patch, which NPE with which PHY will we get? Sep 19 10:11:51 B (I think) Sep 19 10:12:57 PHY 0 or 1? Sep 19 10:13:54 0 Sep 19 10:14:10 ok, i'll try Sep 19 10:14:33 and define CONFIG_ARCH_NSLU2 somewhere Sep 19 10:16:08 ok Sep 19 10:22:58 yvasilev: it configure both NPEs on PHY 0 :D Sep 19 10:23:27 does it have side effects? Sep 19 10:24:49 none that I have yet seen Sep 19 10:25:01 obviously the interface does not work :) Sep 19 10:25:17 maybe we should also use CONFIG_IXP400_ETH_NPEB_ONLY Sep 19 10:25:35 s:maybe:probably: Sep 19 10:25:49 i'll try that Sep 19 10:26:08 but this should be also cobfigured for ial Sep 19 10:27:32 no, ial has nothing to do with CONFIG_IXP400_ETH_NPEB_ONLY, my mistake Sep 19 10:27:55 I just noticed that snapgear patch has also a configuration Sep 19 10:28:35 in vendors/Intel/IXDP425 Sep 19 10:29:42 bbl Sep 19 10:51:11 03koen 07org.openembedded.dev * r38436245... 10/packages/gpe-themes/gpe-theme-clearlooks_0.2.bb: packages/gpe-themes/gpe-theme-clearlooks_0.2.bb: fix (R)DEPENDS Sep 19 10:52:44 results so far: Sep 19 10:52:55 datapath_polling must be 0 otherwise my kernel crashes Sep 19 10:53:14 the working phy seems to be PHY1 because mii-tool works with it. Sep 19 10:53:30 given the log of other nslus it seems it should have been PHY0 Sep 19 10:54:06 Tried almost every combination of NPEs and PHYs Sep 19 10:54:26 i accept suggestions on what to try next... Sep 19 10:58:32 dinner's time... se ya Sep 19 11:35:25 back Sep 19 11:35:40 me too Sep 19 11:37:11 don't know how to proceed :) Sep 19 11:38:41 dwery: do you have any idea if the mii interface works true microcode or independently of that? Sep 19 11:39:17 so we know if microcode works and it's modules fault or the other way around? Sep 19 11:40:41 yvasilev: no idea. i'll give a quick look Sep 19 11:43:11 i believe it to be indipendent Sep 19 11:44:38 not good, do you have an idea about how could we test if npe works? Sep 19 11:45:15 no :( Sep 19 11:48:30 were you able to insert the module on your slug? Sep 19 11:49:22 have not tried it any more as I now only have remote access to it, so it'll be just one try and no more Sep 19 11:50:06 oh :) Sep 19 11:50:26 Jacmet: still there? Sep 19 11:54:13 dwery: so to get it right, you got ixp0/eth0 in ifconfig -a, mii-tool works, but can't send/receive packates, right? and does changing parameters with ifconfig (setting ip and so) work? Sep 19 11:55:22 yes Sep 19 11:56:04 mii-tool works fine only on th einterface associated to PHY1 Sep 19 11:58:57 could you add some verbosity to the module, so you know when it get interrupts and send packets to it's ip and see if events are generated form the network? Sep 19 12:01:09 03koen 07org.openembedded.dev * re1286bc9... 10/packages/gpe-themes/gpe-theme-clearlooks_0.2.bb: packages/gpe-themes/gpe-theme-clearlooks_0.2.bb: gtk-engines provides gtk-engine-clearlooks, but gtk-clearlooks-engine provides something else. g-c-e is obsolete, so let's depend on g-e and rdepends on g-e-c Sep 19 12:01:12 03koen 07org.openembedded.dev * rf6961b68... 10/packages/gpe-themes/gpe-theme-clearlooks_0.2.bb: packages/gpe-themes/gpe-theme-clearlooks_0.2.bb: bump PR after rdepend changes Sep 19 12:01:35 also, can you ping yourself over that interface? Sep 19 12:02:09 no, I cant ping myself Sep 19 12:02:19 i'll see where to add verbosity Sep 19 12:09:16 mmmmm Sep 19 12:09:17 qmgr Sep 19 12:09:23 seems to handl the ints Sep 19 12:15:53 the isr can be either called from a PMU timer, as in the default option, or by an int on each packet. Sep 19 12:16:01 the second option will crash my machine. Sep 19 12:18:53 dwery: what is isr? Sep 19 12:19:11 found Sep 19 12:19:24 :) Sep 19 12:19:30 the interrupt seems to be IXP425_INT_LVL_QM1 Sep 19 12:21:04 03koen 07org.openembedded.dev * r77d8debc... 10/packages/meta/meta-gpe.bb: packages/meta/meta-gpe.bb: add gpesyncd to gpe-task-pim Sep 19 12:22:12 while the PMU int is IXP425_INT_LVL_XSCALE_PMU Sep 19 12:23:08 i think the pmu is used by the kernel. i'm going to check that. Sep 19 12:25:25 I can;t fined where IXP425_INT_LVL_XSCALE_PMU is defined... Sep 19 12:25:58 yes, this looks like it, i gave CONFIG_XSCALE_PMU=y Sep 19 12:26:07 in .config Sep 19 12:27:56 no, there is an CONFIG_XSCALE_PMU_TIMER and it's not defined, no the name difference is probably ok Sep 19 12:29:40 mmm... Sep 19 12:29:57 dwery: not necessarily :-| Sep 19 12:30:26 yvasilev: I i can find the definition i'll check the code Sep 19 12:30:39 this is the relevan part: http://rafb.net/paste/results/zL0kBz13.html Sep 19 12:31:07 if you do a menuconfig Sep 19 12:31:16 you will notice that option will not be proposed to you Sep 19 12:31:25 and the CONFIG_XX will always be enabled Sep 19 12:31:30 if you change it manually Sep 19 12:31:46 in the .config Sep 19 12:31:47 this is the only mention about CONFIG_XSCALE_PMU_TIMER Sep 19 12:31:58 it will be reactivated. Sep 19 12:32:04 I want to find the interrupt definition Sep 19 12:32:09 ans see if it's used somewhere Sep 19 12:34:48 QM1 is interrupt 3 Sep 19 12:35:19 PMU is 18 Sep 19 12:37:13 IRQ_IXP4XX_QM1 Sep 19 12:37:28 IRQ_IXP4XX_XSCALE_PMU Sep 19 12:37:44 no please give me those intel engineer who has still to learn touse defines... Sep 19 12:38:51 ./arch/arm/oprofile/op_model_xscale.c Sep 19 12:39:05 * yvasilev looking :-) Sep 19 12:39:25 seems the only place in the kernel wher it is used Sep 19 12:39:36 but i think oprofile is disabled in our build. Sep 19 12:40:48 / Sep 19 12:43:01 do I understand correctly that if this will be enabled in kernel, the _eth module will not be able to trap into this PMU thing (I guess some king of very fast periodic irq)? Sep 19 12:43:40 * yvasilev knows very little about the kernel (among many other things) Sep 19 12:43:48 yes. actually, not very fast probably. at least, slower that one interrupt per packet. Sep 19 12:44:12 but since the kernel seems not using it, using PMU in _eht should be fine. Sep 19 12:44:52 yes, I also have not built it into the kernel Sep 19 12:45:18 ok Sep 19 12:46:46 the fact is, that when eth tries to enable pmu, the slug oopses Sep 19 12:47:00 and without it, we do not receive anything. Sep 19 12:47:36 then looks like we know where is the problem Sep 19 12:48:43 s/the/a/ :D Sep 19 12:49:04 details :-P Sep 19 12:53:33 the driver requests QM1 Sep 19 12:53:51 and the ISR is dev_qmgr_os_isr Sep 19 12:54:01 request_irq(IX_OSAL_IXP400_XSCALE_PMU_IRQ_LVL) is it the same thing as QM1? Sep 19 12:54:12 no Sep 19 12:54:24 that one is PMU int Sep 19 12:54:44 the PMU int Sep 19 12:54:49 with ISR dev_poll_os_isr is requested Sep 19 12:55:20 when datapath_poll == 1, the default. Sep 19 12:55:46 this seems to be an option Sep 19 12:55:55 but a note in the beginning of the file Sep 19 12:56:08 does not agree. Sep 19 12:57:54 you lost me Sep 19 12:59:01 dev_qmgr_os_isr gets called on ISR iterrups or on PMU ones? Sep 19 13:00:06 QM1 ints call dev_qmgr_os_isr, PMU ints call dev_poll_os_isr Sep 19 13:00:40 ISR -> Interrupt Service Routine, Sep 19 13:01:02 . Sep 19 13:01:39 ok, yes, thanks Sep 19 13:02:16 i guess i have to tap into those routines Sep 19 13:02:31 PMU -> Performance Monitoring Unit. what are you doing with that? Sep 19 13:03:30 bullet: nothing :) Sep 19 13:03:38 mkay Sep 19 13:03:39 but the driver wants to use it :) Sep 19 13:07:08 don't know how to debug the functions.. dev_qmgr_os_isr gets called "a few thousand times per second" Sep 19 13:08:04 dwery: there is one that is called every 60 secs, you can as a counter to dev_qmgr_os_isr and read it form the other one ;-) Sep 19 13:10:21 http://www.nslu2-linux.org/wiki/OpenSlug/EnableNetconsole Sep 19 13:10:31 if foun that link in the file you sent me via email Sep 19 13:11:11 it seems someone worked on those same problems Sep 19 13:11:17 03hrw 07org.openembedded.dev * r94d63e09... 10/packages/qte/ (qte-2.3.10/fix-native-build.patch qte_2.3.10.bb): Sep 19 13:11:17 qt/e 2.3.10: changes for MACHINE="native": Sep 19 13:11:17 - patch to fix build Sep 19 13:11:17 - enabled QVFb support Sep 19 13:11:17 With that changes it is possible to run OPIE/OE in QVFb/X11. Sep 19 13:12:17 the patches you sent me are interesting :) Sep 19 13:15:36 do you have the original ixp425_eth.c ? Sep 19 13:22:15 <[g2]> beewoolie, HEY! Sep 19 13:23:19 yvasilev: are you there? Sep 19 13:24:38 yes Sep 19 13:25:48 did you gave a loo at the patch? Sep 19 13:26:04 the netconsole one? Sep 19 13:26:10 no.. the one related to the int Sep 19 13:26:57 intdriven.patch Sep 19 13:27:05 loocking again Sep 19 13:28:32 ok, yes, locks related, what does SA_SAMPLE_RANDOM mean? Sep 19 13:28:54 don;t know, bu if it's there, i'll do the same thing :) Sep 19 13:29:04 actualy it is #if 0'ed Sep 19 13:29:08 I would need anunpatched ixp425_eth.c Sep 19 13:29:17 to examine the the differences. Sep 19 13:29:23 do you have one at handy? Sep 19 13:29:30 sending Sep 19 13:29:44 thanks Sep 19 13:30:23 "http://www.intel.com/design/network/swsup/ixp400LinuxEthernetDriverPatch-1_1.zip Sep 19 13:31:54 it's inside this zip Sep 19 13:32:39 ok thanks Sep 19 13:37:57 just sent you another patch that needs to be applied before that one, with ixp425_eth.c.patch I sent you earlier Sep 19 13:39:15 thanks Sep 19 13:40:01 it seems datapath_poll_setup has been completly disabled in 425 Sep 19 13:40:41 which is what the datapath_poll = 0 option do Sep 19 13:40:56 does that option work for you? Sep 19 13:43:08 if I don't use it, the kernel crashes a few millisecs after modprobe. Sep 19 13:49:01 tried no_csr_init=1? (this will be like the other #if 0) Sep 19 13:49:43 who was needing to get in touch with kas11? Sep 19 13:50:22 ByronT: me Sep 19 13:50:39 yvasilev: have to check that Sep 19 13:50:39 kas11 is in #openslug Sep 19 13:50:46 ByronT: thanks Sep 19 13:50:55 sorry, #openjtag Sep 19 13:50:59 not #openslug Sep 19 13:51:01 heh Sep 19 14:02:16 yvasilev: comparing the files... nothing useful :( Sep 19 14:02:23 :-( Sep 19 14:03:16 there is also that SA_SHIRQ -> SA_SHIRQ | SA_SAMPLE_RANDOM, does it make any sense to you? Sep 19 14:03:32 no.. but let's try anyway... Sep 19 14:16:13 03hrw 07org.openembedded.dev * rd9213f68... 10/packages/opie-pimconverter/ (3 files): opie-pimconverter: fixed dependency on both SQLite versions Sep 19 14:17:33 yvasilev: tried. nothin. packets are not being sent on the wire Sep 19 14:17:56 dwery: going back one some steps, what are your BI_ENDIAN_COMPONENTS? Sep 19 14:19:22 and can you test if dev_qmgr_os_isr is getting called by the interrupt, because if it is, it looks to me that something in ial is not working Sep 19 14:19:25 oslinux qmgr npeMh npeDl ethAcc ethDB ethMii featureCtrl Sep 19 14:19:35 yvasilev: going to test that Sep 19 14:20:46 which debugging functions can be used in interrupts? Sep 19 14:21:15 you can do it with a counter Sep 19 14:21:31 ok Sep 19 14:22:56 and print it in cleanup_module Sep 19 14:28:32 compiling Sep 19 14:29:09 given that stats in the ifconfig output do not change, i think there's a whole IAL problem here.. Sep 19 14:29:29 but you can set ip? Sep 19 14:30:53 yes Sep 19 14:36:54 yvasilev: always 0 Sep 19 14:37:05 not good Sep 19 14:37:26 is there any nslu2 specific path for the old ial? Sep 19 14:38:46 dwery: please verify what I manage to understand about how things work: Sep 19 14:39:26 1) dev_poll_os_isr is never called/registered, else you get kernel crashes Sep 19 14:40:00 yes. Sep 19 14:40:29 2) dev_qmgr_os_isr calls the dispatcherFunc wich i had not found a place where it substituted dummies for real functions Sep 19 14:41:09 03hrw 07org.openembedded.dev * r0f9c1705... 10/packages/meta/meta-opie.bb: meta-opie: cleaned dependencies on openobex Sep 19 14:41:20 ixQMgrDispatcherLoopGet (&dispatcherFunc); Sep 19 14:41:27 3) the two obvious functions to do some real network transfers are ixEthRxFrameQMCallback and ixEthTxFrameDoneQMCallback Sep 19 14:41:36 yes Sep 19 14:42:16 if I understan correctly ixQMgrDispatcherLoopGet (&dispatcherFunc); initializes dispatcherFunc, but does not register anything useful Sep 19 14:42:43 dispatcherFunc is a function from IAL Sep 19 14:42:53 that call asks IAL to give backa pointer Sep 19 14:43:02 the funcs at point 3 Sep 19 14:43:20 are called from within the isr under pmu control Sep 19 14:43:22 4) the functions from (3) are only called/mentioned in dev_poll_os_isr which is never called because of (1) Sep 19 14:44:53 given that the old driver works this way Sep 19 14:45:05 probably the direct call of those two funcs Sep 19 14:45:10 is only an optimization. Sep 19 14:45:59 * dwery thinks the driver is ok and that IAL does something nasty :) Sep 19 14:46:22 yes, I agree Sep 19 14:47:53 so we need to track where (3) funcs are called form ial's default queue, and also make the driver enter that interrupt (remember that you where getting 0 in the counter) Sep 19 14:48:17 so the driver is not completely ok Sep 19 14:48:42 the driver does not receive interrupts Sep 19 14:48:53 probably because IAL has not enabled them in the chip Sep 19 14:51:03 IXP425_INT_LVL_QM1 interrupt should be called only on hardware interrupts, or should it be something periodic and independent form the eth logic? Sep 19 14:51:37 QM is the queue manager. i think is something embedded in the chip or something very close Sep 19 14:51:52 it shold be called Sep 19 14:52:02 only when a packet is received Sep 19 14:52:23 ah, I had wrong that part Sep 19 14:54:24 I really have not deep knowledge on the ixp4xx Sep 19 14:54:33 maybe [g2] Sep 19 14:54:43 <[g2]> what that ? Sep 19 14:54:47 <[g2]> what's that ? Sep 19 14:55:25 do you have any info on how the inner networking things of the ixp4xx work? Sep 19 14:55:41 <[g2]> glancing back, the driver runs in either a polled mode or an interrupt mode Sep 19 14:56:04 [g2]: yes. we are forcing it to interrupt mode right now. Sep 19 14:56:14 [g2]: but interrupts are not coming. Sep 19 14:56:42 <[g2]> did you guys look at the patches applied by the openslug build at all ? Sep 19 14:56:56 <[g2]> when building the ixp4xx and ixp425_eth modules Sep 19 14:57:18 yes Sep 19 14:57:25 <[g2]> which interrupt are you mapped to ? Sep 19 14:57:29 QM1 Sep 19 14:57:51 <[g2]> well there are GPIOs and INTs Sep 19 14:58:01 [g2]: open slugs patch also disables polling Sep 19 14:58:31 <[g2]> yvasilev I think I'm the one who checked that in Sep 19 14:58:43 [g2]: :D Sep 19 14:58:47 :-) Sep 19 14:59:02 <[g2]> I think geil made it work first with the netconsole stuff but my memory may be fuzzy Sep 19 15:00:00 <[g2]> I've been getting my stuff together for the Loft Sep 19 15:00:18 <[g2]> I'm booting 2.6.11.12 Sep 19 15:00:40 2.6.11.12? Sep 19 15:00:44 <[g2]> I don't have the ide driver forward ported, but I did add eth e1000 Sep 19 15:00:51 <[g2]> e1000 Sep 19 15:01:17 <[g2]> it's a miniPCI so I should be able to mount a nfs debian root Sep 19 15:01:52 <[g2]> then I'll start playing with adding the ixp400/ixp425 modules Sep 19 15:02:04 <[g2]> actually, I may boot to jffs2 first Sep 19 15:02:11 there is actually an easy way to verify, [g2] could you compile the patch with the counter thing and run it once with no net activity and another time running something like several ping -f -b x.x.x.255 and see if there is a noticeable difference? Sep 19 15:02:47 yvasilev: [g2] isnot runing IAL 2.0 i think Sep 19 15:02:59 it should be the same Sep 19 15:03:36 the driver logic had not changed much from 1.4, so with 1.5 should be about in the middle Sep 19 15:04:13 yvasilev: since 1.4 is working, i really suppose it's getting interrupts :) Sep 19 15:05:10 the question is how many is it getting, the promised 4000/s or just 1/packet Sep 19 15:06:03 may I have a cat /proc/interrupts on an opensglub based slug? Sep 19 15:06:34 <[g2]> well I'll probably start with version 1.4 then move to 1.5 Sep 19 15:08:09 my cat is here : http://rafb.net/paste/results/H3t0kI93.html Sep 19 15:08:21 [g2]: even on your loft could be useful Sep 19 15:09:02 <[g2]> dwery what's that ? Sep 19 15:09:27 dwery: ok, that confirms it, [g2] just ignore my request ;-) Sep 19 15:09:34 <[g2]> the /proc/interrupts ? Sep 19 15:09:41 show requested interrupts Sep 19 15:09:47 and their counters Sep 19 15:10:02 <[g2]> On the loft I don't have a 2.6 rootfs running yet Sep 19 15:10:16 <[g2]> I'm sure you don't care about the 2.4 kernel Sep 19 15:10:19 oops :) Sep 19 15:10:24 anyone with a slug here? Sep 19 15:10:27 <[g2]> I'm getting very close Sep 19 15:10:32 dwery: several Sep 19 15:10:36 <[g2]> and I do have an openslug Sep 19 15:10:53 okey, someone please do a cat /proc/interrupt Sep 19 15:10:54 :) Sep 19 15:11:45 <[g2]> you guys do much nfs root mounting ? Sep 19 15:11:57 [g2]: only once in my entire life :) Sep 19 15:12:10 http://rafb.net/paste/results/ATHIkj32.html Sep 19 15:12:11 <[g2]> that's one more than me :) Sep 19 15:12:22 [g2]: ans I was young! :D Sep 19 15:12:35 <[g2]> ok.... I've done some LTSP boots but they don't count Sep 19 15:12:40 dwery: It's been up for 8+ days, so there's a fair bit of interrupts ;) Sep 19 15:12:52 NAiL: I noticed :) thanks! Sep 19 15:13:00 ok, 1.4 was getting interrupts. Sep 19 15:13:16 np Sep 19 15:13:45 [g2]: I usually run things form nfsroots Sep 19 15:14:13 <[g2]> yvasilev what's the cmdline look like ? Sep 19 15:14:26 ok, what's the number of the Intel's IAL hotline? :-D Sep 19 15:15:05 NAiL: you have eth0 and eth1, isn't it? Sep 19 15:15:22 dwery: yeah, but eth1 doesn't work Sep 19 15:15:23 oot=/dev/nfs nfsroot=192.168.81.3:/var/exports/softgun/root,rw,sync,dirsync,rsize=8192,wsize=8192,hard,intr,tcp,nolock ip=192.168.81.10::192.168.81.3:255.255.255.0:softgun:eth1: Sep 19 15:15:45 s/oot/root/ Sep 19 15:15:51 <[g2]> ok.. thx Sep 19 15:16:27 fear me, for I am oot! Sep 19 15:16:31 NAiL: ok, that I wanted to know. Sep 19 15:16:38 NAiL: do you have mii-tool ? Sep 19 15:16:41 I have written a howto for nfs booting softgun with more info: http://gentoo-wiki.com/HOWTO_Softgun_ARM_Emulator Sep 19 15:16:42 nope Sep 19 15:16:59 <[g2]> yvasilev, is it ip=x.x.x.x:: ? Sep 19 15:17:34 <[g2]> yvasilev, THX Sep 19 15:17:37 <[g2]> dinner time Sep 19 15:17:39 192.168.81.10 you, 192.168.81.3 server Sep 19 15:17:39 <[g2]> bbiab Sep 19 15:17:58 <[g2]> i figured that I'm just asking if the first is :: Sep 19 15:18:09 yes Sep 19 15:18:13 <[g2]> Excellent... Sep 19 15:18:19 <[g2]> I'll try it after dinner Sep 19 15:18:45 dwery: If you have an armeb binary somewhere I can download I can test Sep 19 15:19:43 NAiL: I don't think so.. yvasilev? Sep 19 15:20:21 no, but we (specially dwery) can guide you into creating one ;-) Sep 19 15:20:35 :D Sep 19 15:20:40 compiling, two sec Sep 19 15:20:46 urgh Sep 19 15:20:49 NAiL: wow, thanks :) Sep 19 15:20:53 :-) Sep 19 15:21:06 http://rafb.net/paste/results/cinrgU80.html Sep 19 15:21:37 isn;'t there an openslug package with it? Sep 19 15:21:54 nope, atleast not yet :P Sep 19 15:22:04 SIOCGMIIREG on eth0 failed: Operation not permitted Sep 19 15:22:09 eth0: negotiated 100baseT4 flow-control, link ok Sep 19 15:22:09 eth1: negotiated 100baseTx-FD, link ok Sep 19 15:22:21 heh... link ok on eth1? Interesting :P Sep 19 15:22:34 :) Sep 19 15:22:40 what if you disconnect the cable? Sep 19 15:22:54 heh, I don't have serial on that slug Sep 19 15:23:19 argh. Sep 19 15:23:41 NAiL: if you gace screen or nohup you can roon it timed (sleep 10), and see ofter you reconect Sep 19 15:23:52 s/gace/have/ Sep 19 15:24:01 I was suggesting the same thing :) Sep 19 15:24:09 yeah, can do Sep 19 15:24:19 did -v: http://rafb.net/paste/results/siGkxh89.html Sep 19 15:24:53 gotta install screen first :P Sep 19 15:24:53 yea! I was at time faster than dwery!!! :-D Sep 19 15:25:23 :-D Sep 19 15:26:19 ok, screen running.. should give me useful output in a couple of secs Sep 19 15:26:29 yvasilev: I was unable to remember the shell command to wait a specific amount of time.. so i tried wait and delay on a bash before seeing your message :) Sep 19 15:26:57 odd Sep 19 15:26:58 http://rafb.net/paste/results/MsmyBT19.html Sep 19 15:27:24 http://rafb.net/paste/results/pu4WTL95.html Sep 19 15:27:43 eth0 claims link is ok with cable disconnected Sep 19 15:27:48 LOL Sep 19 15:27:48 but eth0 is the interface I use Sep 19 15:27:59 eth1 says no link though... Sep 19 15:28:11 so it's eth0 the one that detects the link :-S Sep 19 15:28:11 odd but at least consistent to what I'm obtaining Sep 19 15:28:22 brb Sep 19 15:28:23 ok, IAL has more than onebug:) Sep 19 15:28:38 in more than one version ;-) Sep 19 15:29:07 * NAiL isn't surprised :P Sep 19 15:29:17 they should opensource the whole thing ;) Sep 19 15:29:53 argh... "make setup" doesn't create topdir.conf Sep 19 15:30:58 LE was introduced in 2.0 or 1.5? Sep 19 15:31:22 2.0 iirc Sep 19 16:52:34 bye all... Sep 19 17:31:11 03nail 07org.openembedded.dev * rec6809b2... 10/packages/linux/ (2 files in 2 dirs): nslu2-kernel: Add "disk_led_blinking.patch", to enable disk1/disk2 leds. Sep 19 18:16:09 03nail 07org.openembedded.dev * r7ee33083... 10/packages/meta/openslug-image.bb: openslug-image: Add udev. With udev_070 it works like it's supposed to Sep 19 19:05:49 rwhitby: more packages coming soon Sep 19 21:30:55 <[g2]> rwhitby you wanted to talk about upstream kernel changes ? Sep 19 21:32:38 Yep, you said there were three things needed ... Sep 19 21:32:44 dwery is working on the RTC Sep 19 21:32:49 what are the other two? Sep 19 21:33:09 <[g2]> The other changes are NSLU2 specific Sep 19 21:33:20 <[g2]> some general, some really specific Sep 19 21:34:06 <[g2]> I've been working from the 2.6.11.12 aggregated patchset that Jacmet, dwery and yvasilev have been playing with some Sep 19 21:35:49 OK, is everyone aware of the list of requirements that Lennert sent to nslu2-developers, that need to be done before the patches have any hope of upstream acceptance? Sep 19 21:38:19 <[g2]> I've got an old e-mail from Lennert Sep 19 21:38:31 <[g2]> it's got extensive commments in it Sep 19 21:38:56 <[g2]> he may want to sanitize it a little Sep 19 21:39:05 Is that the one that Lennert mailed to nslu2-developers? Sep 19 21:39:16 <[g2]> quite possibly Sep 19 21:39:23 <[g2]> I'll check the list Sep 19 21:39:42 http://groups.yahoo.com/group/nslu2-developers/message/33 Sep 19 21:40:17 <[g2]> was just reading that's the summary of the issues Sep 19 21:41:21 and then dwery has started work on that list: http://groups.yahoo.com/group/nslu2-developers/message/37 Sep 19 21:42:01 So we need to get those into monotone, and work on Lennert's list in place ... Sep 19 21:42:31 [g2]: ping Sep 19 21:43:29 actually, some be guy: ping Sep 19 21:43:36 <[g2]> yvasilev pong Sep 19 21:43:36 * yvasilev needs some help Sep 19 21:44:01 <[g2]> rwhitby those are recycled OE patches Sep 19 21:44:08 [g2]: do you have acess to a 2.6.x running be slug? Sep 19 21:44:26 <[g2]> yvasilev I can boot one in 30 seconds Sep 19 21:44:39 I'm (almost) shure I found the bud Sep 19 21:44:52 <[g2]> cool! Sep 19 21:45:02 could you compile and tun be module, Sep 19 21:45:05 2.0 Sep 19 21:45:52 <[g2]> ? Sep 19 21:45:59 you'll need IPL_ixp400AccessLibrary-2_0.zip, IPL_ixp400NpeLibrary-2_0.zip and snapgear-modules-20050914.sh Sep 19 21:46:10 s/tun/run Sep 19 21:47:43 <[g2]> yvasilev I'm not really setup right now to test the 2.0 libs Sep 19 21:47:45 [g2]: yes, dwery has done the first step (organise them in the way that upstream kernel maintainers like them) Sep 19 21:48:32 [g2]: it's just a quick compile and a couple of insmods ;-) Sep 19 21:48:56 [g2]: and he also changed the -timer, -setup and -io to complete at least one of the items on Lennert's list. So they are a definite step forware. Sep 19 21:48:58 forward. Sep 19 21:48:58 <[g2]> well the loft covers many similar changes Sep 19 21:49:05 if i'm correct, it should work out of the box Sep 19 21:49:20 [g2]: no - let's get you and dwery working together on them instead of duplicating effort then :-) Sep 19 21:49:27 s/no/nod/ Sep 19 21:49:39 rwhitby: another 15-20 packages uploading now Sep 19 21:49:45 <[g2]> rwhitby I'm just about done Sep 19 21:49:53 <[g2]> it's clean up time Sep 19 21:50:08 <[g2]> I've only got 431 lines of patches total Sep 19 21:50:17 [g2]: have you completed all the items on Lennert's list already? You are the MAN! Sep 19 21:50:53 [g2]: and the nslu2 should be identical to your boars with respect to this module Sep 19 21:50:54 <[g2]> not yet, but I don't think it'll take that long to clean up a few hunderd lines Sep 19 21:51:19 else, I need a be volunteer! Sep 19 21:51:34 anyone have any experience with linux on ip27? Sep 19 21:51:41 [g2]: we need to make sure that you and dwery are not doing the same "cleanup" then Sep 19 21:52:05 <[g2]> yvasilev I'd _love_ to try the changes but I'm working on the board I got just this last Friday. Sep 19 21:52:20 [g2]: and is the loft set going into monotone to replace the existing ones there? Or are we diverging into a separate Loft repo? Sep 19 21:52:22 [g2]: ok, no problem Sep 19 21:52:36 <[g2]> It's the 1st board after several months Sep 19 21:53:26 <[g2]> right now I've got to forward port 1 module and prepare to push these kernel changes upstream Sep 19 21:53:35 [g2]: i.e. are you and dwery both working on nslu2 kernel patches to replace the existing set in OE monotone nslu2-kernel dir? Or are you doing a separate set for Loft (in which case dwery needs to keep going on the nslu2 set) ? Sep 19 21:54:34 <[g2]> rwhitby the changes between the Loft and the NSLU2 for these 12 files are pretty much all cookie cutter Sep 19 21:55:01 <[g2]> the platform will diverge a bunch from there Sep 19 21:55:03 [g2]: i.e. in the (at least) couple of months it will take to get patches accepted upstream, and released into a kernel version that we use, will we have two sets of patches, or will there be one set of patches that lives in the OE monotone repo which are used for both nslu2 and Loft ? Sep 19 21:55:45 (i.e. will *you* be checking the patches that you are pushing upstream into the OE monotone repo before you push them upstream?) Sep 19 21:55:58 (so that dwery can start from those instead) Sep 19 21:56:03 <[g2]> rwhitby with the emergence of OpenDebianSlug, having a separate set of kernel patches became much more imporant Sep 19 21:56:51 fully agree with that. Where does that single set of ixp425 nslu2/Loft patches (some generic, some specific to the board) live? Is it in your business's repo, or is it in the OE monotone repo? Sep 19 21:56:57 <[g2]> I think the debonaras work and ODS is 99% independent of the nslu2-linux/monotone build Sep 19 21:57:27 <[g2]> the NSLU2 and Loft are different machine ids Sep 19 21:57:48 <[g2]> so they are two separate sets Sep 19 21:58:08 I ask again. Where are those patches going to be stored, so that people working on Unslung/OpenSlug/OpenDebianSlug/LoftOS/Debian-armeb/Whatever can all use the subset ? Sep 19 21:58:17 <[g2]> the Loft happens to be much closer to the IXP425 reference and there's not very much baggage Sep 19 21:58:52 <[g2]> I'll be posting the Loft's changes on www.giantshoulderinc.com Sep 19 21:58:58 [g2]: is there going to be a common repo for the Loft and NSLU2 patches, or not? Sep 19 21:59:16 <[g2]> yeah the arm-linux-kernel Sep 19 21:59:40 <[g2]> they are two sub arches in the mach-ixp4xx Sep 19 22:00:49 yes, that will be the resting place when the patches are accepted upstream. Sep 19 22:01:34 where do they live in the meantime (which could be easily 6 months) Sep 19 22:02:26 Will there be a common single repo, where Loft and NSLU2 patches co-reside (so that anything in common can be shared and worked on together), or will there not? Sep 19 22:02:58 <[g2]> the platforms are divergent Sep 19 22:03:21 <[g2]> however, they start with 40% overlap Sep 19 22:03:45 <[g2]> and the changes submitted upstream can be identical but unique to the platform Sep 19 22:03:48 Will there be a common single repo, where Loft and NSLU2 patches co-reside (so that anything in common can be shared and worked on together), or will there not? Sep 19 22:05:42 <[g2]> well they will not be because there won't really be a repo for the Loft Sep 19 22:06:09 <[g2]> it's just kernel changes, Redboot/APEX, and the unofficial Debian rootfs Sep 19 22:06:31 ok, what repo will the kernel changes be checked into? Sep 19 22:06:33 <[g2]> since all the kernel changes are going upstream, in the meantime is a simple patchset Sep 19 22:06:44 03bzhou * 10unslung/ (make/git-core.mk sources/git-core/Makefile.patch): upstream upgrade from 0.99.4 to 0.99.7 Sep 19 22:07:15 <[g2]> I'm saying that I have no need to have the Loft kernel patches in a repo Sep 19 22:07:18 03bzhou * 10unslung/make/cogito.mk: upstream upgrade from 0.13 to 0.15 Sep 19 22:07:34 <[g2]> they'll just be on the my web site Sep 19 22:07:49 You may not have a need, but nslu2-linux has a need to not duplicate effort on patches for the nslu2 kernel. Sep 19 22:08:45 <[g2]> right that's exactly why I'm doing those changes first, to be able to make the same changes for NSLU2 if desired and check those into the nslu2 repo Sep 19 22:09:03 <[g2]> that get nslu2 40% of the way there Sep 19 22:09:10 <[g2]> it's a process Sep 19 22:09:12 OK, but dwery is also doing the same thing at the moment. Sep 19 22:09:53 <[g2]> yeah and there 250 machine Ids for ARM in the last 1.5 years... Lots of people are doing it Sep 19 22:10:39 Right, but those people are not part of the nslu2-linux community, so they have an excuse to not cooperate. We have scarce resources and need to build upon each other's work, not duplicate effort. Sep 19 22:10:44 <[g2]> we clearly need to communicate with one another and not duplicate work Sep 19 22:11:01 <[g2]> but somethimes that'll happen Sep 19 22:11:03 Excellent. Thanks. Sep 19 22:14:25 I have posted a summary to nslu2-developers, so everyone knows what the plan is. Sep 19 22:15:12 But it would be much easier if you had a public repo (or just used the OE repo) for the Loft changes ... Sep 19 22:21:50 Jacmet: we need to somehow get your http://peter.korsgaard.com/articles/openslug1.2-2.6.11.12.patch into this process of rationalisation of NSLU2 kernel patches for upstream too ... Sep 19 22:21:55 <[g2]> rwhitby-web, I've only been working on the Loft specific stuff or like 72 hours now Sep 19 22:22:13 <[g2]> I've done the dry-run before on the old Avila board Sep 19 22:22:21 [g2]: All the better - start off with the patches in the right place ;-) Sep 19 22:22:39 <[g2]> and the right place is the upstream kernel Sep 19 22:22:48 <[g2]> that's what I'm preparing Sep 19 22:23:03 <[g2]> all 400/500 lines of it Sep 19 22:23:25 NO!!!!!!!!!!!!!! I am talking about BEFORE it goes upstream. Sep 19 22:23:39 (and until it comes *BACK* from upstream) Sep 19 22:23:50 How can I make that more clear? Sep 19 22:24:45 <[g2]> rwhitby-web, Are you saying I should hold up the Loft specific changes ? Sep 19 22:25:43 No. Sep 19 22:25:52 <[g2]> well that's all I'm talking about Sep 19 22:26:20 <[g2]> so I'm confused Sep 19 22:26:24 I'm requesting (and it's just that - you are free to do what you want as giantshoulderinc) that you develop that patchset in a common repo with nslu2-linux so that others can build upon it in-place. Sep 19 22:26:51 and structure it in many small patches so that those that are common with nslu2 can be used in-place Sep 19 22:27:31 and gain the benefit of Lennert and others reviewing your patches before you send them off (if you so desire) Sep 19 22:27:58 but not letting nslu2-linux hold up or impede your business plans for getting Loft kernel patches upstream Sep 19 22:30:03 From day one in nslu2-linux, we have kept our source code in publicly-readable (and trusted-developer-writeable) repositories, and we have reaped the FOSS reward for doing that. I'm at a loss to understand why you are diverging from that principle now (i.e. developing the patches in private, and putting them on a website instead of in a repo) Sep 19 22:30:33 If there is a business reason for doing so, then I can fully appreciate that, and will stop hassling you. Sep 19 22:30:55 <[g2]> rwhitby-web you have a control issue about this Sep 19 22:31:33 <[g2]> it's a mountain from a mole-hill Sep 19 22:32:40 <[g2]> After I do a tiny bit more clean up in the morning I'll post the entire thing to the nslu2-developer ml Sep 19 22:49:51 [g2]: ok, just to try and summarize: Sep 19 22:50:16 1/ You prefer to keep the Loft-specific changes separate Sep 19 22:50:28 <[g2]> rwhitby-web, nod. Sep 19 22:50:47 2/ You're going to take Lennert's list into account when you do the Loft changes (to give yourself the best chance of getting them accepted upstream) Sep 19 22:51:01 <[g2]> nod again Sep 19 22:51:09 3/ Then you're going to post them (or put them on your website) Sep 19 22:51:19 <[g2]> both. Sep 19 22:51:50 4/ dwery should continue to structure the nslu2 changes independently, cause you believe there will be little in common (same sort of changes, but different files or regions in the same file) Sep 19 22:52:31 <[g2]> dwery and I should compare lists Sep 19 22:52:53 <[g2]> about 12 files are just simple name changes NSLU2/LOFT Sep 19 22:52:58 <[g2]> nslu2_ loft_ Sep 19 22:53:19 5/ dwery should then take your Loft changes (and http://peter.korsgaard.com/articles/openslug1.2-2.6.11.12.patch) and Lennert's list as inputs, and then produce a replacement set of nslu2 patches which can be checked into monotone by dwery and used as the basis of the kernel for UcSlugC, OpenSlug an OpenDebianSlug, and also used for the Debian nslu2 kernel package. Sep 19 22:54:53 [g2]: does that meet both our needs? Sep 19 22:54:54 <[g2]> on 5/, based on the comments on the loft changes, the should incorporate those Sep 19 22:55:04 <[g2]> and then submit upstream Sep 19 22:55:06 nod Sep 19 22:55:33 <[g2]> I can preview the changes on nslu2-developer ml before sending upstream for RFC Sep 19 22:55:58 That would be great. Sep 19 22:56:27 <[g2]> Well let's plan on it Sep 19 22:56:32 We would want the Loft and nslu2 kernel changes to be along the same lines, to give both the best chance of acceptance, but not hold each other up. Sep 19 22:56:41 <[g2]> the changes should be done tomorrow or the next day Sep 19 22:57:23 <[g2]> I'm just missing 1 change which is for CF/IDE booting that's unrelated to the NSLU2 Sep 19 22:57:56 Okay, I was just thinking about the CSR_1.5 . Sep 19 22:58:03 Did you remember to make the device node? Sep 19 22:58:10 or was that only introduced in 2.0 ? Sep 19 22:58:38 I think it wants to be a 241 0 for loading the npe microcode. Sep 19 22:58:59 That is, unless you've told it to include the microcode. Sep 19 22:59:02 dyoung-web: are you addressing dwery-zzzz and yvasilev ? Sep 19 22:59:10 yes Sep 19 22:59:49 [g2]: ok, we have a good plan. thanks for the discussion and thanks as always for the contribution you make. Sep 19 23:00:12 <[g2]> rwhitby-web I'm honored to just be a part of the team Sep 19 23:00:29 [g2]: so am I :-) Sep 19 23:00:37 <[g2]> I'm sorry If I've been unclear Sep 19 23:00:51 Okay, apparently I just missed something here. Sep 19 23:01:05 But that was my random thought of the day for the Intel Access Library. Sep 19 23:01:07 bye. Sep 19 23:01:18 I gotta go too. Sep 19 23:03:34 <[g2]> dyoung-web the V1.2 stuff I'm running (pre-built) doesn't appear to have the nod 241 0 but loads and runs fine Sep 19 23:05:21 the device only became neccessary when they unbundled the npe library. Sep 19 23:05:29 that was either in CSR 1.5 or 2.0 Sep 19 23:07:41 <[g2]> dyoung-web well I don't think it's 1.5 Sep 19 23:08:03 I just dont remember. Sep 19 23:08:12 Its an issue I've faced before; dont remember when. Sep 19 23:08:27 it became the default in 2.0 Sep 19 23:09:32 <[g2]> yvasilev is there a good summary of the 2.0 changes somewhere ? Sep 19 23:11:16 no idea, have seen something in intel pdfs, but don't remember exactly which ones Sep 20 00:11:07 03jbowler 07org.openembedded.dev * r0f461962... 10/conf/distro/ucslugc-packages.conf: ucslugc: add udev bb files to the packages to support udev in openslug-image Sep 20 00:20:45 Im checking with Peter if he needs help with the serial-less debian install work btw, so we dont duplicate too much work. Sep 20 00:46:41 03frederic 07org.openembedded.dev * r52e24857... 10/packages/linux/ (31 files in 5 dirs): (log message trimmed) Sep 20 00:46:41 added opensimpad-2.4.27-vrs1-pxa1-jpm1 kernel. This contains the Sep 20 00:46:41 following new patches over 2.4.25: Sep 20 00:46:41 - simpad-proc-sys-board.patch (/proc/sys/board patch from Till Harbaum) Sep 20 00:46:41 - simpad-serial.patch (DTR/RTS/CTS support patch from Till Harbaum) Sep 20 00:46:42 - mppe-20040216.patch (add MPPE encryption for PPP) Sep 20 00:46:44 - 2.4.27-mh1.patch (bluetooth patches from Marcel Holtmann) Sep 20 00:46:47 03frederic 07org.openembedded.dev * rf14fb6df... 10/packages/gpsd/gpsd.inc: Changed section from network to console/network. Sep 20 00:46:49 03frederic 07org.openembedded.dev * r5ec5f2c1... 10/packages/totem/ (14 files in 4 dirs): Sep 20 00:46:52 totem: version 1.0.2 now compiles Sep 20 00:46:54 I removed version 0.101 which was marked as broken. Sep 20 00:46:55 A few fixes were needed to disable gnomeui code in totem-1.0.2. Sep 20 00:46:58 Don't even try to upgrade it to version 1.2.x for now: it has even more Sep 20 00:47:00 dependencies, such as a very recent version of gnome-vfs... Sep 20 02:00:09 juhu.. glibc done Sep 20 02:46:35 checking in... Sep 20 02:47:42 yvasilev: I've read you found the bug? is that correct? Sep 20 02:50:02 dwery: here's the update (excuse the flood): Sep 20 02:50:05 Sep 19 22:49:51 [g2]: ok, just to try and summarize: Sep 20 02:50:05 Sep 19 22:50:16 1/ You prefer to keep the Loft-specific changes separate Sep 20 02:50:05 Sep 19 22:50:28 <[g2]> rwhitby-web, nod. Sep 20 02:50:05 Sep 19 22:50:47 2/ You're going to take Lennert's list into account when you do the Loft changes (to give yourself the best chance of getting them accepted upstream) Sep 20 02:50:05 Sep 19 22:51:01 <[g2]> nod again Sep 20 02:50:07 Sep 19 22:51:09 3/ Then you're going to post them (or put them on your website) Sep 20 02:50:08 Sep 19 22:51:19 <[g2]> both. Sep 20 02:50:10 Sep 19 22:51:50 4/ dwery should continue to structure the nslu2 changes independently, cause you believe there will be little in common (same sort of changes, but different files or regions in the same file) Sep 20 02:50:13 Sep 19 22:52:31 <[g2]> dwery and I should compare lists Sep 20 02:50:15 Sep 19 22:52:53 <[g2]> about 12 files are just simple name changes NSLU2/LOFT Sep 20 02:50:17 Sep 19 22:52:58 <[g2]> nslu2_ loft_ Sep 20 02:50:19 Sep 19 22:53:19 5/ dwery should then take your Loft changes (and http://peter.korsgaard.com/articles/openslug1.2-2.6.11.12.patch) and Lennert's list as inputs, and then produce a replacement set of nslu2 patches which can be checked into monotone by dwery and used as the basis of the kernel for UcSlugC, OpenSlug an OpenDebianSlug, and also used for the Debian nslu2 kernel package. Sep 20 02:50:24 Sep 19 22:54:53 [g2]: does that meet both our needs? Sep 20 02:50:26 Sep 19 22:54:54 <[g2]> on 5/, based on the comments on the loft changes, the should incorporate those Sep 20 02:50:28 Sep 19 22:55:04 <[g2]> and then submit upstream Sep 20 02:50:30 Sep 19 22:55:06 nod Sep 20 02:50:32 Sep 19 22:55:33 <[g2]> I can preview the changes on nslu2-developer ml before sending upstream for RFC Sep 20 02:50:34 Sep 19 22:55:58 That would be great. Sep 20 02:50:36 Sep 19 22:56:27 <[g2]> Well let's plan on it Sep 20 02:50:38 Sep 19 22:56:32 We would want the Loft and nslu2 kernel changes to be along the same lines, to give both the best chance of acceptance, but not hold each other up. Sep 20 02:50:41 Sep 19 22:56:41 <[g2]> the changes should be done tomorrow or the next day Sep 20 02:51:23 ... Sep 20 02:52:22 rwhitby-away: ok. thanks. **** ENDING LOGGING AT Tue Sep 20 02:59:56 2005