Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kern/57564 raspberry pi zero W also panic in linux (should be closed?)



Hello

After several days of long and boring CVS/rm cycle torture RaspberryPiZeroW testing, here we have the results.

As some people here suggested, first of all I wanted to discard a faulty power supply.

Using the USB power adaptor mentioned before, I connected my Fluke voltage tester to the GPIO 5V/GND RaspberryPi Zero W GPIO header pins in max/min voltage measurement mode. After a CVS/rm torture test, max and min voltage values were registered (VMAX= 5 .008V / Vmin= 4.986 V). No problem at all, voltage was good. Panics were present in raspbian at 1 GHz.

To definitely discard a power supply problem at all, I connected the RaspberryPi ZeroW to my laboratory linear power supply, feeding the Pi through 5V/GND GPIO header pins (using two 5V pins and 2 GND pins to have a better connection). 5V voltage and 5 A max current setting were stablished on the power supply. The panics showed up again in raspbian at 1 GHz máx frequency with a good power supply, so I definititely discarded a power supply issue.

So I burned again my previously saved copy of NetBSD in my new 64 GB SD card and tested again both 1 GHz and 700 MHz fixed frequency. At 1 GHz fixed frequency and after a random number of few hours I got the usual kernel panics. I eventually got a slightly different kernel diagnostic assertion panic that failed at a different function:


Sep 12 02:26:30 raspa-netbsd syslogd[456]: restart Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8104056] panic: kernel diagnostic assertion "!cpu_softintr_p()" failed: file "../../../../kern/subr_kmem.c", line 431 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8104056] cpu0: Begin traceback... Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8104056] 0xc8b3db54: netbsd:db_panic+0xc Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8104056] 0xc8b3db74: netbsd:vpanic+0xf4 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8104056] 0xc8b3db8c: netbsd:kern_assert+0x3c Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8104056] 0xc8b3dbc4: netbsd:kmem_zalloc+0xd0 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8204366] 0xc8b3dbfc: netbsd:bwfm_proto_bcdc_set_dcmd+0x44 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8204366] 0xc8b3dc2c: netbsd:bwfm_start+0x1b4 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8204366] 0xc8b3dc54: netbsd:if_transmit+0x13c Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8204366] 0xc8b3dc9c: netbsd:ether_output+0x2c0 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8304615] 0xc8b3dce4: netbsd:arprequest+0x1d0 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8304615] 0xc8b3dd54: netbsd:arp_llinfo_output+0x158 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8304615] 0xc8b3dedc: netbsd:nd_timer+0x390 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8404855] 0xc8b3df24: netbsd:callout_softclock+0xcc Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8404855] 0xc8b3dfac: netbsd:softint_dispatch+0x118 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8404855] 0xc96ede44: netbsd:softint_switch+0x5c Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8404855] 0xc96edec4: netbsd:irq_entry+0xac Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8505045] 0xc96edf14: netbsd:mi_switch+0x2e4 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8505045] 0xc96edf44: netbsd:sleepq_block+0xb0 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8505045] 0xc96edf6c: netbsd:cv_wait+0x50 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 22577.8505045] 0xc96edfac: [ 1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, Sep 12 02:26:30 raspa-netbsd /netbsd: [ 1.0000000] 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, Sep 12 02:26:30 raspa-netbsd /netbsd: [ 1.0000000] 2014, 2015, 2016, 2017, 2018, 2019, 2020, 2021, 2022, 2023 Sep 12 02:26:30 raspa-netbsd /netbsd: [ 1.0000000] The NetBSD Foundation, Inc. All rights reserved.

At 700 MHz there were no kernel panics. On the other hand, I got frequent WIFI failures with network stopped working. I connected a TV HDMI set to see what happened. The system was alive but could not recover the network without a reboot.

I suspected that my Raspberry Pi Zero W did not work properly at high frequency.

I have here another Raspberry pi Zero PCB that has been working without problems during several years. So I started to run the tests in NetBSD and Raspbian to see if there was diferences among both RaspberryPis. I have called them "The Flaky" and "The Good" RaspberryPi Zero W.

The results of the comparison test between both Raspberries:

******** FLAKY RASPBERRY ZERO W **********

NetBSD @ 1 GHz
   AFTER RANDOM NUMBER OF FEW HOURS:

   KERNEL PANIC->IT REBOOTS
   OR
   WIFI FAILURE-> NO NETWORK
   ( SYSTEM ALIVE BUT NETWORK NOT   RECOVERALE WITHOUT REBOOT)


NetBSD @ 700 MHz

   AFTER RANDOM NUMBER OF FEW HOURS:

   NO KERNEL PANICS

   WIFI FAILURE-> NO NETWORK
   ( SYSTEM ALIVE BUT NETWORK NOT  RECOVERALE WITHOUT REBOOT)"


RASPBIAN @700-1000 MHz F SCALING
   AFTER RANDOM NUMBER OF FEW HOURS:

   KERNEL PANIC-> IT HANGS


RASPBIAN  @ 700-900 MHz F SCALING
   AFTER 72 DAYS RUNNING FINE:
   SD CARD DIED.

*************************************************

********* GOOD RASPBERRY PI ZERO W ********

NetBSD @ 1 GHz
   AFTER RANDOM NUMBER OF FEW HOURS:

   NO KERNEL PANICS

   WIFI FAILURE-> NO NETWORK
   ( SYSTEM ALIVE BUT NETWORK NOT RECOVERALE WITHOUT REBOOT)

NetBSD @ 700 MHz
   NOT TESTED

RASPBIAN @ 700-1000 MHz F SCALING
   RUNS JUST FINE (DURING 5 DAYS AND  I STOPPED THE TEST)


RASPBIAN @ 700-900 MHz F SCALING
   NOT TESTED

**************************************************

So my conclusion is that my Flaky Rpi does not work properly at 1 GHz in both NetBSD and Raspbian. Some people in internet have experienced the same behaviour. I do not know if there are a few faulty units or you are in luck if your RaspberryPiZeroW works at 1 GHz without problems. The problem arises when the system is stressed and the scaling algorithm selects the highest CPU speed. In a relaxed Rpi the issue is more difficult to happen. On the other hand, on my NetBSD system with fixed 1 GHz CPU speed, the issue is more likely to happen.

Also noticed that bwfm WIFI NetBSD driver does not work reliable (I think that more people complain about the driver in other platforms). That is odd because the system becomes unreachable very frequently and you need to reboot it.

Please let me know what you think and  if this bug can be closed now.

Regards.
Ramiro

















Home | Main Index | Thread Index | Old Index