Custom Query (1948 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (16 - 18 of 1948)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Ticket Resolution Summary Owner Reporter
#2267 fixed [wifi] kernel oops when starting wpa_supplicant openmoko-devel tilman2
Description

I'm running shr-unstable from April 9th: http://build.shr-project.org/shr-unstable/images/om-gta02/openmoko-shr-lite-image-glibc-ipk--20090409-om-gta02.rootfs.jffs2 http://build.shr-project.org/shr-unstable/images/om-gta02/uImage-2.6.28-oe1+gitr119783+901d73fe51f33032b34b2ae5612eb863ec90532a-r3.1-om-gta02.bin

The kernel version reported is 2.6.29-rc3.

When starting wpa_supplicant, the kernel oopses. I'll attach the output of dmesg and my wpa_supplicant.conf.

#2266 fixed xf86-video-glamo fills xdm.log with GLAMOExaPrepareSolid: Only 16bpp is supported openmoko-kernel lindi
Description

[I sent this by email to lars last month but just to make sure I don't forget it here's a bug report as well]

after running xf86-video-glamo for a while (it seems to be quite stable!) I noticed that my /var/log/xdm.log now has 46 megabytes of the line

GLAMOExaPrepareSolid: Only 16bpp is supported

Can you ratelimit this a bit? Maybe it should only be printed the first time?

#2265 fixed kernel spams with useless messages (fbcon_event_notify action, etc.) openmoko-kernel lindi
Description

Even when I am not using the phone at all my logs get filled with kernel messages like

Apr  7 04:18:32 ginger kernel: [  289.015000] fbcon_event_notify action=9, data=c4609e08
Apr  7 04:18:32 ginger kernel: [  289.015000] jbt6k74 spi2.0: **** jbt6k74 powerdown
Apr  7 04:18:42 ginger kernel: [  299.090000] fbcon_event_notify action=9, data=c4609e08
Apr  7 04:18:42 ginger kernel: [  299.090000] jbt6k74 spi2.0: **** jbt6k74 powerdown
Apr  7 04:18:52 ginger kernel: [  309.160000] fbcon_event_notify action=9, data=c4609e08
Apr  7 04:18:52 ginger kernel: [  309.160000] jbt6k74 spi2.0: **** jbt6k74 powerdown
Apr  7 04:19:02 ginger kernel: [  319.235000] fbcon_event_notify action=9, data=c4609e08
Apr  7 04:19:02 ginger kernel: [  319.235000] jbt6k74 spi2.0: **** jbt6k74 powerdown
Apr  7 04:19:12 ginger kernel: [  329.310000] fbcon_event_notify action=9, data=c4609e08
Apr  7 04:19:12 ginger kernel: [  329.310000] jbt6k74 spi2.0: **** jbt6k74 powerdown
Apr  7 04:19:13 ginger kernel: [  330.445000] pcf50633 0-0073: INT1=0x80 INT2=0x00 INT3=0x10 INT4=0x00 INT5=0x00
Apr  7 04:19:14 ginger ogsmd.channel DEBUG    <MiscChannel via /dev/pts/0>: _readyToSend: watch timeout = None
Apr  7 04:19:14 ginger kernel: [  330.535000] pcf50633 0-0073: INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00
Apr  7 04:19:14 ginger ogsmd    DEBUG    (<MiscChannel via /dev/pts/0>: last communication with modem was 50 seconds ago. Sending EOF to wakeup)
Apr  7 04:19:14 ginger kernel: [  330.555000] pcf50633 0-0073: INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00
Apr  7 04:19:14 ginger kernel: [  330.715000] pcf50633 0-0073: INT1=0x00 INT2=0x00 INT3=0x20 INT4=0x00 INT5=0x00
Apr  7 04:19:14 ginger ogsmd.channel DEBUG    <MiscChannel via /dev/pts/0>: sending 9 bytes: 'AT+COPS?\r'
Apr  7 04:19:14 ginger kernel: [  330.800000] pcf50633 0-0073: INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00
Apr  7 04:19:14 ginger ogsmd.channel DEBUG    <MiscChannel via /dev/pts/0>: _readyToRead: watch timeout = 317
Apr  7 04:19:14 ginger ogsmd.channel DEBUG    <MiscChannel via /dev/pts/0>: got 28 bytes: '\r\n+COPS: 0,2,"24405"\r\n\r\nOK\r\n'
Apr  7 04:19:14 ginger kernel: [  330.845000] pcf50633 0-0073: INT1=0x00 INT2=0x00 INT3=0x00 INT4=0x00 INT5=0x00
Apr  7 04:19:14 ginger ogsmd.channel DEBUG    <MiscChannel via /dev/pts/0>: COMPLETED 'AT+COPS?' => ['+COPS: 0,2,"24405"', 'OK']
Apr  7 04:19:14 ginger ogsmd.channel DEBUG    <MiscChannel via /dev/pts/0>: _readyToSend: watch timeout = None

this wastes disk space and makes finding the important stuff from logs more difficult. Please consider making these debug prints something that can be configured at runtime if they are really needed.

(Ignore the ogsmd DEBUG messages, they are caused by my periodic watchdog that checks that the phone is connected to GSM network every 50 seconds.)

I am reporting this bug against andy-tracking b8b36e5ec3db71d5 which is quite old. Please close this if the bug has already been fixed in newer kernels. I'll try to move to newer kernels when bugs #2255 and #2257 have been resolved.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Note: See TracQuery for help on using queries.