collie and kernel from 3.5.3 upgrades

[magpie]

I have yet to flash the zImage-collie-64-0-r21.bin and opie-image-collie-20050407173817.rootfs.jffs2 without it hanging at the configuring-modules.

However today I flashed with only the r21.bin and it hung on booting. After Ctrl+C it continued only to hand at starting networking and after another Ctrl+C it continued.

I am unable to start any networking services and will continue to play and troubleshoot for now.

Thanks to the developers for their time and effort.

[Storm]

I dont know why you guys have a problem with r21 kernel on collie.

My collie has OZ 3.5.3 installed after it was released, updated with upgrades and I just flashed r21 kernel and started machine. All works ok. No hangs during startup, no Big Red Warning message - just like it has to be.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=87065\"][{POST_SNAPBACK}][/a][/div]

HRW and all,

I noticed that in a couple of different cases where users have reported issues, both you and Mickeyl have been unable to reproduce the problem. Since both of you are in Europe, I thought that may be a regional issue (e.g. SL-5500 vs. SL-5500G)...Or it could be related to different manufacturer's chips used in construction or rev levels of internal firmware?

I'm just guessing here, but is it possible? Especially with the broad range of manifestations of the original problems (some had problems even after modifying /etc/device_table, some had few problems leaving device_table unmodified, etc) as well as the range of behavior with the new kernel. I know some of it is configuration options we use (for instance, I am pivoting root to the SD card), etc.

Just a thought,
--Storm

[ndsipa pomu]

I dont know why you guys have a problem with r21 kernel on collie.

My collie has OZ 3.5.3 installed after it was released, updated with upgrades and I just flashed r21 kernel and started machine. All works ok. No hangs during startup, no Big Red Warning message - just like it has to be.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=87065\"][{POST_SNAPBACK}][/a][/div]

HRW and all,

I noticed that in a couple of different cases where users have reported issues, both you and Mickeyl have been unable to reproduce the problem. Since both of you are in Europe, I thought that may be a regional issue (e.g. SL-5500 vs. SL-5500G)...Or it could be related to different manufacturer's chips used in construction or rev levels of internal firmware?

I'm just guessing here, but is it possible? Especially with the broad range of manifestations of the original problems (some had problems even after modifying /etc/device_table, some had few problems leaving device_table unmodified, etc) as well as the range of behavior with the new kernel. I know some of it is configuration options we use (for instance, I am pivoting root to the SD card), etc.

Just a thought,
--Storm
[div align=\"right\"][a href=\"index.php?act=findpost&pid=87167\"][{POST_SNAPBACK}][/a][/div]

I've had the same problem with my collie (SL-5500) bought from the UK. I'm also pivoting root to the SD card  - if that's any help.

[l0n3star]

 Hmmmm...

Anyoune with a SL-5000D who can confirm that I'm not the only one that has
a zaurus that has the suspend/resume issues even with the new kernel?

Greetings,

Andreas

Hi,

I've tried this update with a SL-5000D and it worked without any problems (except
the wrong kernel issue when booting).

BUT:

I still have the suspend/resume issues!!!

This fix doesn't seem to work with SL-5000D (at least with mine). For example:
Pressing Right-Button or Menu at the "waiting one minute state" does suspend my
Zaurus.

Any Ideas?

Greetings,

Andreas

P.S.: Same with OZ 3.5.2, only working Version for me is 3.5.1
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86676\"][{POST_SNAPBACK}][/a][/div]

[m3xican]

I dont know why you guys have a problem with r21 kernel on collie.

My collie has OZ 3.5.3 installed after it was released, updated with upgrades and I just flashed r21 kernel and started machine. All works ok. No hangs during startup, no Big Red Warning message - just like it has to be.

If I find some time then I will backup whole machine and try to reflash kernel (r21) with opie-image and post results.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=87065\"][{POST_SNAPBACK}][/a][/div]

I know well that this situation is very frustrating...
The worst thing for a developer is a software that works fine on his system but not on other systems.

So I have a proposal, Hrw could release a new zImage with a "verbose debug" mode on, something that could print out useful informations to understand the problem.

I have studied linux kernel this year, but I'm not a kernel hacker, and I have buyed my Z recently, so I can't give a big help... but I (and I think everyone here) would give an help to solve this problem, also just testing if this is useful.

My nights are at OZ disposal

[colin]

Hi,

I have a 5500 that is not working with the new kernel.

I did a compare between the working and not working kernels. I did an lsmod after booting using calender-C to get me through the new kernel boot. What I found was that there was no usbcore, net_fd and sa1100_bi, also  ipv6 and ipsec show up as initialising on the new kernel. As the working kernel show net_fd and sa1100_bi as using usbdcore I assume that the loading of usbdcore is a candidate for the problems we are seeing. I am guessing that the boot hang after 2 lines is because of the inability to load usbcore or the calender-C is preventing the usbcore module load.

Does this get us any further?

I also did a compare of dmesg outputs, but the amount of information means the stuff from the start of the boot on the new kernel is missing. The dmesg buffer gets filled with a load of exception/crash information. Is there a way to extend the dmesg buffer?

Cheers,

Colin

[m3xican]

Is there a way to extend the dmesg buffer?

quoting dmesg man

SYNOPSIS
       dmesg [ -c ] [ -n level ] [ -s bufsize ]

....

-sbufsize
              Use a buffer of size bufsize to query the kernel ring buffer.  This is 16392  by  default.   (The
              default kernel syslog buffer size was 4096 at first, 8192 since 1.3.54, 16384 since 2.1.113.)  If
              you have set the kernel buffer to be larger than the default then this option can be used to view
              the entire buffer.

I hope this could help you.

[Moreno]

I too have a similar problem, on the same hardware.
I've a SL-5500. I've followed the standard flashing procedure
who had always worked fine.
I've tried with zImage-collie-64-0-r21.bin (renamed zImage of course)
and opie-image-collie-20050407173817.rootfs.jffs2 (renamed initrd.bin).
The flashing go smoothly, but on startup the Z freezes on "configure update-modules".
Twice the flashing for twice the same result.
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

- SL-5500
- 256MB kingston CF
- [a href=\"http://www.openzaurus.org/official/unstable/3.5.3/sl5000,sl5500/gpe-image-collie-20050407173817.rootfs.jffs2]opie last release[/url]
- new collie kernel 64-0

And the same problem...
I have repeated twice the flashing procedure and the Z freezes on  "configure update-modules".

Flashing works fine with the previous 3.5.3 rom.

Please, fix this problem...
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86674\"][{POST_SNAPBACK}][/a][/div]

I've got the same.

SL5500 with zImage-collie-48-16-r21.bin
SanDisk 128Mb
and lates Opie.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=87092\"][{POST_SNAPBACK}][/a][/div]

Same problem here.

SL-5500
Sandisk 1 GB
zImage-collie-48-16-r21
opie image

[magpie]

Success.

After using Hentges http://www.hentges.net/misc/openzaurus/oz3...opie1.2.0.shtml with OpenZaurus .r21 zImage, it boots and works faster than ever, thanks to cardfs.

The suspend resume issue is resolved. Battery life is much more realistic.

[lardman]

I did a compare between the working and not working kernels. I did an lsmod after booting using calender-C to get me through the new kernel boot. What I found was that there was no usbcore, net_fd and sa1100_bi, also ipv6 and ipsec show up as initialising on the new kernel. As the working kernel show net_fd and sa1100_bi as using usbdcore I assume that the loading of usbdcore is a candidate for the problems we are seeing. I am guessing that the boot hang after 2 lines is because of the inability to load usbcore or the calender-C is preventing the usbcore module load.

What error is returned when you try to modprobe net_fd?


Si

[Mase]

I am having the exact same problem. I've just installed a brand new OZ 3.5.3 using the default opie-64-0 zImage and the initrd.bin.

Then to upgrade the kernel, i downloaded the zImage-collie-64-0-2..> kernel from the upgrades/ area.

I then removed everything from the CF card and copied the zImage-collie-64-0-2 file to the root directory as zImage so that only the zImage was on it.

I've also tried with both the new zImage and the initrd.bin file on the CF but this produced the problems quoted below.

What am i doing wrong?

er um...
I do the upgrade and the boot keeps in 'Configuring update modules' for more than 10 minutes, so i concluded that it freezed, so I repited the flash procedure and it freezed again.

I have a zaurus sl5500

Using this files to flash:
opie-image-collie-20050407173817.rootfs.jffs2
zImage-collie-32-32-r21.bin
of course, after renamig it to initrd.bin and zImage
[div align=\"right\"][a href=\"index.php?act=findpost&pid=86459\"][{POST_SNAPBACK}][/a][/div]

[Rev.Tigger]

Sucess ish....

Collie with Hentges ROM and brandnew super kernel !

Seems a bit quicker and yipee I can scroll right...


Alas I seem to now have a different problem,  now the Z does not seem to want to suspend via the cancel key and takes several attempts to suspend...

Then my darling little collie decides to be pedantic about turning back on,  and seems to save those extra keystrokes to turn itself off..  So when I turning the Z back on it turns itself off..  GAH!

So at the moment I am swearing at the damn thing to suspend and then when I turn it back on the blasted thing turns itself off (usually twice) before resuming operations again

I think the naming of the models after dogs is very appropiate,  sometimes I think it does thinks because it wants attention,  othertimes I think it is because it wants to go warwalkies instead of browsing the net

Loving the work of the OZ team   It is a fantastic platform

[Dan2]

Does your Z still crash after running

Code: [Select]

/etc/init.d/hotplug stop
and connecting / disconnecting USB?

Yes, it still did (crash, that is), however manually unloading the networking modules including usbdcore (one test where I only unloaded the two modules depending on it, but not this module itself produced the usual crash after the next suspend) before removing the Z from the cradle seems to do the trick (but I could only repeat the test twice due to lack of time), thanks for the hint. And yes, after putting the Z back in the cradle, the USB connection works again even after suspend/resume.

Your description of the Akita problems actually pretty well matches what I saw on my Collie the past few days...

Dan

[CoreDump]

I've just finished testing USB on my Collie.

It's running a not-yet-released RC of the Hentges ROM and a custom kernel fixing the
annoying "suspend on right-arrow" bug.

USB and USBNet work perfectly fine w/o any tweaks, even after a suspend/resume cycle.

I didn't experience any freezes / crashes.

[Mase]

OK how many people are having this issue? It's obvious that this isn't going to be something easy to fix since most of the people having the problem aren't developers and the developers have working machines and probably a lack of time.

So I guess my question is, would this be a problem that developers would be willing to give priority to if there was a "bounty" of sorts offered, and if so are people willing to contribute or pledge to the bounty? If so how much do we need to raise.?

Since the sharp ROM is essentially crap, and there isn't any acceptable commercial ROM (at least that i'm aware of), so i think most of us are  basically relying on OZ to become stable in order for the 5500 to actually be "useful" and not just a hunk of junk.