Re: NetBSD_10.0_BETA boot issues
On Thu, Jan 05, 2023 at 06:43:32AM -0600, Robert Nestor wrote: > Yes it is, but getting a dmesg during the failure seems to be > difficult since I haven?t seen a failure when booting with serial > console and most of the details of the failure scroll off the screen > before the boot crashes. We don't need the dmesg from the failure case, the working one is fine. Martin
Re: Wiki page review
Brook Milligan wrote: > I have written a page for the NetBSD Wiki on how to build bootable ARM > images using build.sh (see the attached PDF version). Before I commit > it, I would appreciate feedback regarding its clarity and > completeness. If anyone is willing to go through the process > described, that would be ideal as a verification of correctness. Maybe structure it to allow for some systems not needing U-Boot to be added to an image, most systems do need it now but that may change over time. e.g. A Pinebook Pro with Tow-Boot in SPI flash doesn't need U-Boot as well. Also, port-arm@ would probably be a better place to discuss this than netbsd-users@.
Re: Is this normal floppy behavior?
Michael Cheponis writes: > There are a bunch of files on the floppy when mounted; I delete them all; > but then, there is a large amount of 'used' space! unmounting + > remounting 'fixes' this problem. Did you type sync and wait?
Re: NetBSD_10.0_BETA boot issues
Martin, Yes it is, but getting a dmesg during the failure seems to be difficult since I haven’t seen a failure when booting with serial console and most of the details of the failure scroll off the screen before the boot crashes. However I may have stumbled across something that could be causing this. The performance improvements between 9.2 and 10.0 are impressive and very noticeable, especially the boot up time. The HP6200 has a fairly fast CPU and all the disks I’m seeing the boot problems on are 5,400 RPM disks. Some are inexpensive 3.5” and some are 2.5” pulls from old laptops installed into 3.5” sleds. All have identical creatures - 16-sector PIO, LBA48 addressing, PIO Mode 4, DMA Mode 2, Ultra DMA Mode 6, Write DMA FUA NCQ 32. On a hunch I dug up a 7,200 RPM disk and installed 10.0 onto it. That disk has never failed to boot and runs 10.0 just fine. So far I’ve booted it up about a dozen times using both BIOS and UEFI and have yet to see any failure. With the 5,400 disks I’d probably be lucky to see one successful boot in a dozen tries, so something is certainly different here! My hunch is that with the performance improvements the code runs a tad bit faster (my guess is something like 10-20% faster) and on a fast enough CPU with slow ATA attached disks sometimes the code gets ahead of the disk in completing a disk request. That might also explain why booting with a serial console never seems to fail as well, as outputting the console log at 9,600 Baud vs dumping it to the attached monitor slows the boot down just enough to succeed. I’m going to try setting the speed on the serial port to the highest I can to see if that tickles the boot issue. -bob On Jan 5, 2023, at 1:35 AM, Martin Husemann wrote: > On Wed, Jan 04, 2023 at 02:07:04PM -0600, Robert Nestor wrote: >> Be happy to try and provide more info if someone has suggestions. > > Is this the same machine as in https://gnats.netbsd.org/56737 ? > As Rin asked there: we need the full dmesg output of the machine. > > Martin
Re: NetBSD_10.0_BETA boot issues
Here’s one then. (Note the log entires about ehci0: missed micro frame have always been there for this machine no matter which version of NetBSD is used.) [ 1.00] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, [ 1.00] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017, [ 1.00] 2018, 2019, 2020, 2021, 2022 [ 1.00] The NetBSD Foundation, Inc. All rights reserved. [ 1.00] Copyright (c) 1982, 1986, 1989, 1991, 1993 [ 1.00] The Regents of the University of California. All rights reserved. [ 1.00] NetBSD 10.0_BETA (GENERIC) #0: Sat Dec 31 04:55:53 UTC 2022 [ 1.00] mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC [ 1.00] total memory = 12175 MB [ 1.00] avail memory = 11749 MB [ 1.00] timecounter: Timecounters tick every 10.000 msec [ 1.00] Kernelized RAIDframe activated [ 1.00] RTC BIOS diagnostic error 0x50 [ 1.00] timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 [ 1.04] efi: systbl at pa cad28f18 [ 1.04] mainbus0 (root) [ 1.04] ACPI: RSDP 0xCAC11000 24 (v02 HPQOEM) [ 1.04] ACPI: XSDT 0xCAC11078 74 (v01 HPQOEM SLIC-BPC 01072009 AMI 00010013) [ 1.04] ACPI: FACP 0xCAC18C58 F4 (v04 HPQOEM SLIC-BPC 01072009 AMI 00010013) [ 1.04] ACPI: DSDT 0xCAC11180 007AD7 (v02 HPQOEM SLIC-BPC 0008 INTL 20051117) [ 1.04] ACPI: FACS 0xCAD0EF80 40 [ 1.04] ACPI: APIC 0xCAC18D50 92 (v03 HPQOEM SLIC-BPC 01072009 AMI 00010013) [ 1.04] ACPI: SSDT 0xCAC18DE8 0001D6 (v01 AMICPU PROC 0001 MSFT 0301) [ 1.04] ACPI: MCFG 0xCAC18FC0 3C (v01 HPQOEM SLIC-BPC 01072009 MSFT 0097) [ 1.04] ACPI: HPET 0xCAC19000 38 (v01 HPQOEM SLIC-BPC 01072009 AMI. 0004) [ 1.04] ACPI: ASF! 0xCAC19038 A0 (v32 INTEL HCG 0001 TFSM 000F4240) [ 1.04] ACPI: SSDT 0xCAC190D8 005270 (v01 COMPAQ WMI 0001 MSFT 0301) [ 1.04] ACPI: SLIC 0xCAC1E348 000176 (v01 HPQOEM SLIC-BPC 0001 ) [ 1.04] ACPI: TCPA 0xCAC1E4C0 32 (v02 APTIO4 NAPAASF 0001 MSFT 0113) [ 1.04] ACPI: DMAR 0xCAC1E4F8 E8 (v01 ALASKA A M I 0001 INTL 0001) [ 1.04] ACPI: 3 ACPI AML tables successfully acquired and loaded [ 1.04] ioapic0 at mainbus0 apid 0: pa 0xfec0, version 0x20, 24 pins [ 1.04] cpu0 at mainbus0 apid 0 [ 1.04] cpu0: Use lfence to serialize rdtsc [ 1.04] cpu0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, id 0x206a7 [ 1.04] cpu0: node 0, package 0, core 0, smt 0 [ 1.04] cpu1 at mainbus0 apid 2 [ 1.04] cpu1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, id 0x206a7 [ 1.04] cpu1: node 0, package 0, core 1, smt 0 [ 1.04] cpu2 at mainbus0 apid 4 [ 1.04] cpu2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, id 0x206a7 [ 1.04] cpu2: node 0, package 0, core 2, smt 0 [ 1.04] cpu3 at mainbus0 apid 6 [ 1.04] cpu3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, id 0x206a7 [ 1.04] cpu3: node 0, package 0, core 3, smt 0 [ 1.04] cpu4 at mainbus0 apid 1 [ 1.04] cpu4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, id 0x206a7 [ 1.04] cpu4: node 0, package 0, core 0, smt 1 [ 1.04] cpu5 at mainbus0 apid 3 [ 1.04] cpu5: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, id 0x206a7 [ 1.04] cpu5: node 0, package 0, core 1, smt 1 [ 1.04] cpu6 at mainbus0 apid 5 [ 1.04] cpu6: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, id 0x206a7 [ 1.04] cpu6: node 0, package 0, core 2, smt 1 [ 1.04] cpu7 at mainbus0 apid 7 [ 1.04] cpu7: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, id 0x206a7 [ 1.04] cpu7: node 0, package 0, core 3, smt 1 [ 1.04] acpi0 at mainbus0: Intel ACPICA 20221020 [ 1.04] acpi0: X/RSDT: OemId , AslId [ 1.04] acpi0: MCFG: segment 0, bus 0-255, address 0xe000 [ 1.04] ACPI: Dynamic OEM Table Load: [ 1.04] ACPI: SSDT 0x908B61053008 0006F4 (v01 AMIIST 0001 MSFT 0301) [ 1.04] ACPI: Dynamic OEM Table Load: [ 1.04] ACPI: SSDT 0x908B60EA4708 E4 (v01 AMICST 0001 MSFT 0301) [ 1.04] acpi0: SCI interrupting at int 9 [ 1.04] acpi0: fixed power button present [ 1.04] timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 [ 1.008258] hpet0 at acpi0: high precision event timer (mem 0xfed0-0xfed00400) [ 1.008258] timecounter: Timecounter "hpet0" frequency 14318180 Hz quality 2000 [ 1.009003] MCH (PNP0C01) at acpi0 not configured [ 1.009003] pckbc1 at acpi0 (PS2K, PNP0303) (kbd port): io 0x60,0x64 ir
Re: Wiki page review
> On Jan 5, 2023, at 6:24 AM, Robert Swindells wrote: > > Also, port-arm@ would probably be a better place to discuss this > than netbsd-users@. Thanks for all the great feedback. The updated page has benefited from all the comments and have started a new thread on port-arm@, which makes a lot of sense. I’m hoping that will hit more people with ARM-expertise. Please continue discussion there and thanks for taking the time so far. Cheers, Brook
NetBSD basics.
Hi, * In Linux, systemd is contentious. NetBSD appears to have init but not systemd. What's the situation in NetBSD? * Some systems allow choice of alternatives glibc and musl. What's the situation in NetBSD? Thx, ... Peter E. mobile: +1 778 951 5147 VoIP: +1 604 670 0140 https://en.wikibooks.org/wiki/User:PeterEasthope
Re: Wiki page review
> On Jan 5, 2023, at 6:24 AM, Robert Swindells wrote: > > Maybe structure it to allow for some systems not needing U-Boot to be > added to an image, most systems do need it now but that may change over > time. > > e.g. A Pinebook Pro with Tow-Boot in SPI flash doesn't need U-Boot as > well. I’m not quite sure what you mean by this comment; for example, what does “it” refer to in the first sentence? Are you referring to the document, to the way the code works, or to something else? My understanding is that it may or may not be possible to boot the default armv7.img; I can’t really test that myself as my boards require u-boot boot blocks which that image does not have. For those boards that require u-boot boot blocks, it is possible for installboot to add them, thus avoiding all the manual steps that are otherwise required. The document simply makes clear (I hope) how that works. If you are suggesting that I mention that some other boards might boot directly from the armv7.img, that is great to know. I would happily add that information to the document, but I do not know what to say about which boards that applies to. If anyone can elaborate I am happy to improve the wording in this area. If you are suggesting that the code should work differently, that is more complicated and beyond what I am trying to accomplish. However, knowing what people think about how the code should work is potentially useful. Perhaps you were referring to something else? For example, a more general statement about which boards boot how? That would be great to have better knowledge of, but I do not currently know what to write. Clarifying this all likely takes more ARM expertise, which is a great reason for switching to port-arm@ as you suggest and I have done (see below). > Also, port-arm@ would probably be a better place to discuss this > than netbsd-users@. Great idea. As noted in my previous message, I started a new thread there with the version updated from all the comments I have received so far (and changed reply-to: to reflect that). Thanks for helping with this. Cheers, Brook
Re: Wiki page review
Brook Milligan wrote: > On Jan 5, 2023, at 6:24 AM, Robert Swindells wrote: > >> Maybe structure it to allow for some systems not needing U-Boot to be >> added to an image, most systems do need it now but that may change over >> time. >> >> e.g. A Pinebook Pro with Tow-Boot in SPI flash doesn't need U-Boot as >> well. > > I’m not quite sure what you mean by this comment; for example, what does > “it” refer to in the first sentence? Are you referring to the document, > to the way the code works, or to something else? You asked for a review of a proposed Wiki page, "it" refers to that page. I'm just suggesting that you could plan ahead and reduce the amount that someone needs to edit the wiki page in future. Currently your document states that building boot blocks and adding them to an image is always required. I gave an example of a system that doesn't need this, I would expect there will be other ones in future.
Re: NetBSD basics.
On Thu, Jan 5, 2023 at 7:32 PM wrote: > * In Linux, systemd is contentious. NetBSD appears to have init but > not systemd. What's the situation in NetBSD? The situation is very simple, in that there is no systemd. However, this occasionally means trouble when porting some software from Linux that assumes that systemd is present. IIRC, GNOME is one of those. > * Some systems allow choice of alternatives glibc and musl. What's the > situation in NetBSD? Neither. It comes with its own libc. One important difference between any BSD operating system and Linux is that the BSDs ship kernel, userland, libraries etc. as a single unit, the "base system". Any additional apps are installed via ports, packages or pkgsrc. So there is typically a single libc -- the one in the base system -- and that's it. You might find yourself enjoying this tighter integration of system components :) -- Benny
Re: Bluetooth woes
Marc Baudoin writes > % dmesg | grep ubt > [ 3,395938] ubt0 at uhub1 port 5 > [ 3,395938] ubt0: vendor 8087 (0x8087) product 0a2b (0xa2b), rev > 2.00/0.01, addr 1 Hello Sorry to say, this Intel adapter is not supported by NetBSD at this time. I do have one in my laptop but the solution is a bit complex for the time I have available and I've been using an external dongle instead. The problem with the Intel adapters is that they identify as a Bluetooth device but they won't work as one until the ROM is loaded; our stack attaches by default but none of the normal initialization commands work, so btconfig will show the _INIT flags as they have not completed and the device won't work. Some older Broadcom devices would identify as something else, then when the firmware attached would reattach as a Bluetooth so that worked ok; the later Broadcom devices had a functional ROM and you could use it properly and manually load a new ROM for better functionality. Both of those were a lot easier to support, this is a bit more complex as the stack currently has no way to send/receive packets to a device which is not initialized. regards iain
Re: Is this normal floppy behavior?
> Did you type sync and wait? Not originally; but I just tried it, and doing "sync" and waiting 2 hours produces no difference. *# sync* *# echo wait 2 hours* *wait 2 hours* *# df -h /a Filesystem Size Used Avail %Cap Mounted on/dev/sd2a 1.4M 529K 895K 37% /a* Some of the 529K is bad sectors (like 1,024 bytes); but why is 529K "used" when there are no files there: *# pwd * */aarm64# ls -la total 1drwxr-xr-x 1 root wheel 7168 Jan 1 1980 ./drwxr-xr-x 32 root wheel 1024 Dec 29 02:38 ../* fascinatingly, now, when I try to "umount" the filesystem: *# umount /a umount: /a: Device busy* This behavior seems incorrect. On Thu, Jan 5, 2023 at 5:26 AM Greg Troxel wrote: > Michael Cheponis writes: > > > There are a bunch of files on the floppy when mounted; I delete them all; > > but then, there is a large amount of 'used' space! unmounting + > > remounting 'fixes' this problem. > > Did you type sync and wait? >
Re: Is this normal floppy behavior?
On 1/5/23 21:32, Michael Cheponis wrote: fascinatingly, now, when I try to "umount" the filesystem: *# umount /a umount: /a: Device busy* Fascinating, from what you wrote you might still "be" in /a regards, chris
Re: Is this normal floppy behavior?
> On 1/5/23 21:32, Michael Cheponis wrote: >> fascinatingly, now, when I try to "umount" the filesystem: >> >> *# umount /a >> umount: /a: Device busy* > > Fascinating, from what you wrote you might still "be" in /a > > regards, > chris > It could also be that some program is still running which has a file in /a open. That would also explain why the space is still shown as allocated. Gary Duzan
Re: Is this normal floppy behavior?
>> *# umount /a >> umount: /a: Device busy* > Fascinating, from what you wrote you might still "be" in /a Whoops! Trying to minimize arguments, locations, attempts. Now, of course, wouldn't be nice if 'umount' said something like "hey dude! you're in the directory you're trying to umount." Naturally, I 'should' know that "Device busy" means "hey dude! you're in the directory you're trying to umount." gosh. ;-) On Thu, Jan 5, 2023 at 1:33 PM Christian Groessler wrote: > On 1/5/23 21:32, Michael Cheponis wrote: > > fascinatingly, now, when I try to "umount" the filesystem: > > > > *# umount /a > > umount: /a: Device busy* > > Fascinating, from what you wrote you might still "be" in /a > > regards, > chris >
Re: Is this normal floppy behavior?
> It could also be that some program is still running which has a file in > /a open. That would also explain why the space is still shown as > allocated. No other files were open; it was preceded by an "*rm -rf /a/**" cmd. But even after doing that, umounting it, and re-mounting it, I find: *# pwd/root# umount /a# mount_msdos /dev/sd2a /a# df -h /aFilesystem Size Used Avail %Cap Mounted on/dev/sd2a 1.4M 31K 1.4M 2% /a# ls -la /a total 1drwxr-xr-x 1 root wheel 7168 Jan 1 1980 ./drwxr-xr-x 32 root wheel 1024 Dec 29 02:38 ../* Hmmm, somehow 31K are still used. Used for what? Now, I know that on some filesystems, there is some 'hidden' disk space, which only root can access. Back in windows, 32,256 bytes (63 sectors) are seen to be 'used' - but there are no files. Is NetBSD 'reserving' some sectors for some reason? (As I say, normally after formatting, windows only marks sectors 'used' that are bad; and this particular diskette has 2 bad sectors (1,024 bytes)). Reformatting on Windows gives the 1,024 'used' bytes, and 1,456,640 'available' bytes, a capacity of 1,457,664 bytes. Now, the entire disk is 2880 sectors of 512 bytes each, hence 1,474,560 bytes; so the Directory uses 1,474,560 - 1,457,664 =16,896 bytes, or 33 sectors. Back on NetBSD, I get this oddness: *# mount_msdos /dev/sd2a /a mount_msdos: /dev/sd2a on /a: Operation not supported by device# mount_msdos /dev/sd2a /a * *#* OK, no big deal, but not sure why -- after a successful umount previously and ejection of the diskette -- that the error message is generated upon a new mount. *# df -h /a* *Filesystem Size Used Avail %Cap Mounted on/dev/sd2a 1.4M 1.0K 1.4M 0% /aarm64# ls -la /a total 1drwxr-xr-x 1 root wheel 7168 Jan 1 1980 ./drwxr-xr-x 32 root wheel 1024 Dec 29 02:38 ../drwxr-xr-x 1 root wheel 512 Jan 5 14:19 System Volume Information/# ls -la /a/System\ Volume\ Information * *total 1-rwxr-xr-x 1 root wheel 76 Jan 5 14:19 IndexerVolumeGuid** This all looks reasonable, except perhaps the 1.0K 'Used' field. (1K is bad blocks; and the IndexerVolumeGuid is only 76 bytes, which would consume 1 sector of 512 bytes, therefore the 'Used' should presumably be "1,5K" ?) *# df -G /a * */a (/dev/sd2a ): 512 block size 512 frag size 2847 total blocks 2845 free blocks2845 available 0 total files 224 free files 1810 filesys id msdos fstype 0x1000 flag255 filename length 0 owner 0 syncwrites0 asyncwrites* There are 2880 total sectors, and the directory uses 33 sectors, meaning the max# of available sectors is 2847, as is reported. 2 sectors are bad, hence 2845 actual free blocks. But: Where is *System Volume Information/**IndexerVolumeGuid *stored? Writing the biggest possible file (given there are 2 bad sectors): *# dd if=/dev/urandom of=big bs=1456640 count=1 1+0 records in1+0 records out1456640 bytes transferred in 0.063 secs (23121269 bytes/sec)# time cp big /a cp -pi big /a 0.00s user 0.01s system 0% cpu 14.627 total* Clearly, the writes are buffered, as it takes about a minute to write all cylinders. *# df -G /a /a (/dev/sd2a ): 512 block size 512 frag size 2847 total blocks 0 free blocks 0 available 0 total files 224 free files 1810 filesys id msdos fstype 0x1000 flag255 filename length 0 owner 4 syncwrites6 asyncwrites# ls -la /adrwxr-xr-x 1 root wheel 7168 Jan 1 1980 ./drwxr-xr-x 32 root wheel 1024 Dec 29 02:38 ../drwxr-xr-x 1 root wheel 512 Jan 5 14:19 System Volume Information/-rwxr-xr-x 1 root wheel 1456640 Jan 5 22:37 big** So *System Volume Information/**IndexerVolumeGuid *is stored 'someplace special', it would seem. And now, this is the the part I really don't understand: *# rm -rf /a/*zsh: sure you want to delete all the files in /a [yn]? yarm64# ls -la /atotal 1drwxr-xr-x 1 root wheel 7168 Jan 1 1980 ./drwxr-xr-x 32 root wheel 1024 Dec 29 02:38 ../arm64# df -G /a /a (/dev/sd2a ): 512 block size 512 frag size 2847 total blocks899 free blocks 899 available 0 total files 224 free files 1810 filesys id msdos fstype 0x1000 flag255 filename length 0 owner 7 syncwrites 12 asyncwrites* -Mike On Thu, Jan 5, 2023 at 2:07 PM wrote: > > On 1/5/23 21:32, Michael Cheponis wrote: > >> fascinatingly, now, when I try to "umount" the filesystem: > >> > >> *# umount /a > >> umount: /a: Device busy* > > > > Fascinating, from what you wrote you might still "be" in /a > > > > regards, > > chris > > > >It could also be that some program is still running which has a file in
