(08-26-2020, 02:23 AM)mrgtwentythree Wrote: (08-09-2020, 06:55 AM)Carl Wrote: Still experiencing wifi hard hangs in current using the bwfm driver (latest tested with the 2020.8.6 image from armbsd.org) - only happens when running firefox (79, 78, 77, 76 and 52). Usually happens within 20 seconds ~ 1 minute when streaming video or around 3~5 minutes with regular browsing. Keyboard gets completely unresponsive forcing me to do a physical reboot. However, has never experienced a wifi crash in TTY when I'm downloading large files like pkgsrc for example. Downloading large files in X also seems fine.
i've seen this keyboard hang. i've very recently started trying to figure it out and hopefully will have an idea soon. it's very annoying as it seems to affect all keyboard input as well as network IO, and i've not gotten any particular clues yet.
(08-09-2020, 06:55 AM)Carl Wrote: I also tried using a usb ethernet adapter - works a lot better but sometimes still hangs (~ 3 times / hour), doesn't hard hang though so just re-plugging it makes the wifi go back up. (adapter doesn't hang on the stock Manjaro image)
which wifi chipset? i've bee using a urtwn(4) mostly. i forget where the currently in-use one came from..
I used a ethernet adapter with the AX88179 chipset, but I have since switched to a urtwn wifi adapter which works flawlessy.
We are seeing frequent updates on armbsd.org lately. This is awesome.
But what we get is a bootable "disk" image. Rather than starting from scratch with every update, I've been updating my installation thusly:
1) flash image from armbsd.org to an SD-card.
2) boot to the SD-card (I find this difficult but it works)
3) when booting from SD,
/dev/rdk0 is the MS-DOS boot partition on the SD card
/dev/rdk1 is the NetBSD root on the SD card
/dev/rdk2 is the MS-DOS boot partition on the eMMC
/dev/rdk3 is the NetBSD root on the eMMC
I copy (via dd) /dev/rdk0 to /dev/rdk2
4) I mount /dev/rdk3, as /mnt
5) I copy /netbsd to /mnt
6) I copy (recursively) /libdata to /mnt/libdata
I do not know if I'm missing anything, or even if doing this at all is a good idea. But it seems to work.
09-13-2020, 02:04 PM
(This post was last modified: 09-13-2020, 03:16 PM by KC9UDX.)
Here's something I hadn't noticed before. Normally when I get checksum errors, and it doesn't recover soon, I power down. This time I didn't, and the CPU overheated. Something is in a race condition.
Something else worth mentioning is that a reboot never seems to solve the issue; a cold reset is necessary.
So...
I thought I should give another try, time and updates have passed
NetBSD-HEAD
I'm really glad that I know about "extra long press", used it 3 or 4 times
And that is why the air is NOT now blue
I see the root of boot is still littered with rpi files, does whoever makes
these images not have a pbp to test on (or a friend?)
Anyway, until it is fixed, please take it down, unless you wish to be a saboteur
Unmodified, it locked, with cap/num lock flash
De-rpi-ing I was able to get partial boots, one lock left caps/num lights on (not just a flash)
I was trying to usb boot, netbsd may not be capable of that, that may be why it had trouble finding root
Where are you getting this image? I don't think the ones I got from armbsd.org look like this.
Why would you want alpha/beta state software to be unavailable for testing? How are they going to get the bugs out? If you don't like what they're doing, you could certainly help or even compete, rather than kvetch.
http://www.armbsd.org/arm/ ,, click current tab, click pinebookpro button
Because it's EXACTLY the same problem as 2 months ago?
Because all 4 elf file and bootaarch64 are videocore III? (ie rpi)
Because all fix* have videocore in strings? As does bootcode.bin
And, and, config.txt references broadcom !!!!!!
I'm sure it works OK on rpi, but hard lockups are certainly something that should be fixed
I yoosta work for a fellow who would say "For vhat is vrong mit your hands?" 
09-15-2020, 08:04 PM
(This post was last modified: 09-15-2020, 11:58 PM by wdt.)
Well, I have half a clue, can kind of fumble my way around, however for those ....
-------------------------------
My computers broken, help me
(and often, with little detail, you're a mind reader aincha?)
----------------------------
and the 2nd line is far more annoying than the 1st
Anyway, don't try to boot usb, if you succeed you're far better than me
copy the pbp.dtb to root of boot (change type to ms basic data for ease of mounting)
comment out line with broadcom in config.txt (or did I edit it to rockchip, forget, doing update, no vt's)
Simple enough to make right, why not do it right to begin with?
And it did do a hard lockup while figuring it out (today), only 1
internal wifi seems to work OK, has been doing update for 20 min so far
Only sysinst has right repository
--edit--
os_prefix=dtb/rockchip/ (this in config.txt, instead of dtb/broadcom/)
I didn't have to make any modifications to the image from armbsd.org in order to work. And I've used several different releases, both 9.0 and current. I'll have to look at config.txt to see what it says.
What are you updating for 20 minutes? Are you using sysinst? If so, I don't think that does any good. It'll happily update 9.99.72 to 9.99.72, which takes time and data and nets nothing as far as I know.
Maybe because of uboot differences? mrfixit for me
Yes, sysinst, it did take a while before I realized,,
have not found All yet, would prefer something other than twm,, and mc
|
