Oz 3.5.4 Rc Bug & Work-around List

[lardman]

Is the XScale cache bug workaround disabled ? Can one cat "something" somewhere in /proc/ to enable/disable it ?

I was wondering about this myself - you'll have to take a look at the kernel source and see if this is possible (and hack at it). The only issue I can see is whether or not such a transition can take place while the kernel is actually running.


Si

[Hrw]

Default OZ kernels for poodle (5600) have cache fixes enabled to get them working good on pxa250. That kernel run without problem also on pxa255 but we can also provide kernel without ixes enabled as such kernel is faster on pxa255 (but wont work good on pxa250).

[Mickeyl]

Is the XScale cache bug workaround disabled ? Can one cat "something" somewhere in /proc/ to enable/disable it ?

AFAIK the cache workaround can only be enabled/disabled at initialization time. BTW., the handhelds.org folks have a stub on their 2.4.x that automatically enables it when a PXA250 is found. That would be pretty useful for our kernel as well. I don't know if 2.6 contains that already.

[obergix]

May I suggest addition of CONFIG_TUN=m in defconfig-akita so that the kernel-module-tun be built, and openvpn being installable ?

Best regards,

[lardman]

Add this to the bug tracker as an enhancement.


Si

[obergix]

Add this to the bug tracker as an enhancement.


Si
[div align=\"right\"][{POST_SNAPBACK}][/a][/div]

Done : [a href=\"http://bugs.openembedded.org/show_bug.cgi?id=455]http://bugs.openembedded.org/show_bug.cgi?id=455[/url]

[Rev.Tigger]

In order to use WEP encription for wireless network, do I have to set the key to HEX on both the AP and the Z ?

Hi,  to use ASCI keys for WEP under 3.5.3 I had to prefix the key with s:

[obergix]

Hi.
Not sure this may be considered as a bug, but I think that it's not really a good idea to have rfcomm and other bluez modules loaded by default on akita... eats unecessarily memory, unless user adds bluetooth dongle/card. And since the SL-C1000 does not include a bluetooth chip, I think it is safe not to include it by default.

Maybe the problem is that task-bootstrap depends on packages like kernel-module-rfcomm-2.4.

What d'you think : bug, feature ?

Best regards,

[obergix]

Again some suggestion, although I'm not really sure ...

Should e2fsprogs-e2fsck (and e2fsprogs-fsck) be included in default images/tasks ?

It helps alot with things like adding e2fs partitions on SD, using altboot and such...

Your opinion ?

[kdbond]

I am having a problem with the keyboard in 3.5.4.  In particular, I cannot get the keyboard to enter underscore '_', also somettimes the numbers stop working, I press and release the Fn key before pressing the number.  A reboot always seems to bring back the number key, but never got any underscore.  On two occasions the keyboard has become completely non-functional until a reboot, though I cannot reproduce this behavior.

This is 3.5.4rc with Opie on an SL-C6000L

[ironstorm]

aumix from 3.5.3 is broken on 3.5.4RC on Collie/z5500...  outputs:

Code: [Select]

aumix: SOUND_MIXER_READ_RECSRC
and exits...

Bug Filed: http://bugs.openembedded.org/show_bug.cgi?id=488

[koen]

Hi.
Not sure this may be considered as a bug, but I think that it's not really a good idea to have rfcomm and other bluez modules loaded by default on akita... eats unecessarily memory, unless user adds bluetooth dongle/card. And since the SL-C1000 does not include a bluetooth chip, I think it is safe not to include it by default.

Maybe the problem is that task-bootstrap depends on packages like kernel-module-rfcomm-2.4.

What d'you think : bug, feature ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=103671\"][{POST_SNAPBACK}][/a][/div]

OZ (and Familiar) ships the default images with lots of connectivity tools and driver for popular cards. If we remove them people will say "OZ sucks because my card doesn't work" and if they stay in, people will say "OZ is too bloated". I'd let them stay in because the drivers are not that big and adds much needed userfriendliness

[obergix]

Hi.
Not sure this may be considered as a bug, but I think that it's not really a good idea to have rfcomm and other bluez modules loaded by default on akita... eats unecessarily memory, unless user adds bluetooth dongle/card. And since the SL-C1000 does not include a bluetooth chip, I think it is safe not to include it by default.

Maybe the problem is that task-bootstrap depends on packages like kernel-module-rfcomm-2.4.

What d'you think : bug, feature ?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=103671\"][{POST_SNAPBACK}][/a][/div]

OZ (and Familiar) ships the default images with lots of connectivity tools and driver for popular cards. If we remove them people will say "OZ sucks because my card doesn't work" and if they stay in, people will say "OZ is too bloated". I'd let them stay in because the drivers are not that big and adds much needed userfriendliness
[div align=\"right\"][a href=\"index.php?act=findpost&pid=104612\"][{POST_SNAPBACK}][/a][/div]

You're right.

What I meant is that the modules should not be *loaded* in memory on startup... having them on the "disk" is no such a big deal actually... it's more memory limits which is my concern, expecially with GPE.

So I agree for having the ipkg in the images, but maybe not the modules loaded, which would mean adapting the modules' conf files which render their loading on statup ?

[euroclie]

Hello,

Just tried the latest C3000 ROM images, with both Opie and GPE. I'm pretty much impressed by the result, but as mentioned in the original message of this thread, this is a release candidate only, and indeed we're far from really usable stuff.

I couldn't play very long with it, and so far have certainly not uncovered any new bug, but here's what I've found out so far, in case it helps any other C3000 owner to decide if this release candidate is worth installing or not:

1) GPE seems interesting, but there's that infamous suspend bug, so the C3000 can't be suspended at all, neither using the on/off button, not by typing "apm --suspend" in a console. End of the story as far as I'm concerned. I need to take my Zaurus with me and play with it for some time if I'm to find out anything usefull to report, and this obviously won't be the case until I can go away from the electric outlet on the wall...

2) Opie is more usable. I was able to connect to my home Wifi network using a D-Link DCF-660W CF card out of the box, it works great with WellenReiter as well, and using the builtin browser I loaded the google page in no time. Nice!

3) I was able to play a bit longer with Opie, and discovered the (already reported) bug with the Mail application not creating the proper folder structure for POP accounts, so I couldn't get it to work at all. Too bad, as I'll be away from home for a couple of days and really need access to my email on the road...

4) This leads me to my last "report": I was soooo happy to have finally got my Socket Rev G Bluetooth CF card to work with the Sharp ROM (didn't work with the Cacko 1.23 beta for C3000), that I've been disappointed to see it doesn't work with Opie 3.5.4-RC. I tried to hack my way through the bluetooth config files, but whatever I do, despite the serial_cs module being loaded in memory when I insert the card, hcitool dev always return an empty line. So all in all, the bluetooth stuff doesn't work for me, and that's another thing preventing me to connect to the net while I'm away from home...

So far, the Opie ROM looks very promising, though. I'm reverting to the stock Sharp ROM for now, and will try to find out again the exact config that works for my Bluetooth card, so that I may file a bug report for it in the Opie bugtracker. I just hope that someone can find quickly what's wrong with the Mail application, and if I can have the browser, the mail application along with my WiFi and Bluetooth connections, then I'll keep Opie on my Zaurus and try to help as much as I can ironing out the bugs I can find.

Congratulations anyway for this promising RC release, and all the work already done!

[lardman]

4) This leads me to my last "report": I was soooo happy to have finally got my Socket Rev G Bluetooth CF card to work with the Sharp ROM (didn't work with the Cacko 1.23 beta for C3000), that I've been disappointed to see it doesn't work with Opie 3.5.4-RC. I tried to hack my way through the bluetooth config files, but whatever I do, despite the serial_cs module being loaded in memory when I insert the card, hcitool dev always return an empty line. So all in all, the bluetooth stuff doesn't work for me, and that's another thing preventing me to connect to the net while I'm away from home... sad.gif

Have a word with hrw, he's our resident bluetooth expert. You might find it easier to talk to him on irc - #openzaurus is probably the best channel for this conversation.

but there's that infamous suspend bug

Is this not present on the Opie image? Take a look here: https://www.oesf.org/forums/index.php?showtopic=16224

BTW your wifi card should also work 'out of the box' with GPE; was there no browser built-in in the GPE image? gpe-minibrowser or something like that?


Si