| 00:07.25 | *** join/#nslu2-linux kolla_ (kolla@firda.kolla.no) |
| 00:15.55 | *** join/#nslu2-linux grimreap (~grimreap@c-67-165-167-67.hsd1.il.comcast.net) |
| 00:36.00 | *** join/#nslu2-linux rwhitby-away (~rwhitby@rwhitby.nslu2-linux) |
| 01:45.03 | *** join/#nslu2-linux jtucker (~Jim@S01060004e2a07457.vc.shawcable.net) |
| 02:09.03 | CIA-8 | 03jbowler 07org.openembedded.nslu2-linux * r9c0cb9ee... 10/packages/install/ (files/install-sh install-native_0.1.bb): Add support for -p and -D options to install. |
| 02:26.07 | *** join/#nslu2-linux Jacmet (~jacmet@50C59F0E.flatrate.dk) |
| 02:54.00 | CIA-8 | 03jbowler 07org.openembedded.nslu2-linux * r0b04419b... 10/packages/ (5 files in 3 dirs): |
| 02:54.00 | CIA-8 | propagate from branch 'org.openembedded.nslu2-linux' (head 9c0cb9eef455eaf3c4cb9e1631ed1443ce6346e9) |
| 02:54.00 | CIA-8 | <PROTECTED> |
| 03:54.14 | CIA-8 | 03rwhitby 07org.openembedded.nslu2-linux * r9750f55a... 10/packages/ (3 files in 3 dirs): Moved OpenSlug root home directory from /home/root to simply /root |
| 03:54.16 | CIA-8 | 03rwhitby 07org.openembedded.nslu2-linux * r9a6d9077... 10/packages/base-files/base-files_3.0.14.bb: Fixed the OpenSlug root move |
| 04:34.08 | CIA-8 | 03jbowler 07org.openembedded.nslu2-linux * rd3dcb0c3... 10/packages/meta/openslug-packages.bb: util-linux does not build on uclibc (fails in do_install step). |
| 05:25.25 | CIA-8 | 03bzhou * 10unslung/ (3 files in 2 dirs): added ocaml and unison |
| 05:30.12 | CIA-8 | 03bzhou * 10unslung/Makefile: ocaml ready for native testing, including ocamlopt but not ocamlopt.opt |
| 05:53.50 | jtucker | leave |
| 07:56.35 | *** join/#nslu2-linux [cc]smart (~smart@gw.ptr-62-65-149-158.customer.ch.netstream.com) |
| 08:08.11 | *** join/#nslu2-linux eumel (~chatzilla@p5483088A.dip0.t-ipconnect.de) |
| 08:32.01 | *** join/#nslu2-linux grimreap (~grimreap@c-67-165-167-67.hsd1.il.comcast.net) |
| 09:00.38 | *** join/#nslu2-linux kolla_ (kolla@firda.kolla.no) |
| 09:44.52 | dyoung | regarding "reboot problem" in openslug. Seems that if you umount /initrd early it will reboot like its supposed to. Why that would be comopletely escapes me. |
| 09:45.15 | dyoung | It Completely escapes me too. :-) |
| 09:46.52 | kolla_ | so that's why I never had problems rebooting |
| 09:49.57 | dyoung | Anyway, thats my observation of the day. |
| 09:50.52 | dyoung | my openslug installation is kind of a bastard child right now; so it would be nice if someone could confirmm or deny that. |
| 10:00.59 | *** join/#nslu2-linux bwalle (~bwalle@p5491843B.dip0.t-ipconnect.de) |
| 10:08.59 | *** join/#nslu2-linux bwalle (~bwalle@p5491843B.dip0.t-ipconnect.de) |
| 10:26.42 | [cc]smart | dyoung: until now what i have thought is that it would be the case if i'm not on internal flash as root. but that would well be covered by the initrd case. |
| 10:26.45 | [cc]smart | so i'll try that |
| 10:30.08 | dyoung | another something to chew on... |
| 10:30.17 | dyoung | why is this in our defconfig? |
| 10:30.25 | dyoung | # CONFIG_USB_OHCI_BIG_ENDIAN is not set |
| 10:30.26 | dyoung | CONFIG_USB_OHCI_LITTLE_ENDIAN=y |
| 10:31.15 | [cc]smart | dunno... but maybe this could solve the hassle with usb disk/irq issues ? |
| 10:31.48 | [cc]smart | iirc the most obvious problems where usb20 ? |
| 10:32.16 | [cc]smart | unounted /initrd and system rebooted fine |
| 10:32.20 | [cc]smart | there you have it |
| 10:32.44 | *** join/#nslu2-linux grimreap (~grimreap@c-67-165-167-67.hsd1.il.comcast.net) |
| 10:34.04 | dyoung | ochi is the usb1.1 stuff though, and is on irq27 and irq28 . |
| 10:34.36 | [cc]smart | too bad |
| 10:34.54 | [cc]smart | rechecked with /initrd left mounted, and it fails to reboot |
| 10:35.06 | [cc]smart | so i'd count the observation correct |
| 10:39.04 | dyoung | why that would be completely escapes me. |
| 10:39.35 | dyoung | anyways, if a few others can verify the behaviour, I vote for making that bit part of the /boot/foo scripts. |
| 11:27.48 | *** join/#nslu2-linux bwalle (~bwalle@p5491A1A5.dip0.t-ipconnect.de) |
| 12:12.45 | CIA-8 | 03bwalle * 10unslung/ (Makefile make/fIcy.mk): Added fIcy package for testing. |
| 13:45.08 | *** join/#nslu2-linux grimreap (~grimreap@c-67-165-167-67.hsd1.il.comcast.net) |
| 13:47.42 | *** join/#nslu2-linux caplink811 (~Joerg@dsl-213-023-144-145.arcor-ip.net) |
| 14:00.00 | *** part/#nslu2-linux bwalle`afk (~bwalle@p5491A1A5.dip0.t-ipconnect.de) |
| 14:51.18 | CIA-8 | 03ingeba * 10unslung/make/gnutls.mk: Found the old 1.2.4 version in the attic and readjusted SITE info |
| 14:52.01 | *** join/#nslu2-linux bob_tm-away (~chatzilla@145.80-203-34.nextgentel.com) |
| 15:38.49 | jbowler-zzz | So rmdir /initrd might give reliable reboots... |
| 15:39.19 | jbowler | But what does the reboot look like? All LEDs lit, 4s delay then orange? |
| 15:39.35 | jbowler | Or is it all LEDs lit, fractional second delay, then orange? |
| 15:43.19 | CIA-8 | 03ingeba * 10unslung/make/imap.mk: Upgraded to 2004e as 2004d was no longer availble - moving it to ready_for_testing |
| 15:49.00 | CIA-8 | 03ingeba * 10unslung/Makefile: Moved imap to ready_for_testing due to version upgrade |
| 15:57.36 | *** join/#nslu2-linux [cc]smart (~smart@gw.ptr-62-65-149-158.customer.ch.netstream.com) |
| 16:00.41 | *** join/#nslu2-linux grimreap (~grimreap@c-67-165-167-67.hsd1.il.comcast.net) |
| 16:04.58 | jbowler | The reboot is a hard (watchdog) reboot, the soft reboot still hangs. |
| 16:06.01 | jbowler | It seems to work now doing the umount at K06. The problem is that this is a turbo slug and I don't have a non-turbo - when we tried this before it wasn't reliable but maybe it wasn't getting enough time. |
| 16:06.31 | jbowler | Need to know how long it requires. |
| 16:08.01 | CIA-8 | 03bzhou * 10unslung/Makefile: ocaml put in the wrong place, should be under NATIVE_PACKAGES_READY_FOR_TESTING |
| 16:10.47 | [cc]smart | jbowler: you might add a loop that waits unil its umounted |
| 16:11.10 | jbowler | umount waits until it is unmounted |
| 16:11.35 | [cc]smart | er, actually yes, you're right. but now i wonder what you meant :) |
| 16:12.14 | jbowler | I need to know how much time is required between the umount and the reboot. |
| 16:12.24 | [cc]smart | there's a delay ? |
| 16:12.55 | jbowler | There needs to be a delay - that's what dyoung is suggesting anyway. |
| 16:13.15 | [cc]smart | don't get why a delay should be needed... |
| 16:13.37 | [cc]smart | umount syncs the FS |
| 16:13.38 | jbowler | Well, no, I don't either - finding out why would be useful... |
| 16:13.52 | jbowler | sync doesn't help |
| 16:14.04 | [cc]smart | sure, since umount does it already |
| 16:14.21 | [cc]smart | this would have been the only thing i could think of that would make a delay possible |
| 16:14.36 | [cc]smart | s/possible/sensible/ |
| 16:16.37 | jbowler | Well, it certainly seems to work having a delay, but maybe something else important happens after the umount in rc6.d/* |
| 16:17.24 | jbowler | I can't see what though - nothing touches the flash in there |
| 16:18.18 | jbowler | I tried 10s after the existing umount, it still hangs. |
| 16:21.02 | kolla_ | hm, I umount /initrd on bootup |
| 16:21.31 | jbowler | Does shutdown -r work consistently for you (i.e. never hang, apart for the 4s where all the LEDs are alight). |
| 16:21.56 | kolla_ | I never looked at the leds, but it does reboot yes |
| 16:22.17 | jbowler | What is your rootfs (disk, nfs, usb stick?) |
| 16:22.56 | kolla_ | I have two, one with usb disk, and one with usb stick.. the only difference being that the stick is mounted noatime |
| 16:23.49 | jbowler | The hang has been seen to happen with everything - including NFS - but seems not to always happen with NFS. |
| 16:24.02 | jbowler | Adding a 60s delay after the umount of /initrd doesn't help either... |
| 16:24.06 | kolla_ | maybe I've just been lucky :) |
| 16:25.25 | jbowler | Yeah, that's possible, we've known for a long time that umounting /initrd would at least reduce the problem, but I don't think anyone every took the time to see whether it could be eliminated. |
| 16:27.53 | jbowler | Hum. One interesting thing of course is that the /initrd was mounted on / by the kernel. |
| 16:31.03 | CIA-8 | 03ingeba * 10unslung/make/man-pages.mk: Updated man pages to version 2.05 as version 2.01 was no longer available and 2.06 did not have correct access rights |
| 16:31.05 | [cc]smart | jbowler: the test i did was definitely waiting less than 60s, and it worked with /initrd unmounted |
| 16:32.57 | jbowler | Yes, I've eliminated a simple delay as a possibility (not that I liked the idea of doing that very much, shutdown is slow enough already). |
| 16:35.42 | [cc]smart | what always wondered me is why "mount" and "cat /etc/mtab" give different results." |
| 16:35.48 | jbowler | ... and I've eliminated the possibility that it was because the /initrd was from the kernel / mount - I still get the hang if I rmdir /initrd, reboot, mkdir /initrd and mount it. |
| 16:36.30 | jbowler | [cc]smart: busybox mount is effectively cat /proc/mounts, /etc/mtab is written by busybox mount. |
| 16:36.48 | jbowler | Some distros do ln -s /proc/mounts /etc/mtab |
| 16:37.27 | [cc]smart | just like openslug |
| 16:37.45 | [cc]smart | which could be the reason |
| 16:37.55 | [cc]smart | if busybox mount writes into /proc/mounts |
| 16:37.57 | [cc]smart | what happens ? |
| 16:39.33 | jbowler | Oh, ok - on openslug busybox "mount" actually attempts to fix up the contents of /etc/mtab (or whatever it reads) to have the correct information using /etc/fstab. |
| 16:39.53 | [cc]smart | which still makes busybox write into /proc/mounts |
| 16:40.03 | [cc]smart | since theres the link |
| 16:40.04 | jbowler | <PROTECTED> |
| 16:40.05 | [cc]smart | not a file |
| 16:40.34 | [cc]smart | correct |
| 16:40.47 | [cc]smart | except that it's /proc/self/mounts |
| 16:41.06 | jbowler | 'self' is just a link to $$ |
| 16:41.13 | [cc]smart | ah |
| 16:41.14 | [cc]smart | k |
| 16:41.31 | [cc]smart | i'll still try now replacing mtab with a file... let's see what happens... |
| 16:41.39 | jbowler | There seems to be no global mount table in Linux (which makes sense to me). |
| 16:42.05 | [cc]smart | doesn't make sense to me though |
| 16:42.09 | jbowler | I think the support for file mtab is in the init scripts, but I'm not sure. |
| 16:42.10 | [cc]smart | what do new processes get ? |
| 16:42.40 | jbowler | Same as everything else - it's inherited with variations (like the signal mask). |
| 16:43.06 | [cc]smart | which means there is a more global entry up to the most global which is THE global |
| 16:43.19 | [cc]smart | if there's really a different one |
| 16:43.23 | [cc]smart | couldn't see it really |
| 16:43.30 | jbowler | At least I'm assuming that's what happens - after a pivot_root there are two different views of the world. |
| 16:43.31 | [cc]smart | how would backup be possible if there isn't |
| 16:43.42 | [cc]smart | don't think so either |
| 16:44.00 | [cc]smart | his being the reason why you must leave all processes |
| 16:44.30 | [cc]smart | so that the base can be SWITCHED |
| 16:44.39 | [cc]smart | otherwise you'd just have an alternative view |
| 16:44.53 | [cc]smart | which would not require closing all processes |
| 16:45.08 | [cc]smart | but i don't know it really |
| 16:45.25 | [cc]smart | it's just what i would expect/is most logical to me |
| 16:45.28 | jbowler | Got it! mount -o remount,ro /initrd works too! |
| 16:46.44 | jbowler | If this is correct, shutdown -r would always work after reflash too. |
| 16:47.34 | [cc]smart | in any case, removing /etc/mtab as a link and replacing it as a file removes the discrepancy in between the two outputs |
| 16:48.07 | [cc]smart | ah ... |
| 16:48.10 | [cc]smart | this strikes me |
| 16:48.15 | [cc]smart | now assume what |
| 16:48.27 | [cc]smart | how about the following: |
| 16:48.40 | [cc]smart | when i do cat /etc/mtab |
| 16:49.08 | [cc]smart | what i get is the situation for the shell i'm running since /proc/self/mounts hits the shell, no ? |
| 16:49.16 | [cc]smart | if i do it via mount |
| 16:49.31 | [cc]smart | i see a different process accessing /proc/self/mounts |
| 16:49.39 | [cc]smart | or maybe not |
| 16:49.47 | [cc]smart | in any case the two see different situations |
| 16:51.10 | jbowler | ? I don't understand "since /proc/self/mounts hits the shell, no ?" - everything in /proc is inside the kernel. |
| 16:51.28 | [cc]smart | yes, but as you said self is $$ |
| 16:51.46 | [cc]smart | /proc/self/mounts is a different thing for every process |
| 16:52.14 | [cc]smart | so there must be two different vies |
| 16:52.20 | [cc]smart | for whatever reason |
| 16:52.38 | [cc]smart | in any case, replacing /etc/mtab by a file doesnt fix rebooting |
| 16:52.53 | jbowler | Do a diff on /proc/[1-9]*/mounts and see if they are all the same... |
| 16:53.21 | jbowler | I think they might be unless something survives from before the pivot_root, but maybe chroot processes are different? |
| 16:54.24 | [cc]smart | one sec |
| 16:54.30 | [cc]smart | at least in one point you where wrong |
| 16:54.37 | [cc]smart | s/h// |
| 16:54.45 | jbowler | Making /etc/mtab a file results in an empty file after reboot - so there is no support for /etc/mtab (in the traditional form). |
| 16:54.48 | [cc]smart | i replaced /etc/mtab with a file |
| 16:54.56 | [cc]smart | correct |
| 16:55.01 | [cc]smart | it's empty on my side too |
| 16:55.13 | [cc]smart | but mount still gives correct (or wrong then?) output |
| 16:55.18 | [cc]smart | where from ? |
| 16:55.45 | [cc]smart | yes mount gices incorrect output, at least by means of "what i'd expect" |
| 16:55.51 | [cc]smart | /dev/sda1 on /initrd type jffs2 (rw,noatime) |
| 16:55.52 | [cc]smart | /dev/sda1 on / type reiserfs (rw,noatime) |
| 16:55.55 | [cc]smart | which is incorrect |
| 16:56.06 | [cc]smart | sinc /initrd is mtdblock4 no ? |
| 16:56.07 | jbowler | I don't see any difference - it seems to be ignoring /etc/mtab |
| 16:56.16 | [cc]smart | that's what it does |
| 16:56.29 | [cc]smart | but as it was a link isaw two different contents |
| 16:56.41 | [cc]smart | depending if i'd cat /etc/mtab or doe mount |
| 16:56.51 | jbowler | busybox doesn't understand the concept of 'rootfs' I think. |
| 16:57.18 | jbowler | <PROTECTED> |
| 16:57.28 | jbowler | rootfs / rootfs rw 0 0 |
| 16:57.31 | jbowler | /dev/root /initrd jffs2 ro,noatime 0 0 |
| 16:57.31 | jbowler | /dev/sda3 / reiserfs rw,noatime 0 0 |
| 16:57.38 | [cc]smart | so what i assume is the following |
| 16:57.49 | [cc]smart | busybox mount thinks /dev/sda1 is on /initrd |
| 16:58.01 | [cc]smart | and it umounts /dev/sda1 for that, not /initrd |
| 16:58.12 | [cc]smart | which makes / fail |
| 16:58.27 | jbowler | No. It doesn't know what /dev/root is, so it assumes the root device (which is /dev/sda1). |
| 16:58.34 | [cc]smart | nana |
| 16:58.39 | [cc]smart | do "mount" |
| 16:58.50 | jbowler | No. Look at man(2) umount |
| 16:58.51 | [cc]smart | you'll see /dev/sda1 on /initrd type jffs2 (rw,noatime) |
| 16:59.17 | [cc]smart | who'se man page is that ? |
| 16:59.24 | jbowler | Linux |
| 16:59.37 | jbowler | (Since we are running linux ;-) |
| 16:59.51 | [cc]smart | i thought we are running busybox |
| 17:00.41 | jbowler | Yes, that too. I gave you a reference to a system call man page, not a command man page. |
| 17:00.43 | [cc]smart | i bet a pair of used pants on umount doing umount -f /dev/sda1 in my case |
| 17:01.07 | [cc]smart | and pulling it's own / therefore |
| 17:01.12 | [cc]smart | leaving the kernel survived |
| 17:01.21 | [cc]smart | which blocks the slug from doing hardreset |
| 17:02.11 | jbowler | I would strongly recommend against passing devices to the umount command. You don't know what will happen. |
| 17:02.22 | [cc]smart | i'm not saying I do that |
| 17:02.36 | [cc]smart | i'm saying, this is what i think might be happening |
| 17:02.45 | jbowler | No, it doesn't. |
| 17:02.53 | [cc]smart | then i was in bad luck |
| 17:03.04 | [cc]smart | i would fit the behaviour perfectly though |
| 17:03.10 | [cc]smart | s/i/it/ |
| 17:03.15 | jbowler | What behaviour? |
| 17:03.23 | [cc]smart | the hanging reboot |
| 17:03.57 | jbowler | That's a hardware erratum. |
| 17:04.22 | jbowler | Sometimes the hardware reset fails to reset all the system. |
| 17:04.58 | [cc]smart | and you fix the hardware by unmounting /initrd ?????? |
| 17:04.59 | jbowler | It's not clear to me whether the flash driver stuff is at fault or whether it merely makes the hang more likely, but the flash chip hardware is definately involved. |
| 17:05.37 | jbowler | umounting /initrd - or mounting it ro - presumably allows the hardware to settle into a state where the problem is much less likely. |
| 17:06.15 | jbowler | But it's not just a time delay... |
| 17:06.44 | *** join/#nslu2-linux WiP (~fonk@p54990C88.dip0.t-ipconnect.de) |
| 17:09.11 | jbowler | Hum... I guess I have another potential fix though - the remount,ro seems to work reliably for me. Problem is I thought I had a fix when I did the umount of /initrd in the first place, and that didn't work... |
| 17:10.06 | [cc]smart | so unmountign /initrd does unreliable ? ok, that changes this. didn't see this here. |
| 17:11.04 | jbowler | <PROTECTED> |
| 17:11.44 | jbowler | When I did that originally I had thought this was the problem (having /dev/mtdblock4 mounted at shutdown), because my tests to umount it then shutdown -r seemed to work... |
| 17:12.25 | jbowler | So my tests were much earlier in the shutdown sequence, and when I moved the umount and removed my debug code it stopped working. |
| 17:12.47 | jbowler | So I figured someone with a serial port had to debug it. |
| 17:13.00 | [cc]smart | have serial |
| 17:13.03 | jbowler | (Since the debug code wrote log messages to a disk) |
| 17:13.49 | jbowler | Yes, but in fact there are no errors from any of the shutdown commands. |
| 17:14.34 | jbowler | It was, I believe, the simple presence of my debugging which introduced enough stuff for it to work reliably. |
| 17:15.35 | [cc]smart | er, now i see sth. |
| 17:15.41 | [cc]smart | what was that calledd.. |
| 17:15.43 | [cc]smart | one sec |
| 17:15.52 | [cc]smart | think i might have sth. |
| 17:16.15 | [cc]smart | if only the slug would now be in slow mode |
| 17:16.16 | jbowler | Then someone (Tiersten?) pointed out that there was a hardware erratum, so I tried to make software reboot work... |
| 17:16.49 | [cc]smart | give a short moment to go back into slug and tell you what i just did/saw |
| 17:17.35 | [cc]smart | do cat /etc/init.d/umountfs |
| 17:17.49 | [cc]smart | i added : echo $dev $mp $type $opts |
| 17:18.07 | [cc]smart | just behind the if read in unmount |
| 17:18.13 | [cc]smart | heh |
| 17:18.15 | [cc]smart | its' cool |
| 17:18.20 | [cc]smart | this will be it |
| 17:18.22 | [cc]smart | i'm sure |
| 17:18.30 | [cc]smart | now what i saw |
| 17:18.36 | [cc]smart | a couple lines of mtab go by |
| 17:18.47 | [cc]smart | then screen was flooded by empty lines |
| 17:18.53 | [cc]smart | these reason prolly: |
| 17:19.05 | [cc]smart | it unounted its own access to /proc/mounts or similar |
| 17:19.18 | [cc]smart | or sth. along the lines of that |
| 17:19.30 | [cc]smart | in any case, it didn't finish the recursion |
| 17:19.44 | jbowler | It's possible it has a bug, but I hacked a directory 'umount /initrd' into my copy of the file right at the top. |
| 17:20.26 | [cc]smart | what i say is the "if read" succeeds when it shouldnt |
| 17:20.36 | [cc]smart | ah o |
| 17:20.39 | [cc]smart | grr |
| 17:20.45 | [cc]smart | maybe triced myself here |
| 17:20.51 | [cc]smart | nother try |
| 17:21.15 | jbowler | If the 'read' keeps on succeeding then probably the shell script will run until it gets OOM and dies. |
| 17:21.51 | [cc]smart | yes, that's what i thought was the fault, but the fault a least in this test was me sillyness |
| 17:21.55 | [cc]smart | so retry |
| 17:22.25 | jbowler | That function does work fine outside the reboot sequence - that is how I tested it (well, it used to work fine.) |
| 17:24.12 | *** join/#nslu2-linux marceln (~marceln@pion.xs4all.nl) |
| 17:28.38 | *** join/#nslu2-linux bwalle (~bwalle@p5491A1A5.dip0.t-ipconnect.de) |
| 17:29.04 | [cc]smart | i have two testruns here which mighty be of use, dunno: |
| 17:29.06 | [cc]smart | http://pastebin.com/315096 |
| 17:29.18 | CIA-8 | 03marceln * 10unslung/make/inetutils.mk: COSMETIC Change: removed a space in the section name |
| 17:31.23 | jbowler | The ramfs failure is unexpected, I suspect it may be something to do with /dev (which cannot be umounted at this point) |
| 17:31.48 | jbowler | The eth0 is a problem, IMO - it's been there for ever and is happening inside the kernel shutdown. |
| 17:32.08 | [cc]smart | /dev/ is not tried for unmount |
| 17:32.26 | [cc]smart | so the failure must be for a different request |
| 17:32.28 | [cc]smart | funny thing |
| 17:32.32 | [cc]smart | there is no ramfs tried |
| 17:32.54 | [cc]smart | only "out" lines are getting unmounted |
| 17:33.09 | jbowler | Look in the script immediately below the unmount call |
| 17:33.43 | [cc]smart | grr |
| 17:33.47 | [cc]smart | will modify test... |
| 17:34.13 | jbowler | I expect the /dev umount to fail - /dev/console is in use outputing those messages! |
| 17:34.34 | jbowler | I don't quite understand why this should lock /dev, but something seems to. |
| 17:34.56 | [cc]smart | you're right, it's /dev |
| 17:35.23 | jbowler | I wasn't able to find a way to umount it. IMO it would be good if it could be umounted, just for cleanness. |
| 17:37.38 | jbowler | The ramfs in the error message is there because when the umount fails it tries the equivalent of 'mount -o remount,ro ramfs /dev' |
| 17:37.41 | [cc]smart | i will try to identify the sinner.... |
| 17:38.50 | jbowler | ls -l /proc/*/fd/* can be a useful trick. |
| 17:39.57 | [cc]smart | http://pastebin.com/315100 |
| 17:40.32 | [cc]smart | init 1 root 10u FIFO 0,11 564 /dev/initctl |
| 17:40.58 | [cc]smart | rc 993 root 0u CHR 5,1 255 /dev/console |
| 17:40.59 | [cc]smart | rc 993 root 1u CHR 5,1 255 /dev/console |
| 17:40.59 | [cc]smart | rc 993 root 2u CHR 5,1 255 /dev/console |
| 17:41.02 | jbowler | Ooh, look at that mtdblockd |
| 17:42.35 | jbowler | Yeah, those /dev/consoles are where the output is. I tried to find a way to kill them, but I don't think it matters - /dev mounted shouldn't be an issue anywhere. |
| 17:43.10 | [cc]smart | need to read what mtdblockd is all about.... |
| 17:44.32 | jbowler | init has /dev/initctl open, but that's actually on /, not on the ramfs |
| 17:46.47 | jbowler | The mtdblockd is a kernel thread from the jffs2 file system support. Since jffs2 is built in there is no way to rmmod it therefore, I think, no way to stop it. |
| 17:47.06 | *** join/#nslu2-linux AdamBaker (~aab@userch028.dsl.pipex.com) |
| 17:47.32 | [cc]smart | may mtdblockd be stopping to flush too early/leave a "half flushed" state ? : http://www.ussg.iu.edu/hypermail/linux/kernel/0408.1/1913.html |
| 17:47.43 | jbowler | It might be possible to shut down eth in a controlled fashion by rmmod, but it clearly doesn't stop the hardware reset. |
| 17:50.14 | jbowler | I don't believe it can be a software kernel problem because of the way the reboots - soft or hard -happen. Hard is a watchdog timer which pulls the reset line on the chip down. Soft is a direct jump into the RedBoot code. |
| 17:52.14 | [cc]smart | i think the situation somehow doesn't allow the kernel to stop |
| 17:52.31 | [cc]smart | afaik, the kernel is keeping the watchdog happy for as long as it works |
| 17:53.17 | *** join/#nslu2-linux caplink811 (~Joerg@dsl-213-023-144-145.arcor-ip.net) |
| 17:54.49 | jbowler | Oh no, the kernel stops. Believe me I can stop the kernel... |
| 17:55.24 | jbowler | And the watchdog fires too, because otherwise those LEDs would stay all lit (or go to just amber.) |
| 17:56.06 | jbowler | Anyway, I'm just removing that code - it was only for debugging, I'm going to revert to hard reboot and, if that seems to work, check it in and see whether it works for everyone. |
| 17:56.22 | jbowler | (I.e I have a change to umountinitrd.sh to remount,ro /initrd on boot.) |
| 17:58.09 | [cc]smart | this would suggest two problems |
| 17:58.21 | [cc]smart | one in software which puts HW in strange state |
| 17:58.37 | [cc]smart | one in HW which is that watchdog reset doesnt work in all cases |
| 17:59.31 | jbowler | Yes |
| 17:59.44 | jbowler | And the software one presumably kills the software reboot too. |
| 18:00.37 | *** join/#nslu2-linux mkrause (~wolf@dsl-082-082-250-207.arcor-ip.net) |
| 18:00.53 | mkrause | hiho |
| 18:00.54 | [cc]smart | so a possible scenario with -o ro relieving might be that flash is put into write mode and it doesnt return from that |
| 18:01.22 | [cc]smart | iirc that falsh needs write mode to raise voltage etc to make a write |
| 18:02.08 | [cc]smart | which would be a physical "" |
| 18:02.17 | [cc]smart | "state" |
| 18:02.22 | jbowler | Yes, possible. Indeed it seems certain that something the flash driver does to support write must leave the hardware in a state where reset doesn't work. |
| 18:03.33 | mkrause | I would like to add loop-support and iso9660 filesystem support to my nslu2. For that it would be nice to have a .config for the kernel running on my unslung 4.x. Any suggestions where to find such a .config? |
| 18:04.46 | [cc]smart | monotone repo should prolly have that |
| 18:04.47 | [cc]smart | lemme see |
| 18:06.50 | [cc]smart | seems we have such |
| 18:06.53 | [cc]smart | in two pieces |
| 18:07.00 | [cc]smart | one prolly the original linksys |
| 18:07.04 | [cc]smart | and a patch for that |
| 18:07.22 | [cc]smart | can monotone be browsed via web ? |
| 18:07.39 | [cc]smart | or do you have a copy of the repo ? |
| 18:08.28 | [cc]smart | openembedded/packages/linux/nslu2-linksys-kernel-2.4.22/nslu2/defconfig |
| 18:08.57 | [cc]smart | openembedded/packages/linux/nslu2-linksys-kernel-2.4.22/config-fixes.patch |
| 18:09.26 | [cc]smart | ah forget about the patch |
| 18:10.15 | mkrause | sorry, but where can I access those files? |
| 18:11.28 | mkrause | it's not the cvs from sf.net right? |
| 18:12.54 | [cc]smart | no |
| 18:12.58 | [cc]smart | monotone repo |
| 18:13.04 | [cc]smart | bu maybe it's on the cvs too |
| 18:13.14 | [cc]smart | it should be a relativey old file |
| 18:14.20 | [cc]smart | do you maybe have /proc/config on your slug ? |
| 18:15.42 | mkrause | no :( |
| 18:16.09 | mkrause | how to access the monotone repo? |
| 18:16.49 | [cc]smart | try this: http://monotone.vanille.de/viewmtn/getfile.py?id=fa7e3b0e1fa2d612403b4249a3699780c86048ce&path=packages/linux/nslu2-linksys-kernel-2.4.22/nslu2/defconfig |
| 18:17.06 | mkrause | thanks :) |
| 18:24.13 | CIA-8 | 03jbowler 07org.openembedded.nslu2-linux * r726e7491... 10/ (7 files in 6 dirs): |
| 18:24.13 | CIA-8 | propagate from branch 'org.openembedded.dev' (head 888665f8d2b7e9a8781c746c740393ab7115129a) |
| 18:24.13 | CIA-8 | <PROTECTED> |
| 18:43.05 | jbowler | [cc]smart: I just got a hang after a reflash - a system where /dev/mtdblock4 was not mounted anywhere. |
| 18:45.18 | [cc]smart | hm |
| 18:45.41 | [cc]smart | but it had booted... ? |
| 18:46.16 | jbowler | ? I executed shutdown -r, so yes, it had to have booted. |
| 18:46.42 | [cc]smart | hrhr... cause you saiod "after a reflash" which i interpreted different :) |
| 18:47.05 | jbowler | xscale-reset.patch also seems to be relevant, since now I can't even get the original working scenario to work. |
| 18:47.06 | [cc]smart | so you made a flash image that would go to external media directly ? |
| 18:47.23 | jbowler | no, I did reflash -i then shutdown -r and it hung. |
| 18:47.51 | jbowler | Then I power cycled, booted to the new kernel, and now shutdown -r hangs even though my remount,ro fix is there. |
| 18:47.56 | [cc]smart | er, but then mtdblock4 is / no ? |
| 18:48.59 | [cc]smart | hmmm.... |
| 18:49.05 | [cc]smart | new observation... |
| 18:49.42 | [cc]smart | ah no |
| 18:49.44 | [cc]smart | irrelevant |
| 18:52.05 | jbowler | No, everything is as before - diskfull system, /dev/mtdblock4 mounted on /initrd ro, or not mounted at all. |
| 18:52.30 | jbowler | I'm backing out the kernel change though - I'm just going to remove the 4s timeout. |
| 18:59.05 | [cc]smart | does reboot -n actually o what it should ? |
| 19:00.17 | jbowler | I should think so, it can be fairly important. |
| 19:03.41 | [cc]smart | these are the mounts left right before reboot: |
| 19:03.43 | [cc]smart | rootfs / rootfs rw 0 0 |
| 19:03.44 | [cc]smart | /dev/sda1 / reiserfs ro 0 0 |
| 19:03.44 | [cc]smart | proc /proc proc rw,nodiratime 0 0 |
| 19:03.44 | [cc]smart | ramfs /dev ramfs rw 0 0 |
| 19:04.33 | jbowler | All of which are totally harmless I think. What's more shutdown -r always works if the root is on /dev/mtdblock4. |
| 19:05.25 | jbowler | I'm finding your suggestion more and more believable - suppose that the hang happened if the last access to the flash was a write, not a read? |
| 19:05.33 | [cc]smart | but hten theres no rootfs / rootfs rw 0 0 |
| 19:06.03 | jbowler | ? That's the orginal kernel root. |
| 19:07.33 | jbowler | I.e. linux hangs everything off of that psuedo filesystem. |
| 19:08.00 | [cc]smart | yes, could it be that the reboot tries to get rid of that ? |
| 19:08.16 | [cc]smart | eh |
| 19:08.22 | [cc]smart | but still the kernel is halted |
| 19:08.25 | [cc]smart | or hung |
| 19:08.29 | [cc]smart | really hung |
| 19:08.32 | [cc]smart | maybe |
| 19:09.24 | [cc]smart | verification of the mode of the flash should be realtively easy with a scope |
| 19:09.43 | [cc]smart | so it could be compared between normal boot and this reboot situation |
| 19:14.33 | AdamBaker | I haven't checked what flash chip is in the slug but most flash chips I've had to deal with recently generate Vpp internally so you can't tell from outside if it is still in write state. |
| 19:15.18 | [cc]smart | i love it when plans work |
| 19:16.58 | jbowler | Well, looking at the state of the system might tell us if it hung at the reset or whether it got some way into the RedBoot reboot before it got stuck. That would be useful... |
| 19:17.57 | jbowler | Hum. util-linux doesn't work for me with glibc either - it tries to link something using the build gcc at the do_install step. |
| 19:18.18 | jbowler | | gcc mount.o fstab.o sundries.o xmalloc.o realpath.o mntent.o version.o get_label_uuid.o mount_by_label.o mount_blkid.o mount_guess_fstype.o getusername.o ../lib/setproctitle.o ../lib/env.o nfsmount.o nfsmount_xdr.o nfsmount_clnt.o lomount.o ../lib/xstrncpy.o -o mount |
| 19:18.18 | jbowler | | /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5-20050130/../../../../i686-pc-linux-gnu/bin/ld: mount.o: Relocations in generic ELF (EM: 40) |
| 19:18.18 | jbowler | | mount.o: could not read symbols: File in wrong format |
| 19:18.24 | jbowler | Anyone else see that? |
| 19:19.08 | [cc]smart | will try baking |
| 19:29.28 | [cc]smart | hmmm. could the main Makefile be modified to use a configfile, too, so that i can select what it should care for and what is not used by me ? |
| 19:29.56 | [cc]smart | dont need unslung optware and bitbake there |
| 19:30.18 | jbowler | There's a target for just openslug I think. |
| 19:30.32 | jbowler | Also, cd openslug, source setup-env, bitbake -i ;-) |
| 19:30.49 | [cc]smart | but the update stuff is nice |
| 19:31.34 | jbowler | I have to admit I just have a shell script which syncs everything, does a backup, then waits 10 minutes... |
| 19:31.38 | [cc]smart | so you dont forget the cvs on oe-symlinks et al |
| 19:31.52 | jbowler | Ah. Yes, well, I don't use those. |
| 19:32.45 | [cc]smart | you backup all stuff every 10 minutes ? |
| 19:33.05 | [cc]smart | and a high rate of HD exchange... |
| 19:33.43 | jbowler | I back up all the synced stuff by monotone sync to an NSLU2 running a monotone server. |
| 19:33.53 | *** join/#nslu2-linux rwhitby-treo (~upirc@rwhitby.nslu2-linux) |
| 19:33.59 | [cc]smart | ah |
| 19:34.08 | [cc]smart | that eases the load a bit |
| 19:34.11 | [cc]smart | :) |
| 19:34.12 | jbowler | Because if I don't back it up every time there is a new rev the NSLU2 monotone server will take forever... |
| 19:35.03 | rwhitby-treo | jbowler: One thing I noticed with Unslung is that it prints something like "putting flash into read mode" as it reboots ... |
| 19:35.30 | [cc]smart | eek |
| 19:35.32 | jbowler | Ah ha, now that is a clue... |
| 19:36.00 | rwhitby-treo | I wonder if someone can strace the Do_Reboot in Unslung ... |
| 19:36.03 | [cc]smart | now just tell me that there is a linksys kernel patch around .... |
| 19:36.14 | [cc]smart | i will snoop unslung sources a bit |
| 19:36.18 | jbowler | It's also consistent with everything we've seen so far... I just got my shutdown -r now fix working, but a the cost of retaining the fake soft reboot and 0.25s watchdog timeout. |
| 19:36.36 | jbowler | [cc]smart: build unslung |
| 19:36.38 | jbowler | ;-) |
| 19:37.29 | *** part/#nslu2-linux rwhitby-treo (~upirc@rwhitby.nslu2-linux) |
| 19:37.33 | [cc]smart | sth awoke the undead |
| 19:37.40 | [cc]smart | :) |
| 19:38.25 | jbowler | in fact I think bb unslung-kernel will probably work - but take care to delete tmp/deploy/zImage to avoid confusion... |
| 19:40.05 | jbowler | Ok. This is crazy but it works - my xscale-reset patch, soft reboot (which never completes) and mount -o remount,ro /initrd Yuck. |
| 19:41.06 | [cc]smart | NOTE: package util-linux-2.12q: completed |
| 19:41.07 | [cc]smart | NOTE: build 200507172131: completed |
| 19:51.20 | jbowler | [cc]smart: can you tell me what the timestamps are on two files in the working directory - ls -l work/util-linux*/*/mount/nfsmount_xdr.? |
| 19:51.30 | *** join/#nslu2-linux [g2] (~g2@g2.nslu2-linux) |
| 19:54.05 | CIA-8 | 03jbowler 07org.openembedded.nslu2-linux * r6b3cc2b0... 10/packages/ (6 files in 4 dirs): |
| 19:54.05 | CIA-8 | Horrible hacky, maybe working, work round for shutdown -r. Please report |
| 19:54.05 | CIA-8 | any future hangs on shutdown -r in slugbug 145. |
| 19:57.03 | [cc]smart | er, timestamp of noe ? |
| 19:57.31 | [cc]smart | s/noe/now/ |
| 19:59.41 | *** join/#nslu2-linux kolla_ (kolla@firda.kolla.no) |
| 20:03.14 | jbowler | The modification time of the two files - the .o and the .c |
| 20:05.16 | [cc]smart | already deleted again |
| 20:05.28 | [cc]smart | but well, they were of now |
| 20:05.35 | [cc]smart | current time |
| 20:05.40 | [cc]smart | CET |
| 20:06.45 | [cc]smart | seen the OE mail by freyther regarding quoting in bb files ? |
| 20:06.55 | [cc]smart | will car for the openslug ones |
| 20:07.00 | [cc]smart | s/car/care/ |
| 20:10.49 | AdamBaker | I just checked out Rod.s suggestion (but didn't want to actually reboot the slug) |
| 20:10.49 | AdamBaker | DO_Reboot is a shell script which calls /etc/rc.d/rc.reboot |
| 20:10.49 | AdamBaker | /etc/rc.d/rc.reboot is a shell script which calls busybox to do the reboot |
| 20:10.49 | AdamBaker | I haven't looked but I assume the Linksys source download includes the version of busybox they used |
| 20:13.06 | rwhitby-away | heh - bad assumption |
| 20:15.26 | [cc]smart | it doesn't seem that linksys busybox coontains unusual/flash related strings. |
| 20:18.31 | rwhitby-away | maybe it's in the kernel ... |
| 20:20.19 | [cc]smart | how do you uncompress vmlinuz ? |
| 20:20.49 | jbowler | It's LZ77 I believe, gunzip might work. |
| 20:22.23 | [cc]smart | didnt |
| 20:22.28 | [cc]smart | need to check... |
| 20:22.40 | rwhitby-away | [cc]smart: see the firmware/Makefile in unslung cvs (might have to look in the attic) |
| 20:22.52 | rwhitby-away | unslung 1.0 used to binary sed the kernel |
| 20:25.06 | [cc]smart | arg |
| 20:25.24 | [cc]smart | something scary for nightmares |
| 20:26.01 | rwhitby-away | it wasn't just strings either - we binary edited a number in the code ... |
| 20:45.34 | jbowler | +#ifdef CONFIG_MTD_CFI_INTELEXT |
| 20:45.35 | jbowler | +/* |
| 20:45.35 | jbowler | + * Set the Intel flash back to read mode as MTD may leave it in command mode |
| 20:45.35 | jbowler | + */ |
| 20:46.10 | rwhitby-away | where's that? |
| 20:46.25 | jbowler | 2.4.22-xfs-nslu2.patch |
| 20:46.34 | rwhitby-away | there ya go |
| 20:46.36 | jbowler | Here's another: |
| 20:46.38 | jbowler | ++/* |
| 20:46.38 | jbowler | ++ * HACK: Put flash back in read mode so RedBoot can boot properly. |
| 20:46.38 | jbowler | ++ */ |
| 20:47.27 | jbowler | That's the one with the message, but it does the same thing. |
| 20:47.51 | rwhitby-away | well, that calls for an openslug binary release :-) |
| 20:48.36 | jbowler | If it works then the only remaining issue is irq26 - it would be nice to kill that too. |
| 20:49.08 | rwhitby-away | apparently lennert thinks that's a "comment it out" issue :-) |
| 20:49.20 | rwhitby-away | (but I've got that third or fourth -hand) |
| 20:50.41 | [g2] | jbowler, yes lennert does feel that way |
| 20:51.14 | [g2] | jbowler, excellent news on the reboot |
| 20:51.56 | [g2] | bewoolie had some concerns that that might be the issue as he ran into a similar problem on the sharp platform |
| 20:54.50 | [g2] | You'd think that the jffs2 code would automatically do that when umounting the jffs2 system |
| 20:55.08 | [g2] | actually... that *last* jffs2 partition |
| 20:55.15 | rwhitby-away | it's board-specific |
| 20:55.16 | jbowler | Why? |
| 20:55.27 | jbowler | It's not a jffs2 issue. |
| 20:55.35 | rwhitby-away | jbowler: so it will go in nslu2-setup.c ? |
| 20:56.05 | jbowler | I don't know what it's doing yet. It's a patch to the MTD driver. |
| 20:56.51 | [g2] | I think both Redboot and APEX don't boot properly |
| 20:57.08 | rwhitby-away | [g2]: it's bootloader independent |
| 20:57.30 | [g2] | nod... the Intel Flash chip is left in a bad state right ? |
| 20:58.02 | rwhitby-away | jbowler: nod - it's a mtd maps patch |
| 20:58.04 | jbowler | The fix is in the current kernel source. |
| 20:58.23 | jbowler | It probably just isn't getting called... |
| 20:58.27 | [g2] | The avila boards may have the same issue or they may yank the chip reset and have a work around |
| 20:59.25 | [g2] | jbowler, is that 2.6.12.2 ? |
| 20:59.45 | jbowler | Someone who understands the device drivers needs to have a look at this. It seems to be there in the driver remove code. |
| 20:59.53 | rwhitby-away | jbowler: can't see it in mtd/maps/ixp4xx.c ... ? |
| 21:00.39 | jbowler | Line 121 |
| 21:01.16 | rwhitby-away | ah, right. |
| 21:01.29 | jbowler | So I don't think the whole remove thing is actually called. |
| 21:02.08 | jbowler | And it would be called if the .remove proc was invoked. |
| 21:02.10 | [g2] | probably be easy enough to add a printk in there |
| 21:03.19 | rwhitby-away | called from del_mtd_device in mtdcore.c, but that might not be called either |
| 21:06.11 | [g2] | it's *really* nice having kernel messages back again |
| 21:08.28 | rwhitby-away | jbowler: I think we need to add the explicit register_reboot_notifier to ixp4xx.c with a NSLU2 arch ifdef around it |
| 21:08.41 | dyoung-zzzz | <PROTECTED> |
| 21:08.55 | dyoung | so the reboot issueu is done? |
| 21:09.06 | dyoung | and I can stop looking now? |
| 21:09.19 | rwhitby-away | dyoung: stop looking and start patching :-) |
| 21:09.44 | dyoung | what was the verdict? mtd driver needs to be forcibly put into read mode? |
| 21:10.10 | jbowler | There's code in there to close down the flash correctly, the hypothesis is that none of it is called. |
| 21:10.41 | rwhitby-away | I think we need to take the ixp425_mtd_reboot, ixp425_mtd_notifier and the calls to [un]register_reboot_notifier from unslung's drivers/mtd/maps/ixp425.c and put them in openslug's drivers/mtd/maps/ixp4xx.c with an NSLU2 ifdef around them |
| 21:12.14 | jbowler | Deepak Saxena did the original patch, and did the ixp4xx code too - since the reboot notifier was removed it was probably unnecessary. |
| 21:12.54 | jbowler | After all there must be some way of calling that remove API... |
| 21:13.27 | dyoung | line 105 of drivers/mtd/maps/ixp4xx.c |
| 21:13.48 | [g2] | actually... in 2.6.12.2 we are probably not using the api except for the code that dyoung put it for the nslu2-setup.c |
| 21:13.48 | dyoung | I've seen these calls before, one moement. |
| 21:13.59 | jbowler | Yes - all that stuff, although the first patch only did line 121. |
| 21:14.54 | jbowler | I suspect it worked for a hard reset, but without the last line a soft reset wouldn't work. |
| 21:15.01 | rwhitby-away | jbowler: my guess is that we are missing something in our shutdown sequence, which keeps the mtd devce driver loaded, and so that remove routine never gets called |
| 21:15.48 | jbowler | Yes, that is also possible, however I've reproduced the problem where the last thing done to the flash was writing direct to /dev/mtdblock? |
| 21:15.54 | rwhitby-away | maybe deepak never had occasion to pivot_root an ixp4xx board ... |
| 21:16.37 | [g2] | well.. I was thinking we've pivoted and umountd the initrd |
| 21:16.52 | [g2] | is the driver even active ? |
| 21:17.22 | rwhitby-away | who knows. I vote for just putting the reboot notifier in, and punting on the whole issue. |
| 21:17.52 | [g2] | for testing yes |
| 21:18.00 | rwhitby-away | it's not like it's going to have any side-effects after that code is executed :-) |
| 21:18.12 | rwhitby-away | (apart from allowing the reboot to proceed) |
| 21:18.13 | [g2] | for production... we should fix this properly and get it upstream if it's not already there |
| 21:18.38 | [g2] | I'm looking to get all the kernel changes upstream |
| 21:19.02 | rwhitby-away | I disagree. A forcible reboot should always work, no matter what other state the rest of the kernel drivers are in. |
| 21:19.12 | rwhitby-away | (disagree on testing vs production) |
| 21:19.38 | rwhitby-away | My position is that this reboot notifier must be in production too, to handle rebooting when the kernel drivers are in a bad state. |
| 21:19.50 | [g2] | I fully agree the forcible reboot should always work too |
| 21:20.06 | rwhitby-away | To assume that the mtd device can always be unloaded when you need to reboot is not a safe assumption. |
| 21:20.13 | [g2] | I'm just saying that I'm not convinced the fix is the only and most proper one |
| 21:20.41 | jbowler | class_simple_device_remove? |
| 21:21.10 | rwhitby-away | [g2]: I'm saying that irrespective of whether there is another fix which should be done, the reboot notifier should be there anyway. |
| 21:21.32 | [g2] | that may very well be the case |
| 21:22.04 | rwhitby-away | of course adding the reboot notifier will mask whatever the other fix may be required for ... |
| 21:22.20 | rwhitby-away | but if it's for a reboot, then who cares ... |
| 21:22.27 | [g2] | I'm wondering if our 2.6.12.x port is missing somethings like possibly the reboot notifier because of the way we implemented it |
| 21:23.01 | jbowler | rwhitby-away: it looks to me that the platform_notify slot has already been used up in common-pci.c |
| 21:23.27 | jbowler | Ah, hang on, that's remove, not reboot... |
| 21:24.40 | jbowler | Ok, so there is a registration interface, not a single slot, but is it used? |
| 21:29.58 | dyoung | can someone verify the sanity of line 51 in nslu2-setup.c please |
| 21:30.39 | *** join/#nslu2-linux bwalle (~bwalle@p5491A1A5.dip0.t-ipconnect.de) |
| 21:32.14 | *** join/#nslu2-linux bwalle (~bwalle@p5491A1A5.dip0.t-ipconnect.de) |
| 21:33.14 | jbowler | dyoung: it seems to be the same as ixdp425-setup.c (which doesn't mean it is correct) |
| 21:36.50 | [g2] | reflash -k zImage-printk |
| 21:36.50 | [g2] | reflash: /boot/rootfs.jffs2: root file system image file not found |
| 21:36.52 | [g2] | ???? |
| 21:37.22 | jbowler | That would seem to be correct, if the file name extensions are to be believed. |
| 21:38.03 | jbowler | BTW that's an old reflash I think. |
| 21:38.24 | [g2] | is there a version number ? |
| 21:38.57 | jbowler | Try reflash --help |
| 21:39.09 | dyoung | jbowler, is that line the same as saying .dev.platform_data = &nslu2_flash_data ? |
| 21:39.11 | [g2] | reflash --help |
| 21:39.12 | [g2] | reflash: usage: /usr/sbin/reflash [-k kernel -j rootfs] | -i image |
| 21:39.12 | [g2] | <PROTECTED> |
| 21:39.12 | [g2] | <PROTECTED> |
| 21:39.12 | [g2] | <PROTECTED> |
| 21:39.12 | [g2] | <PROTECTED> |
| 21:39.28 | jbowler | That's an old one. |
| 21:40.02 | jbowler | Note the options: [-k kernel -j rootfs] | -i image |
| 21:40.27 | [g2] | it should only be a week or so old |
| 21:41.05 | rwhitby-away | that's a looooong slugtime |
| 21:41.43 | jbowler | ipkg install openslug-init |
| 21:41.58 | jbowler | (from unstable) |
| 21:42.54 | [g2] | I've got a test kernel which does the printk before and after the check for the !info the mtd remove function |
| 21:43.18 | [g2] | this is a clean FatTurbo that was setting of for package testing |
| 21:43.48 | [g2] | however, this is an very important topic and I'd like to try to help get closure on this issue |
| 21:44.48 | dyoung | [g2] thats what I'm trying to determine. |
| 21:44.53 | dyoung | does info return 0 or not |
| 21:45.06 | dyoung | if it doesnt, we know where to look. |
| 21:45.14 | [g2] | I'm ready to test and I'm search the logs for the devio comd |
| 21:45.16 | [g2] | cmd |
| 21:45.42 | [g2] | Jun 01 11:22:38 <jbowler> This command: devio '<<zImage-openslug;>>/dev/mtdblock2;wb$16+4;fb12,0;cp$' |
| 21:45.48 | [g2] | that one |
| 21:46.33 | [g2] | DOH! I'm such a dumbass |
| 21:47.34 | [g2] | it's a cp /initrd/boot for me |
| 21:47.38 | [g2] | and a reboot |
| 21:49.35 | [g2] | sigh... |
| 21:49.50 | [g2] | Ok... this slug is a litte out of date |
| 21:51.49 | [g2] | ok... this will work better |
| 21:59.45 | [g2] | http://pastebin.ca/17940 |
| 21:59.58 | [g2] | it appears to me that the routine is not getting called |
| 22:00.32 | jbowler | Yes, that's the same as [cc]smart saw earlier today. |
| 22:01.34 | [g2] | ah.. sorry I missed that |
| 22:01.56 | [g2] | I didn't know you guys had already verifed via running code that it didn't get called |
| 22:03.41 | jbowler | No - we didn't - I'm saying that there is no extra message in your code |
| 22:04.05 | jbowler | Adding a printk didn't change anything. |
| 22:04.15 | [g2] | Oh.. I did have extra messages in my code and that was the print out with the missing messages |
| 22:04.27 | jbowler | Right. |
| 22:09.21 | dyoung | is that code supposed to be run at startup or shutdown |
| 22:09.40 | dyoung | I would have expected it at startup |
| 22:10.14 | jbowler | ixp4xx_flash_remove? It's run on error from the probe, to clean up, and when the device is removed. |
| 22:12.25 | [g2] | what's the mbcache module btw ? |
| 22:19.38 | [g2] | dyoung, jbowler rwhitby-away etc.... From my kernel novice understanding we are running the cfi driver and the ixp4xx.c code is running the ixp4xx driver |
| 22:20.29 | rwhitby-away | http://www.amazon.com/exec/obidos/tg/detail/-/B0000DF2GD/ref=e_de_a_smtpd/104-3248000-3615135?v=glance&s=electronics&vi=tech-data <- this thing runs linux ... |
| 22:21.37 | [g2] | yeah... the AXIS like is for the SOC and there was even and Open FPGA code that did the video encoding |
| 22:22.08 | [g2] | they've been doing that stuff for 1-2 years probably |
| 22:22.22 | dyoung | more than that. |
| 22:22.25 | [g2] | there was a really cool article on linuxdevice about that |
| 22:22.37 | dyoung | I had a linux-ified axis many years ago. |
| 22:22.45 | [g2] | nod |
| 22:22.45 | dyoung | it was $$$ |
| 22:22.49 | [g2] | nod. |
| 22:22.51 | [g2] | :) |
| 22:23.43 | [g2] | So... I think we are passing a device text name of IXP4XX-Flash, but are really running the CFI driver |
| 22:23.56 | [g2] | agree, disagree ? |
| 22:24.47 | *** part/#nslu2-linux marceln (~marceln@pion.xs4all.nl) |
| 22:26.03 | dyoung | but we're calling the cfi detection reoutines. |
| 22:27.26 | [g2] | right CFI finds the flash |
| 22:28.26 | rwhitby-away | dyoung: the axis 205 is starting to get into a reasonable price range ... |
| 22:29.00 | rwhitby-away | alternatively: this one has pan and tilt too: http://www.amazon.com/exec/obidos/tg/detail/-/B0002GS4Z0/ref=pd_bxgy_text_1/104-3248000-3615135?v=glance&s=electronics&st=* |
| 22:29.28 | dyoung | Yeah, at $180 its starting to get cheaper to get one of those instead of fooling around with nslu2's |
| 22:33.50 | jbowler | Something weird here: remove is called to dissociate a driver with a device. This may be |
| 22:33.50 | jbowler | called if a device is physically removed from the system, if the |
| 22:33.51 | jbowler | driver module is being unloaded, or during a reboot sequence. |
| 22:51.33 | CIA-8 | 03ingeba * 10unslung/make/openvpn.mk: Added dependency for kernel-module-tun.mk |
| 22:52.16 | CIA-8 | 03ingeba * 10unslung/make/openvpn.mk: Bumped IPK number |
| 22:53.41 | *** join/#nslu2-linux bwalle (~bwalle@p5491A1A5.dip0.t-ipconnect.de) |
| 22:54.49 | CIA-8 | 03ingeba * 10unslung/make/samba.mk: Added cups staging to ensure the presence of cups.h in staging area |
| 22:55.30 | jbowler | [g2]: can you try out this patch: http://pastebin.ca/17943 |
| 22:55.47 | bwalle | @bob_tm-toandfrom: Are you Inge Bjørnvall Arnesen? |
| 22:55.56 | jbowler | It should result in the remove API being called, but on my system something goes wrong at that point. |
| 22:55.57 | bob_tm-toandfrom | bwalle: Yes |
| 22:56.23 | bwalle | Because of the capital letter issue: Do you have the latest ipkg-utils installed? |
| 22:56.27 | bwalle | I don't have this problem. |
| 22:56.39 | bob_tm-toandfrom | Are you cross or native? |
| 22:56.42 | bwalle | But if it is the policy to have lowsercase letters in package names, I can change |
| 22:56.45 | bwalle | cross |
| 22:57.04 | bob_tm-toandfrom | Hmmm... it is all from the common make system - just a moment. |
| 22:57.22 | [g2] | jbowler, sure I think I and try that |
| 22:57.29 | [g2] | I can |
| 22:57.40 | jbowler | You should get your message then probably an oops. |
| 22:57.53 | jbowler | (It doesn't hang the kernel - the power button still works). |
| 22:58.03 | bwalle | I have the solution: It depends on $LANG |
| 22:58.19 | bwalle | Normally I have LANG=de_DE.utf-8, no error. With LANG=C I get the same error as you |
| 22:58.38 | bwalle | This means I'll fix the package name. Just wait a moment |
| 22:59.30 | bwalle | Well, this means I have to delete fIcy.mk and re-add ficy.mk |
| 22:59.32 | bob_tm-toandfrom | bwalle: Ah - that explains it. AFAIK all packages are lower case only - sort of remember an issue about gIft (or whatever the real name is) |
| 23:00.32 | bob_tm-toandfrom | bwalle: You won't believe it, but there are 11 versions of ipkg-build in the make system (some are i686 and some ARM though) |
| 23:01.36 | bwalle | Don't understand the last message |
| 23:02.08 | CIA-8 | 03ingeba * 10unslung/make/sysstat.mk: Upgraded to 6.0.1 as 6.0.0 was no longer availabel - bumped IPK number |
| 23:02.37 | bob_tm-toandfrom | Oh - it is just that there are so many binaries of the same program in the Unslung/openslug make file system, so it is hard to find which is actually being used. |
| 23:03.04 | bwalle | :) |
| 23:03.49 | bob_tm-toandfrom | bwalle: Need to go to bed. I'm on CET summer time like you, but my sleep pattern is all screwed up. |
| 23:04.10 | jbowler | Ok, fixed hard reboot but not soft - something after the 0x55 stuff hangs. |
| 23:04.27 | bob_tm-toandfrom | I will look at fIcy tomorrow - will be fun. Thanks for the port! Keep up the good work! |
| 23:04.29 | bwalle | ok |
| 23:04.45 | bwalle | Good night :) |
| 23:04.50 | bob_tm-toandfrom | Night all |
| 23:06.22 | [g2] | jbowler, our code is different |
| 23:06.36 | CIA-8 | 03bwalle * 10unslung/ (Makefile make/ficy.mk make/fIcy.mk): Renamed fIcy to ficy. |
| 23:06.42 | [g2] | you've got: |
| 23:06.47 | [g2] | # |
| 23:06.47 | [g2] | <PROTECTED> |
| 23:06.47 | [g2] | # |
| 23:06.47 | [g2] | @@ -243,6 +248,7 @@ |
| 23:07.04 | [g2] | I've got |
| 23:07.09 | [g2] | <PROTECTED> |
| 23:07.09 | [g2] | <PROTECTED> |
| 23:07.31 | jbowler | It's a patch to 2.6.12.2 |
| 23:08.47 | [g2] | jbot, I've got 2.6.12.2 |
| 23:09.04 | [g2] | ~lart autocomplete |
| 23:09.06 | jbowler | It's just setting up the 'shutdown' member of the driver structure (with the remove function). |
| 23:09.10 | dyoung | wait a minute |
| 23:09.17 | dyoung | [g2] what file are you trying to patch? |
| 23:09.43 | dyoung | I think youre talking about diffnert files |
| 23:10.05 | [g2] | <PROTECTED> |
| 23:10.34 | jbowler | I have [g2]'s line in my (driver/mtd/maps) file, it's after the probe API. Let me check is I damaged the.orig |
| 23:11.00 | [g2] | very similar |
| 23:11.51 | jbowler | No diff. |
| 23:12.24 | jbowler | I.e. my orig file is an exact match for the ixp4xx.c in a build tree I have from 0715 |
| 23:15.36 | jbowler | 2634d3ce89ebac6cdffa804747127183 ixp4xx.c |
| 23:15.51 | jbowler | And it is identical in 2.6.11.2 as well. |
| 23:16.41 | [g2] | are you looking at the pre or post patched version |
| 23:16.57 | jbowler | post |
| 23:17.07 | jbowler | It's a patch to the source in the tree. |
| 23:17.45 | [g2] | it that the sha1 on the ixp4xx.c ? |
| 23:20.55 | jbowler | Yes |
| 23:21.29 | jbowler | It's the sha1 (md5sum) of the original (OE patched) file, before my patch. |
| 23:21.53 | [g2] | sha1sum tmp/work/openslug-kernel-2.6.12.2-r0/linux-2.6.12.2/drivers/mtd/maps/ixp4xx.c |
| 23:21.53 | [g2] | fc87a723aa5563bccc1714d31d14ef0e56e27057 tmp/work/openslug-kernel-2.6.12.2-r0/linux-2.6.12.2/drivers/mtd/maps/ixp4xx.c |
| 23:22.28 | [g2] | md5sum... |
| 23:22.48 | [g2] | <PROTECTED> |
| 23:22.48 | [g2] | 2634d3ce89ebac6cdffa804747127183 tmp/work/openslug-kernel-2.6.12.2-r0/linux-2.6.12.2/drivers/mtd/maps/ixp4xx.c |
| 23:22.58 | [g2] | md5's match |
| 23:23.59 | [g2] | line 15 in the path file isn't right then in http://pastebin.ca/17943 |
| 23:24.00 | jbowler | tabs converted to white space? |
| 23:24.17 | [g2] | could be from |
| 23:24.23 | [g2] | something like that |
| 23:25.07 | [g2] | but the struct before the 243 is clearly not that same as in file |
| 23:26.55 | jbowler | That's line 149. Looks identical to me (apart from tab vs spaces) |
| 23:27.17 | *** join/#nslu2-linux Tiersten (tman@Tiersten.nslu2-linux) |
| 23:27.26 | [g2] | Ahhh... ok |
| 23:27.47 | [g2] | the stuff after line 243 starts with .bus.... |
| 23:28.10 | jbowler | No, that would be line 243, and that is .bus |
| 23:28.50 | CIA-8 | 03bzhou * 10unslung/make/py-psycopg.mk: source site moved, fixed the location |
| 23:34.44 | jbowler | What's really annoying is that every test involves rebooting twice, once to get the new kernel after flashing it, once to test it... |
| 23:35.08 | [g2] | jbowler, actually you can just load the kernel via tftp and boot |
| 23:35.45 | jbowler | I never managed to get that to work. |
| 23:36.57 | jbowler | The (new) hang is in one of the following three lines: |
| 23:36.59 | jbowler | <PROTECTED> |
| 23:36.59 | jbowler | <PROTECTED> |
| 23:37.07 | jbowler | <PROTECTED> |
| 23:38.47 | jbowler | Maybe those things can't be done in shutdown. |
| 23:49.06 | jbowler | It's one of the first two lines. |