Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
What does cpufreq-set -g performance do? Sounds like it would lock the BBB at max CPU clock speed, or at least, not let it go down to the lowest speeds. I found the generic Debian docs on *cpufreq-set*, but not the BBB specific instruction set and meanings. --- Graham On Mon, Jul 13, 2015 at 8:41 AM, Graham Haddock gra...@flexradio.com wrote: OK. I took my Rev.C unit (1c:ba:8c:d9:5e:dd) and loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a 16 GB uSD card. Unit, power supply and card are trusted. Absolutely no changes to the image, just install, boot, run. No updates, additions or modifications. No cape, only connections are 5V power and Ethernet. Times are GMT/UTC. I define the boot completion as the time when systemd updates the internal time from the network. Initial boot completion: Jul 12 19:12:09 Autonomous reboot:Jul 13 10:54:19 This time it took 15 hours for the autonomous reboot to occur. I'll let this one keep going, and report. --- Graham == On Mon, Jul 13, 2015 at 12:13 AM, William Hermans yyrk...@gmail.com wrote: *(3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: no more reboot* Interesting . . . If memory serves correctly, that was the fix for an older kernel. So possibly older code crept into the newer ? On Sun, Jul 12, 2015 at 8:35 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Results from overnight test: I used the worst rebooters for some tests: (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot* uptime 03:23:37 up 14:50, 1 user, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot* uptime 03:29:57 up 9:01, 1 user, load average: 0.02, 0.06, 0.05 As I have to leave for the day, I will let all my systems run for at least 12h without changes. If then still like this, I will do (1) and (3) on some more devices. @RobertCNelson: If you have further suggestions which image to test, let me know. --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
OK. I took my Rev.C unit (1c:ba:8c:d9:5e:dd) and loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a 16 GB uSD card. Unit, power supply and card are trusted. Absolutely no changes to the image, just install, boot, run. No updates, additions or modifications. No cape, only connections are 5V power and Ethernet. Times are GMT/UTC. I define the boot completion as the time when systemd updates the internal time from the network. Initial boot completion: Jul 12 19:12:09 Autonomous reboot:Jul 13 10:54:19 This time it took 15 hours for the autonomous reboot to occur. I'll let this one keep going, and report. --- Graham == On Mon, Jul 13, 2015 at 12:13 AM, William Hermans yyrk...@gmail.com wrote: *(3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: no more reboot* Interesting . . . If memory serves correctly, that was the fix for an older kernel. So possibly older code crept into the newer ? On Sun, Jul 12, 2015 at 8:35 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Results from overnight test: I used the worst rebooters for some tests: (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot* uptime 03:23:37 up 14:50, 1 user, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot* uptime 03:29:57 up 9:01, 1 user, load average: 0.02, 0.06, 0.05 As I have to leave for the day, I will let all my systems run for at least 12h without changes. If then still like this, I will do (1) and (3) on some more devices. @RobertCNelson: If you have further suggestions which image to test, let me know. --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
On Mon, Jul 13, 2015 at 8:46 AM, Graham Haddock gra...@flexradio.com wrote: What does cpufreq-set -g performance do? Sounds like it would lock the BBB at max CPU clock speed, or at least, not let it go down to the lowest speeds. Correct... I found the generic Debian docs on cpufreq-set, but not the BBB specific instruction set and meanings. It's a generic kernel interface, nothing bbb specific about it.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
debian@beaglebone:~$ uptime 11:58:48 up 23:22, 1 user, load average: 0.22, 0.07, 0.06 debian@beaglebone:~$ uname -a Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l GNU/Linux debian@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Image 2015-03-01 debian@beaglebone:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor ondemand may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 300 MHz:0.04%, 600 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:99.96% (4) I'll let it idle longer, but pretty sure it will have no problems. This board is an element14 REVC for what that's worth. On Mon, Jul 13, 2015 at 6:54 AM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, Jul 13, 2015 at 8:46 AM, Graham Haddock gra...@flexradio.com wrote: What does cpufreq-set -g performance do? Sounds like it would lock the BBB at max CPU clock speed, or at least, not let it go down to the lowest speeds. Correct... I found the generic Debian docs on cpufreq-set, but not the BBB specific instruction set and meanings. It's a generic kernel interface, nothing bbb specific about it.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Oh, and in case this might be relevant. The board is powered by USB, with only ethernet plugged in. On Mon, Jul 13, 2015 at 12:01 PM, William Hermans yyrk...@gmail.com wrote: debian@beaglebone:~$ uptime 11:58:48 up 23:22, 1 user, load average: 0.22, 0.07, 0.06 debian@beaglebone:~$ uname -a Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l GNU/Linux debian@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Image 2015-03-01 debian@beaglebone:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpuf...@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor ondemand may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 300 MHz:0.04%, 600 MHz:0.00%, 800 MHz:0.00%, 1000 MHz:99.96% (4) I'll let it idle longer, but pretty sure it will have no problems. This board is an element14 REVC for what that's worth. On Mon, Jul 13, 2015 at 6:54 AM, Robert Nelson robertcnel...@gmail.com wrote: On Mon, Jul 13, 2015 at 8:46 AM, Graham Haddock gra...@flexradio.com wrote: What does cpufreq-set -g performance do? Sounds like it would lock the BBB at max CPU clock speed, or at least, not let it go down to the lowest speeds. Correct... I found the generic Debian docs on cpufreq-set, but not the BBB specific instruction set and meanings. It's a generic kernel interface, nothing bbb specific about it.. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Results from overnight test: I used the worst rebooters for some tests: (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot* uptime 03:23:37 up 14:50, 1 user, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot* uptime 03:29:57 up 9:01, 1 user, load average: 0.02, 0.06, 0.05 As I have to leave for the day, I will let all my systems run for at least 12h without changes. If then still like this, I will do (1) and (3) on some more devices. @RobertCNelson: If you have further suggestions which image to test, let me know. --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Anyway, guys, give me an idea of what you're doing on these boards. When you get random system reset, and I'll test here too. I have a couple free beaglebones I can run arbitrary tests on at the moment. On Sun, Jul 12, 2015 at 12:19 PM, William Hermans yyrk...@gmail.com wrote: I've had this, or something similar happen to me a few times. When I did apt-get update again right after, it succeeded. But I'm still not sure of the cause. On Sun, Jul 12, 2015 at 11:48 AM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: If I look on one - but not the target worst case Beaglebone, I see only one package matching Robert's suggestion apt-cache search linux-image | grep ti | grep 4.1 linux-image-4.1.1-ti-r2 - Linux kernel, version 4.1.1-ti-r2 However, if I want to apt-get update on the two current worst case targets, I am getting Get:10 http://ftp.us.debian.org jessie-updates/non-free armhf Packages [20 B] Fetched 9247 kB in 20s (457 kB/s) W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. This system has installed uname -a Linux bb6c1f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux Is this a temporary hickup or any other idea? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch Solution: http://askubuntu.com/questions/41605/trouble-downloading-packages-list-due-to-a-hash-sum-mismatch-error Simply: rm -rf /var/lib/apt/lists/* -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
I've had this, or something similar happen to me a few times. When I did apt-get update again right after, it succeeded. But I'm still not sure of the cause. On Sun, Jul 12, 2015 at 11:48 AM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: If I look on one - but not the target worst case Beaglebone, I see only one package matching Robert's suggestion apt-cache search linux-image | grep ti | grep 4.1 linux-image-4.1.1-ti-r2 - Linux kernel, version 4.1.1-ti-r2 However, if I want to apt-get update on the two current worst case targets, I am getting Get:10 http://ftp.us.debian.org jessie-updates/non-free armhf Packages [20 B] Fetched 9247 kB in 20s (457 kB/s) W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. This system has installed uname -a Linux bb6c1f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux Is this a temporary hickup or any other idea? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Hi William: Doing nothing with the board. It is just sitting on the side connected to +5V power and Ethernet. So, for example, late last night (Central US time) I loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a trusted uSD card expanded the memory using gparted to the full 16GB, and turned off the four blue blinky lights. No other changes. Then I went to bed. Reading syslog, (Times are GMT, boot completion defined as systemd updating the time to network time. the initial boot (completion) was at JUL 12, 05:09:27 the lab was quiet, lights off, nothing running. The BBB automously rebooted at 08:25:33, 13:13:22, and 14:32:27 I am now rerunning with untouched reload of bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img Just load, install and boot. Talk to command line by SSH. --- Graham == On Sun, Jul 12, 2015 at 2:22 PM, William Hermans yyrk...@gmail.com wrote: Anyway, guys, give me an idea of what you're doing on these boards. When you get random system reset, and I'll test here too. I have a couple free beaglebones I can run arbitrary tests on at the moment. On Sun, Jul 12, 2015 at 12:19 PM, William Hermans yyrk...@gmail.com wrote: I've had this, or something similar happen to me a few times. When I did apt-get update again right after, it succeeded. But I'm still not sure of the cause. On Sun, Jul 12, 2015 at 11:48 AM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: If I look on one - but not the target worst case Beaglebone, I see only one package matching Robert's suggestion apt-cache search linux-image | grep ti | grep 4.1 linux-image-4.1.1-ti-r2 - Linux kernel, version 4.1.1-ti-r2 However, if I want to apt-get update on the two current worst case targets, I am getting Get:10 http://ftp.us.debian.org jessie-updates/non-free armhf Packages [20 B] Fetched 9247 kB in 20s (457 kB/s) W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. This system has installed uname -a Linux bb6c1f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux Is this a temporary hickup or any other idea? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
*Hi William:* *Doing nothing with the board. It is just sitting on the side connected to +5V power and Ethernet.* *So, for example, late last night (Central US time) I loaded bone-debian-8.1-lxqt-4gb-* *armhf-2015-07-05-4gb.img* *onto a trusted uSD card expanded the memory using gparted to the full 16GB, and turned off the four blue* *blinky lights. No other changes.* *Then I went to bed.* *Reading syslog,* *(Times are GMT, boot completion defined as systemd updating the time to network time.* *the initial boot (completion) was at JUL 12, 05:09:27 * *the lab was quiet, lights off, nothing running.* *The BBB automously rebooted at 08:25:33, 13:13:22, and 14:32:27* *I am now rerunning with untouched reload of bone-debian-8.1-lxqt-4gb-* *armhf-2015-07-05-4gb.img* *Just load, install and boot. Talk to command line by SSH.* *--- Graham* OK. Well, my own personal feelings is that this could be related to systemd. Somehow. I have no proof so substantiate that. So, I'll work on the problem bottom to top. What I mean by this is that I'll start with a rootfs I know that works. In my case wheezy 7.8. I've got that running now with debian@beaglebone:~$ uname -a Linux beaglebone 4.1.0-rc8-bone9 #1 Tue Jun 16 23:45:22 UTC 2015 armv7l GNU/Linux. I'll let it sit and idle for a day or so. After that, I'll download and flash the Jessie image, install sysv, disable systemd. Then start the test over again. Oh and yeah if one of you can do me a favor and run one of your boards as is with *sudo cpufreq-set -g performance* and see if the problem clears up ? On Sun, Jul 12, 2015 at 12:35 PM, Graham Haddock gra...@flexradio.com wrote: Hi William: Doing nothing with the board. It is just sitting on the side connected to +5V power and Ethernet. So, for example, late last night (Central US time) I loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a trusted uSD card expanded the memory using gparted to the full 16GB, and turned off the four blue blinky lights. No other changes. Then I went to bed. Reading syslog, (Times are GMT, boot completion defined as systemd updating the time to network time. the initial boot (completion) was at JUL 12, 05:09:27 the lab was quiet, lights off, nothing running. The BBB automously rebooted at 08:25:33, 13:13:22, and 14:32:27 I am now rerunning with untouched reload of bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img Just load, install and boot. Talk to command line by SSH. --- Graham == On Sun, Jul 12, 2015 at 2:22 PM, William Hermans yyrk...@gmail.com wrote: Anyway, guys, give me an idea of what you're doing on these boards. When you get random system reset, and I'll test here too. I have a couple free beaglebones I can run arbitrary tests on at the moment. On Sun, Jul 12, 2015 at 12:19 PM, William Hermans yyrk...@gmail.com wrote: I've had this, or something similar happen to me a few times. When I did apt-get update again right after, it succeeded. But I'm still not sure of the cause. On Sun, Jul 12, 2015 at 11:48 AM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: If I look on one - but not the target worst case Beaglebone, I see only one package matching Robert's suggestion apt-cache search linux-image | grep ti | grep 4.1 linux-image-4.1.1-ti-r2 - Linux kernel, version 4.1.1-ti-r2 However, if I want to apt-get update on the two current worst case targets, I am getting Get:10 http://ftp.us.debian.org jessie-updates/non-free armhf Packages [20 B] Fetched 9247 kB in 20s (457 kB/s) W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. This system has installed uname -a Linux bb6c1f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux Is this a temporary hickup or any other idea? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/lF1X1XINjDo/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it,
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
ah I see. following my own advice comes in handy sometimes . . . as in GitBisect. A bit out of my abilities. On Sun, Jul 12, 2015 at 1:41 PM, William Hermans yyrk...@gmail.com wrote: *Yeah, I think the transition to linear irq domain (added at 3.18) made cpsw* * a little extra flaky. Plus the new omap_8250 serial driver is not bug-free;* * just found a flow control bug in the h/w last week.* * I've had ssh shells go sideways on occasion, but not with that kind of* * regularity or effect.* * Like I said, the right diagnostic method is bisecting the kernel.* * It's going to take a while (multiple days) if several hours are required to* * distinguish good from bad kernel.* * Regards,* * Peter Hurley* Hi Peter. bisecting the kernel is unknown to me. As in the meaning, But I was wondering if some sort of remote, and very verbose logging might not help ? Currently I'm in the process of reading / learning advanced Linux programming, and have all these crazy ideas of what we could do. Just not sure what to trap and exactly 100% how to trap it. On Sun, Jul 12, 2015 at 1:29 PM, Peter Hurley pe...@hurleysoftware.com wrote: On 07/12/2015 03:35 PM, Graham Haddock wrote: Hi William: Doing nothing with the board. It is just sitting on the side connected to +5V power and Ethernet. So, for example, late last night (Central US time) I loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a trusted uSD card expanded the memory using gparted to the full 16GB, and turned off the four blue blinky lights. No other changes. Then I went to bed. Reading syslog, (Times are GMT, boot completion defined as systemd updating the time to network time. the initial boot (completion) was at JUL 12, 05:09:27 the lab was quiet, lights off, nothing running. The BBB automously rebooted at 08:25:33, 13:13:22, and 14:32:27 I am now rerunning with untouched reload of bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img Just load, install and boot. Talk to command line by SSH. Yeah, I think the transition to linear irq domain (added at 3.18) made cpsw a little extra flaky. Plus the new omap_8250 serial driver is not bug-free; just found a flow control bug in the h/w last week. I've had ssh shells go sideways on occasion, but not with that kind of regularity or effect. Like I said, the right diagnostic method is bisecting the kernel. It's going to take a while (multiple days) if several hours are required to distinguish good from bad kernel. Regards, Peter Hurley -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Thanks Peter for the in depth explanation. I was actually just reading a very detailed blog post by a person bug hunting in fedora 20 . . . the blog post could be considered a book in of its self, and wow yes, lots of learning to do before I can achieve the same myself. On Sun, Jul 12, 2015 at 2:16 PM, Peter Hurley pe...@hurleysoftware.com wrote: On 07/12/2015 04:41 PM, William Hermans wrote: /Yeah, I think the transition to linear irq domain (added at 3.18) made cpsw/ /a little extra flaky. Plus the new omap_8250 serial driver is not bug-free;/ /just found a flow control bug in the h/w last week./ // /I've had ssh shells go sideways on occasion, but not with that kind of/ /regularity or effect./ // /Like I said, the right diagnostic method is bisecting the kernel./ /It's going to take a while (multiple days) if several hours are required to/ /distinguish good from bad kernel./ // /Regards,/ /Peter Hurley/ Hi Peter. bisecting the kernel is unknown to me. As in the meaning, But I was wondering if some sort of remote, and very verbose logging might not help ? Currently I'm in the process of reading / learning advanced Linux programming, and have all these crazy ideas of what we could do. Just not sure what to trap and exactly 100% how to trap it. Linux mainline kernel source is really just a massive linear series of patches, one after the other, all tracked by git. Bisecting is a method of reducing the number of patches under test by 1/2 at each iteration to arrive at a problem commit. So, for example, let's say that I have a problem that cropped up on 4.2-rc1, but the problem wasn't happening on 4.1-rc7. I start a bisect with git: $ git bisect start v4.2-rc1 v4.1-rc7 Bisecting: 6261 revisions left to test after this (roughly 13 steps) [4570a37169d4b44d316f40b2ccc681dc93fedc7b] Merge tag 'sound-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound I build this kernel, test it, and mark it good or bad. Let's say the problem doesn't exhibit in this kernel. $ git bisect good Bisecting: 3371 revisions left to test after this (roughly 12 steps) [8d7804a2f03dbd34940fcb426450c730adf29dae] Merge tag 'driver-core-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Now I build this kernel, test it, and mark it good or bad. Let's say bad this time. $git bisect bad [3d9f96d850e4bbfae24dc9aee03033dd77c81596] Merge tag 'armsoc-dt' of git:// git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Each time, the number of commits under test are being reduced by 1/2. For a small kernel like Beaglebone this is no big deal, couple of minutes build time. For a 64-bit distro kernel, this can take several days for 14 iterations. Having a bunch of BBBs, all testing the same kernel at the same time significantly improves the confidence at each iteration that the kernel is good or bad (since obviously a problem that takes time to manifest may be mistakenly identified as good and then the bisect will narrow on the wrong commits). Instrumenting a problem like this is basically impossible. Regards, Peter Hurley -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
I now have one of the worst case rebooters running on 3.19.3-bone4 (already installed 8h ago) root@bb1cf1:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.1 (jessie) Release:8.1 Codename: jessie root@bb1cf1:~# uname -a Linux rc1cf1 3.19.3-bone4 #1 Fri Mar 27 16:05:22 UTC 2015 armv7l GNU/Linux root@bb1cf1:~# uptime 19:47:17 up 7:49, 1 user, load average: 0.47, 0.17, 0.09 and one on Robert's suggestion 4.1.1-ti-r2 root@rc6c1f:~# uname -a Linux rc6c1f 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux root@rc6c1f:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.1 (jessie) Release:8.1 Codename: jessie root@rc6c1f:~# uname -a Linux rc6c1f 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux root@rc6c1f:~# uptime 19:49:39 up 22 min, 1 user, load average: 1.09, 0.69, 0.31 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Something else that might help troubleshoot this issue if we can get a snapshot of each system by way of *ps aux *and store them somewhere for later examination. maybe pastebin. http://pastebin.com/ydneAtne On Sun, Jul 12, 2015 at 12:50 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: I now have one of the worst case rebooters running on 3.19.3-bone4 (already installed 8h ago) root@bb1cf1:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.1 (jessie) Release:8.1 Codename: jessie root@bb1cf1:~# uname -a Linux rc1cf1 3.19.3-bone4 #1 Fri Mar 27 16:05:22 UTC 2015 armv7l GNU/Linux root@bb1cf1:~# uptime 19:47:17 up 7:49, 1 user, load average: 0.47, 0.17, 0.09 and one on Robert's suggestion 4.1.1-ti-r2 root@rc6c1f:~# uname -a Linux rc6c1f 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux root@rc6c1f:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.1 (jessie) Release:8.1 Codename: jessie root@rc6c1f:~# uname -a Linux rc6c1f 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux root@rc6c1f:~# uptime 19:49:39 up 22 min, 1 user, load average: 1.09, 0.69, 0.31 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
*Yeah, I think the transition to linear irq domain (added at 3.18) made cpsw* * a little extra flaky. Plus the new omap_8250 serial driver is not bug-free;* * just found a flow control bug in the h/w last week.* * I've had ssh shells go sideways on occasion, but not with that kind of* * regularity or effect.* * Like I said, the right diagnostic method is bisecting the kernel.* * It's going to take a while (multiple days) if several hours are required to* * distinguish good from bad kernel.* * Regards,* * Peter Hurley* Hi Peter. bisecting the kernel is unknown to me. As in the meaning, But I was wondering if some sort of remote, and very verbose logging might not help ? Currently I'm in the process of reading / learning advanced Linux programming, and have all these crazy ideas of what we could do. Just not sure what to trap and exactly 100% how to trap it. On Sun, Jul 12, 2015 at 1:29 PM, Peter Hurley pe...@hurleysoftware.com wrote: On 07/12/2015 03:35 PM, Graham Haddock wrote: Hi William: Doing nothing with the board. It is just sitting on the side connected to +5V power and Ethernet. So, for example, late last night (Central US time) I loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a trusted uSD card expanded the memory using gparted to the full 16GB, and turned off the four blue blinky lights. No other changes. Then I went to bed. Reading syslog, (Times are GMT, boot completion defined as systemd updating the time to network time. the initial boot (completion) was at JUL 12, 05:09:27 the lab was quiet, lights off, nothing running. The BBB automously rebooted at 08:25:33, 13:13:22, and 14:32:27 I am now rerunning with untouched reload of bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img Just load, install and boot. Talk to command line by SSH. Yeah, I think the transition to linear irq domain (added at 3.18) made cpsw a little extra flaky. Plus the new omap_8250 serial driver is not bug-free; just found a flow control bug in the h/w last week. I've had ssh shells go sideways on occasion, but not with that kind of regularity or effect. Like I said, the right diagnostic method is bisecting the kernel. It's going to take a while (multiple days) if several hours are required to distinguish good from bad kernel. Regards, Peter Hurley -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
On 07/12/2015 04:41 PM, William Hermans wrote: /Yeah, I think the transition to linear irq domain (added at 3.18) made cpsw/ /a little extra flaky. Plus the new omap_8250 serial driver is not bug-free;/ /just found a flow control bug in the h/w last week./ // /I've had ssh shells go sideways on occasion, but not with that kind of/ /regularity or effect./ // /Like I said, the right diagnostic method is bisecting the kernel./ /It's going to take a while (multiple days) if several hours are required to/ /distinguish good from bad kernel./ // /Regards,/ /Peter Hurley/ Hi Peter. bisecting the kernel is unknown to me. As in the meaning, But I was wondering if some sort of remote, and very verbose logging might not help ? Currently I'm in the process of reading / learning advanced Linux programming, and have all these crazy ideas of what we could do. Just not sure what to trap and exactly 100% how to trap it. Linux mainline kernel source is really just a massive linear series of patches, one after the other, all tracked by git. Bisecting is a method of reducing the number of patches under test by 1/2 at each iteration to arrive at a problem commit. So, for example, let's say that I have a problem that cropped up on 4.2-rc1, but the problem wasn't happening on 4.1-rc7. I start a bisect with git: $ git bisect start v4.2-rc1 v4.1-rc7 Bisecting: 6261 revisions left to test after this (roughly 13 steps) [4570a37169d4b44d316f40b2ccc681dc93fedc7b] Merge tag 'sound-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound I build this kernel, test it, and mark it good or bad. Let's say the problem doesn't exhibit in this kernel. $ git bisect good Bisecting: 3371 revisions left to test after this (roughly 12 steps) [8d7804a2f03dbd34940fcb426450c730adf29dae] Merge tag 'driver-core-4.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Now I build this kernel, test it, and mark it good or bad. Let's say bad this time. $git bisect bad [3d9f96d850e4bbfae24dc9aee03033dd77c81596] Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Each time, the number of commits under test are being reduced by 1/2. For a small kernel like Beaglebone this is no big deal, couple of minutes build time. For a 64-bit distro kernel, this can take several days for 14 iterations. Having a bunch of BBBs, all testing the same kernel at the same time significantly improves the confidence at each iteration that the kernel is good or bad (since obviously a problem that takes time to manifest may be mistakenly identified as good and then the bisect will narrow on the wrong commits). Instrumenting a problem like this is basically impossible. Regards, Peter Hurley -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
By the way, currently on sdcard I am running wheezy 7.8 I believe. debian@beaglebone:~$ cat /etc/dogtag BeagleBoard.org Debian Image 2015-03-01 debian@beaglebone:~$ uname -a Linux beaglebone 3.8.13-bone70 #1 SMP Fri Jan 23 02:15:42 UTC 2015 armv7l GNU/Linux So I could apt-get install linux-image-4.1whatever and see if this could be related to the rootfs, or what. On Sun, Jul 12, 2015 at 12:22 PM, William Hermans yyrk...@gmail.com wrote: Anyway, guys, give me an idea of what you're doing on these boards. When you get random system reset, and I'll test here too. I have a couple free beaglebones I can run arbitrary tests on at the moment. On Sun, Jul 12, 2015 at 12:19 PM, William Hermans yyrk...@gmail.com wrote: I've had this, or something similar happen to me a few times. When I did apt-get update again right after, it succeeded. But I'm still not sure of the cause. On Sun, Jul 12, 2015 at 11:48 AM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: If I look on one - but not the target worst case Beaglebone, I see only one package matching Robert's suggestion apt-cache search linux-image | grep ti | grep 4.1 linux-image-4.1.1-ti-r2 - Linux kernel, version 4.1.1-ti-r2 However, if I want to apt-get update on the two current worst case targets, I am getting Get:10 http://ftp.us.debian.org jessie-updates/non-free armhf Packages [20 B] Fetched 9247 kB in 20s (457 kB/s) W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. This system has installed uname -a Linux bb6c1f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux Is this a temporary hickup or any other idea? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
On 07/12/2015 03:35 PM, Graham Haddock wrote: Hi William: Doing nothing with the board. It is just sitting on the side connected to +5V power and Ethernet. So, for example, late last night (Central US time) I loaded bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img onto a trusted uSD card expanded the memory using gparted to the full 16GB, and turned off the four blue blinky lights. No other changes. Then I went to bed. Reading syslog, (Times are GMT, boot completion defined as systemd updating the time to network time. the initial boot (completion) was at JUL 12, 05:09:27 the lab was quiet, lights off, nothing running. The BBB automously rebooted at 08:25:33, 13:13:22, and 14:32:27 I am now rerunning with untouched reload of bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img Just load, install and boot. Talk to command line by SSH. Yeah, I think the transition to linear irq domain (added at 3.18) made cpsw a little extra flaky. Plus the new omap_8250 serial driver is not bug-free; just found a flow control bug in the h/w last week. I've had ssh shells go sideways on occasion, but not with that kind of regularity or effect. Like I said, the right diagnostic method is bisecting the kernel. It's going to take a while (multiple days) if several hours are required to distinguish good from bad kernel. Regards, Peter Hurley -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
*(3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: no more reboot* Interesting . . . If memory serves correctly, that was the fix for an older kernel. So possibly older code crept into the newer ? On Sun, Jul 12, 2015 at 8:35 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Results from overnight test: I used the worst rebooters for some tests: (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot* uptime 03:23:37 up 14:50, 1 user, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot* uptime 03:29:57 up 9:01, 1 user, load average: 0.02, 0.06, 0.05 As I have to leave for the day, I will let all my systems run for at least 12h without changes. If then still like this, I will do (1) and (3) on some more devices. @RobertCNelson: If you have further suggestions which image to test, let me know. --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
I have several Rev C BBB units, that have been in use enough to be considered trusted hardware. All of them, running Debian 8.1 kernel 3.14 are rock solid. By that, I mean that they will run for months without problems. Maybe longer, I have not left them undisturbed for any longer than that. I have tried to run the Debian 8.1 / kernel 4.1.x test releases, and they all autonomously reboot several times per day. No regular or reproducible pattern, nothing in the syslog, other than the reboot process itself. This includes the 2015-07-05 kernel 4.1.1 release. (bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img) All I do is put it on a 16 GB card, expand the available memory to 16 GB from 4 GB, and turn off the 4 blinky lights. No other changes. The unit will reboot at random, several times per day. This has been common to all the kerenl 4.1 releases. Although a random pattern to the reboots, it is easy enough to reproduce. If you turn off the blinky lights, it is easy to recognize, since they come back on when it reboots. Or examine the syslog. --- Graham == -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
On Jul 12, 2015 12:20 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Instabilities have been found by just flashing elinux.org images from, for example, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console, in special Flasher: (console) (BeagleBone Black eMMC) and letting the board idle with network + serial console connected Also, is 4.1.x stable if you don't mess with the image I am willing to try with serveral images, as I have 15 boards suffering from this under supervision But I don't understand which sequence to go for. There are so many, if I look for them in apt-cache search linux-image | grep ti | grep 4.1 BTW, we had similar issues when we started testing 3.14.. I saw it happen on a board Thursday, won't be able to dig into it again to Monday. --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
On 07/12/2015 10:17 AM, Graham wrote: I have several Rev C BBB units, that have been in use enough to be considered trusted hardware. All of them, running Debian 8.1 kernel 3.14 are rock solid. By that, I mean that they will run for months without problems. Maybe longer, I have not left them undisturbed for any longer than that. I have tried to run the Debian 8.1 / kernel 4.1.x test releases, and they all autonomously reboot several times per day. No regular or reproducible pattern, nothing in the syslog, other than the reboot process itself. This includes the 2015-07-05 kernel 4.1.1 release. (bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img) All I do is put it on a 16 GB card, expand the available memory to 16 GB from 4 GB, and turn off the 4 blinky lights. No other changes. The unit will reboot at random, several times per day. This has been common to all the kerenl 4.1 releases. Although a random pattern to the reboots, it is easy enough to reproduce. If you turn off the blinky lights, it is easy to recognize, since they come back on when it reboots. Or examine the syslog. The common debugging method for problems like this is to bisect. However, if the start and end points are 3.14 and 4.1.x, respectively, that would be prohibitive. Best to find a closer start point than 3.14. Also, is 4.1.x stable if you don't mess with the image? Regards, Peter Hurley -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Instabilities have been found by just flashing elinux.org images from, for example, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console, in special *Flasher: (console) (BeagleBone Black eMMC)* and letting the board idle with network + serial console connected Also, is 4.1.x stable if you don't mess with the image? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Instabilities have been found by just flashing elinux.org images from, for example, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console, in special *Flasher: (console) (BeagleBone Black eMMC)* and letting the board idle with network + serial console connected Also, is 4.1.x stable if you don't mess with the image I am willing to try with serveral images, as I have 15 boards suffering from this under supervision But I don't understand which sequence to go for. There are so many, if I look for them in apt-cache search linux-image --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
I will try it by reloading a totally untouched bone-debian-8.1-lxqt-4gb-armhf-2015-07-05-4gb.img, and report back. No cape, trusted Rev.C hardware and power supply. All communications via Ethernet. By my saying that 3.14 is rock solid, this includes up to bone-debian-8.1-lxqt-4gb-armhf-2015-06-15-4gb.img, which was the last non-kernel-4 test release. Same hardware, same power supplies, same Ethernet connection. No other hardware or connections. --- Graham == -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
If I look on one - but not the target worst case Beaglebone, I see only one package matching Robert's suggestion apt-cache search linux-image | grep ti | grep 4.1 linux-image-4.1.1-ti-r2 - Linux kernel, version 4.1.1-ti-r2 However, if I want to apt-get update on the two current worst case targets, I am getting Get:10 http://ftp.us.debian.org jessie-updates/non-free armhf Packages [20 B] Fetched 9247 kB in 20s (457 kB/s) W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. This system has installed uname -a Linux bb6c1f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux Is this a temporary hickup or any other idea? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
watchdog was the first thing that popped into my mind heh. On Sun, Jul 12, 2015 at 10:46 AM, Robert Nelson robertcnel...@gmail.com wrote: On Jul 12, 2015 12:20 PM, 'dl4mea' via BeagleBoard beagleboard@googlegroups.com wrote: Instabilities have been found by just flashing elinux.org images from, for example, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console, in special Flasher: (console) (BeagleBone Black eMMC) and letting the board idle with network + serial console connected Also, is 4.1.x stable if you don't mess with the image I am willing to try with serveral images, as I have 15 boards suffering from this under supervision But I don't understand which sequence to go for. There are so many, if I look for them in apt-cache search linux-image | grep ti | grep 4.1 BTW, we had similar issues when we started testing 3.14.. I saw it happen on a board Thursday, won't be able to dig into it again to Monday. --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
