开云体育

Thanks Mark. I’ll that a try

开云体育

You just downloaded the operating system onto the SD card. It doesn't work that way. You have to image the SD card using a program such as WinDisk32imager. So download the OS and then use the imager to image the SD card.

Mick - W7CAT

New to Raspberry Pi
I have downloaded the Raspberry Pi program onto a mini Scan Disk and inserted into the board.? When powering up the raspberry it flashes five different colors on the monitor, and that's all. Where have I gone wrong?
thank you
Phil

That's because no reputable vendor will sell that garbage. Caveat Emptor.


Nigel Gunn, G8IFF/W8IFF wrote on 1/12/24 10:07 AM:

There's great electronics stuff on AliExpress that you just can't get elsewhere.
They're a great dealer.

On 12/01/2024 12:03 GMT Kevin McCrory <kbmccrory@...> wrote:


My advice is to stay away from aliexpress and temu for electronics.


On Fri, Jan 12, 2024, 04:09 Chuck Berry <n7chs.qsx@...> wrote:

Seeking advice on how to shop AliExpress. I am looking for a Radioberry v2.0. There appears to be no uniform price. They vary from $80 - $150. The descriptions for the top and bottom priced units appear to be similar but not copies. Both indicate the same installed hardware.



Any advice would be greatly appreciated. TIA N7CHS

Nigel A. Gunn, ///shoulders.outwards.resolutions tel +1-937-971-0366
Amateur Radio G8IFF W8IFF and GMRS WRBV701, e-mail nigel@... www

I would avoid AliExpress at all costs. I had never placed an order with them, never even went to their website, when charges started appearing on my credit card statement. It started with a couple charges here and there, all for under $20 each. It took me a while to notice them. Then there were several per day. I attempted to contact AliExpress with no response. I contacted my bank who said they were told by AliExpress these were all orders placed and delivered. By the time the charges accumulated to several thousand dollars I escalated to fraud charges and the bank looked deeper. Eventually my credit cards were cancelled and the charges removed. This all took a couple months. The bank fraud department told me this was actually a common occurrence, but since AliExpress was offshore, there was nothing they could do about it. I have since run into a number of other people with similar experiences.

I understand similar issues have occurred with Temu as well.

Stick with Amazon or other reliable US vendors. If it is a valid product, Amazon or regular ham stores will carry it.

Michael WA7SKG

Chuck Berry wrote on 1/11/24 10:49 AM:

I echo Steve here. I bought an Aursinc Radioberry (Amazon, not from AliExpress). It works as advertised, but be aware that you will need to create a T/R switching circuit, particularly if you plan to drive a small amp with the TX section. I doubt the RX front end is rugged enough to handle high signal input without damage.
KD4IZ

Hello David,

I ran across this video this morning:
leepspvideo does a fair job explaining the features of the Edatec RPi-5, and
also the Edatec industrialized display. You'll find a look inside the case,
comprehensive disassembly, and insight into its features and operation.
There are many useful links on the video page too.

Best regards,
Larry
WB6BBB

On Mon, Jan 8, 2024 at 09:37 AM, David Ranch wrote:

Interesting.. if your custom built Pat really isn't linked to AX.25 at all yet the panic is coming from Pat.. this means Pat is doing something very bad.

? Well, Pat probably isn't doing anything bad; you have to consider that /usr/bin/beacon triggers this as well. ?It's unlikely that separate bugs in both of those programs trigger the same crash. ?It's most likely a bug in the kernel, IMHO.

Ok.. sounds like a packaging miss but regardless, it sounds like your issue is still on the Linux AX.25 stack.

After I posted my note yesterday, I pulled down the source for Pat and compiled it on my test Pi. ?The recommend build process includes a step where the build scripts grab a copy of libax25, builds and statically links it. ?It's not a packaging miss; Martin decided to statically include a version of libax25 code, one that presumably has fixes he finds useful. ?From the non-preferred build method:

WARNING: No static libax25 library available.

? Linking against shared library instead. To fix

? this issue, set CGO_LDFLAGS to the full path of

? libax25.a, or run 'make.bash libax25' to download

? and compile libax25-0.0.12-rc4 in .build/

I'm currently aware of two ways to break the Linux kernel. ?

?? 1. I'm not 100% sure this is reproducible for all current kernel versions but I CAN reproduce this on Ubuntu 20.04 running 5.15.0.? Bring up your AX.25 stack with a

I tested the first bug by connecting to a remote node near by and connecting back to my -10 RMS server on the Pi. ?The Winlink banner came a cross and I issued the RMS help command, which sent about 2kb of data total through the remote node and back to my Pi. ?No crash or any notable issues.

?? 2. "Address already in use": From the Linux machines console (NOT SSHing into the AX.25 enabled LInux host) and using the "call" program, create an outbound

I tested the second bug, but I did use a ssh connection. ?You can simply escape the sequence by sending ~~. ; unfortunately, my node is headless and my serial console is busy waiting for a kernel panic, so I didn't have a console option. ?When I terminated the session, my terminal broke back to the Pi (e.g. the ssh connection was still established), but netstat did not show any hung connections. ?Be that as it may, I have seen this bug many times in older versions of Raspbian, some 4-5 years ago.


? Thanks
? Mike

开云体育

Hello MIchael,

Thanks for your help on this. ?Had another crash this morning (kernel blamed Pat) and, for reference, the last change I made was the firmware update.

Interesting.. if your custom built Pat really isn't linked to AX.25 at all yet the panic is coming from Pat.. this means Pat is doing something very bad.

Since I don't have much for connected mode packet, I skipped step 1 and instead did 2,3, and 4. ?I built the VE7FET tools on another identical RPi4 with Bookworm, removed the stock ax25 packages and installed the VE7FET versions on my packet station. ?I assume the *dbgsym* packages aren't necessary and were built by default?

Ok.. by skipping #1.. you made your life a bit harder since you might be hitting a known kernel issue but ultimately replacing the AX.25 packages with the VE7FET version is a good thing.? Correct, you don't need to install the dbgsym debugging symbol packages unless you want to improve the decoding a coredumps of programs (but not the kernel itself).

I don't think that's accurate as Pat is a modular Go program and the one binary might not link in stuff like this.? If you look at the package dependencies, they are there:
??

I should mention that I'm using Martin's build of Pat 0.15.1 from?. ?Unlike the Debian maintained package, this version isn't linked against libax25 nor is it a dependency for the package. ?Anyways, it's a moot point as my traffic still goes through /usr/sbin/kissattach (thus libax25) even if Pat doesn't use it, so I can't eliminate anything for troubleshooting.

Ok.. sounds like a packaging miss but regardless, it sounds like your issue is still on the Linux AX.25 stack.

I don't think there are any known issues with the Linux AX.25 stack and UI (aka unconnected) packets.? There *are* known issues with connected-mode sessions though.

It's really hard to tell what traffic may be triggering this crash, so I can't really rule out either UI or connected. ?However, my station is very quiet and it can go weeks with out answering a connected mode session. ?I did leave the Direwolf console open prior to the last crash so I could see the last traffic samples; nothing addressed to my station.

It is interesting, however, that the kernel shifted the blame from 'beacon' to 'pat', both apps generating UI packets. ?After the next crash, I think I'll disable the beacon in Pat to see if that shifts the kernel's blame again. ?I also have built a separate, nearly identical RPi4, and have configured it to beacon every minute into snd-dummy. ?The thought was to reproduce the crash on another node and hopefully speed it up. ?It's been running for 2 weeks and no joy.

If you still eventually hit the kernel panic again, try doing the #1 work around and see if it helps (works around a known issue of ANSWERING an incoming AX.25 connected-mode session which will panic the kernel on Ubuntu 20.04 hosts using the 5.15.0-xx kernel.

Do you have any details on this bug? ?I assume this is related to your thread?on the Direwolf list. ?If there is a known way to excerise the panic, then I could try to duplicate it on my setup. ?I'd welcome a way to crash my station on demand :) .

I'm currently aware of two ways to break the Linux kernel.? Doing this the most basic way:

?? 1. I'm not 100% sure this is reproducible for all current kernel versions but I CAN reproduce this on Ubuntu 20.04 running 5.15.0.? Bring up your AX.25 stack with a "server" program that creates a listening AX.25 socket (I also bring up other things like netromd, mheardd, etc):
??
??
??

?? Maybe Pat can do this for accepting incoming connections but Linpac will do this as well.? In this example, I use Linpac (0.29 develop branch).? When in Linpac, make an outbound connection to a remote packet node that supports making new connections.? Once connected to that remote node, initiate a connection back to your system's callsign+SSID.? Once connected, request some data such as the help command with Linpac's "//h" command.? At that point, your machine running Linpac will kernel panic.? If you're doing all this from within a Xwindows-based GUI, the machine will just cease up.? If you do this from a text console view, you'll see the panic output showing AX.25.?? This was reported a long time ago but no official fixes have been upstreamed into newer kernels.? To work around this issue, I've found that if you bring up the Linux AX.25 stack, then bring it down, and then bring it back up again.. the machine will not panic when incoming connections happen.


?? 2. "Address already in use": From the Linux machines console (NOT SSHing into the AX.25 enabled LInux host) and using the "call" program, create an outbound packet connection to any remote device be it a node, a BBS, a Winlink station, etc.? One the connection is up, forcefully disconnect the session with they key sequence: tilde (~) and then period (.).? Btw, this is the same force-disconnect sequence at OpenSSH's disconnect.? Once this happens, run the Linux command "netstat -A ax25 -an".? In this view, you will see the old session pair between the remote callsign+ssid to your local callsign+ssid present but listed as "LISTENING" state.? See for more detail.? At this point, that callsign+SSID pair will never work again from this link machine due to a bad kernel state.? The only way to clear this state is to reboot.? When you try to reboot, you will see messages like the following on the console (the final negative number will differ depending on how many stale kernel sessions are present:

?? "unregister_netdevice: waiting for ax0 to become free.? Usage count = -2"

The machine WILL reboot but it can take anywhere from 2 - 5 minutes before it finally goes down though I don't understand the variability in the time it takes.


?? 3. There are other minor "known issues" with the Linux AX.25 stack including some level of AX.25 state loss where received packets won't be acknowledged for a short period of time but resent packets will be recognized, some
packet loss with TCP/IP over AX.25 (AX-IP) packets (see with high rate pings, etc over Ethernet or IP-IP tunnels), and I think there are a few other minor ones I'm forgetting

--David
KI6ZHD

Hi David,

Thanks for your help on this. ?Had another crash this morning (kernel blamed Pat) and, for reference, the last change I made was the firmware update.

Since I don't have much for connected mode packet, I skipped step 1 and instead did 2,3, and 4. ?I built the VE7FET tools on another identical RPi4 with Bookworm, removed the stock ax25 packages and installed the VE7FET versions on my packet station. ?I assume the *dbgsym* packages aren't necessary and were built by default?

I don't think that's accurate as Pat is a modular Go program and the one binary might not link in stuff like this.? If you look at the package dependencies, they are there:
??

I should mention that I'm using Martin's build of Pat 0.15.1 from?. ?Unlike the Debian maintained package, this version isn't linked against libax25 nor is it a dependency for the package. ?Anyways, it's a moot point as my traffic still goes through /usr/sbin/kissattach (thus libax25) even if Pat doesn't use it, so I can't eliminate anything for troubleshooting.

I don't think there are any known issues with the Linux AX.25 stack and UI (aka unconnected) packets.? There *are* known issues with connected-mode sessions though.

It's really hard to tell what traffic may be triggering this crash, so I can't really rule out either UI or connected. ?However, my station is very quiet and it can go weeks with out answering a connected mode session. ?I did leave the Direwolf console open prior to the last crash so I could see the last traffic samples; nothing addressed to my station.

It is interesting, however, that the kernel shifted the blame from 'beacon' to 'pat', both apps generating UI packets. ?After the next crash, I think I'll disable the beacon in Pat to see if that shifts the kernel's blame again. ?I also have built a separate, nearly identical RPi4, and have configured it to beacon every minute into snd-dummy. ?The thought was to reproduce the crash on another node and hopefully speed it up. ?It's been running for 2 weeks and no joy.

If you still eventually hit the kernel panic again, try doing the #1 work around and see if it helps (works around a known issue of ANSWERING an incoming AX.25 connected-mode session which will panic the kernel on Ubuntu 20.04 hosts using the 5.15.0-xx kernel.

Do you have any details on this bug? ?I assume this is related to your thread?on the Direwolf list. ?If there is a known way to excerise the panic, then I could try to duplicate it on my setup. ?I'd welcome a way to crash my station on demand :) .

? Thanks
? Mike

开云体育

Hello Michael,

Following up on this issue, I've had a couple of more kernel panics since my last message. ?Unfortunately, I couldn't dedicate my monitor to troubleshooting, so I missed the first panic text output. ?However, since I had disabled beacon prior to the crash, I at least know it wasn't involved in this one.

I don't think there are any known issues with the Linux AX.25 stack and UI (aka unconnected) packets.? There *are* known issues with connected-mode sessions though.

? I strung up a serial console and ran "apt upgrade-full" to continue troubleshooting. ?The second crash happened this afternoon, from which I was able to capture the console messages below. ?It looks like Pat made the call that triggered the panic. ?I think that lets me rule out the user space AX-25 tools.

Not necessarily but I do suspect the issue is the in-kernel AX.25 stack but can be provoked by user-space I/O coming through libax25

? I've updated the EEPROM firmware, but I'm not really hopeful that is going to make a difference. ?I'm trying to figure out what I should try after the next crash. ?It seems like replacing ax25-apps and ax25-utils with VE7FET versions may not be helpful, since Pat is outside of this code base and it triggered the crash.

That though process is incorrect here.? Pat is just an userland-based application and depending on configured it to make AX.25 packet connections, it will either do it via the Linux in-kernel AX.25 support of via an AGW connection (offered via say Direwolf, G8BPQ Qtsoundmodem, etc).? btw.. the Rpi4/5 eeprom firmware is really more for hardware initialization and booting level stuff..? not OS/software related function.

?I thought about replacing libax25 with VE7FET's version, but I note that Pat isn't linked against libax25:

root@hammy:~# ldd /usr/bin/pat

linux-vdso.so.1 (0x0000007fa1e8e000)

libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa1ca0000)

/lib/ld-linux-aarch64.so.1 (0x0000007fa1e51000)

I don't think that's accurate as Pat is a modular Go program and the one binary might not link in stuff like this.? If you look at the package dependencies, they are there:
??


I would recommend this sequence:

?? 1. reboot your pi, start up the whole Linux AX.25 stack however you do that (script, system, etc).? Now bring DOWN the entire AX.25 stack.? Now bring the stack back up again, try Pat, and now try to reproduce the issue again (might take days as you said before)


If you still eventually hit the kernel panic again, now try these steps:

?? 2. uninstall the old OS provided ax25-apps, ax25-tools, libax25 packages
?? 3. download, compile, and install the VE7FET, ax25-apps, ax25-tools, libax25 packages
?? 4. Bring up the AX.25 stack and try to reproduce the panic again

If you still eventually hit the kernel panic again, try doing the #1 work around and see if it helps (works around a known issue of ANSWERING an incoming AX.25 connected-mode session which will panic the kernel on Ubuntu 20.04 hosts using the 5.15.0-xx kernel.


--David
KI6ZHD

Following up on this issue, I've had a couple of more kernel panics since my last message. ?Unfortunately, I couldn't dedicate my monitor to troubleshooting, so I missed the first panic text output. ?However, since I had disabled beacon prior to the crash, I at least know it wasn't involved in this one.

? I strung up a serial console and ran "apt upgrade-full" to continue troubleshooting. ?The second crash happened this afternoon, from which I was able to capture the console messages below. ?It looks like Pat made the call that triggered the panic. ?I think that lets me rule out the user space AX-25 tools.

? I've updated the EEPROM firmware, but I'm not really hopeful that is going to make a difference. ?I'm trying to figure out what I should try after the next crash. ?It seems like replacing ax25-apps and ax25-utils with VE7FET versions may not be helpful, since Pat is outside of this code base and it triggered the crash. ?I thought about replacing libax25 with VE7FET's version, but I note that Pat isn't linked against libax25:

root@hammy:~# ldd /usr/bin/pat

linux-vdso.so.1 (0x0000007fa1e8e000)

libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fa1ca0000)

/lib/ld-linux-aarch64.so.1 (0x0000007fa1e51000)

?Any ideas would be appreciated.

? Thanks
? Mike

hammy login: [338459.077054] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000318

[338459.086148] Mem abort info:

[338459.089117] ? ESR = 0x0000000096000006

[338459.093057] ? EC = 0x25: DABT (current EL), IL = 32 bits

[338459.098565] ? SET = 0, FnV = 0

[338459.101771] ? EA = 0, S1PTW = 0

[338459.105065] ? FSC = 0x06: level 2 translation fault

[338459.110122] Data abort info:

[338459.113154] ? ISV = 0, ISS = 0x00000006

[338459.117154] ? CM = 0, WnR = 0

[338459.120272] user pgtable: 4k pages, 39-bit VAs, pgdp=000000010188c000

[338459.126919] [0000000000000318] pgd=0800000102a5f003, p4d=0800000102a5f003, pud=0800000102a5f003, pmd=0000000000000000 ??

[338459.137830] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP

[338459.144284] Modules linked in: mkiss ax25 cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep vc4 brcmfmac snd_usb_audio snd_soc_hdmi_codec hci_uart drm_display_helper btbcm brcmutil cec bluetooth snd_hwdep drm_dma_helper snd_usbmidi_lib cfg80211 binfmt_misc drm_kms_helper snd_rawmidi snd_seq_device rpivid_hevc(C) bcm2835_codec(C) snd_soc_core v3d bcm2835_isp(C) v4l2_mem2mem bcm2835_v4l2(C) gpu_sched bcm2835_mmal_vchiq(C) snd_compress videobuf2_vmalloc snd_bcm2835(C) videobuf2_dma_contig snd_pcm_dmaengine ecdh_generic drm_shmem_helper snd_pcm videobuf2_memops videobuf2_v4l2 ecc cdc_acm snd_timer videobuf2_common rfkill raspberrypi_hwmon libaes videodev vc_sm_cma(C) snd fb_sys_fops raspberrypi_gpiomem mc syscopyarea sysfillrect sysimgblt nvmem_rmem uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 gpio_keys i2c_bcm2835 i2c_brcmstb

[338459.225429] CPU: 0 PID: 12263 Comm: pat Tainted: G ? ? ? ? C ? ? ? ? 6.1.0-rpi7-rpi-v8 #1 ?Debian 1:6.1.63-1+rpt1

[338459.235928] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)

[338459.241927] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)

[338459.249074] pc : ax25_addr_ax25dev+0x58/0xf0 [ax25]

[338459.254127] lr : ax25_addr_ax25dev+0x60/0xf0 [ax25]

[338459.259170] sp : ffffffc00fe4bcb0

[338459.262612] x29: ffffffc00fe4bcb0 x28: ffffff8103b98000 x27: 0000000000000000

[338459.269939] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000

[338459.277264] x23: 0000000000000000 x22: 0000000000000001 x21: ffffffde25b35b00

[338459.284591] x20: ffffffc00fe4bd78 x19: ffffff81048e8100 x18: 0000000000000000

[338459.291917] x17: 0000000000000000 x16: ffffffde94006014 x15: 00000040001d6000

[338459.299243] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000

[338459.306569] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffde25b27660

[338459.313895] x8 : ffffffc00fe4bbd8 x7 : 0000000000000000 x6 : ffffffc00fe4bdb0

[338459.321221] x5 : ffffffde9486e000 x4 : 00000000000000ac x3 : 0000000000000006

[338459.328548] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffffc00fe4bd78

[338459.335874] Call trace:

[338459.338435] ?ax25_addr_ax25dev+0x58/0xf0 [ax25]

[338459.343125] ?ax25_bind+0x2d8/0x300 [ax25]

[338459.347286] ?__sys_bind+0xfc/0x110

[338459.350824] ?__arm64_sys_bind+0x28/0x40

[338459.354797] ?invoke_syscall+0x50/0x120

[338459.358686] ?el0_svc_common.constprop.0+0x68/0x124

[338459.363630] ?do_el0_svc+0x34/0xd0

[338459.367075] ?el0_svc+0x30/0x94

[338459.370257] ?el0t_64_sync_handler+0xf4/0x120

[338459.374672] ?el0t_64_sync+0x18c/0x190

[338459.378471] Code: f9400273 b4000213 f9400661 aa1403e0 (f9418c21)

[338459.384736] ---[ end trace 0000000000000000 ]---

[338459.389501] Kernel panic - not syncing: Oops: Fatal exception in interrupt

[338459.396558] SMP: stopping secondary CPUs

[338459.400621] Kernel Offset: 0x1e8b400000 from 0xffffffc008000000

I was wondering what made it "industrialized" ...

开云体育

A lot of the things on there, they are just a reseller for like Amazon is. Amazon certainly aren't any better. Amazon tried to screw me over years ago, so I won't buy from them.

Mick - W7CAT