Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART
messages (Openmoko Public Trac)
2. Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART
messages (Openmoko Public Trac)
3. Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART
messages (Openmoko Public Trac)
4. Re: Openmoko Bug #2180: stable-tracking: 'rxserr' UART
messages (Openmoko Public Trac)
5. Openmoko Bug #2231: interrupt not always generated when
flowcontrolled=1 and modem wants to talk (Openmoko Public Trac)
--- Begin Message ---
#2180: stable-tracking: 'rxserr' UART messages
-----------------------------+----------------------------------------------
Reporter: laforge | Owner: openmoko-kernel
Type: defect | Status: new
Priority: high | Milestone: FSO
Component: System Software | Version:
Severity: major | Keywords: gps s3x24xx_serial rxerr
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by Sascha):
> For GTA02 I guess that's WLAN driver, what's the status of your WLAN
device when you are running these tests?
Module not loaded or loaded, but not used:
{{{
$ cat /proc/interrupts
CPU0
16: 1 s3c-ext0 lis302dl
17: 4 s3c-ext0 modem
30: 404740 s3c S3C2410 Timer Tick
33: 0 s3c s3c-mci
37: 400955 s3c s3c-mci
41: 97214 s3c s3c2410_udc
42: 36 s3c ohci_hcd:usb1
43: 1834 s3c s3c2440-i2c
48: 1 s3c-ext Neo1973 Headphone jack
49: 0 s3c-ext ar6000
50: 1 s3c-ext Neo1973 AUX button
51: 1 s3c-ext Neo1973 HOLD button
53: 19 s3c-ext pcf50633
60: 1 s3c-ext lis302dl
70: 540463 s3c-uart0 s3c2440-uart
71: 12968 s3c-uart0 s3c2440-uart
79: 6 s3c-adc s3c2410_action
80: 408 s3c-adc s3c2410_action
Err: 0
}}}
> Does ignore_s3c2410_serial_overruns.patch mean that we are able to
survive all of these claimed errors OK now?
for gsm: yes so far
for gps: no
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:15>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2180: stable-tracking: 'rxserr' UART messages
-----------------------------+----------------------------------------------
Reporter: laforge | Owner: openmoko-kernel
Type: defect | Status: new
Priority: high | Milestone: FSO
Component: System Software | Version:
Severity: major | Keywords: gps s3x24xx_serial rxerr
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by andy):
21 + 16 --> 37, which is under "s3cmci" and has 400955 interrupts to its
name.
Apparently because "real" hard SDIO interrupt detection is broken in 2442
or at least the driver, we sit there polling the device 100 times a second
or some such over SDIO interface to see if it has a pending interrupt.
So I guess this goes on whether the ar6000 part above it is active or not
and makes the latencies.
For GPS unlike GSM the overruns are real I think. Maybe you can try the
attached patch about changing interrupt priority to put UART1 before SDI
and removing rotation, I still got GPS overruns here but I never saw a
spew as in you log.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:16>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2180: stable-tracking: 'rxserr' UART messages
-----------------------------+----------------------------------------------
Reporter: laforge | Owner: openmoko-kernel
Type: defect | Status: new
Priority: high | Milestone: FSO
Component: System Software | Version:
Severity: major | Keywords: gps s3x24xx_serial rxerr
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by Sascha):
Hmm, I've removed ar6000.ko and rebooted:
{{{
# cat /proc/interrupts
CPU0
16: 1 s3c-ext0 lis302dl
17: 14 s3c-ext0 modem
30: 495931 s3c S3C2410 Timer Tick
33: 0 s3c s3c-mci
37: 349 s3c s3c-mci
41: 49772 s3c s3c2410_udc
42: 38 s3c ohci_hcd:usb1
43: 1274 s3c s3c2440-i2c
48: 1 s3c-ext Neo1973 Headphone jack
49: 0 s3c-ext ar6000
50: 1 s3c-ext Neo1973 AUX button
51: 1 s3c-ext Neo1973 HOLD button
53: 15 s3c-ext pcf50633
60: 1 s3c-ext lis302dl
70: 128818 s3c-uart0 s3c2440-uart
71: 1844 s3c-uart0 s3c2440-uart
73: 92360 s3c-uart1 s3c2440-uart
74: 61 s3c-uart1 s3c2440-uart
79: 14 s3c-adc s3c2410_action
80: 1032 s3c-adc s3c2410_action
Err: 0
}}}
And I still get:
{{{
Feb 11 15:00:24 gta02 kernel: [ 2240.430000] asm_do_IRQ(21): 8784 us
Feb 11 15:00:26 gta02 kernel: [ 2241.650000] rxerr: port=1 ch=0xb5,
rxs=0x00000001
Feb 11 15:00:26 gta02 kernel: [ 2241.680000] asm_do_IRQ(21): 5751 us
Feb 11 15:00:26 gta02 kernel: [ 2241.685000] rxerr: port=1 ch=0x70,
rxs=0x00000001
Feb 11 15:00:31 gta02 kernel: [ 2247.030000] asm_do_IRQ(21): 6536 us
Feb 11 15:00:31 gta02 kernel: [ 2247.045000] asm_do_IRQ(21): 6129 us
Feb 11 15:00:39 gta02 kernel: [ 2255.380000] rxerr: port=1 ch=0x03,
rxs=0x00000001
Feb 11 15:00:42 gta02 kernel: [ 2258.060000] rxerr: port=1 ch=0x76,
rxs=0x00000001
Feb 11 15:01:04 gta02 kernel: [ 2280.400000] rxerr: port=1 ch=0x6a,
rxs=0x00000001
Feb 11 15:01:04 gta02 kernel: [ 2280.460000] asm_do_IRQ(21): 7199 us
Feb 11 15:01:04 gta02 kernel: [ 2280.480000] asm_do_IRQ(21): 6596 us
Feb 11 15:01:04 gta02 kernel: [ 2280.495000] asm_do_IRQ(21): 7503 us
Feb 11 15:01:09 gta02 kernel: [ 2284.990000] asm_do_IRQ(21): 7268 us
Feb 11 15:01:39 gta02 kernel: [ 2315.420000] rxerr: port=1 ch=0x9a,
rxs=0x00000001
Feb 11 15:01:41 gta02 kernel: [ 2317.045000] asm_do_IRQ(21): 6133 us
Feb 11 15:01:41 gta02 kernel: [ 2317.050000] rxerr: port=1 ch=0xb5,
rxs=0x00000001
}}}
while "349 s3c s3c-mci" doesn't change...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:17>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2180: stable-tracking: 'rxserr' UART messages
-----------------------------+----------------------------------------------
Reporter: laforge | Owner: openmoko-kernel
Type: defect | Status: new
Priority: high | Milestone: FSO
Component: System Software | Version:
Severity: major | Keywords: gps s3x24xx_serial rxerr
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
Comment(by werner):
While the AR6k driver is providing the eth0 interface, the SDIO device is
active as far as the SDIO stack is concerned, and thus you get the
interrupt polling.
If the AR6k driver is absent or disabled (rfkill), you have no SDIO device
but still the SDIO controller. So the interrupt is shown but shouldn't
move. If unbinding the driver of the SDIO controller, the interrupt
vanishes completely.
- Werner
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2180#comment:18>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2231: interrupt not always generated when flowcontrolled=1 and modem wants to
talk
-----------------------------+----------------------------------------------
Reporter: lindi | Owner: openmoko-kernel
Type: defect | Status: new
Priority: normal | Milestone:
Component: System Software | Version: unspecified
Severity: normal | Keywords:
Haspatch: 0 | Blockedby:
Estimated: | Patchreview:
Blocking: | Reproducible:
-----------------------------+----------------------------------------------
This issue has been discussed on IRC and a mailing list thread
"Occasional fail to initiate resume by incoming call, easy workaround
proposed" but I have not seen a bug report with clear steps to
reproduce. In that thread moko11-beta1 firmware is suggested as a
workaround so anybody who upgrades to that will want to verify that it
really fixes the issue for them with these steps.
{{{
Steps to reproduce:
1) start
socat - file:/dev/ttySAC0,crtscts,crnl,echo=0,b115200
in another terminal and keep it running during steps 1-9
2) echo 0 > /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-pm-gsm.0/power_on
3) echo 1 > /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-pm-gsm.0/power_on
4) register to network manually by typing the following to socat (mind
your own PIN though!):
ATE1
AT+CFUN=1
AT+CPIN="0000"
AT+CPIN?
AT+COPS
AT+COPS?
4) grep modem /proc/interrupts
5) call the phone from some other phone
6) let caller hangup
7) echo 1 > /sys/class/i2c-adapter/i2c-0/0-0073/neo1973-pm-
gsm.0/flowcontrolled
8) call the phone from some other phone
9) grep modem /proc/interrupts
Expected results:
4-9) When flowcontrolled=1 an interrupt is generated when GSM has
something to send.
Actual results:
4-9) Interrupt count does not increase:
17: 5 s3c-ext0 modem
17: 5 s3c-ext0 modem
and thus if the phone is put to suspend it won't wake up either.
More info:
1) I am running moko8 firmware on GTA02V5
AT+CGMR
+CGMR: "HW: GTA02BV5, GSM:
gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko8"
$ grep Revision /proc/cpuinfo
Revision : 0350
2) I am using andy-tracking kernel b8b36e5ec3db71d5 from beginning of
January 2009.
}}}
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2231>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
