Release 3.2 kernel issue tracking thread

[notaz]

You tell me, can never be sure about such things.

 

[Linux-SWAT]

I tested.


Oss works with xmms, but i'm surprised to see the CPU usage is the same as Alsa.


Sound works in picodrive (if i remember right it's oss).

 

[porg]

Further observed issues:

• Happened once: Woke from standby while charging battery (has reached almost 100% by then), screen unexpectedly was in CLI mode, with no text there, just a blinking prompt
  
• Chromium crashes the whole system (both with kernel 3.x and 2.x), screen turns into CLI mode, filled with text (do not remember its content)
  
• EDIT: Touchscreen: Pointer position sometimes has a variable offset (stronger offset if you move to the outer screen regions
  
• LEDs unreliable: Both the Power/Charging and the WiFi LED are unreliable into both directions (lit if not active, as well as not lit although active)
  

 

[Galaxis]

How is WLAN for others? I'm currently trying to download a 100MB file with wget, and about every 30 MB, things stop working (WLAN still shows as connected, but no data is being transferred, and even the default gateway drops from the ARP table after some time).


With the old kernel, WLAN was slow, but stable in comparison.

 

[Darkknight512]

Mine has always been unstable under any circumstance at home. With power management off, its bearable...


At school its perfect, 600 kb/s down with power management on.

 

[WizardStan]

What was the OSS bug?

 

[Linux-SWAT]

The sound was slow, like a sample played at low speed/pitch.

 

[porg]

The touchscreen offset was due to a false calibration done my me!


But the false calibration happens due to a bug in the "Configure Screen" utility, which arose in SuperZaxxon.


The first crosshair (top-left) is NOT shown, I just tapped somewhere into the screen (near the center in my case), and then the following crosshairs showed correctly (top-right, bottom-right, bottom-left, center). To counter that bug, I restarted "Configure Screen" and made the first tap approximately where the first (top-left) crosshair was supposed to be, and continued with the other crosshairs normally. Rebooted the Pandora, and from then on the pointer was correctly aligned.


Please fix that bug in "Configure Screen"

 

[Galaxis]

Does anyone else have the problem that the Pandora won't shut down with the 3.2.1 kernel from Beta2?


My box gets stuck with the "experimental kernel" screen and the blue progress bar being blacked out, but the system doesn't power off.


Also mmc_core.removable=0 doesn't seem to work 100% - get some mmc errors when resuming the system. This is on the old hardware.

http://www.openpando.../Zaxxon-HF6.zip


My NAND was full and this full reflash helped me. Had a similar issue when I installed Super Zaxxon, it worked for me. I then was able to reinstall Super Zaxxon Beta 1 and Beta 2 without issue.

Seems like the not shutting down problem may be because the OS can't unmount my SD card when I have a swap partition active...


As for the mmc errors - they don't happen right after resume but usually sometime later. I'll try to save some of the dmesg next time it comes up.

 

[urjaman]

notaz: What is the plan on bluetooth? Are you going to make the HCI UART driver work for us (firmware? gpio reset? this seems to be missing stuff and/or I just dont know enough about it...), or are we going to port the 2.6.27 hci_h4p driver to 3.2?


I'll admit that I just spent a few hours crudely hacking the hci_h4p driver to 3.2 and the current result is that it loads firmware, and seems to be up and piscan, but for some reason (I'm guessing that it is some too active power management, my hacks were quite crude) it doesnt find any devices (that I know to be findable) with hcitool scan, and I cant find it with my other devices...

 

[notaz]

I'd like to get it working though /dev/ttyO0, that hci_h4p driver is screwy and should be dropped. As I don't have any use for BT, which results in low motivation and no ability to test this properly, could you try the following:


Add gpio_export() to board-omap3pandora.c to make GPIO15 available (or "echo 15 > /sys/class/gpio/export" might be enough) so you get reset control over /sys/class/gpio .


Then bring it out of reset (set GPIO high) and do something with hciattach/hciconfig, I've checked bluez source and it seems to have TI firmware loading support, but I'm not sure how to actually use it. Maybe "hciattach /dev/ttyO0 texasalt", then "hciconfig hci0 up". It also seems to look for firmware in /etc/firmware .


It would be great if someone could get it working that way, would relieave lots of kernel maintenance pain.

 

[urjaman]

Thanks for the direction, I'll test (and/or hack) this later tonight.

 

[sepulep]

I found screen blanking (both spontaneous and due to time change) causes system freeze (3.2 kernel of beta 2). Tested a few times swithing between standard (everything ok) and experimental kernel (not ok)

 

[notaz]

I found screen blanking (both spontaneous and due to time change) causes system freeze (3.2 kernel of beta 2). Tested a few times swithing between standard (everything ok) and experimental kernel (not ok)

No such problem here, do you have anything running when this happens?

 

[urjaman]

These commands arent verbatim copied, so check for typos

sudo su

cd /etc

ln -s /lib/firmware firmware

echo 15 > /sys/class/gpio/export

echo out > /sys/class/gpio/gpio15/direction

echo 1 > /sys/class/gpio/gpio15/value

hciattach -n /dev/ttyO0 texasalt

=>

Texas module LMP version : 0x03

Texas module LMP sub-version : 0x1126

	internal version freeze: 38

	software version: 2

	chip: brf6300 (4)

Opening firmware file: /etc/firmware/brf6300.bin

Uploading firmware...

Firmware upload successful.

Device setup complete

And bluetooth works (no led obviously) , but at 115200 ...

I tried to set other baudrates, but when I tried it would just freeze and not come up.

Then I downloaded bluez and looked at hciattach sources and the reason seems obvious:

hciattach_tialt.c line 97..

static int texas_change_speed (int fd, uint32_t speed) {

	return 0;

}

Ugh...


But yeah posted from a pandora running 3.2 and over bluetooth.


EDIT: Added code tags ...

 

[EvilDragon]

Awesome news, urjaman, thanks a lot for the help

 

[urjaman]

I've attached a patch to bluez (/tools/hciattach_tialt.c) that enables changing the baudrate. The forum ate my attachment or something. Here is a link then: http://urjaman.dyndn...ed_change.patch


The fastest currently working rate is 3Mbps because that is the highest that has a baudrate define and also works with the omap and the bt chip. That is enough fast for me, but i think one could pach hciattach to use BOTHER and c_ospeed to set 3686400 that was used by the old driver. I think that this patch could actually make it into bluez upstream. I mostly adapted the code from the speed change in hci_h4p driver.


Now i think all that is missing from the bluetooth system is integrating this all into the scripts and either controlling the led from the script in a simple on/off manner or adding led code to the kernel hci uart driver (there really is no other place i think) if we really want usage blinking.


That firmware symlink should somehow go into the rootfs or we could patch that too in hciattach.


So in boot:


echo 15 > /sys/class/gpio/export


echo out > /sys/class/gpio/gpio15/direction


to bring bluetooth up (hciattach -n is nodetach if needed/ add that when debugging):


echo 1 > /sys/class/gpio/gpio15/value


hciattach /dev/ttyO0 texasalt 3000000


(maybe some of the old up stuff here, maybe with some 3s wait for hciattach to work)


down:


(old down stuff here)


killall hciattach # or use pidfile


echo 0 > /sys/class/gpio/gpio15/value # needs to be reset for next up to work


EDIT: Or alternatively we could just start hciattach on boot and use only hciconfig up/down - that would be faster and maybe simpler. The above is quite thorough in how totally it brings bt up and down


(Now that I've written this i think that this message should have traditionally gone into the bugtracker or mailing list, but I think the right people will still get the message so i wont bother...)

 

[Linux-SWAT]

Sounds nice !


Thanks for you researches !

 

[Cloudef]

I've attached a patch to bluez (/tools/hciattach_tialt.c) that enables changing the baudrate. The forum ate my attachment or something. Here is a link then: http://urjaman.dyndn...ed_change.patch

That patch seems to look good enough at first glance, I suggest sending it to upstream.

 

[notaz]

I've attached a patch to bluez (/tools/hciattach_tialt.c) that enables changing the baudrate. The forum ate my attachment or something. Here is a link then: http://urjaman.dyndn...ed_change.patch


The fastest currently working rate is 3Mbps because that is the highest that has a baudrate define and also works with the omap and the bt chip. That is enough fast for me, but i think one could pach hciattach to use BOTHER and c_ospeed to set 3686400 that was used by the old driver. I think that this patch could actually make it into bluez upstream. I mostly adapted the code from the speed change in hci_h4p driver.

Looks good, it would be best if you sent this as formal git patch to bluez mailing list, as you can test any adjustments they might want. You'd only need to replace spaces with tabs to match their coding style.

Now i think all that is missing from the bluetooth system is integrating this all into the scripts and either controlling the led from the script in a simple on/off manner or adding led code to the kernel hci uart driver (there really is no other place i think) if we really want usage blinking.


That firmware symlink should somehow go into the rootfs or we could patch that too in hciattach.

Could you do a git patch against http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openpandora.oe.git;a=blob;f=recipes/pandora-system/pandora-scripts/op_bluetooth.sh;h=2d5b79aa45ca0f4b03f8e1fa5d0ff79f0cd41382;hb=HEAD with this? It could look something like:

bt_enable()

{

  # hciattach stuff here

}


kernel_major=`uname -r | cut -c 1`

if [ "$kernel_major" = "3" ]; then

  bt_enable

fi

No worries if you don't want this, somebody else can add it there I guess.


As for the LED, I guess it's enough to just enable it while BT is active, at least for now. It's strange that BT core code doesn't have any LED code to this day.

EDIT: Or alternatively we could just start hciattach on boot and use only hciconfig up/down - that would be faster and maybe simpler. The above is quite thorough in how totally it brings bt up and down

I'd prefer to keep BT in shutdown state (GPIO low) until it's actually used, that means hciattach on every enable. Although if it has good power management it could make sense to keep it on, although there are some people who never use BT, and some that have broken wifi modules, there could be problems if you try to talk to dead chip there.