September 18, 2019, 07:37:16 am

News:

Have you visited the Allwinner Chipset wiki? - http://linux-sunxi.org/


Allwinner A10 network bug report (Cubieboard, Samba)

Started by Cubear, September 10, 2013, 07:24:43 am

Previous topic - Next topic

Cubear

September 10, 2013, 07:24:43 am Last Edit: September 10, 2013, 07:27:06 am by Cubear
Greetings devs!

I found a possible networking bug on Cubieboard A10. The problem is that sometimes the upload speed of samba is extremely slow while download works normally. Not sure, if this relates to samba directly, but samba seems to be the only program affected by it that I've found. I've tested this on two A10 cubieboards with two operating systems. I've always booted from a sd-card.

The first linux distro I tested was Debian Wheezy - I used Roman's headless image, which can be found here. I used the default included kernel, but later switched to a custom one from sunxi-3.4.43 github repository. Both exhibit the same behavior. The second image I tried was Arch linux ARM found here with identical results. From these tests I assume this is an distro-independent bug, possibly a samba or a kernel bug. I'm going to demonstrate how to reproduce it by using the Roman's Debian Wheezy image.


Prepare test image:
First download and install the distro image, as specified in the installation instructions here. Once the sd card is ready insert it into cubieboard and plug the power. It is imperative that you do not unplug the device from power or attempt to reboot it!!! Also, make sure cubieboard is connected to internet (switch) by an ethernet cable. Connect a usb-to-serial adapter to it (or ssh to it once an IP address is obtained) to get a terminal with root access. When you have logged in (root:password) run "# apt-get update" to refresh the package list (make sure you have internet access, cubieboard should try to obtain an IP address during boot via DHCP). Next you have to install samba: "# apt-get install samba samba-tools samba-common-bin". When the installation is done edit the /etc/samba/smb.conf file and enter my config (see below, you could use your own too, I've tested multiple different configs with the same result). Finally restart samba to use the new config: "#service samba restart ". Please note that I've used the ram-mounted /tmp folder in my config to eliminate any potential disk problems, but the same behavior is observed when using an external disk as the target path.

How to reproduce:
If you rebooted the device in previous steps then please unplug it from power for 10 seconds before booting. Do not reboot the device unless I say so. The device has to boot by plugging in the power. So now the device is booted and samba ready. Go to a file explorer and upload a file about 100 to 200 megs to the remote share. Note down the upload speed. I'm using a 100M ethernet, and the speed was about 9 MB/s. Then download the file you just uploaded, and note the network speed. Again, the speed should be about 9 MB/s. Okay, now the problem. Go back to your root terminal and issue a "reboot" command. This will cause the device to reboot, but do not unplug the +5VDC power! Once the device has rebooted, perform the same speed tests again! The download speed should be the same, but the upload speed now suffers greatly for some reason - I'm getting a mere 1.8 to 2.2 MB/s upload speed. No matter how many more times you reboot the device the upload speed will always be this slow. To reset the upload speed, unplug cubieboard from power, wait 10s and reconnect it. Perform the same speed tests again. The speeds should be normal until the next reboot.

I've also found out that instead of rebooting you can simply do: "# service networking restart" that also causes the bug to trigger. The only way to reset the speed is to unplug the device from power!


Here is my smb.conf, but any config should do:

[global]
    workgroup = TEST
    server string = Test server
    netbios name = TESTSRV
   
    interfaces = lo 0.0.0.0 ::
    bind interfaces only = no
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
    name resolve order = bcast host lmhosts wins
    os level = 65
    dns proxy = no
   
    log file = /var/log/samba/log.%m
    max log size = 10000
    syslog = 1
    log level = 1
   
    security = user
    encrypt passwords = true
    passdb backend = tdbsam
   
    guest account = nobody
    map to guest = Bad User
   
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
   
    follow symlinks = yes
    wide links = yes
    unix extensions = no

    hide unreadable = yes
    hide special files = yes
   
[Storage]
    comment = Data storage devices
    path = /tmp
    browsable = yes
    read only = no
    public = yes
    create mask = 0644
    directory mask = 0755
    force create mode = 0664
    force directory mode = 0775


Best regards!

patwood

September 10, 2013, 09:24:01 am #1 Last Edit: September 10, 2013, 09:28:57 am by patwood
Quote from: Cubear on September 10, 2013, 07:24:43 am
Greetings devs!

I found a possible networking bug on Cubieboard A10. The problem is that sometimes the upload speed of samba is extremely slow while download works normally. Not sure, if this relates to samba directly, but samba seems to be the only program affected by it that I've found. I've tested this on two A10 cubieboards with two operating systems. I've always booted from a sd-card.

The first linux distro I tested was Debian Wheezy - I used Roman's headless image, which can be found here. I used the default included kernel, but later switched to a custom one from sunxi-3.4.43 github repository. Both exhibit the same behavior. The second image I tried was Arch linux ARM found here with identical results. From these tests I assume this is an distro-independent bug, possibly a samba or a kernel bug. I'm going to demonstrate how to reproduce it by using the Roman's Debian Wheezy image.


Prepare test image:
First download and install the distro image, as specified in the installation instructions here. Once the sd card is ready insert it into cubieboard and plug the power. It is imperative that you do not unplug the device from power or attempt to reboot it!!! Also, make sure cubieboard is connected to internet (switch) by an ethernet cable. Connect a usb-to-serial adapter to it (or ssh to it once an IP address is obtained) to get a terminal with root access. When you have logged in (root:password) run "# apt-get update" to refresh the package list (make sure you have internet access, cubieboard should try to obtain an IP address during boot via DHCP). Next you have to install samba: "# apt-get install samba samba-tools samba-common-bin". When the installation is done edit the /etc/samba/smb.conf file and enter my config (see below, you could use your own too, I've tested multiple different configs with the same result). Finally restart samba to use the new config: "#service samba restart ". Please note that I've used the ram-mounted /tmp folder in my config to eliminate any potential disk problems, but the same behavior is observed when using an external disk as the target path.

How to reproduce:
If you rebooted the device in previous steps then please unplug it from power for 10 seconds before booting. Do not reboot the device unless I say so. The device has to boot by plugging in the power. So now the device is booted and samba ready. Go to a file explorer and upload a file about 100 to 200 megs to the remote share. Note down the upload speed. I'm using a 100M ethernet, and the speed was about 9 MB/s. Then download the file you just uploaded, and note the network speed. Again, the speed should be about 9 MB/s. Okay, now the problem. Go back to your root terminal and issue a "reboot" command. This will cause the device to reboot, but do not unplug the +5VDC power! Once the device has rebooted, perform the same speed tests again! The download speed should be the same, but the upload speed now suffers greatly for some reason - I'm getting a mere 1.8 to 2.2 MB/s upload speed. No matter how many more times you reboot the device the upload speed will always be this slow. To reset the upload speed, unplug cubieboard from power, wait 10s and reconnect it. Perform the same speed tests again. The speeds should be normal until the next reboot.

I've also found out that instead of rebooting you can simply do: "# service networking restart" that also causes the bug to trigger. The only way to reset the speed is to unplug the device from power!


Here is my smb.conf, but any config should do:

[global]
    workgroup = TEST
    server string = Test server
    netbios name = TESTSRV
   
    interfaces = lo 0.0.0.0 ::
    bind interfaces only = no
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
    name resolve order = bcast host lmhosts wins
    os level = 65
    dns proxy = no
   
    log file = /var/log/samba/log.%m
    max log size = 10000
    syslog = 1
    log level = 1
   
    security = user
    encrypt passwords = true
    passdb backend = tdbsam
   
    guest account = nobody
    map to guest = Bad User
   
    load printers = no
    printing = bsd
    printcap name = /dev/null
    disable spoolss = yes
   
    follow symlinks = yes
    wide links = yes
    unix extensions = no

    hide unreadable = yes
    hide special files = yes
   
[Storage]
    comment = Data storage devices
    path = /tmp
    browsable = yes
    read only = no
    public = yes
    create mask = 0644
    directory mask = 0755
    force create mode = 0664
    force directory mode = 0775


Best regards!

Sounds like this problem:  https://groups.google.com/forum/m/?fromgroups#!searchin/linux-sunxi/wemac/linux-sunxi/_rrSl3YI_b0 and this:  https://groups.google.com/forum/m/?fromgroups#!searchin/linux-sunxi/wemac/linux-sunxi/ZMLVhN1mjjo

What kernel branch are you building and what is the last commit?

Cubear

For Arch linux ARM I used the bundled uImage as per instructions. For Roman's image I used the default kernel that is present in the image. For my own it was git-cloned and rebuilt from the linux-sunxi github repository here:
https://github.com/linux-sunxi/linux-sunxi

No idea what the commit was. I could try to update and recompile to see if the recent version exhibits the same problems. It's funny though only samba seems to be affected among the programs I've tried.

Finally may I suggest that there be a warning message instead of kernel panic, if the uEnv.txt refers to a non-existent fex/bin file.

Let me know if you need any more info, I'll see if I can help. I'm interested in solving this.
Best regards!

patwood

Quote from: Cubear on September 10, 2013, 11:06:44 am
For Arch linux ARM I used the bundled uImage as per instructions. For Roman's image I used the default kernel that is present in the image. For my own it was git-cloned and rebuilt from the linux-sunxi github repository here:
https://github.com/linux-sunxi/linux-sunxi

Ah, but which branch?  Do a "git status"; the first line tells you the branch.  The latest and greatest is stage/sunxi-3.4.

Quote
No idea what the commit was. I could try to update and recompile to see if the recent version exhibits the same problems. It's funny though only samba seems to be affected among the programs I've tried.

Do a "git log"; the first line is the latest commit.  A couple of really important changes to the AW ethernet driver were made in late July on the stage branch.

Quote
Finally may I suggest that there be a warning message instead of kernel panic, if the uEnv.txt refers to a non-existent fex/bin file.

No, it should panic.  The script.bin file configures *everything* for the kernel, not just gpios and monitors, and is therefore considered an integral part of the kernel.  It's not the same as forgetting to install /lib/modules.

Without script.bin, even the serial tty and SD card wouldn't be configured properly (well, ttyS0 could always be defaulted as enabled, but there are devices where MMC2 is used instead of MMC0 for booting).  On Android boxes, even the DRAM timings are set from script.bin by the bootloader (I don't think the linux u-boot does this, though).

Cubear

$ git status
# On branch sunxi-3.4
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# compile.sh
# config-sun4i.txt
# output_fir/
# output_mod/
nothing added to commit but untracked files present (use "git add" to track)


$ git log
commit e75be343e97208590807481702ad83641166e4f4
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Tue Mar 12 13:00:42 2013 +0100

    ARM: 7670/1: fix the memset fix
   
    Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
    recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
    with the memset return value.  However the memset itself became broken
    by that patch for misaligned pointers.
   
    This fixes the above by branching over the entry code from the
    misaligned fixup code to avoid reloading the original pointer.
   
    Also, because the function entry alignment is wrong in the Thumb mode
    compilation, that fixup code is moved to the end.
   
    While at it, the entry instructions are slightly reworked to help dual
    issue pipelines.
   
    Signed-off-by: Nicolas Pitre <nico@linaro.org>
    Tested-by: Alexander Holler <holler@ahsoftware.de>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
...




So which kernel code should I use? I followed this guide when installing the source code: http://linux-sunxi.org/FirstSteps
git clone git://github.com/linux-sunxi/u-boot-sunxi.git
git clone git://github.com/linux-sunxi/linux-sunxi.git
git clone git://github.com/linux-sunxi/sunxi-tools.git
git clone git://github.com/linux-sunxi/sunxi-boards.git




Quote from: patwood on September 10, 2013, 11:55:16 am
No, it should panic.  The script.bin file configures *everything* for the kernel, not just gpios and monitors, and is therefore considered an integral part of the kernel.  It's not the same as forgetting to install /lib/modules.

Without script.bin, even the serial tty and SD card wouldn't be configured properly (well, ttyS0 could always be defaulted as enabled, but there are devices where MMC2 is used instead of MMC0 for booting).  On Android boxes, even the DRAM timings are set from script.bin by the bootloader (I don't think the linux u-boot does this, though).

Erm, I'm sorry. Perhaps I wasn't being clear in my previous post. What I was trying to suggest is that the panic info be hidden and instead display a simple error like "PANIC: the .bin file is missing or not specified". I'm running a serial connection to cubieboard, and whenever I forget to configure the fex/bin file I get this huge debug dump that looks like a backtrace or a stack/register memory dump of some sort that completely coveres my screen, so I am unable to see the original error message. the "screen /dev/ttyUSB0 115200" command I use won't let me scroll up.



patwood

Quote from: Cubear on September 10, 2013, 12:17:12 pm
$ git status
# On branch sunxi-3.4
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
# compile.sh
# config-sun4i.txt
# output_fir/
# output_mod/
nothing added to commit but untracked files present (use "git add" to track)


$ git log
commit e75be343e97208590807481702ad83641166e4f4
Author: Nicolas Pitre <nicolas.pitre@linaro.org>
Date:   Tue Mar 12 13:00:42 2013 +0100
...



So which kernel code should I use? I followed this guide when installing the source code: http://linux-sunxi.org/FirstSteps
git clone git://github.com/linux-sunxi/u-boot-sunxi.git
git clone git://github.com/linux-sunxi/linux-sunxi.git
git clone git://github.com/linux-sunxi/sunxi-tools.git
git clone git://github.com/linux-sunxi/sunxi-boards.git


The git://github.com/linux-sunxi/linux-sunxi.git repository is considered the "golden" repository for all kernel things allwinner.  The sunxi-3.4 branch was recently brought up to date with respect to stage/sunxi-3.4 but often falls behind (as you may have noticed).  This branch is supposed to be more stable as opposed to the "stage" branches, which are for development and possibly unstable changes that haven't had a lot of testing.

You may want to pull the updates from github and rebuild your kernel.  In the future, when investigating problems, it's a good idea to switch to the stage/sunxi-3.4 branch before building a test kernel, i.e., run "git checkout stage/sunxi-3.4".  Also, the linux-sunxi google group tracks patches submitted by kernel devs that can take a week or more to be committed to stage/sunxi-3.4.

You can just go to https://github.com/linux-sunxi/linux-sunxi and see the current state of the default sunxi-3.4 branch or all branches (click on the branches tab).

Quote
Quote from: patwood on September 10, 2013, 11:55:16 am
No, it should panic.  The script.bin file configures *everything* for the kernel, not just gpios and monitors, and is therefore considered an integral part of the kernel.  It's not the same as forgetting to install /lib/modules.

Without script.bin, even the serial tty and SD card wouldn't be configured properly (well, ttyS0 could always be defaulted as enabled, but there are devices where MMC2 is used instead of MMC0 for booting).  On Android boxes, even the DRAM timings are set from script.bin by the bootloader (I don't think the linux u-boot does this, though).

Erm, I'm sorry. Perhaps I wasn't being clear in my previous post. What I was trying to suggest is that the panic info be hidden and instead display a simple error like "PANIC: the .bin file is missing or not specified". I'm running a serial connection to cubieboard, and whenever I forget to configure the fex/bin file I get this huge debug dump that looks like a backtrace or a stack/register memory dump of some sort that completely coveres my screen, so I am unable to see the original error message. the "screen /dev/ttyUSB0 115200" command I use won't let me scroll up.


Ah, yes, I see your point.  u-boot could probably refuse to boot the kernel without a script.bin, just like it does if it can't find uImage (or whatever the "kernel" env variable references). I don't maintain uboot, but I'll look into adding something like this to my builds.

Cubear

September 15, 2013, 05:14:39 pm #6 Last Edit: September 15, 2013, 05:18:49 pm by Cubear
There, I took some time to test the new kernel today.

$ git branch
* stage/sunxi-3.4
  sunxi-3.4

$ git log
commit 18f10f59b8325d41ea59729213108fa011b0c9d0
Author: Alejandro Mery <amery@geeks.cl>
Date:   Fri Sep 6 07:53:11 2013 +0200

    Revert "sunxi-hci: Remove code believed to be no-op"
   
    This reverts commit 5443e361562b0d30f18fdbde7ee8bce468cdc37a.
   
    by author request. "it is broken"
   
    Signed-off-by: Alejandro Mery <amery@geeks.cl>


Here's how I compiled. While running menuconfig I just looked around a bit then exited - it asked me to save, so I said yes.

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- sun4i_defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- uImage modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- EXTRAVERSION=-test -j6 INSTALL_MOD_PATH=output modules_install
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- EXTRAVERSION=-test -j6 INSTALL_MOD_PATH=output firmware_install


After that I copied uImage to /boot, firmware and modules to /lib/firmware and /lib/modules. The new kernel booted fine, samba worked fine the first time, but now I can't test it because the device won't reboot. Whenever I issue a reboot command (via serial or ssh) it gets stuck. One of the leds is programmed to turn on during boot, and it should turn back off while rebooting, but it doesn't happen.

Here's what the serial output shows:
Debian GNU/Linux 7 cubie1 ttyS0

cubie1 login: <6>br0: port 1(eth0) entered disabled state
[   35.412217] br0: port 1(eth0) entered disabled state
<6>br0: port 1(eth0) entered forwarding state
[   35.434524] br0: port 1(eth0) entered forwarding state
<6>br0: port 1(eth0) entered forwarding state
[   35.443832] br0: port 1(eth0) entered forwarding state
<6>br0: port 1(eth0) entered disabled state
[   35.661801] br0: port 1(eth0) entered disabled state
<6>br0: port 1(eth0) entered forwarding state
[   35.861057] br0: port 1(eth0) entered forwarding state
<6>br0: port 1(eth0) entered forwarding state
[   35.870389] br0: port 1(eth0) entered forwarding state
<6>br0: port 1(eth0) entered disabled state
[  175.002920] br0: port 1(eth0) entered disabled state
<6>device eth0 left promiscuous mode
[  175.025565] device eth0 left promiscuous mode
<6>br0: port 1(eth0) entered disabled state
[  175.033957] br0: port 1(eth0) entered disabled state
<6>sunxi-rtc sunxi-rtc: actually set time to 2013-9-15 21:3:10
[  180.496534] sunxi-rtc sunxi-rtc: actually set time to 2013-9-15 21:3:10


Notice the kernel log timestamps. At 175 seconds I issue a reboot command via ssh, and the serial output prints this. Then it gets stuck forever. I have to reset it by using the reset button or by unplugging it. The old kernel reboots fine.

Any ideas?

Cubear

September 16, 2013, 01:19:57 pm #7 Last Edit: September 17, 2013, 03:18:04 pm by Cubear
I noticed that there were some major updates in the kernel repository recently, so I decided to try out the stable branch again after failing with the staging one.

$ git branch
* sunxi-3.4
$ git log
commit 9ee9fc5f0988df5677f0f142b5b88a8988d283d7
Author: Henrik Nordstrom <henrik@henriknordstrom.net>
Date:   Mon Sep 16 09:17:05 2013 +0200

    pwm-sunxi: pwm-sunxi.h is a local include
   
    use correct #include statement for local includes. Was breaking in-tree builds.


Preliminary tests show that the samba network problem has been fixed, and the upload once again works fine. Also the rebooting bug has been eliminated. Finally the kernel version has been bumped to 3.4.61. I will test some more, and report back. If this kernel turns out to be stable I'll mark the thread solved.

~cubear

EDIT: If I issue a reboot command via the serial interface sometimes the reboot won't work. It prints out "INIT:" and freezes. But this has also been happening with earlier kernels including roman's. The reboot from ssh works fine so far.

EDIT 2: Looks like I spoke too soon. The reboot-freeze problem is back. Funny though that it worked 2 or 3 times from the beginning. I was able to test samba in-between, and the upload seemed fine. It was about 7.8 to 8.2 MB's, which is a bit slower than what I got earlier with the staging kernel (9MB/s). I did recompile the kernel several times during the test, so it is possible that some option in the kernel config is responsible for this faulty behavior. One thing I noticed is that during those reboots that worked I was able to see the kernel debug messages output like [OK] Stopping service abc... - this does not happen with the non-working reboots. I'll do some more tests tomorrow.

EDIT 3: Okay, this is weird. Earlier I cloned a new git repository, and compiled a bare sunxi-3.4 (3.4.61) kernel by doing a make sun4i_defconfig. The new kernel booted fine, rebooted fine and had no ethernet problems with samba. Afterwards I modified some kernel options (i.e. enabled ipv6, added filesystems, enabled some drivers, etc), and recompiled a couple more times. Samba seemed to work fine, but then after a certain kernel update the device suddenly failed to reboot... same old story. I suspected it was some kernel config that I modified. I tried to revert back to the bare kernel that I know worked fine by doing make clean and make sun4i_defconfig. Then I was going to periodically enable new config options to try to find out what causes the reboot problem. Unfortunately this new kernel failed to reboot too. Strange.

EDIT 4: To hell with this. I have no idea what's wrong. I reverted to the previous kernel that I've compiled before recompiling the bare image, and now it works again... and it doesn't. Seems to randomly decide to freeze.

EDIT 5: Okay, I'm about to give up on this. The slow samba upload has returned, and sometimes the reboot doesn't work - gets stuck as described above.

EDIT 6: Update! Earlier I reported that sometimes the reboot procedure gets stuck, and the hardware serial console only shown a string like "INIT:" after the reboot command has been issued. While the hardware serial stops responding, I was still able to SSH into the device, and poke around a bit. I noticed that there was a process like "/bin/sh /etc/init.d/rc 6" in the process list. There was also a process like "stty onlcr". When I killed this stty process the reboot procedure continued, and some more debug output was printed out in the hardware serial terminal. The device still failed to reboot with the usual "actually set time to... bla bla bla" message, but at least this time it got to that point. It would appear that sometimes the reboot process gets stuck inside the /etc/init.d/rc script on this line:

# Set onlcr to avoid staircase effect.
stty onlcr 0>&1


This spawns a new task that never finishes.

Cubear

September 18, 2013, 05:05:43 am #8 Last Edit: September 18, 2013, 06:48:46 am by Cubear
Patwood, are you still here? I think I found out a pattern (finally)!

Here's the thing. Whenever I boot the roman's headless image with my kernel (3.4.61 from sunxi-3.4 branch - using default sun4i_defconfig) by plugging in the power, the reboot process will freeze - the last thing serial outputs is that "actually set time to..." line. Sometimes it gets stuck and only outputs the "INIT:" string. No matter how many times I unplug the power and replug this will always happen.

Okay. So now that the reboot process is stuck let's reset the cubieboard by pressing and holding the reset button on the cubieboard (do not unplug it from power). It's the button next to the power socket. I hold it for like 8 seconds, and the board powers off. Then after like 10 seconds I push the button again and hold it for 1 second, the board will boot again. When it finishes booting I login and issue a reboot command as always. Now the board reboots fine! It even reboots fine consecutively (as many times in a row as I've tested).

patwood

Quote from: Cubear on September 18, 2013, 05:05:43 am
Patwood, are you still here? I think I found out a pattern (finally)!

Here's the thing. Whenever I boot the roman's headless image with my kernel (3.4.61 from sunxi-3.4 branch - using default sun4i_defconfig) by plugging in the power, the reboot process will freeze - the last thing serial outputs is that "actually set time to..." line. Sometimes it gets stuck and only outputs the "INIT:" string. No matter how many times I unplug the power and replug this will always happen.

Okay. So now that the reboot process is stuck let's reset the cubieboard by pressing and holding the reset button on the cubieboard (do not unplug it from power). It's the button next to the power socket. I hold it for like 8 seconds, and the board powers off. Then after like 10 seconds I push the button again and hold it for 1 second, the board will boot again. When it finishes booting I login and issue a reboot command as always. Now the board reboots fine! It even reboots fine consecutively (as many times in a row as I've tested).

Are you using a USB->serial port cable?  Can you reproduce this with the serial port disconnected?  I remember weird things happening sometimes with the serial port connected -- some power leaks from the serial port into the cubieboard.  Things like the power button not working with the serial port connected, system not rebooting, etc.

There's also a recent problem with uboot that was fixed.  Perhaps you should see if Roman has created newer images?

Cubear

Quote from: patwood on September 18, 2013, 09:37:04 pmAre you using a USB->serial port cable?  Can you reproduce this with the serial port disconnected?

Yes and yes (via ssh).

Where do you propose I get this updated bootloader? Most tutorials refer to the old one from hwpack here. Is there an updated version somewhere? Just checking, if I have to compile it too.

Roman doesn't seem to have any newer images. I'll have to consult him on this anyhow.
http://romanrm.ru/dl/a10/debian/


Oh, the samba problem is mostly gone again :-/
Still happens occasionally though I have no idea what triggers it.

alexvf

Sorry for take this thread to life after so much time, but i have interest in knowing how the reboot issue was fixed, if at all. Do any of you remember?