← Back to team overview

ac100 team mailing list archive

Re: new natty installer up

 

Hello Michael,

> On Tue, Jun 7, 2011 at 9:00 PM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
> > hi,
> > 
> > Am Dienstag, den 07.06.2011, 09:12 +1200 schrieb Michael Hope:
> >> On Fri, Jun 3, 2011 at 2:30 AM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
> >> 
> >> The installer works fine but I'm afraid the installation is unusable
> >> on my AC100.  I have it set to auto-logon and it always gets to the
> >> Unity desktop and takes some initial input, but then two times out of
> >> three it locks up and won't respond to the keyboard or mouse.  When it
> >> does keep going, the mouse often loses sync and jumps all over the
> >> place when you try to move it.  Switching to a VT and back sometimes
> >> clears this.
> >> 
> >> I grabbed the image on Friday.  I'll look further - it seems mildly
> >> more reliable if I switch to a VT early, wait for the desktop to
> >> finish loading, then switch back.
> > 
> > try to get online and upgrade the linux-ac100 package, it will pull in a
> > new kernel that works around the blocked input devices ..
> 
> I tried to do a dist-upgrade but it keeps hanging on installing
> gnome-user-guide.  I grabbed just the kernel and did a flash-kernel to
> load it up and the same probelm happens.  The dmesg shows:
> 
> Jun  8 09:52:53 vela kernel: [  344.640630] nvec nvec.0: new
> transaction during send trying to retransmit!
> Jun  8 09:53:03 vela kernel: [  354.919043] nvec nvec.0: new
> transaction during send trying to retransmit!
> Jun  8 09:53:14 vela kernel: [  365.290305] nvec nvec.0: new
> transaction during send trying to retransmit!

I'm slowing running out of ideas what's the root cause of these problems. You 
may try to compile your own kernel using the latest HEAD which includes some
rewrite of the interrupt code, but I fear the real problem is somewhere else.

> Jun  8 09:53:17 vela kernel: [  369.166625] INFO: task dpkg:1712
> blocked for more than 120 seconds.
> Jun  8 09:53:17 vela kernel: [  369.174255] "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> Jun  8 09:53:17 vela kernel: [  369.174293] dpkg          D 4042ba64
>   0  1712   1491 0x00000000
> Jun  8 09:53:17 vela kernel: [  369.174342] Backtrace:
> Jun  8 09:53:17 vela kernel: [  369.174444] [<4042ba64>]
> (schedule+0x5ac/0x6ac) from [<401dedf4>]
> (jbd2_log_wait_commit+0xac/0x104)
> Jun  8 09:53:17 vela kernel: [  369.174542] [<401dedf4>]
> (jbd2_log_wait_commit+0xac/0x104) from [<40142e58>]
> (vfs_fsync_range+0x58/0x7c)
> Jun  8 09:53:17 vela kernel: [  369.174617] [<40142e58>]
> (vfs_fsync_range+0x58/0x7c) from [<40142f14>] (vfs_fsync+0x20/0x28)
> Jun  8 09:53:17 vela kernel: [  369.174685] [<40142f14>]
> (vfs_fsync+0x20/0x28) from [<40142f3c>] (do_fsync+0x20/0x34)
> Jun  8 09:53:17 vela kernel: [  369.174784] [<40142f3c>]
> (do_fsync+0x20/0x34) from [<4003b2c0>] (ret_fast_syscall+0x0/0x30)
> 
> so the filesystem is getting stuck perhaps due to the MMC driver getting
> stuck.

This looks strange. We saw stucked mmc/usb in the past, but those were gone 
after the removal of the agressive battery polling. I also see no hints which 
could verify a problem with the power supply.

Thinking about it, I remember I also got those messages while installing some 
large packages (during dist-upgrade). Is it possible that such a message could 
be produces by very slow media (e.g. slow mmc)? In this case, the system should 
be able to recover after some more time.

> The installed kernel is shown here:
>  http://pastebin.ubuntu.com/621277/
> 
> The full syslog is here:
>  http://pastebin.ubuntu.com/621279/
> 
> The Wifi power saving also seems to be very aggressive.  A SSH session
> into the AC100 is very laggy, but running a 'sudo ping -i 0.05
> other-host' to keep the Wifi on works around it.

yup, this is an upstream problem. You can try of "iwconfig power off" helps 
here, but I know this is not a real solution.

Marc


Follow ups

References