IK5 & Tethering

[Archer]

So, Mädels... hab' italy mal mit Debug Info kompiliert. Und, was muss ich sagen... es liegt tatsächlich am bcm4325 Treiber.

<3>[  173.616538] BUG: scheduling while atomic: iwconfig/1439/0x00000002
<4>[  173.616573] Modules linked in: bcm4325 multipdp dpram [last unloaded: bcm4
325]
<4>[  173.616623] [<c002c194>] (dump_stack+0x0/0x14) from [<c005e5d4>] (__schedu
le_bug+0x54/0x60)
<4>[  173.616705] [<c005e580>] (__schedule_bug+0x0/0x60) from [<c02795f8>] (sche
dule+0x78/0x2e8)
<4>[  173.616776]  r4:00000000
<4>[  173.616791] [<c0279580>] (schedule+0x0/0x2e8) from [<c0279e9c>] (schedule_
timeout+0x98/0xc4)
<4>[  173.616846] [<c0279e04>] (schedule_timeout+0x0/0xc4) from [<bf019250>] (dh
d_os_ioctl_resp_wait+0x7c/0xf8 [bcm4325])
<4>[  173.617116]  r6:c1118000 r5:c1119444 r4:00000064
<4>[  173.617148] [<bf0191d4>] (dhd_os_ioctl_resp_wait+0x0/0xf8 [bcm4325]) from
[<bf02f928>] (dhd_bus_rxctl+0x58/0x170 [bcm4325])
<4>[  173.617521] [<bf02f8d0>] (dhd_bus_rxctl+0x0/0x170 [bcm4325]) from [<bf0267
30>] (dhdcdc_cmplt+0x54/0x78 [bcm4325])
<4>[  173.617890] [<bf0266dc>] (dhdcdc_cmplt+0x0/0x78 [bcm4325]) from [<bf026b98
>] (dhdcdc_query_ioctl+0x158/0x224 [bcm4325])
<4>[  173.618241]  r8:00000001 r7:00000000 r6:c6c500a0 r5:c62da400 r4:c12f0000
<4>[  173.618285] [<bf026a40>] (dhdcdc_query_ioctl+0x0/0x224 [bcm4325]) from [<b
f0270bc>] (dhd_prot_ioctl+0x108/0x1e0 [bcm4325])
<4>[  173.618633] [<bf026fb4>] (dhd_prot_ioctl+0x0/0x1e0 [bcm4325]) from [<bf019
99c>] (dhd_ioctl_entry+0x6d0/0x7e4 [bcm4325])
<4>[  173.618936] [<bf0192cc>] (dhd_ioctl_entry+0x0/0x7e4 [bcm4325]) from [<bf02
1744>] (dev_wlc_ioctl+0x98/0xd8 [bcm4325])
<4>[  173.619203] [<bf0216ac>] (dev_wlc_ioctl+0x0/0xd8 [bcm4325]) from [<bf0225b
8>] (dev_wlc_bufvar_get+0x58/0x80 [bcm4325])
<4>[  173.619501]  r8:00000294 r7:c1119b84 r6:c1119758 r5:c6c50400 r4:00000400
<4>[  173.619545] [<bf022560>] (dev_wlc_bufvar_get+0x0/0x80 [bcm4325]) from [<bf
0226b8>] (wl_iw_get_wireless_stats+0xd8/0x13c [bcm4325])
<4>[  173.619858]  r8:c31da620 r7:c6c50400 r6:c6c50400 r5:c6c50020 r4:c1119b84
<4>[  173.619901] [<bf0225e0>] (wl_iw_get_wireless_stats+0x0/0x13c [bcm4325]) fr
om [<bf018e7c>] (dhd_get_wireless_stats+0x20/0x30 [bcm4325])
<4>[  173.620191]  r6:c31da620 r5:c6c50400 r4:c6c50020
<4>[  173.620221] [<bf018e5c>] (dhd_get_wireless_stats+0x0/0x30 [bcm4325]) from
[<c0276200>] (get_wireless_stats+0x28/0x34)
<4>[  173.620381]  r4:00000002
<4>[  173.620398] [<c02761d8>] (get_wireless_stats+0x0/0x34) from [<c0277074>] (
wireless_seq_show+0x38/0x110)
<4>[  173.620451] [<c027703c>] (wireless_seq_show+0x0/0x110) from [<c00d4b80>] (
seq_read+0x294/0x3d8)
<4>[  173.620506]  r8:00000400 r7:00010008 r6:c31da620 r5:c6c50400 r4:00000002
<4>[  173.620550] [<c00d48ec>] (seq_read+0x0/0x3d8) from [<c00ed814>] (proc_reg_
read+0xb0/0xc4)
<4>[  173.620600] [<c00ed764>] (proc_reg_read+0x0/0xc4) from [<c00b7930>] (vfs_r
ead+0xb4/0x144)
<4>[  173.620663] [<c00b787c>] (vfs_read+0x0/0x144) from [<c00b7cf8>] (sys_read+
0x44/0x70)
<4>[  173.620720]  r7:00000400 r6:c30e3d40 r5:00000000 r4:00000000
<4>[  173.620755] [<c00b7cb4>] (sys_read+0x0/0x70) from [<c0027c20>] (ret_fast_s
yscall+0x0/0x2c)
<4>[  173.620823]  r8:c0027dc8 r7:00000003 r6:afe39dd0 r5:00000000 r4:afe3cd30
<3>[  174.080331] init: untracked pid 1454 exited

Ich werde mal schauen, ob ich, wenn ich den Treiber durch einen der Vorversionen (Frühere Samsung Sources) ersetze, das Ding ans Fliegen bekomme.

D. h. kernel backen bis der Arzt kommt

 

[Archer]

Bäh nö, tut's wohl nicht. Jetzt werde ich mir mal den Scheduler vornehmen. Hach ist interessant ;-)

 

[Archer]

Und wieder nix, der ist in allen Sourcen gleich...

Ich werd' noch zum Kernel Hacker wenn das so weiter geht.

 

[colarus]

So, damit dieser Fred nicht zum Monolog wird wollte ich mich mal für Deine große Mühe bedanken.

 

[Archer]

Mein persönliches Android Kernel Hacking Tagebuch wird um einen kurzen Eintrag bereichert...

Es schaut aus, als wenn im Android-Kernel einiges rund um den Scheduler einiges gefixt worden ist. Das würde sich natürlich erledigen, wenn ich statt dem CFQ den BFS einsetzen könnte. Hier gibt's nur ein Problem: der BFS basiert auf Änderungen (header files, anderswo im Code) die in dem Samsung Kernel noch nicht drin sind.

Jetzt gibt es zwei Möglichkeiten:
a) ich fiesel die Scheduling-Änderungen zum Samsung Kernel
b) ich fiesel die Samsung-Änderungen zum Android Kernel

Die Schwierigkeit, die sich nun auftut: um die Samsung-Änderungen klar zu identifizieren, bräuchte ich erstmal den Stand, von dem Samsung losgelaufen ist. Der ist aber schwer zu finden, da die Android-Quellen keine Minor-Versionsnummern enthalten, der Kernel identifiziert sich stur als "2.6.27". Das ist natürlich ärgerlich...

Das wird auch der Grund sein, an dem mustymod gerade zu beißen hat. Denn dass nach und nach Geräte funktionieren, liegt imho daran, dass er sich vermutlich den entsprechenden Kernel-Tree vornimmt, die Samsung-Quellen extrahiert und dann in den 2.6.29er einpflegt...

Ich werde jetzt mal den GalaxoKernel mit in die Untersuchung aufnehmen

 

[Archer]

Oh ich bin so dämlich!

Drakaz hat BFS schon drin gehabt. Und somit wissen wir auch, warum tethering bei im läuft und beim Samsung Kernel nicht!

Jetzt kann's losgehen. Merge also nun den Kernel vom neuesten Samsung-Release mit den Änderungen von Drakaz.

 

[Archer]

So, vielleicht haben wir es jetzt. Auch mit den Galaxo Quellen wollte das nicht so recht. Und ich habe wieder weitergelesen. Das Problem ist, dass der Treiber warten will (und dafür schedule_timeout nutzt) wo er eigentlich schedule_timeout_uninterruptible nutzen sollte. Also habe ich dhd_linux.c vom broadcom Treiber entsprechend angepasst. Wollen wir mal testen!

 

[colarus]

Also, es tut mir wirklich Leid wenn ich in Dein "persönliches Android Kernel Hacking Tagebuch" jetzt mit kritzle.

Ich habe allerdings eine brennende Frage an Dich. Ich hoffe sie ist Dir nicht zu persönlich. Wenn Du nicht magst brauchst Du auch nicht darauf eingehen. Es ist nur so, ich verfolge Deine Beträge wenn ich mal wieder vor der Kiste sitze. Ich hoffe Du hältst mich jetzt nicht für einen Stalker. Du arbeitest rund um die Uhr an Deinem Custom Rom. Wann zum Teufel schläfst Du?

 

[Jay1982]

@ colarus:
Storker??? Du meinst wohl eher Stalker *ggg*

 

[Archer]

Schlaf wird überbewertet

Nein, ich bin momentan etwas gelangweilt und bastel gerne. Gerade wenn etwas nicht funktioniert. Und diese Sache ist halt sehr sehr bastelig ;-)

Mal ein Hilferuf:

Kann jemand, der das Galaxo-Rom und Tethering einsetzt mal die Ausgabe von "dmesg" schicken, wenn man das Tethering eingeschaltet hat?

 

[Archer]

So, die Ausgaben habe ich. Ich habe jetzt auch mal meinen Kernel mit der II5 getestet. Ergebnis: tethering funktioniert mit meinem Kernel und der II5. Ich habe mal einen der Entwickler kontaktiert...

 

[colarus]

Hast Du schon mal einen andere Version von Wifi-Tether mit Deinem Kernel versucht? Es gibt ja eine spezielle Version für das Galaxy. Ich kann mich dunkel erinnern das es am Anfang da Problem gab weil es nicht so wie bei den anderen Geräten funktionierte. Vielleicht funktioniert ja mit IK5 die "Standard" Version von Wifi-Tether? Vielleicht ist es auch nur eine Blöde Idee.

 

[jojoger]

So, die Ausgaben habe ich. Ich habe jetzt auch mal meinen Kernel mit der II5 getestet. Ergebnis: tethering funktioniert mit meinem Kernel und der II5. Ich habe mal einen der Entwickler kontaktiert...

Und? Schon ne Antwort bekommen?

 

[Archer]

Und? Schon ne Antwort bekommen?

Ne, leider noch nicht... aber Italy und tethering funktioniert jetzt

 

[jojoger]

Ne, leider noch nicht... aber Italy und tethering funktioniert jetzt

Wie hast dus hinbekommen? Ist das deine Lösung gewesen?

Das Problem ist, dass der Treiber warten will (und dafür schedule_timeout nutzt) wo er eigentlich schedule_timeout_uninterruptible nutzen sollte. Also habe ich dhd_linux.c vom broadcom Treiber entsprechend angepasst.

 

[Archer]

Ne... der Bug existiert immernoch (wenn man das umstellt auf "schedule_timeout_uninterruptible", dann will der Treiber gar nicht mehr). Ich habe die FW-Dateien aus der II5 extrahiert und beim Herrn drakaz noch eine "wpa-supplicant-tether.conf" gefunden, an welcher von beiden es gelegen hat, weiß ich aber noch nicht ;-)

Außerdem scheinen im 2.6.27 die Abhängigkeiten für netfilter/ iptables ein wenig broken. Geladen werden müssen:

ipt_MASQUERADE
iptable_nat
iptable_filter
xt_multiport
ip_tables
x_tables
nf_nat
nf_conntrack_ipv4
nf_conntrack

 

[jojoger]

Hast du zufällig noch eine Liste der FW Dateien, die du aus der II5 extrahiert hast?

Ne... der Bug existiert immernoch (wenn man das umstellt auf "schedule_timeout_uninterruptible", dann will der Treiber gar nicht mehr). Ich habe die FW-Dateien aus der II5 extrahiert und beim Herrn drakaz noch eine "wpa-supplicant-tether.conf" gefunden, an welcher von beiden es gelegen hat, weiß ich aber noch nicht ;-)

Außerdem scheinen im 2.6.27 die Abhängigkeiten für netfilter/ iptables ein wenig broken. Geladen werden müssen:

ipt_MASQUERADE
iptable_nat
iptable_filter
xt_multiport
ip_tables
x_tables
nf_nat
nf_conntrack_ipv4
nf_conntrack

 

[Archer]

Das sind zwei ".bin"-Dateien unterhalb von /system/etc/ ...

Grüße,
Archer

 

[jojoger]

Bei mir hat es gereicht eine Datei auszutauschen, die /system/etc/rtecdc.bin.
Falls jemand anderes auch diese Probleme beim upgrade auf die neue Firmware version hat
rtecdc.bin ... at uploaded.to - Free File Hosting, Free Image Hosting, Free Music Hosting, Free Video Hosting, ... runterladen (rtecdc.bin aus Drakaz Galaxo)
und per adb nach /system/etc/ pushen.