Build error
With up-to-date sopurces I am seeing the following: cleandir ===> lib/libterminfo nbmake[5]: "/build/netbsd-current/src_ro/lib/libterminfo/Makefile" line 50: Could not find Makefile.hash nbmake[5]: Fatal errors encountered -- cannot continue nbmake[5]: stopped in /build/netbsd-current/src_ro/lib/libterminfo nbmake[4]: stopped in /build/netbsd-current/src_ro/lib nbmake[3]: stopped in /build/netbsd-current/src_ro nbmake[2]: stopped in /build/netbsd-current/src_ro nbmake[1]: stopped in /build/netbsd-current/src_ro nbmake: stopped in /build/netbsd-current/src_ro This seems to be reproducible... +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Failure building -current amd64
On Fri, 12 Apr 2024, Chavdar Ivanov wrote: Does anybody else have the same problem? My last amd64 build is from the 31st of March. We are aware of the current breakage in HEAD +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Strange sensor names for amdzentemp(4)
On Wed, 20 Mar 2024, J. Hannken-Illjes wrote: # envstat -d amdzentemp0 Current CritMax WarnMax WarnMin CritMin Unit cpu0 temperature:55.125 degC cpu0 ccd0 temperature:36.375 degC cpu0 ccd1 temperature:37.500 degc # The string originates from sys/arch/x86/pci/amdzentemp.c line 471. In this context CCD is a synonym for Core Complex Die. Ah! That makes more sense! Thanks! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Strange sensor names for amdzentemp(4)
Oddly, I am seeing the following sensor info. Note that the config doesn't even contain ``ccd''. (Previous incarnations of this config _did_ have ccd, but it's been completely removed when I changed to use raidframe...) # envstat -d amdzentemp0 Current CritMax WarnMax WarnMin CritMin Unit cpu0 temperature:55.125 degC cpu0 ccd0 temperature:36.375 degC cpu0 ccd1 temperature:37.500 degc # +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Usage/syntax for command-line utilities
Just a quick bit of confusion here... Why do we have drvctl(8) and gpt(8) (for example only, there are others) which put the device-to-act-on at the end of the command: gpt [-Hnqrv] [-m mediasize] [-s sectorsize] [-T timestamp] command [command_options] device while others such as dkctl(8) and scsictl(8) put the device-to-act-on immediately after the utility name: dkctl device command [arg [...]] scsictl device command [arg [...]] This just feels confusing, and leads to interesting error messages if you enter the command in the incorrect sequence: # scsictl start sd0 scsictl: start: No such file or directory +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: raidframe and gpt
On Sat, 16 Mar 2024, Paul Goyette wrote: Does anyone have an example of how to configure raid0 on a GPT disk? I can easily set the partition type with gpt, but how do I reserve space for the raid component label? Do I need to reserve that space? Also, does raidframe understand the NAME=gpt-label syntax in the config file? Or does it require me to specify the particular dk ? (And what happens if something moves and changes?) One more quuestion: the raidctl man page talks about partitioning the raid device using mbr partitions. Is it possible to use GPT here? Will the resulting wedges show up automatically? It seems so much simpler to use ccd(4) but there's a nasty memory allocation bug which makes it unuseable for now. Thanks in advance! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+ !DSPAM:65f65ac4122352312412431! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
raidframe and gpt
Does anyone have an example of how to configure raid0 on a GPT disk? I can easily set the partition type with gpt, but how do I reserve space for the raid component label? Do I need to reserve that space? Also, does raidframe understand the NAME=gpt-label syntax in the config file? Or does it require me to specify the particular dk ? (And what happens if something moves and changes?) It seems so much simpler to use ccd(4) but there's a nasty memory allocation bug which makes it unuseable for now. Thanks in advance! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
Well, the power adapter cable arrived today but it doesn't solve the problem. With 'scsictl sd0 start' and 'dkctl sd0 makewedges' it works fine, so I'm moving on to finding something to address the display problem. Thanks for all the help so far. On Wed, 13 Mar 2024, Paul Goyette wrote: On Wed, 13 Mar 2024, Michael van Elst wrote: On Tue, Mar 12, 2024 at 11:00:02PM -0700, Paul Goyette wrote: ``scsictl sd0 start'' makes a little bit of progress, and claims to be "fabricating a geometry". ``gpt show -a sd0'' shows two partitions (one for NetBSD backups, and one for Windoze backups) # gpt show sd0 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 342014 Unused 2048 4294967296 1 GPT part - NetBSD FFSv1/FFSv2 4294969344 3518951424 2 GPT part - Windows basic data 7813920768 49119 Unused 7813969887 32 Sec GPT table 7813969919 1 Sec GPT header That looks fine. But it does not seem to progress to the discover-wedges process, and no wedges seem to exist: # dkctl sd0 listwedges /dev/rsd0: no wedges configured The wedge autodetection happens when the device attaches (and failed since the disk was offline). This is different from disklabels that are fetched by the first opener (and are usually dropped with the last close, except traditionally for vnd). You can manually trigger autodetection with dkctl sd0 makewedges Yup, that's the magic word. I used scsictl and dkctl both, and the external drive appeears normal. Thanks! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+ !DSPAM:65f231e1156131740011365! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Graphics card issues with new system build
FWIW, I also found a crash dump. I've seen a couple of these, but was not aware of any succcessful dump. I'm not sure what kernel was in use at the time of the dump, but here's the backtrace. Crash version 10.99.10, image version 10.99.10. Kernel compiled without options LOCKDEBUG. System panicked: dump forced via kernel debugger Backtrace from time of crash is available. layer_putpages() at 0 kern_reboot() at kern_reboot+0x87 db_sync_cmd() at db_sifting_cmd db_command() at db_command+0x123 db_command_loop() at db_command_loop+0x1c7 db_trap() at db_trap+0xcc kdb_trap() at kdb_trap+0x106 trap() at trap+0x2de --- trap (number 1) --- breakpoint() at breakpoint+0x5 vpanic() at vpanic+0x173 panic() at printf_nostamp assert_sleepable() at assert_sleepable+0x99 pool_cache_get_paddr() at pool_cache_get_paddr+0x13c ccdstart() at ccdstart+0x13b bdev_strategy() at bdev_strategy+0x81 spec_strategy() at spec_strategy+0x6e VOP_STRATEGY() at VOP_STRATEGY+0x3c dkstart() at dkstart+0x13e dkiodone() at dkiodone+0xa6 lddone() at lddone+0x10 nvme_q_complete() at nvme_q_complete+0xff softint_dispatch() at softint_dispatch+0x112 DDB lost frame for Xsoftintr+0x4c, trying 0xbca0dfe9c0f0 Xsoftintr() at Xsoftintr+0x4c --- interrupt --- _KERNEL_OPT_MEMORY_RBFLAGS() at bd010ac7c1c8 On Thu, 14 Mar 2024, Paul Goyette wrote: OK, I'm getting frustrated as hell. :-) I've got my new system built, and managed to get the dmesg uploaded to NYCBug ... It's got a AMD Ryzen 9 7950X3D CPU, which has internal video configured as acpivga0 - I disable this (using userconf) when I boot because I need to use the older-but-supported GeForce 730 graphics card. Boot comes up normally and starts X (via xdm). However, I'm getting the following message logged on the console. As far as I can tell, they're logged when switching from the xdm console session to a non-X session; but it is difficult to be certain of the timing. nouveau0: error: DRM: core notifier timeout I also sometimes get nouveau0: failed to idle channel n [user] when stopping xdm. During normal operation, things are OK, other than "jerky" cursor tracking. Most often, the cursor "sticks" in one spot for a few seconds, and then continues to track. "One spot" is very often, but NOT ALWAYS, at a point where the mouse icon needs to change (ie, it enters or leaves a window or button, etc.) After a while, the system just hangs (suspicion: it's hitting one of the core notifier timeouts, and hangs forever rather than time-out). I can still access the machine via network log-in but cannot get anything done "locally". At this point I can't even switch to the non-X console sessions. The hang-time varies, but comes much sooner when there is heavy system activity - like build.sh - going on. It even comes, however, with no activity at all - just staring at the screen for a few hours triggers the hang. I've got a bunch of newer video cards, but our current video drivers don't support them, and end up using genfb with a "default" mode-line that makes everything look wrong. And I've already cannabilized the old machine (which had a now non-functional GeForce 1050 Ti - maybe it was a 1080 but I can't find any marking) so I can't go back. At this point, I am stuck and don't know how to proceed. I'm willing to buy one more video card (but only one!) if I have a high likelihood of it working. But if there's something else going on which is likely to be fatal no matter what video card I choose I'd rather not spend more cash. If you do recommend another card, please be very explicit in identifying the make and model and any other relevant attributes (how much graphics memory, for example). All reasonable suggestions will be appreciated. If there are specific debug commands to try, please let me know. (But also know that I don't know much about the video subsystem - this is way beyond my usual level of knowledge.) +-+----------+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+ !DSPAM:65f3b5ba62041665336889! +-+----------+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9
Graphics card issues with new system build
OK, I'm getting frustrated as hell. :-) I've got my new system built, and managed to get the dmesg uploaded to NYCBug ... It's got a AMD Ryzen 9 7950X3D CPU, which has internal video configured as acpivga0 - I disable this (using userconf) when I boot because I need to use the older-but-supported GeForce 730 graphics card. Boot comes up normally and starts X (via xdm). However, I'm getting the following message logged on the console. As far as I can tell, they're logged when switching from the xdm console session to a non-X session; but it is difficult to be certain of the timing. nouveau0: error: DRM: core notifier timeout I also sometimes get nouveau0: failed to idle channel n [user] when stopping xdm. During normal operation, things are OK, other than "jerky" cursor tracking. Most often, the cursor "sticks" in one spot for a few seconds, and then continues to track. "One spot" is very often, but NOT ALWAYS, at a point where the mouse icon needs to change (ie, it enters or leaves a window or button, etc.) After a while, the system just hangs (suspicion: it's hitting one of the core notifier timeouts, and hangs forever rather than time-out). I can still access the machine via network log-in but cannot get anything done "locally". At this point I can't even switch to the non-X console sessions. The hang-time varies, but comes much sooner when there is heavy system activity - like build.sh - going on. It even comes, however, with no activity at all - just staring at the screen for a few hours triggers the hang. I've got a bunch of newer video cards, but our current video drivers don't support them, and end up using genfb with a "default" mode-line that makes everything look wrong. And I've already cannabilized the old machine (which had a now non-functional GeForce 1050 Ti - maybe it was a 1080 but I can't find any marking) so I can't go back. At this point, I am stuck and don't know how to proceed. I'm willing to buy one more video card (but only one!) if I have a high likelihood of it working. But if there's something else going on which is likely to be fatal no matter what video card I choose I'd rather not spend more cash. If you do recommend another card, please be very explicit in identifying the make and model and any other relevant attributes (how much graphics memory, for example). All reasonable suggestions will be appreciated. If there are specific debug commands to try, please let me know. (But also know that I don't know much about the video subsystem - this is way beyond my usual level of knowledge.) +-+----------+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: dwiic errors
On Thu, 14 Mar 2024, Manuel Bouyer wrote: It could also be some sensors I guess. Any chance to see what attaches at dwiic0 ? Maybe entering ddb before the console gets spammed ? The error messages start immediately after attaching the dwiic. I have waited for several minutes and the timeout messages continue with nothing else. FWIW I have a laptop with the touchpad as ihidev@dwiic and it works fine with RC6 Yeah, this system seems to behave somewhat oddly. +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: dwiic errors
On Thu, 14 Mar 2024, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: as soon as you proceed past this point (including normal non-single- user boot), the dwiic starts spewing time-out messages. These messages come every 0.5 second or so, and there's usually a hundred or more messages before they stop; in some cases the messages have continued to stream by for several minutes (at which point I pressed the reset button). The value for %d is always 0 or 1. Probably result of GENERIC:ihidev* at iic? that is probing for a modern laptop touchpad. Can you disable ihidev instead of dwiic and see what happens then ? No change. It attaches dwiic0 and then starts with the messages. +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
On Wed, 13 Mar 2024, Michael van Elst wrote: On Tue, Mar 12, 2024 at 11:00:02PM -0700, Paul Goyette wrote: ``scsictl sd0 start'' makes a little bit of progress, and claims to be "fabricating a geometry". ``gpt show -a sd0'' shows two partitions (one for NetBSD backups, and one for Windoze backups) # gpt show sd0 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 342014 Unused 2048 4294967296 1 GPT part - NetBSD FFSv1/FFSv2 4294969344 3518951424 2 GPT part - Windows basic data 7813920768 49119 Unused 7813969887 32 Sec GPT table 7813969919 1 Sec GPT header That looks fine. But it does not seem to progress to the discover-wedges process, and no wedges seem to exist: # dkctl sd0 listwedges /dev/rsd0: no wedges configured The wedge autodetection happens when the device attaches (and failed since the disk was offline). This is different from disklabels that are fetched by the first opener (and are usually dropped with the last close, except traditionally for vnd). You can manually trigger autodetection with dkctl sd0 makewedges Yup, that's the magic word. I used scsictl and dkctl both, and the external drive appeears normal. Thanks! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
dwiic errors
Well, another issue to deal with on my new build. This time, it is
the dwiic0 device at fault.
Booting single user gets as far as the ``which shell'' prompt, but
as soon as you proceed past this point (including normal non-single-
user boot), the dwiic starts spewing time-out messages. These
messages come every 0.5 second or so, and there's usually a hundred
or more messages before they stop; in some cases the messages have
continued to stream by for several minutes (at which point I pressed
the reset button). The value for %d is always 0 or 1.
(excerpt from $SRC/sys/dev/ic/dwiic.c starting at line 496)
if (rx_avail == 0) {
device_printf(sc->sc_dev,
"timed out reading remaining %d\n",
(int)(len - 1 - readpos));
sc->sc_i2c_xfer.error = 1;
return (1);
}
This is so intrusive and unpredictable in duration that I need to
run the system with dwiic disabled (via userconf).
Any clue on what might be wrong? This is a brand new build with all
new parts. The dmesg (minus the dwiic) is posted at
https://dmesgd.nycbug.org/index.cgi?do=view=7563
+-+--+------+
| Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com|
| Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
+-+--+--+
Re: Problem with umass/scsibus/wd0
On Tue, 12 Mar 2024, Paul Goyette wrote: On Wed, 13 Mar 2024, Simon Burge wrote: Not enough USB power? Same model external drive: https://forums.tomshardware.com/threads/2tb-wd-elements-2621-is-detected-on-one-of-my-computers-but-not-the-other.3720369/#post-22432202 Certainly a possibility. But I wouldn't have a clue on how to fix it. Ah, /i read further and found the links to Amazon. The new box _should_ have enuf power since it is USB3.2. But considering the price, I ordered a cable. I'll report results next week (I don't have Amazon Prime, so shipping takes a couple additional days!) +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
On Wed, 13 Mar 2024, Simon Burge wrote: Not enough USB power? Same model external drive: https://forums.tomshardware.com/threads/2tb-wd-elements-2621-is-detected-on-one-of-my-computers-but-not-the-other.3720369/#post-22432202 Certainly a possibility. But I wouldn't have a clue on how to fix it. +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Problem with umass/scsibus/wd0
On Wed, 13 Mar 2024, Michael van Elst wrote: Sounds like that drive isn't spinning up. The "Elements" product doesn't exactly tell what it is, some units either come with their own power supply or require non-standard USB power. The device is pretty standard. One thing I forgot to mention in the original report is that it used to work just fine with NetBSD on the old build. Maybe 'scsictl sd0 start' helps to get the disk online. If that has an effect you may need 'dkctl sd0 makewedges' if you use a GPT label. ``scsictl sd0 start'' makes a little bit of progress, and claims to be "fabricating a geometry". ``gpt show -a sd0'' shows two partitions (one for NetBSD backups, and one for Windoze backups) # gpt show sd0 startsize index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 342014 Unused 2048 4294967296 1 GPT part - NetBSD FFSv1/FFSv2 4294969344 3518951424 2 GPT part - Windows basic data 7813920768 49119 Unused 7813969887 32 Sec GPT table 7813969919 1 Sec GPT header But it does not seem to progress to the discover-wedges process, and no wedges seem to exist: # dkctl sd0 listwedges /dev/rsd0: no wedges configured +-+--+------+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Problem with umass/scsibus/wd0
On my new build, I finally got my monitor/display issues resolved, so today I turned to making my usual off-line backup. For several years I've used an external USB-driven hard-drive for the backups, but now when I try to attach the external drive, it never comes ready: [ 29641.773703] umass0 at uhub11 port 4 configuration 1 interface 0 [ 29641.773703] umass0: Western Digital (0x1058) Elements 2621 (0x2621), rev 3.20/10.34, addr 4 [ 29641.773703] umass0: using SCSI over Bulk-Only [ 29641.793714] scsibus0 at umass0: 2 targets, 1 lun per target [ 29641.793714] sd0 at scsibus0 target 0 lun 0: disk fixed [ 29641.793714] sd0(umass0:0:0:0): Check Condition on CDB: 0x00 00 00 00 00 00 [ 29641.793714] SENSE KEY: Not Ready [ 29641.793714] ASC/ASCQ: Logical Unit Is In Process Of Becoming Ready [ 29641.793714] sd0: drive offline ... [ 29671.778736] sd0: detached [ 29671.778736] scsibus0: detached [ 29671.778736] umass0: detached [ 29671.778736] umass0: at uhub11 port 4 (addr 4) disconnected I've waited patiently for the situation to resolve (in one case, I waited for several hours) but the drive never comes ready. And I've also tried numerous usb ports, all with the same result. The drive still works on my Windoze laptop with no issues. I cannot try any other NetBSD systems - I only have one. This is on a GENERIC 10.99.10 NetBSD built locally from sources updated ``Sun Mar 3 23:26:30 UTC 2024''. And here is the provenance of the usb port. (They're all pretty much the same, as this machine has only xhci controllers.) [ 1.039673] usb4 at xhci2: USB revision 3.1 [ 2.045963] uhub4 at usb4: NetBSD (0x) xHCI root hub (0x), class 9/0, rev 3.00/1.00, addr 0 [ 2.605967] uhub11 at uhub4 port 5: ASUS TEK. (0x174c) ASM107x (0x3074), class 9/0, rev 3.00/0.01, addr 1 Anyone got any suggestions? +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: strange happenings with new system build
FWIW,, I'm currently using an unsupported-because-its-too-new video card to make the machine almost useable. The genfb attributes have a poor aspect ratio, and everything is too large, but at least it's not crashing or hanging. :) Hopefully, the new Radeon display card I ordered will be useable. On Tue, 5 Mar 2024, Paul Goyette wrote: On Tue, 5 Mar 2024, Paul Goyette wrote: Well, I just built me a new toy and it mostly works just fine. But there are some mostly display-related strangenesses... The entire dmesg for the new build is attaached. dmesg for the old machine is not available since I had to cannabilize some parts. As a summary, the new build is a amd64 `` AMD Ryzen 9 7950X3D'' with 128GB of DDR5 on an Asus ROG Crosshair Hero motherboard 1. Using the same video card as from the original machine (identified ``NVIDIA GeForce GTX 1050 Ti''), a normal boot fails to complete s/1050/1080/ the initial mode-set that occurs during auto-config. The bottom 25% or so of the screen is broken up into 4 sets of "garbage" (looks like bar code, but not really), and blind typing results in scrolling of the 25% section, 1 set at a time. After about 10 or 15 minutes, it suddenly starts working and displays the usual xdm login dialog! 2. Things will go along nicely for (some value of) a while, and then suddenly switching to the console (via ctrl-alt-f1) hangs. This, too, eventually unhangs 3. There's a dwiic0 attached via acpi, and an iic0 attached to the dwiic0. The attach seems to succeed, but approximately 17 seconds later, immediately after a USB4 HCI fails to attach, I start to get a flurry of dwiic0: timed out waiting for rx_full intr dwiic0: timed out reading remaining 0 The messages always come in pairs, and there is roughly a 0.5sec interval between pairs. In total, there are about 150 pairs, then the messages just stop. 4. There are lots of nouveau0 errors, and they seem to correspond to mode-switch attempts: [ 1796.949817] nouveau0: autoconfiguration error: error: DRM: core notifier timeout [ 1826.944253] nouveau0: autoconfiguration error: error: DRM: core notifier timeout [ 1887.113245] nouveau0: autoconfiguration error: error: DRM: base-0: timeout [ 1889.114196] nouveau0: autoconfiguration error: error: DRM: core notifier timeout [ 1891.115161] nouveau0: autoconfiguration error: error: DRM: core notifier timeout [ 1893.196173] nouveau0: autoconfiguration error: error: DRM: core notifier timeout +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+ +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+ +-+--+------+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: strange happenings with new system build
On Tue, 5 Mar 2024, Paul Goyette wrote: Well, I just built me a new toy and it mostly works just fine. But there are some mostly display-related strangenesses... The entire dmesg for the new build is attaached. dmesg for the old machine is not available since I had to cannabilize some parts. As a summary, the new build is a amd64 `` AMD Ryzen 9 7950X3D'' with 128GB of DDR5 on an Asus ROG Crosshair Hero motherboard 1. Using the same video card as from the original machine (identified ``NVIDIA GeForce GTX 1050 Ti''), a normal boot fails to complete s/1050/1080/ the initial mode-set that occurs during auto-config. The bottom 25% or so of the screen is broken up into 4 sets of "garbage" (looks like bar code, but not really), and blind typing results in scrolling of the 25% section, 1 set at a time. After about 10 or 15 minutes, it suddenly starts working and displays the usual xdm login dialog! 2. Things will go along nicely for (some value of) a while, and then suddenly switching to the console (via ctrl-alt-f1) hangs. This, too, eventually unhangs 3. There's a dwiic0 attached via acpi, and an iic0 attached to the dwiic0. The attach seems to succeed, but approximately 17 seconds later, immediately after a USB4 HCI fails to attach, I start to get a flurry of dwiic0: timed out waiting for rx_full intr dwiic0: timed out reading remaining 0 The messages always come in pairs, and there is roughly a 0.5sec interval between pairs. In total, there are about 150 pairs, then the messages just stop. 4. There are lots of nouveau0 errors, and they seem to correspond to mode-switch attempts: [ 1796.949817] nouveau0: autoconfiguration error: error: DRM: core notifier timeout [ 1826.944253] nouveau0: autoconfiguration error: error: DRM: core notifier timeout [ 1887.113245] nouveau0: autoconfiguration error: error: DRM: base-0: timeout [ 1889.114196] nouveau0: autoconfiguration error: error: DRM: core notifier timeout [ 1891.115161] nouveau0: autoconfiguration error: error: DRM: core notifier timeout [ 1893.196173] nouveau0: autoconfiguration error: error: DRM: core notifier timeout +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+ +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: rc.d start order
On Tue, 5 Mar 2024, Paul Goyette wrote: I _think_ it will work correctly if I modify fstab to refer to NAME=Builds instead of ccd0. I will update here after I confirm. Yes this seems to work. +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: rc.d start order
On Mon, 4 Mar 2024, Paul Goyette wrote: Hmmm, you're right (as usual) regarding the sequence-control keywords, as verified by rcorder. There must've been something else going on. I'll have to check again after I resolve a few other issues. Ah, OK, I think I understand the problem now. The sequence of calls is correct, ccd is called befeore fsck. The ccd is created correctly. The resulting device, however, is a gpt device (with one wedge named ``Builds''). There is an entry for ccd0 in /etc/fstab, but there is no /dev/ccd0 so get the following failure logged in /var/run/rc.log Can't stat `ccd0' (No such file or directory)Can't stat ccd0: No such file or directory CAN'T CHECK FILE SYSTEM. ccd0: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY. I _think_ it will work correctly if I modify fstab to refer to NAME=Builds instead of ccd0. I will update here after I confirm. +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: rc.d start order
Hmmm, you're right (as usual) regarding the sequence-control keywords, as verified by rcorder. There must've been something else going on. I'll have to check again after I resolve a few other issues. On Tue, 5 Mar 2024, Robert Elz wrote: Date:Mon, 4 Mar 2024 17:31:22 -0800 (PST) From:Paul Goyette Message-ID: | Is there a reason that checking disks (vi fsck) happens before the ccd | and.or cgd drivers can create their devices? It's hard to check on ccd0 | before it exists! Really? On my system both ccd and cdg are "# BEFORE: DISKS" whereas fsck is "# REQUIRE: localswap" and swap1 (which is # PROVIDE localswap) is "# REQUIRE: DISKS".That is, ccd and cgd both come before DISKS and fsck (other than fsck_root which is almost the first thing that happens) comes after DISKS which puts both ccd and cgd ahead of fsck. If you're attempting root on ccd or cgd then the fsck_root is going to have problems, but neither of those is something that's supported. To make that work you're going to need tricks (inside those systems perhaps) like raidframe has - and the system would effectively be starting with one root and then changing to another during the boot process. For cgd that's inevitable, as cgd requires the params file for the device, and that has to come from somewhere, before the cgd can be configured, so there has to be a filesystem from which to read it, and there cannot be any filesystems without root. I suspect ccd is the same - but I just use raidframe (raid0) instead of that. raidframe has autoconfigure so it has the ability to set itself up before root, so a root on raidframe can be made to work. kre !DSPAM:65e69db831121223027042! +-+------+------+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
rc.d start order
Is there a reason that checking disks (vi fsck) happens before the ccd and.or cgd drivers can create their devices? It's hard to check on ccd0 before it exists! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
ccd error with two large components
I have two 2TB nvme devices, configured with ``ccdconfig ccd0 64 none /dev/dk1 /dev/dk0'' then i mount the ccd on /mnt and then ccdconfig -g goes boom!! prevented access to 0x7f7fff9e7fbc (SMAP) ccd_info_sysctl+77 The instruction decode at that point is movl 0(%r8), %esi (The rest of the backtrace isn't very interesting, just the sysctl dispatch.) Any clues? +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Request-for-recommendation
On Wed, 21 Feb 2024, jo...@sdf.org wrote: On my Windows machine, at least, I can get higher screen refresh rates from the DP port than HDMI. On that note, I found this Hackaday post useful: https://hackaday.com/2023/07/11/displayport-a-better-video-interface/ Very useful - thanks! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Request-for-recommendation
I'm building a new machine, and it's got a RX5700XT video card that needs to talk to a 32" monitor. Both the card and the display support HDMI 2.0 and DisplayPort 1.2 - any reason to pick one vs the other? FWIW the display is advertised as "2K 165Hz ultrawide monitor, 1440P 145Hz monitor" with "2560x1440P/2k high resolution". Thanks in advance for any suggestions. +-+--+------+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Could ccdconfig(8) be made to handle wedge names?
On Sun, 4 Feb 2024, Paul Goyette wrote: Just wondering... How hard would it be for ccdconfig to handle a list of NAME=blah instead of /dev/dk ? Looking at the code it would appear that this is not currently supportted. Looking closer at the code, it looks like this _IS_ supported, using getfsspecname(3). +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Could ccdconfig(8) be made to handle wedge names?
Just wondering... How hard would it be for ccdconfig to handle a list of NAME=blah instead of /dev/dk ? Looking at the code it would appear that this is not currently supportted. +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Unacceptable firefox behavior with nouveau graphics card
It's been a couple of years now since I installed my current "GeForce GTX 1050 Ti" video card. It has always had "issues", especially with firefox, and it seems to be getting worse as time goes by. Symptoms generally manifest themselves as long-delay hangs (up to a minute or more, sometimes longer than my limited patience will tolerate). During these hangs, firefox seems to behave almost normal - menus drop down, mouse clicks on the "x" close tabs, new tabs can be opened, etc. But other things, such as cursor changing to a finger when moved over a link, or trying to execute a search, or even a simple reload-page are ignored. As I said, this has been getting worse over time, and with a recent update of the OS (running 10.99.4, updating from October to last week) firefox has become almost unuseable. I can search for things on newegg.com but cannot display interesting results. So, I'm looking for a few things: 1) Does this sound familiar to anyone else? Or am I just a set-of-1 ? 2) Are there any alternatives to firefox? 3) Any recommendations on potential replacement of the video card? Thanks in advance! +-+------+------+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: Disk sizes
On Thu, 28 Dec 2023, xuser wrote: I have a 2018 disk and it does not work it says invalid mbr size IIRC, mbr-formatted disks are limited to 2TB. For larger, I think you need to use gpt and wedges. xu...@sdf.org SDF Public Access UNIX System - http://sdf.org On Thu, 28 Dec 2023, David Brownlee wrote: On Thu, 28 Dec 2023 at 18:47, xuser wrote: Does NetBSD support 3TB ATA drive? Some very old (decade plus) controllers are not able to support drives of that size, but any hardware that supports a 3TB ATA drive, NetBSD should also support it. If you're using somewhat older 3TB drives be aware there was a period where Seagate 3TB drives were best avoided. David !DSPAM:658df94f72151099810367! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Re: software raid
man raidctl On Thu, 28 Dec 2023, xuser wrote: How to setup software raid? xu...@sdf.org SDF Public Access UNIX System - http://sdf.org !DSPAM:658dbca4251572052416023! +-+--+--+ | Paul Goyette (.sig) | PGP Key fingerprint: | E-mail addresses:| | (Retired) | 1B11 1849 721C 56C8 F63A | p...@whooppee.com| | Software Developer | 6E2E 05FD 15CE 9F2D 5102 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | +-+--+--+
Build failure for gdb on amd64
t/src_ro/external/gpl3/gdb/bin/gdb/../../dist/libdecnumber
-I/build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb/../../dist
-I/build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb/../../lib/libbfd/arch/x86_64
-I/build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb/../../lib/libgdbsupport/arch/x86_64
-I/build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb/../../lib/libgnulib/arch/x86_64
-I/build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb/../../lib/libgnulib/arch/x86_64/gnulib/import
-I/build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb/../../dist/bfd
-I/build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb/../../dist/include
-D_KERNTYPES -D_KERNTYPES -c
/build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb/../../dist/gdb/gdb.c -o
gdb.o
${CTFCONVERT_RUN}
=>
*** [gdb.o] Error code 1
nbmake[10]: stopped in /build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb
1 error
nbmake[10]: stopped in /build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb
nbmake[9]: stopped in /build/netbsd-current/src_ro/external/gpl3/gdb/bin/gdb
nbmake[8]: stopped in /build/netbsd-current/src_ro/external/gpl3/gdb/bin
nbmake[7]: stopped in /build/netbsd-current/src_ro/external/gpl3/gdb
nbmake[6]: stopped in /build/netbsd-current/src_ro/external/gpl3
nbmake[5]: stopped in /build/netbsd-current/src_ro/external
nbmake[4]: stopped in /build/netbsd-current/src_ro
nbmake[3]: stopped in /build/netbsd-current/src_ro
nbmake[2]: stopped in /build/netbsd-current/src_ro
nbmake[1]: stopped in /build/netbsd-current/src_ro
nbmake: stopped in /build/netbsd-current/src_ro
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
X.log
Description: Binary data
distrib sets error for DEBUG build
With all of MKDEBUG{,LIB,KERNEL} set, I see
checkflist ===> distrib/sets
=== 1 extra files in DESTDIR =
Files in DESTDIR but missing from flist.
File is obsolete or flist is out of date ?
--
./usr/libdata/debug/usr/lib/libtsan.so.1.0.debug
= end of 1 extra files ===
== 1 missing files in DESTDIR
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/libdata/debug/usr/lib/libtsan.so.2.0.debug
end of 1 missing files ==
Were the tsan files just removed, rather than marking obsolete?
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Re: Build failure
This has been fixed - thanks!
On Tue, 1 Aug 2023, Paul Goyette wrote:
With a clean check-out and clean DEST/OBJ/TOOL dirs I am seeing the
following repeatable compile failure. In case it makes a difference,
my build is with all 3 of MKDEBUG{,LIB,KERNEL} turned on.
...
# compile libasan/asan_interceptors.pico
/build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-c++
-frandom-seed=5d74f46f -O2 -Wall -Wpointer-arith -Wno-sign-compare
-Wa,--fatal-warnings -Werror -fPIE -std=gnu++11 -fsized-deallocation
-fvisibility=hidden -fno-builtin -fno-exceptions -fno-rtti -funwind-tables
--sysroot=/build/netbsd-local/dest/amd64
-I/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/include
-I/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer -D_DEBUG
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-DSANITIZER_HAS_EXCEPTIONS=1 -DSANITIZER_NEEDS_SEGV=1 -DCAN_SANITIZE_UB=0 -c
-DPIC -fPIC -g
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/asan/asan_interceptors.cc
-o asan_interceptors.pico
In file included from
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1802,
from
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/asan/asan_interceptors.cc:171:
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:
In function 'void ioctl_table_fill()':
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:36:7:
error: 'IOCTL_USB_DEVICEINFO_30' was not declared in this scope
36 | if (IOCTL_##rq != IOCTL_NOT_PRESENT) {
\
| ^~
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:454:3:
note: in expansion of macro '_'
454 | _(USB_DEVICEINFO_30, READWRITE, struct_usb_device_info30_sz);
| ^
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:454:35:
error: 'struct_usb_device_info30_sz' was not declared in this scope
454 | _(USB_DEVICEINFO_30, READWRITE, struct_usb_device_info30_sz);
| ^~~
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:40:42:
note: in definition of macro '_'
40 | ioctl_table[ioctl_table_size].size = sz;
\
| ^~
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:36:7:
error: 'IOCTL_USB_GET_DEVICEINFO_30' was not declared in this scope
36 | if (IOCTL_##rq != IOCTL_NOT_PRESENT) {
\
| ^~
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:474:3:
note: in expansion of macro '_'
474 | _(USB_GET_DEVICEINFO_30, WRITE, struct_usb_device_info30_sz);
| ^
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:474:35:
error: 'struct_usb_device_info30_sz' was not declared in this scope
474 | _(USB_GET_DEVICEINFO_30, WRITE, struct_usb_device_info30_sz);
| ^~~
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:40:42:
note: in definition of macro '_'
40 | ioctl_table[ioctl_table_size].size = sz;
\
| ^~
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:36:7:
error: 'IOCTL_BIOCGSTATS_30' was not declared in this scope
36 | if (IOCTL_##rq != IOCTL_NOT_PRESENT) {
\
| ^~
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:677:3:
note: in expansion of macro '_'
677 | _(BIOCGSTATS_30, WRITE, struct_bpf_stat30_sz);
| ^
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:677:27:
error: 'struct_bpf_stat30_sz' was not declared in this scope
677 | _(BIOCGSTATS_30, WRITE, struct_bpf_stat30_sz);
| ^~~~
/build/netbsd-local/src_ro/external/gpl3/gcc.old/dist/libsanitizer/sanitizer_common/sanitizer_interceptors_ioctl_netbsd.inc:40:42:
note: in definition of macro '_'
40 | ioctl_table[ioctl_table_size].size = sz;
\
| ^~
*** Failed target: asan_interceptors.pico
*** Failed commands:
${_MKTARGET_COMPILE}
=> @echo '# ' "compile &
Re: Strange behavior for route(8)
{184} route show -inet net 192.168.0/24
route: botched keyword: 192.168.0/24
Usage: route [-dfLnqSsTtv] cmd [[-] args]
route show is documented to print the table. It does not take narrowing
specifiers.
Try
route get -inet 192.168.0.0/24
and it's arguably a bug that
route get -inet 192.168.0/24
errors, but that route show prints it that way.
kewl, thanks. somehow I completely missed all mention of ``route get''
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Strange behavior for route(8)
Can anyone exlpain what I'm doing wrong?
{183} route show -inet
Routing tables
Internet:
DestinationGatewayFlagsRefs UseMtu Interface
default192.168.0.1UG -- - wm0
127/8 localhost UGRS-- 33624 lo0
localhost lo0UHl -- 33624 lo0
172.16.1.5 172.16.1.6 UH -- - tun0
172.16.1.6 tun0 UHl -- - lo0
192.168.0/24 link#1 UC -- - wm0
192.168.0.37 link#1 UHl -- - lo0
192.168.0.1a8:6a:bb:df:02:9c UHL -- - wm0
{184} route show -inet net 192.168.0/24
route: botched keyword: 192.168.0/24
Usage: route [-dfLnqSsTtv] cmd [[-] args]
{185} uname -a
NetBSD speedy.whooppee.com 10.99.6 NetBSD 10.99.6 (SPEEDY 2023-07-25 11:13:55
UTC) #0: Tue Jul 25 16:34:53 UTC 2023
p...@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY
amd64
{186}
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
video (nouveau) speed-up with 10.99.6
Well, I hadn't noticed any relevant commit messages, but I just upgraded from 10.99.4 to 10.99.6 and I was pleasantly surprised! Firefox (and several other large graphics programs which used to take 10-20 seconds to start up now seem to take only 2 or 3 seconds before being fully functional! Whoever/whatever is responsible, a huge *T*H*A*N*K*S* for this! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Build failure for malloc stuff - amd64 HEAD
If it matters, this is with all of MK{,LIB,KERNEL}DEBUG set...
On Tue, 4 Jul 2023, Paul Goyette wrote:
I'm seeing a repeatable error building from sources updated on 2023-07-04 at
19:12:27 UTC
Here's the details (my mailer will probabl mess it up badly with line
breaks; for original log see the attachment)
...
dependall ===> lib/libbsdmalloc
# compile libbsdmalloc/malloc.go
/build/netbsd-current/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2
-fno-builtin-aligned_alloc -fno-builtin-calloc -fno-builtin-free
-fno-builtin-malloc -fno-builtin-posix_memalign -fno-builtin-realloc
-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -Wno-sign-compare -Werror -fPIE
--sysroot=/build/netbsd-current/dest/amd64 -D_REENT -D_REENTRANT
-I/build/netbsd-current/src_ro/lib/libbsdmalloc/../libc/include/ -c -DDEBUG
-g /build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c -o malloc.go
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c: In function 'botch':
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:152:18: error:
assignment discards 'const' qualifier from pointer target type
[-Werror=discarded-qualifiers]
152 | iov[0].iov_base = "\nassertion botched: ";
| ^
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:154:20: error: cast
discards 'const' qualifier from pointer target type [-Werror=cast-qual]
154 | iov[1].iov_base = (void *)s;
|^
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:156:18: error:
assignment discards 'const' qualifier from pointer target type
[-Werror=discarded-qualifiers]
156 | iov[2].iov_base = "\n";
| ^
cc1: all warnings being treated as errors
*** Failed target: malloc.go
*** Failed commands:
${_MKTARGET_COMPILE}
=> @echo '# ' "compile " libbsdmalloc/malloc.go
${COMPILE.c} ${DEBUGFLAGS} ${COPTS.${.IMPSRC:T}}
${CPUFLAGS.${.IMPSRC:T}} ${CPPFLAGS.${.IMPSRC:T}} -g ${.IMPSRC} -o ${.TARGET}
=> /build/netbsd-current/tools/x86_64/amd64/bin/x86_64--netbsd-gcc
-O2 -fno-builtin-aligned_alloc -fno-builtin-calloc -fno-builtin-free
-fno-builtin-malloc -fno-builtin-posix_memalign -fno-builtin-realloc
-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -Wno-sign-compare -Werror -fPIE
--sysroot=/build/netbsd-current/dest/amd64 -D_REENT -D_REENTRANT
-I/build/netbsd-current/src_ro/lib/libbsdmalloc/../libc/include/ -c -DDEBUG
-g /build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c -o malloc.go
*** [malloc.go] Error code 1
nbmake[7]: stopped in /build/netbsd-current/src_ro/lib/libbsdmalloc
1 error
++------+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
++------+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Build failure for malloc stuff - amd64 HEAD
I'm seeing a repeatable error building from sources updated on
2023-07-04 at 19:12:27 UTC
Here's the details (my mailer will probabl mess it up badly with line
breaks; for original log see the attachment)
...
dependall ===> lib/libbsdmalloc
# compile libbsdmalloc/malloc.go
/build/netbsd-current/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2
-fno-builtin-aligned_alloc -fno-builtin-calloc -fno-builtin-free
-fno-builtin-malloc -fno-builtin-posix_memalign -fno-builtin-realloc
-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -Wno-sign-compare -Werror -fPIE
--sysroot=/build/netbsd-current/dest/amd64 -D_REENT -D_REENTRANT
-I/build/netbsd-current/src_ro/lib/libbsdmalloc/../libc/include/ -c -DDEBUG
-g /build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c -o malloc.go
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c: In function 'botch':
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:152:18: error:
assignment discards 'const' qualifier from pointer target type
[-Werror=discarded-qualifiers]
152 | iov[0].iov_base = "\nassertion botched: ";
| ^
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:154:20: error: cast
discards 'const' qualifier from pointer target type [-Werror=cast-qual]
154 | iov[1].iov_base = (void *)s;
|^
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:156:18: error:
assignment discards 'const' qualifier from pointer target type
[-Werror=discarded-qualifiers]
156 | iov[2].iov_base = "\n";
| ^
cc1: all warnings being treated as errors
*** Failed target: malloc.go
*** Failed commands:
${_MKTARGET_COMPILE}
=> @echo '# ' "compile " libbsdmalloc/malloc.go
${COMPILE.c} ${DEBUGFLAGS} ${COPTS.${.IMPSRC:T}}
${CPUFLAGS.${.IMPSRC:T}} ${CPPFLAGS.${.IMPSRC:T}} -g ${.IMPSRC} -o ${.TARGET}
=> /build/netbsd-current/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2
-fno-builtin-aligned_alloc -fno-builtin-calloc -fno-builtin-free
-fno-builtin-malloc -fno-builtin-posix_memalign -fno-builtin-realloc -std=gnu99
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare
-Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type
-Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter
-Wno-sign-compare -Werror -fPIE--sysroot=/build/netbsd-current/dest/amd64
-D_REENT -D_REENTRANT
-I/build/netbsd-current/src_ro/lib/libbsdmalloc/../libc/include/ -c -DDEBUG-g
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c -o malloc.go
*** [malloc.go] Error code 1
nbmake[7]: stopped in /build/netbsd-current/src_ro/lib/libbsdmalloc
1 error
++------+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+...
dependall ===> lib/libbsdmalloc
# compile libbsdmalloc/malloc.go
/build/netbsd-current/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2
-fno-builtin-aligned_alloc -fno-builtin-calloc -fno-builtin-free
-fno-builtin-malloc -fno-builtin-posix_memalign -fno-builtin-realloc
-std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings
-Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra
-Wno-unused-parameter -Wno-sign-compare -Werror -fPIE
--sysroot=/build/netbsd-current/dest/amd64 -D_REENT -D_REENTRANT
-I/build/netbsd-current/src_ro/lib/libbsdmalloc/../libc/include/ -c -DDEBUG
-g /build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c -o malloc.go
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c: In function 'botch':
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:152:18: error:
assignment discards 'const' qualifier from pointer target type
[-Werror=discarded-qualifiers]
152 | iov[0].iov_base = "\nassertion botched: ";
| ^
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:154:20: error: cast
discards 'const' qualifier from pointer target type [-Werror=cast-qual]
154 | iov[1].iov_base = (void *)s;
|^
/build/netbsd-current/src_ro/lib/libbsdmalloc/malloc.c:156:18: error:
assignment discards 'const' qualifier from pointer target type
[-Werror=discarded-qualifiers]
156 | iov[2].iov_base = "\n";
| ^
cc1: all warnings being
Re: Build error
On Tue, 20 Jun 2023, Paul Goyette wrote:
On Tue, 20 Jun 2023, Paul Goyette wrote:
With sources updated on 2023-06-20 at 17:26:58 UTC and building into
a completely empty $DESTDIR I am getting
== 2 missing files in DESTDIR
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/lib/i386/libvers_g.a
./usr/lib/libvers_g.a
end of 2 missing files ==
Any clues?
FWIW, this build was with all 3 of DEBUG{,LIB,KERNEL} set.
Looks like this debug library goes away with the new heimdal.
I'll commit the changes as soon as I get a clean build.
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Re: Build error
On Tue, 20 Jun 2023, Paul Goyette wrote:
With sources updated on 2023-06-20 at 17:26:58 UTC and building into
a completely empty $DESTDIR I am getting
== 2 missing files in DESTDIR
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/lib/i386/libvers_g.a
./usr/lib/libvers_g.a
end of 2 missing files ==
Any clues?
FWIW, this build was with all 3 of DEBUG{,LIB,KERNEL} set.
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Build error
With sources updated on 2023-06-20 at 17:26:58 UTC and building into a completely empty $DESTDIR I am getting == 2 missing files in DESTDIR Files in flist but missing from DESTDIR. File wasn't installed ? -- ./usr/lib/i386/libvers_g.a ./usr/lib/libvers_g.a end of 2 missing files == Any clues? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: sets list error?
PR bin/57455 has been filed for this. On Mon, 5 Jun 2023, Paul Goyette wrote: Note that this happens when I specify all of MKDEBUG, MKDEBUGKERNEL, and MKDEBUGLIB. Not sure if the error occurs without the debug. On Mon, 5 Jun 2023, Paul Goyette wrote: With sources from 2023-06-05 at 07:26:53 UTC I am seeing the following errors: ===> build.sh command:./build.sh \ -T /build/netbsd-current/tools/x86_64/amd64 \ -D /build/netbsd-current/dest/amd64 \ -O /build/netbsd-current/obj/amd64 \ -R /build/netbsd-current/release \ -V RELEASEMACHINEDIR=amd64 \ -V MKDEBUG=yes \ -V MKDEBUGKERNEL=yes \ -V MKDEBUGLIB=yes \ -V KERNEL_DIR=no \ -U -N2 -m amd64 -j1 release ... === 10 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/libexec/ld.elf_so/libh_abuse_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_abuse_static_g.a ./usr/tests/libexec/ld.elf_so/libh_def_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_def_static_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyctor_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_onlydef_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyuse_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyuse_static_g.a ./usr/tests/libexec/ld.elf_so/libh_use_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_use_static_g.a = end of 10 extra files === *** Failed target: checkflist ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+ ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+ ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: sets list error?
Note that this happens when I specify all of MKDEBUG, MKDEBUGKERNEL, and MKDEBUGLIB. Not sure if the error occurs without the debug. On Mon, 5 Jun 2023, Paul Goyette wrote: With sources from 2023-06-05 at 07:26:53 UTC I am seeing the following errors: ===> build.sh command:./build.sh \ -T /build/netbsd-current/tools/x86_64/amd64 \ -D /build/netbsd-current/dest/amd64 \ -O /build/netbsd-current/obj/amd64 \ -R /build/netbsd-current/release \ -V RELEASEMACHINEDIR=amd64 \ -V MKDEBUG=yes \ -V MKDEBUGKERNEL=yes \ -V MKDEBUGLIB=yes \ -V KERNEL_DIR=no \ -U -N2 -m amd64 -j1 release ... === 10 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/libexec/ld.elf_so/libh_abuse_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_abuse_static_g.a ./usr/tests/libexec/ld.elf_so/libh_def_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_def_static_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyctor_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_onlydef_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyuse_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyuse_static_g.a ./usr/tests/libexec/ld.elf_so/libh_use_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_use_static_g.a = end of 10 extra files === *** Failed target: checkflist ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+ ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
sets list error?
With sources from 2023-06-05 at 07:26:53 UTC I am seeing the following errors: ===> build.sh command:./build.sh \ -T /build/netbsd-current/tools/x86_64/amd64 \ -D /build/netbsd-current/dest/amd64 \ -O /build/netbsd-current/obj/amd64 \ -R /build/netbsd-current/release \ -V RELEASEMACHINEDIR=amd64 \ -V MKDEBUG=yes \ -V MKDEBUGKERNEL=yes \ -V MKDEBUGLIB=yes \ -V KERNEL_DIR=no \ -U -N2 -m amd64 -j1 release ... === 10 extra files in DESTDIR = Files in DESTDIR but missing from flist. File is obsolete or flist is out of date ? -- ./usr/tests/libexec/ld.elf_so/libh_abuse_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_abuse_static_g.a ./usr/tests/libexec/ld.elf_so/libh_def_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_def_static_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyctor_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_onlydef_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyuse_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_onlyuse_static_g.a ./usr/tests/libexec/ld.elf_so/libh_use_dynamic_g.a ./usr/tests/libexec/ld.elf_so/libh_use_static_g.a = end of 10 extra files === *** Failed target: checkflist ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: binutils still failing on amd64
| can you update and post the latest failures? Will do. FWIW, touch(1)ing all copies of bfd.info gets us past the ``build.sh tools'' successfully. I have seen no new issues. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
re: binutils still failing on amd64
> > Sources updated to 2022-12-31 at 13:42:04 UTC and all output dirs > > (obj, release, dist, tools) were cleaned. > > Is no-one else seeing this problem with ``build.sh tools'' ? it's not seen by most because it depends upon the timestamps of some files.. my first attempt to fix it failed, i haven't gotten back to looking. try manually touching any of the files the build is trying to update for now. Yeah, that seems to help. For the current failure on bfdver.texi I needed to touch .../bfd.info ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: binutils still failing on amd64
On Sat, 31 Dec 2022, Paul Goyette wrote:
Sources updated to 2022-12-31 at 13:42:04 UTC and all output dirs (obj,
release, dist, tools) were cleaned.
Is no-one else seeing this problem with ``build.sh tools'' ?
===> build.sh command:./build.sh -T
/build/netbsd-current/tools/x86_64/amd64 -D /build/netbsd-current/dest/amd64 -O
/build/netbsd-current/obj/amd64 -R /build/netbsd-current/release -V
RELEASEMACHINEDIR=amd64 -V MKDEBUG=yes -V MKDEBUGKERNEL=yes -V MKDEBUGLIB=yes -V
KERNEL_DIR=no -U -N2 -m amd64 -j1 tools
===> build.sh started:Sat Dec 31 19:27:16 UTC 2022
===> NetBSD version: 10.99.2
===> MACHINE: amd64
===> MACHINE_ARCH:x86_64
===> Build platform: NetBSD 9.99.107 amd64
===> HOST_SH: /bin/sh
===> No $TOOLDIR/bin/nbmake, needs building.
===> Bootstrapping nbmake
checking for sh... /bin/sh
...
CC libz_a-zutil.o
AR libz.a
GEN elf64-target.h
Making info in po
GEN
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi
x86_64--netbsd-install:
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc:
chown/chmod: Read-only file system
sh: cannot create
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi:
read-only file system
sh: cannot create
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi:
read-only file system
sh: cannot create
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi:
read-only file system
sh: cannot create
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi:
read-only file system
*** Failed target: doc/bfdver.texi
*** Failed commands:
$(AM_V_GEN) $(MKDIR_P) $(@D); echo "@set VERSION $(VERSION)" > $@; if test -n "$(PKGVERSION)"; then echo "@set
VERSION_PACKAGE $(PKGVERSION)" >> $@; fi; echo "@set UPDATED `date '+%B %Y'`" >> $@; if test -n "$(REPORT_BUGS_TEXI)";
then echo "@set BUGURL $(REPORT_BUGS_TEXI)" >> $@; fi
=> @echo " GEN " /build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi;
/build/netbsd-current/tools/x86_64/amd64/bin/x86_64--netbsd-install -d -p /build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc; echo
"@set VERSION 2.39" > /build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi; if test -n "(NetBSD Binutils
nb1)"; then echo "@set VERSION_PACKAGE (NetBSD Binutils nb1)" >>
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi; fi; echo "@set UPDATED `date '+%B %Y'`" >>
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi; if test -n "@uref{http://www.NetBSD.org/support/send-pr.html};;
then echo "@set BUGURL @uref{http://www.NetBSD.org/support/send-pr.html}; >>
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist/bfd/doc/bfdver.texi; fi
*** [doc/bfdver.texi] Error code 2
nbmake[6]: stopped in /build/netbsd-current/obj/amd64/tools/binutils/build/bfd
1 error
nbmake[6]: stopped in /build/netbsd-current/obj/amd64/tools/binutils/build/bfd
nbmake[5]: stopped in /build/netbsd-current/obj/amd64/tools/binutils/build/bfd
*** Failed target: all-bfd
*** Failed command: r=`${PWDCMD-pwd}`; export r; s=`cd /build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils/dist; ${PWDCMD-pwd}`; export s; FLEX="/build/netbsd-current/tools/x86_64/amd64/bin/nblex"; export FLEX; LEX="/build/netbsd-current/tools/x86_64/amd64/bin/nblex"; export LEX; BISON="true"; export BISON; YACC="/build/netbsd-current/tools/x86_64/amd64/bin/nbyacc"; export YACC; M4="/build/netbsd-current/tools/x86_64/amd64/bin/nbm4"; export M4; SED="/usr/pkg/bin/gsed"; export SED; AWK="/build/netbsd-current/tools/x86_64/amd64/bin/nbawk"; export AWK; MAKEINFO="/build/netbsd-current/tools/x86_64/amd64/bin/nbmakeinfo"; export MAKEINFO; CC="cc"; export CC; ADA_CFLAGS=""; export ADA_CFLAGS; CFLAGS="-O "; export CFLAGS; CONFIG_SHELL="/bin/sh"; export CONFIG_SHELL; CXX="c++"; export CXX; CXXFLAGS="-O "; export CXXFLAGS; GFORTRAN=""; export GFORTRAN; GOC=""; export GOC; GDC="@GDC@"; export GDC; AR="ar"; export AR; AS="as"; export AS; CC_FOR_BUILD="cc"; export CC_FOR_BUILD; CPP_FOR_BUILD="@CPP_FOR_BUILD@"; export CPP_FOR_BUILD; CPPFLAGS_FOR_BUILD="@CPPFLAGS_FOR_BUILD@"; export CPPFLAGS_FOR_B
binutils still failing on amd64
Sources updated to 2022-12-31 at 13:42:04 UTC and all output dirs (obj, release, dist, tools) were cleaned. ``build.sh tools'' fails trying to build bfdver.texi - see attachment for log details ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+ XXX Description: Binary data
Re: 10.0 BETA: Managed to get boot menu; it doesn't find kernel though
On Tue, 27 Dec 2022, Mayuresh wrote: On Tue, Dec 27, 2022 at 10:10:24PM +0530, Mayuresh wrote: The kernel happens to be on /dev/dk5. Is it required to be copied on the UEFI partition? Or alternatively, how to specify the disk path to a UEFI boot option? I figured out that boot hd0f:netbsd boots from the boot prompt, but where to write this information? Check out /boot.cfg (on NetBSD root partition) and/or /EFI/boot.cfg (on the UEFI partition, not on the NetBSD root). You may need to adjust. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
tools build failure
on amd64 host and with amd64 target I am seeing
...
/build/netbsd-current/tools/x86_64/amd64/bin/nbyacc: f - cannot open
"/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils.old/dist/gas/config/m68k-parse.c"
*** Failed target:
/build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils.old/dist/gas/config/m68k-parse.c
*** Failed commands:
${_MKTARGET_YACC}
=> @echo '# ' " yacc "
binutils//build/netbsd-current/src_ro/tools/binutils/../../external/gpl3/binutils.old/dist/gas/config/m68k-parse.c
${YACC.y} -o ${.TARGET} ${.IMPSRC}
...
Wondering why amd64 builds are referencing m68k stuff? :-)
++--+----------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Re: strange bot problem
Ignore me - I forgot to install the new modules, so I failed to autoload EXEC_ELF64 On Mon, 31 Oct 2022, Paul Goyette wrote: I'm trying to update my NetBSD-9.99.99 (amd64) system to .104 and it's giving me some heartburn. I've alraeady updated bootstrap files, and the kernel loads just find. But when it comes time to exec /sbin/init it fails with ENOEXEC (errno == 8). It proceeds to try the various "backup" names for init, all attempts fail with ENOSUCH (except for the /rescue/init which also fails with ENOEXEC). The /sbin/init file works just fine for booting NetBSD 9.99.99 Any clues on what I'm doing wrong? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+ ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
strange bot problem
I'm trying to update my NetBSD-9.99.99 (amd64) system to .104 and it's giving me some heartburn. I've alraeady updated bootstrap files, and the kernel loads just find. But when it comes time to exec /sbin/init it fails with ENOEXEC (errno == 8). It proceeds to try the various "backup" names for init, all attempts fail with ENOSUCH (except for the /rescue/init which also fails with ENOEXEC). The /sbin/init file works just fine for booting NetBSD 9.99.99 Any clues on what I'm doing wrong? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: How to BIOS-boot from NVMe device?
On Thu, 8 Sep 2022, Paul Goyette wrote: Would be nice to get my menu back and have it default to the NetBSD system partition, but at least it boots! I got my menu back. Just had to put it at /efi/boot.cfg (ie, at the root of the EFI partition). ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: How to BIOS-boot from NVMe device?
Yay - it boots again! I re-ran ``gpt biosboot'' and ``installboot'' specifying the NetBSD partition (index=2), and completely disconnected the hard drives. It booted! But I think it is still confused. The BIOS no longer offers EFI as a boot option. Yet, the boot menu I get is the NetBSD flag with no menu options listed. It simply declares a default boot file and timeout. Since the timeout does not match what I specified in installboot, _and_ the default file to boot is on device NAME=EFI-system I can only surmise that it did a EFI-boot. (The EFI partition is still marked ``bootme''.) Would be nice to get my menu back and have it default to the NetBSD system partition, but at least it boots! Thanks! PS I _detest_ x86 bootstrap crap! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: How to BIOS-boot from NVMe device?
OK, now I _really_ messsed things up, to the point where I have to write this using the old spinny-rust! Kernel is at least a month out of date! I tried to run gpt biosboot (and specified -i 1 for the partition) and I also ran installboot. Result: an unbootable system. :( Just goes back to the BIOS boot page without any messages. On a positive front, the BIOS seems to now recognize the NVMe as having a UEFI OS. Trying to boot it takes me down some new path having to do with SecureBoot, and I don't have time for that now. Any suggestions on how to get my legacy boot stuff back? On Wed, 7 Sep 2022, Paul Goyette wrote: On Thu, 8 Sep 2022, Robert Elz wrote: Do you have evidence that the motherboard can boot from nmve at all? If the motherboard in question is of a similar vintage to those 10 year old boxes of rust, then it might not be able to, and you might need some kind of SATA (or perhaps USB) device to boot. Well, the AMI BIOS talks about UEFI so I just ass-u-me'd ... | I'm guessing I need to install some primary boot blocks, but I do | not know how to do this for gpt drives (ie, wedges). I know how to | handle on disklabel'd drives, but not gpt. See the biosboot sub-command in "man gpt", that's all it has ever taken for me, perhaps along with a suitable installboot (I'm not sure if gpt installs that one or not, it does install the PMBR boot code). OK, I apparently tried this a long time ago, and I have a copy of x86 BIOS Boot from vintage 9.99.82 or so... :) With no disks attached, the system boots that code. Nothing seems to indicate that any UEFI boot attempt was made. Some bios's apparently require the PMBR partition (that is, the protective MBR partition) to be marked "active" in order to boot from it. Looks like that was already done, too. If the BIOS can do UEFI booting, as Michael suggested, (and it works) then that's a better way. | PS I _do_ have a msdos/efi partition on the nvme, but I don't know | what to put there! :) For BIOS booting it would be irrelevant. I guess that once I update to newer BIOS Boot, it will process my boot.cfg file appropriately. ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+ !DSPAM:63195ac554638293983044! ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: How to BIOS-boot from NVMe device?
On Thu, 8 Sep 2022, Robert Elz wrote: Do you have evidence that the motherboard can boot from nmve at all? If the motherboard in question is of a similar vintage to those 10 year old boxes of rust, then it might not be able to, and you might need some kind of SATA (or perhaps USB) device to boot. Well, the AMI BIOS talks about UEFI so I just ass-u-me'd ... | I'm guessing I need to install some primary boot blocks, but I do | not know how to do this for gpt drives (ie, wedges). I know how to | handle on disklabel'd drives, but not gpt. See the biosboot sub-command in "man gpt", that's all it has ever taken for me, perhaps along with a suitable installboot (I'm not sure if gpt installs that one or not, it does install the PMBR boot code). OK, I apparently tried this a long time ago, and I have a copy of x86 BIOS Boot from vintage 9.99.82 or so... :) With no disks attached, the system boots that code. Nothing seems to indicate that any UEFI boot attempt was made. Some bios's apparently require the PMBR partition (that is, the protective MBR partition) to be marked "active" in order to boot from it. Looks like that was already done, too. If the BIOS can do UEFI booting, as Michael suggested, (and it works) then that's a better way. | PS I _do_ have a msdos/efi partition on the nvme, but I don't know | what to put there! :) For BIOS booting it would be irrelevant. I guess that once I update to newer BIOS Boot, it will process my boot.cfg file appropriately. ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: How to BIOS-boot from NVMe device?
On Wed, 7 Sep 2022, Michael van Elst wrote: p...@whooppee.com (Paul Goyette) writes: I have completely disconnected the wd0 and wd1 hard drives, and now the motherboard/BIOS can't find something (primary boot?). It does not give any helpful messages (no messages at all), but just goes back to the interactivve BIOS screens. It's likely that the BIOS doesn't know about the NVMe device and you must use UEFI. PS I _do_ have a msdos/efi partition on the nvme, but I don't know what to put there! :) You need: ./efi/boot/bootx64.efi and you may need to tell the machine that it should do an UEFI boot. Ah, OK. I did # mount -t msdos NAME=EFI-system /efi # cd /efi # mkdir efi # mkdir efi/boot # cp /usr/mdec/bootx64.efi efi/boot/ # cd / # umount /efi I'll give a try later, next time i can open up the case. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
How to BIOS-boot from NVMe device?
I'm trying desperately to retire my way-too-old spinny-rust, but I have run into a little problem. I have completely disconnected the wd0 and wd1 hard drives, and now the motherboard/BIOS can't find something (primary boot?). It does not give any helpful messages (no messages at all), but just goes back to the interactivve BIOS screens. I'm guessing I need to install some primary boot blocks, but I do not know how to do this for gpt drives (ie, wedges). I know how to handle on disklabel'd drives, but not gpt. For now, I have reconnected one of the wd drives and it's working, but I really don't want to depend on drives that have been running more-or-less 24x7 for 10+ years! Thanks in advance for any help! PS I _do_ have a msdos/efi partition on the nvme, but I don't know what to put there! :) ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Build break for amd64?
On Fri, 2 Sep 2022, Paul Goyette wrote:
Trying to build HEAD I am seeing
checkflist ===> distrib/sets
== 1 missing files in DESTDIR
Files in flist but missing from DESTDIR.
File wasn't installed ?
--
./usr/tests/usr.bin/make/unit-tests/local.init.mk
end of 1 missing files ==
Just in case it matters, the failure occurs when building with all
of MKDEBUG{,LIB,KERNEL} set to "yes".
I just retrired with sources updated to 2022-09-03 at 01:05:52 UTC
and the failure still occurs.
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Build break for amd64?
Trying to build HEAD I am seeing checkflist ===> distrib/sets == 1 missing files in DESTDIR Files in flist but missing from DESTDIR. File wasn't installed ? -- ./usr/tests/usr.bin/make/unit-tests/local.init.mk end of 1 missing files == ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Bad symbols in Installer menu in USB Stick Kingston Elite G2
Looks to me like there's a string that is not null-terminated, thus we see garbage following the string/label (serial number?) which reads ``PMAPPAMP1234'' On Sun, 28 Aug 2022, Dmitrii Postolov wrote: Hi! Sorry for my bad English... Bad symbols in NetBSD-9.99-CURRENT in Installer menu in case of USB Stick Kingston Elite G2, on FreeBSD all correct in Installer menu: NetBSD photo: https://disk.yandex.ru/i/1_yySwBrx0sl9A FreeBSD photo: https://disk.yandex.ru/i/SjbYZo2xya6eRg Kingston Elite G2 photo: https://disk.yandex.ru/i/lsrtxKGUYhoywA !DSPAM:630ad23c149829464610240! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Doc error - sysctl
On Mon, 25 Jul 2022, J. Hannken-Illjes wrote: On 25. Jul 2022, at 16:30, Paul Goyette wrote: It seems that kern.maxvnodes is dodcumented as "cannot be lowered" kern.maxvnodes (KERN_MAXVNODES) The maximum number of vnodes available on the system. This can only be raised. However, the kernel allows you to lower the value, and it helps if you want to flush file cache (free up active memory). Yes, it can be lowered and will fail if you try to go below the number of active vnodes. Please go ahead and fix the documentation. Done! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Doc error - sysctl
It seems that kern.maxvnodes is dodcumented as "cannot be lowered" kern.maxvnodes (KERN_MAXVNODES) The maximum number of vnodes available on the system. This can only be raised. However, the kernel allows you to lower the value, and it helps if you want to flush file cache (free up active memory). ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Removing swapfile takes a lock for long time
I've noticed that when you do ``swapctl -d ' all accesses to the count-of-swapped-out-pages are blocked. Seems that bringing the out-swapped pages back takes some lock for the entire process, which can be quite lengthy if there's a lot of swap... Among other use cases, there's no way to tell how-many-pages-remain- to-swap-in; it also seems to prevent running processes from bringing their own pages back in. Shouldn't we be occassionally releasing-and-reacquiring the relevant lock, so that other things can also make progress? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: nouveau: back in text console after switch to graphical one
On Wed, 8 Jun 2022, Thomas Klausner wrote: Did either of you install any firmware files? Only from a normal install Which firmware file is loaded? how do I tell? FWIW, I noticed my machine is still on 9.99.96 (not 97) in case it makes any difference. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: nouveau: back in text console after switch to graphical one
On Wed, 8 Jun 2022, Cygnus X-1 wrote: 8< snip >8 I wonder if nouveau has been actually working for anybody on HEAD, or if the driver is in a completely broken state. ... Yup. At least with 9.99.97 my nouveau is running great on my Geforce GTX 1050 Ti ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Threaded version of TOOL_XZ ?
Thanks - the extra lib was what I missed earlier!
I'd like this to be optional, ie USE_XZ_THREADS={yes, no}
As for passsing -T0 that could be done in the setting of XZ_OPT
in distrib/sets/Makefile, also done conditionally based on
USE_XZ_THREADS
On Tue, 19 Apr 2022, Tobias Nygren wrote:
On Tue, 19 Apr 2022 10:18:20 -0700 (PDT)
Paul Goyette wrote:
Using TOOL_XZ instead of TOOL_GZ satisfies requirement #1, and use of
(unsupported) TOOL_PIGZ satisfies #2, but neither option can meet
both. TOOL_XZ is explicitly built without thread support, and simply
modifying its Makefile to enable_threads=yes doesn't build.
This patch does more or less what you want. But doing it this way means
NetBSD can no longer be cross-compiled from a host without pthreads.
Not sure if we care about this anymore or if we need to hide this
behind a toggle. You also need to hook "-T 0" into xz args for sets.
# set cpu on fire
/work/tools/bin/nbxz -T 0 -9c < /dev/zero > /dev/null
Index: external/public-domain/xz/bin/xz/Makefile
===
RCS file: /cvsroot/src/external/public-domain/xz/bin/xz/Makefile,v
retrieving revision 1.6
diff -p -u -r1.6 Makefile
--- external/public-domain/xz/bin/xz/Makefile 12 Apr 2021 02:54:08 -
1.6
+++ external/public-domain/xz/bin/xz/Makefile 19 Apr 2022 18:03:58 -
@@ -44,7 +44,7 @@ FILESNAME_${XZSRCDIR}/po/${lang}.gmo= xz
.if defined(HOSTPROG)
HOST_CPPFLAGS+= ${CPPFLAGS:N-Wp,-iremap,*}
XZLIBDIR!= cd ${NETBSDSRCDIR}/tools/xz-lib && ${PRINTOBJDIR}
-LDADD+=-L${XZLIBDIR} -llzma
+LDADD+=-L${XZLIBDIR} -llzma -lpthread
DPADD+= ${XZLIBDIR}/liblzma.a
.else
DPADD+= ${LIBLZMA} ${LIBINTL} ${LIBPTHREAD}
Index: external/public-domain/xz/lib/Makefile
===
RCS file: /cvsroot/src/external/public-domain/xz/lib/Makefile,v
retrieving revision 1.10
diff -p -u -r1.10 Makefile
--- external/public-domain/xz/lib/Makefile 25 Sep 2018 05:42:08 -
1.10
+++ external/public-domain/xz/lib/Makefile 19 Apr 2022 18:03:58 -
@@ -57,9 +57,7 @@ SRCS+=common.c block_util.c easy_preset
index_decoder.c index_hash.c stream_buffer_decoder.c \
stream_decoder.c stream_flags_decoder.c vli_decoder.c
-.if !defined(HOSTLIB)
SRCS+= stream_encoder_mt.c
-.endif
.PATH: ${XZSRCDIR}/src/liblzma/delta
SRCS+= delta_common.c delta_encoder.c delta_decoder.c
Index: tools/xz-include/Makefile
===
RCS file: /cvsroot/src/tools/xz-include/Makefile,v
retrieving revision 1.4
diff -p -u -r1.4 Makefile
--- tools/xz-include/Makefile 18 Sep 2021 01:47:11 - 1.4
+++ tools/xz-include/Makefile 19 Apr 2022 18:03:59 -
@@ -8,7 +8,7 @@
#
.include "Makefile.inc"
-CONFIGURE_ARGS+= --enable-threads=no --disable-nls
+CONFIGURE_ARGS+= --enable-threads=posix --disable-nls
.if ${MAKEVERBOSE} == 0
CONFIGURE_ARGS+=--silent
.endif
!DSPAM:625efa5669779096642723!
++------+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Threaded version of TOOL_XZ ?
From recent investigations into PR install/54844, I have noted that we don't have a useful build tool that can both 1) compress much better/smaller than gzip, and 2) use multiple threads to do parallel compressions to reduce run-time. Using TOOL_XZ instead of TOOL_GZ satisfies requirement #1, and use of (unsupported) TOOL_PIGZ satisfies #2, but neither option can meet both. TOOL_XZ is explicitly built without thread support, and simply modifying its Makefile to enable_threads=yes doesn't build. FWIW, on my 8core/16thread Intel CPU, PIGZ compression takes just a fraction of the time GZ takes to build a debug set (saving more than 20 minutes from a ``build.sh -J7 release''; yet the resulting sets files from PIGZ are 50% to 100% larger than those from XZ. So, it would seem reasonable to provide an option to build TOOL_XZ with threads enabled, even if only through a hidden option (and maybe eveen useful only in build.sh's -E expert mode). Suggestion? Comments? Patches? :-) ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: config(1) help needed!
On Thu, 31 Mar 2022, Paul Goyette wrote: I trying to merge the midi and sequencer modules (to resolve some circular dependency), and running into a problem getting the build to create a combined ioconf.[ch] file. I've joined the two pre-existing ioconf files thusly: ioconf midi include "conf/files" pseudo-root midibus* midi* at midibus? ioconf sequencer<<<--- pseudo-root midi* <<<--- pseudo-device sequencer I've tried with all four combinations of including/omitting the two <<<--- lines, without any success. config(1) creates all of the stuff for midi but doesn't create anything for the sequencer device. Any suggestions on how to make this work? Interestingly, config _does_ create the declaration for the sequencerattach() routine in ionconf.h but it declares a cfdriver only for midi; there is no cfdriver for the sequencer device. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
config(1) help needed!
I trying to merge the midi and sequencer modules (to resolve some circular dependency), and running into a problem getting the build to create a combined ioconf.[ch] file. I've joined the two pre-existing ioconf files thusly: ioconf midi include "conf/files" pseudo-root midibus* midi* at midibus? ioconf sequencer<<<--- pseudo-root midi* <<<--- pseudo-device sequencer I've tried with all four combinations of including/omitting the two <<<--- lines, without any success. config(1) creates all of the stuff for midi but doesn't create anything for the sequencer device. Any suggestions on how to make this work? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Re: Crash on various Supermicro motherboards
On Wed, 23 Mar 2022, 6b...@6bone.informatik.uni-leipzig.de wrote: On Wed, 23 Mar 2022, Paul Goyette wrote: Date: Wed, 23 Mar 2022 08:50:03 -0700 (PDT) From: Paul Goyette To: 6b...@6bone.informatik.uni-leipzig.de Cc: current-users@netbsd.org Subject: [Extern] Re: Crash on various Supermicro motherboards On Wed, 23 Mar 2022, 6b...@6bone.informatik.uni-leipzig.de wrote: I can't offer a dump. The kernel jumps into the ddb. This does not accept input from USB devices. Recompile a kernel with ``options DDB_COMMANDONENTER="reboot 0x100' '' Should reboot 0x100 create a kernel dump? I'm afraid this doesn't work. No drive or swap is mounted at the time of the crash. The config line should help config netbsd root on wd0a dump on wd0b (of course use ethe correct drive designation) also try setting up a serial-console connection to another machine so you can capture the console messages ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Crash on various Supermicro motherboards
On Wed, 23 Mar 2022, 6b...@6bone.informatik.uni-leipzig.de wrote: I can't offer a dump. The kernel jumps into the ddb. This does not accept input from USB devices. Recompile a kernel with ``options DDB_COMMANDONENTER="reboot 0x100' '' ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Strange ``tail -f'' behaviour - kqueue-related?
On Thu, 10 Feb 2022, Paul Goyette wrote: I've been seeing some very odd behaviour lately, with ``tail -f''. I've got a bunch of packages being built (in a chroot sandbox), and occassionally I do a ``tail -f'' on the current package's log file just to make sure it is still making progress. So the file is open by both the package-building shell and the tail process. Occassionally the tail process fails to notice any further changes to the file's size, and just sits there. Indeed, it is now more than 30 minutes since a particular build completed (and the shell has long ago closed the log file), but the tail output is still stuck somewhere in the middle of the file. (I've seen this a few times now, and while it happens again and again, it does not seem predictable on when it might happen.) I'm wondering if some of the recent changes to kqueue might be responsible. I don't ever remember seeing this prior to my recent update from 9.99.92 to .93 Just to test this assumption, I checked with ``ps -o wchan'' and sure enough the tail process is waiting on kqueue. I can keep the "hung" tail process around for a while in case of any diagnostic requests. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Strange ``tail -f'' behaviour - kqueue-related?
I've been seeing some very odd behaviour lately, with ``tail -f''. I've got a bunch of packages being built (in a chroot sandbox), and occassionally I do a ``tail -f'' on the current package's log file just to make sure it is still making progress. So the file is open by both the package-building shell and the tail process. Occassionally the tail process fails to notice any further changes to the file's size, and just sits there. Indeed, it is now more than 30 minutes since a particular build completed (and the shell has long ago closed the log file), but the tail output is still stuck somewhere in the middle of the file. (I've seen this a few times now, and while it happens again and again, it does not seem predictable on when it might happen.) I'm wondering if some of the recent changes to kqueue might be responsible. I don't ever remember seeing this prior to my recent update from 9.99.92 to .93 I can keep the "hung" tail process around for a while in case of any diagnostic requests. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: Disappearing mouse buttons
I've noticed some possibly-related strange behavior with my USB mouse... ... [ 1.020834] xhci0 at pci0 dev 20 function 0: vendor 8086 product 8d31 (rev. 0x05) [ 1.020834] xhci0: 64-bit DMA [ 1.020834] xhci0: interrupting at msi0 vec 0 [ 1.020834] xhci0: xHCI version 1.0 [ 1.020834] usb0 at xhci0: USB revision 3.0 ... [ 1.020834] usb1 at xhci0: USB revision 2.0 [ 1.864441] uhub1 at usb1: NetBSD (0x) xHCI root hub (0x), class 9/0, rev 2.00/1.00, addr 0 ... [ 4.031817] uhidev2 at uhub1 port 14 configuration 1 interface 0 [ 4.031817] uhidev2: PixArt (0x17ef) Lenovo USB Optical Mouse (0x600e), rev 2.00/1.00, addr 6, iclass 3/1 [ 4.041817] ums0 at uhidev2: 3 buttons and Z dir [ 4.041817] wsmouse0 at ums0 mux 0 ... Sometimes (without any discernible pattern), moving the scroll wheel "down" does nothing. Under normal conditions, it does what you'd expect, scrolling the page, AND there are detectable "detents" in the wheel movement (ie, little bumps). However, when it decides to misbehave, there are no more detents and no more scrolling. Yet it still works in the scroll-up rotation (including the detents). It usually resets in a few seconds, and then all is will until the next occurrence. This is on amd64 9.99.93 with sources dated 2022-01-08 03:00:28 UTC. (The kernel does have some custom stuff, but no customizations that should have any relation to USB.) It sorta feels like something is disabling (or turning off) the down-scroll function of the wheel, without breaking anything else. I don't remember this happening on earlier kernels, but I'm getting old so the memory might be operating in sieve-mode. :-) ++--+------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: XEN devices included in kernel even if not XEN
On Tue, 21 Dec 2021, Brad Spencer wrote: Manuel Bouyer writes: On Tue, Dec 21, 2021 at 07:44:59AM -0800, Paul Goyette wrote: I've noticed that device drivers listed in arch/xen/conf/files.xen (or, at least, most of those devices) seem to be included in kernel even if not using XEN. Shouldn't all those devices be conditional? # sysctl -a | grep driver | tr ',' '\n' | grep 'x[be]*' ... [141 -1 xenevt] [142 142 xbd] [143 -1 xencons] I think this lists all the known major numbers for the $MACHINE, I don't think it means that the driver is actually loaded. ... and a PVHVM guest can use the GENERIC kernel, but will want the Xen devices too. Thanks to all for the info. Manuel is correct - I actually checked the build object directory and there are no *.o files related to the xen devices. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
XEN devices included in kernel even if not XEN
I've noticed that device drivers listed in arch/xen/conf/files.xen
(or, at least, most of those devices) seem to be included in kernel
even if not using XEN. Shouldn't all those devices be conditional?
# sysctl -a | grep driver | tr ',' '\n' | grep 'x[be]*'
...
[141 -1 xenevt]
[142 142 xbd]
[143 -1 xencons]
# tail $OBJDIR/amd64/sys/arch/amd64/compile/SPEEDY/opt_xen.h
#endif
/* option `XEN' not defined */ <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
#ifdef _LOCORE
.ifndef _KERNEL_OPT_XEN
.global _KERNEL_OPT_XEN
.equiv _KERNEL_OPT_XEN,0x6e074def
.endif
#else
__asm(" .ifndef _KERNEL_OPT_XEN\n .global _KERNEL_OPT_XEN\n .equiv
_KERNEL_OPT_XEN,0x6e074def\n .endif");
#endif
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
| & Network Engineer | | pgoyett...@gmail.com |
++--+--+
Re: Heads up: objdir is now rm -rf resistent
On Wed, 15 Dec 2021, Greg Troxel wrote: Andreas Gustafsson writes: m...@netbsd.org wrote: I hope fixing this is enough to fix all the cryptic issues. The build is now fixed, but I still need to give the testbeds the ability to automatically remove objdirs containing non-writable directories, because otherwise they will get stuck whenever they decide to build a historic version from the affected time range. This is also going to be an ongoing pitfall for anyone building historic versions, for example when bisecting. I wonder if "rm -rf" should actually succeed with these modes, by doing a chmod when necessary. It has always seem to me that -f is supposed to really mean -f. But maybe POSIX says otherwise. It actually does try a chmod in the build, but that also fails with EPERM! (Sorry if someone has already pointed this out; I'm a bit behind in my reading.) ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: backward compatibility: how far can it reasonably go?
On Tue, 7 Dec 2021, Greg A. Woods wrote: So I've got a couple of old but important machines (Xen amd64 domUs) running NetBSD-5, and I've finally decided that I'm reasonably well enough prepared to try upgrading them. However it seems a "modern" (9.99.81, -current from about 2021-03-10) kernel with COMPAT_40 isn't able to run some of the userland on those systems. Is this something that should work? I believe that this should work. If it should I think it would make the upgrade much easier as I could then plop down the new userland and run etcupdate. (there are of course alternative ways to do the upgrade, eased by the fact they are domUs (*)) The most immediate problems I noticed are with networking. ifconfig -a returns without printing anything, and trying to enable IPF crashes: Without looking at the details of your backtrace, the issue with ifconfig(8) could be related to PRs kern/54150 and/or kern/54151. ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
Re: HP DL380p Gen8 interrupt storm
Try booting with the CD drive disabled (via userconf)
On Fri, 3 Sep 2021, Havard Eidnes wrote:
Hi,
one machine I'm testing NetBSD on feels sort of sluggish, which
is strange because it's got lots of RAM (128GB) and a pair of
Xeon(R) CPU E5-2650 CPUs, for a total of 16 physical cores and 32
with hyperthreading.
It looks like one of the CPUs is using most of its time doing
interrupt processing, "systat vm" often shows * in "Intr" and
I have a constant buzz of 6.3% System CPU:
Proc:r d sCsw Traps SysCal Intr Soft Fault PAGING SWAPPING
1 7557281355 * 64277 in out in out
ops
6.3% Sy 0.0% Us 0.0% Ni 0.1% In 93.6% Idpages
|||||||||||
=== 2 forks
2 fkppw
Checking further:
stest: {8} vmstat -i
interrupt total rate
TLB shootdown 4677209 0
cpu0 timer 1046424629 99
msix2 vec 0 62702425 5
msix6 vec 0 3294854 0
ioapic0 pin 21 84 0
ioapic0 pin 20 21074226 2
ioapic0 pin 17 3344590700017 319462
ioapic0 pin 4 12722 0
Total 3345728886166 319570
stest: {9} grep 'ioapic0 pin 17' /var/run/dmesg.boot
pciide0: using ioapic0 pin 17 for native-PCI interrupt
stest: {10}
pciide0 only has the built-in CD drive, if I see correctly.
Full dmesg attached below.
Any hints about what's going on and how to further diagnose and
eventually cure it?
Regards,
- H?vard
!DSPAM:61324ecd137045439215331!
++--+------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
|| | pgoyett...@gmail.com |
++--+--+
Re: Question about using I2C_IOCTL_EXEC to read data over I2C
Dave,
As I recall, our I2C driver does not support block transfers. It is
necessary to read (or write) one byte at a time. So you would have
to loop from 0xAA-0xBF.
A long time ago I prepared patches for a small subset of our supported
I2C controllers, but they (the patches) are long gone.
Good luck!
On Tue, 17 Aug 2021, Dave Tyson wrote:
I am trying to get data from a temperature/pressure sensor connected via i2c
to a banana pi running NetBSD current. I understand the I2C protocol but I am
having a bit of difficulty understanding what appears on the wire when the
I2C_IOCTL_EXEC is called with the various op commands. By trial and error I
seem to have been able to read the data, but want to check a few things in
case I am doing it all wrong :-)
The device appears at address 0x77 (it's a BMP085) with i2cscan, the data
sheet indicates the read address=0xEF/write address=0xEE. I just put 0x77 in
the address field and assume the read/write bit on the wire is added based on
the op code (I2C_OP_WRITE, I2C_OP_READ etc).
The device has R/O calibration data in 22 contiguous registers starting at
0xAA->0xBF. Linux programs seem to grab the data in one go starting at 0xAA.
The other registers needed to initiate a sensor data grab are R/W - you write
a control byte into the 0xF4 register, wait a bit and then read the data from
another register set.
A naive attempt to read the calibration data using:
command = 0xAA ;
iie.iie_op = I2C_OP_READ ;
iie.iie_addr = 0x77 ;
iie.iie_cmd = ;
iie.iie_cmdlen = 1 ;
iie.iie_buf = [0] ;
iie.iie_buflen = 22;
if ((ioctl(iicfd, I2C_IOCTL_EXEC, )) !=0) {
printf("read failed %d\n",errno) ;
exit(1) ;
}
actually seemed to work OK, but I don't understand why!
I had expected to need a I2C_OP_WRITE first followed by a I2C_OP_READ_STOP.
The former would send a start bit, the device addr/write bit and the target
register. The latter would send a (re)start bit, device addr/read bit, pull
the data back and issue a stop. Maybe because the register I am addressing is
R/O there is no need for a write and what I am doing is correct... (or do I
need a I2C_OP_READ_STOP)
Could someone explain what actually gets sent on the wire for the various ops:
I2C_OP_READ
I2C_OP_READ_WITH_STOP
I2C_OP_WRITE
I2C_OP_WRITE_WITH_STOP
I2C_OP_READ_BLOCK
I2C_OP_WRITE_BLOCK
and what difference block operations make as man ICC(4) is terse to say the
least.
Cheers,
Dave
!DSPAM:611be3ce51591168618607!
++--+--+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
|| | pgoyett...@gmail.com |
++--+--+
Build failures?
After your commit to hack the evbsh3 (and other) builds, I tried to
re-run all my failed builds. They were all run "from clean" so there
were no remnants of the earlier builds.
All six of the builds failed with the same error (dreamcast, hpcsh,
mmeye, landisk, and evbsh3-e[bl]).
/build/netbsd-current/src_ro/lib/libcurses/slk.c: In function '__slk_wset':
/build/netbsd-current/src_ro/lib/libcurses/slk.c:571:52: error: format '%ld'
expects argument of type 'long int', but argument 3 has type 'size_t' {aka
'unsigned int'} [-Werror=format=]
571 | __CTRACE(__CTRACE_INPUT, "__slk_wset: wcsrtombs %ld\n", len);
| ~~^ ~~~
|| |
|| size_t {aka
unsigned int}
|long int
| %d
cc1: all warnings being treated as errors
*** Failed target: slk.go
*** Failed commands:
${_MKTARGET_COMPILE}
${COMPILE.c} ${DEBUGFLAGS} ${COPTS.${.IMPSRC:T}}
${CPUFLAGS.${.IMPSRC:T}} ${CPPFLAGS.${.IMPSRC:T}} -g ${.IMPSRC} -o ${.TARGET}
*** [slk.go] Error code 1
Have you seen this in the officials builds?
++--+------+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses:|
| (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com|
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org |
|| | pgoyett...@gmail.com |
++--+--+
Re: ``ddump -W'' fails in /etc/daily
FWIW, the [*] tag was intended to lead to: [*] The drive had a little help on the path to failure - my new puppy pulled on the cable and the drive experienced a free-fall of approximately 20 inches (0.5 meters). It seemed to work for a short while, but then totally locked up and won't even complete the auto-conf discovery process. :-( On Tue, 15 Jun 2021, Paul Goyette wrote: I have the following entry in my /etc/fstab file: ... NAME=backups/backup ffs rw,noauto ... This is for a removable USB drive which is used to store various backups (as suggested by the label!). Most of the time, the drive is _not_connected_ - I only plug it in when I am actively doing a backup. Previously, the backup drive was labeled with disklabel(8), and the fstab entry specified ``/dev/sd0e''. Everything was fine. But that old backup device failed [*] so I had to replaced it, and I decided to use gpt(8) labels instead. Now, the daily job complains with the following message: Uptime: 3:15AM up 2 days, 7:49, 2 users, load averages: 0.00, 0.00, 0.00 DUMP: can't resolve mount point NAME=backups (no match for `backups'): Nosuch process DUMP: The ENTIRE dump is aborted. This would seem to be generated by the following: if [ -s /etc/dumpdates ] ; then dump -W > $TMP2 fi This behavior seems sub-optimal to me! Should I submit a PR? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | || | pgoyett...@gmail.com | ++--+--+ !DSPAM:60c8a300140861428417275! ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | || | pgoyett...@gmail.com | ++--+--+
``ddump -W'' fails in /etc/daily
I have the following entry in my /etc/fstab file: ... NAME=backups/backup ffs rw,noauto ... This is for a removable USB drive which is used to store various backups (as suggested by the label!). Most of the time, the drive is _not_connected_ - I only plug it in when I am actively doing a backup. Previously, the backup drive was labeled with disklabel(8), and the fstab entry specified ``/dev/sd0e''. Everything was fine. But that old backup device failed [*] so I had to replaced it, and I decided to use gpt(8) labels instead. Now, the daily job complains with the following message: Uptime: 3:15AM up 2 days, 7:49, 2 users, load averages: 0.00, 0.00, 0.00 DUMP: can't resolve mount point NAME=backups (no match for `backups'): Nosuch process DUMP: The ENTIRE dump is aborted. This would seem to be generated by the following: if [ -s /etc/dumpdates ] ; then dump -W > $TMP2 fi This behavior seems sub-optimal to me! Should I submit a PR? ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | || | pgoyett...@gmail.com | ++--+--+
cvslatest vs. local changes
Any clue on how to make ``build.sh -P'' work when you have local changes in the source tree, and those changes have been merged with subsequent real changes via ``cvs update''? I'm getting nbcvslatest: Malformed time `Result of merge' in `/build/netbsd-local/src_ro/distrib/sets/lists/debug/CVS/Entries' There are indeed several changed files in my local tree which have the `Result of merge' value in the date field. The cvslatest(1) utility has a ``-i'' switch to ignore malformed time-stamps, but there doesn't seem to be any way for build.sh to specify it. Since the `Result of merge' seems to be a valid value, perhaps we should either just ignore it, or stat(1) the relevant source file and use its last-modified date? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: -current build.sh install-image failure
On Thu, 29 Apr 2021, Chavdar Ivanov wrote: ... Populating `work.efi' Image `work.efi' complete cat work.mbr.truncated work.efi imgroot.fs work.gpt > work.img /home/sysbuild/amd64/tools/bin/nbgpt work.img biosboot -i 2 -c /home/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/installimage/work/usr/mdec/gptmbr.bin nbgpt: work.img: No secondary GPT header; run recover *** Failed target: NetBSD-9.99.82-amd64-install.img *** Failed command: /home/sysbuild/amd64/tools/bin/nbgpt work.img biosboot -i 2 -c /home/sysbuild/amd64/obj/home/sysbuild/src/distrib/amd64/installimage/work/usr/mdec/gptmbr.bin *** Error code 1 Stop. nbmake[4]: stopped in /home/sysbuild/src/distrib/amd64/installimage . This is due to a stale installation file. There is ongoing discussion of this problem for PR 56132. Please look there! As a work-around, rm -rf /build/netbsd-local/obj/amd64/distrib/amd64/installimage/ ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: IPv6 default route flapping
On Wed, 21 Apr 2021, Robert Swindells wrote: Think we need to make dhcpcd work with rump if it is the only way to do RA processing. And create an appropriate set of rump-based atf tests to detect future regressions. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: HEADS UP: GCC 10 now default on several ports
Something in your environment? /etc/mk.conf ? On Sun, 18 Apr 2021, Johnny Billquist wrote: On 2021-04-18 17:49, Martin Husemann wrote: On Sun, Apr 18, 2021 at 05:46:39PM +0200, Johnny Billquist wrote: I said in my original mail: "Building from NetBSD-8 does not work. Unsure if this is a known limitation." So, not building from current, but am trying to build current. Yes, but you are overriding HAVE_GCC somehow. Not that I am aware of. But obviously it has been set by something already before it comes to those lines in bsd.own.mk But I checked, and my whole source tree is pretty much unmodified, except for some vax specific files, where I have my own development stuff going on. Nothing that affects this. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol !DSPAM:607c55fb81081654361426! ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Build failure for usr.bin/printf
Christos has committed a fix On Fri, 16 Apr 2021, Chavdar Ivanov wrote: #metoo On Fri, 16 Apr 2021 at 19:22, Paul Goyette wrote: With $SRCDIR updated on 2021-04-16 at 18:08:17 UTC I am seeing ... # compile csh/printf.o /build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -fPIE -g -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wconversion -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror --sysroot=/build/netbsd-local/dest/amd64 -I/build/netbsd-local/src_ro/bin/csh -I. -DBUILTIN -DFILEC -DNLS -DSHORT_STRINGS -DEDIT -c -Wno-format-nonliteral /build/netbsd-local/src_ro/usr.bin/printf/printf.c -o printf.o.o /build/netbsd-local/src_ro/usr.bin/printf/printf.c: In function 'conv_escape': /build/netbsd-local/src_ro/usr.bin/printf/printf.c:508:14: error: conversion from 'int' to 'char' may change value [-Werror=conversion] 508 |value <<= 3; | ^ /build/netbsd-local/src_ro/usr.bin/printf/printf.c:122:21: error: conversion from 'int' to 'char' may change value [-Werror=conversion] 122 | #define octtobin(c) (char)((c) - '0') | ^ /build/netbsd-local/src_ro/usr.bin/printf/printf.c:509:13: note: in expansion of macro 'octtobin' 509 |value += octtobin(*str); | ^~~~ /build/netbsd-local/src_ro/usr.bin/printf/printf.c:522:14: error: conversion from 'int' to 'char' may change value [-Werror=conversion] 522 |value <<= 4; | ^ /build/netbsd-local/src_ro/usr.bin/printf/printf.c:524:13: error: conversion from 'int' to 'char' may change value [-Werror=conversion] 524 |value += d; | ^ cc1: all warnings being treated as errors *** [printf.o] Error code 1 nbmake[7]: stopped in /build/netbsd-local/src_ro/bin/csh ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ -- !DSPAM:6079da57112701352789184! ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Build failure for usr.bin/printf
With $SRCDIR updated on 2021-04-16 at 18:08:17 UTC I am seeing ... # compile csh/printf.o /build/netbsd-local/tools/x86_64/amd64/bin/x86_64--netbsd-gcc -O2 -fPIE -g -std=gnu99-Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare -Wsystem-headers -Wno-traditional -Wa,--fatal-warnings -Wreturn-type -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wextra -Wno-unused-parameter -Wno-sign-compare -Wold-style-definition -Wconversion -Wsign-compare -Wformat=2 -Wno-format-zero-length -Werror --sysroot=/build/netbsd-local/dest/amd64 -I/build/netbsd-local/src_ro/bin/csh -I. -DBUILTIN -DFILEC -DNLS -DSHORT_STRINGS -DEDIT -c -Wno-format-nonliteral /build/netbsd-local/src_ro/usr.bin/printf/printf.c -o printf.o.o /build/netbsd-local/src_ro/usr.bin/printf/printf.c: In function 'conv_escape': /build/netbsd-local/src_ro/usr.bin/printf/printf.c:508:14: error: conversion from 'int' to 'char' may change value [-Werror=conversion] 508 |value <<= 3; | ^ /build/netbsd-local/src_ro/usr.bin/printf/printf.c:122:21: error: conversion from 'int' to 'char' may change value [-Werror=conversion] 122 | #define octtobin(c) (char)((c) - '0') | ^ /build/netbsd-local/src_ro/usr.bin/printf/printf.c:509:13: note: in expansion of macro 'octtobin' 509 |value += octtobin(*str); | ^~~~ /build/netbsd-local/src_ro/usr.bin/printf/printf.c:522:14: error: conversion from 'int' to 'char' may change value [-Werror=conversion] 522 |value <<= 4; | ^ /build/netbsd-local/src_ro/usr.bin/printf/printf.c:524:13: error: conversion from 'int' to 'char' may change value [-Werror=conversion] 524 |value += d; | ^ cc1: all warnings being treated as errors *** [printf.o] Error code 1 nbmake[7]: stopped in /build/netbsd-local/src_ro/bin/csh ++--+-------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: regarding the changes to kernel entropy gathering
Personally, I'm happy with anything that your average high school student is unlikely to be able to crack in an hour. I don't run a bank, or a military installation, and I'm not the NSA. If someone is prepared to put in the effort required to break into my systems, then let them, it isn't worth the cost to prevent that tiny chance. That's the same way that my house has ordinary locks - I'm sure they can be picked by someone who knows what they're doing, and better security is available, at a price, but a nice happy medium is what fits me best. FWIW, I used to work for a company whose marketing motto was Good enough isn't! But I definitely agree with you - what we used to have is "good enough" for the vast bulk of our users and potential users. Perhaps sysinst(8) should ask Do you need a hyper-secure system? If yes, then leave things as they are today. But if you answer no, we should automatically copy enough pseudo-entropy bits to /dev/rnd to prevent future blocking. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: extra files in DESTDIR
It *was* worse when I had errant cvs tags in effect, and so part of the tree was updated differently than the rest, but thats sorted out now. Since you readily acknowledge having had some errant tagging issues in your tree previously, I would just delete and re-checkout your source tree. At the very least do a ``cvs up -A'' ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Routing socket issue?
On Sat, 30 Jan 2021, Roy Marples wrote: On 30/01/2021 18:27, Paul Goyette wrote: On Sat, 30 Jan 2021, Roy Marples wrote: On 30/01/2021 15:12, Paul Goyette wrote: I thought we took care of the buffer-space issue a long time ago, but today I've gotten about a dozen of these: ... Jan 30 05:20:11 speedy ntpd[3146]: routing socket reports: No buffer space available I recently adding a patch to enable the diagnostic AND take action on it. We can change the upstream default from LOG_ERR to LOG_DEBUG or maybe their custom DPRINTF though if you think that would help reduce the noise. Not concerned about noise, just wanted to make sure we didn't have a regression slip by. As long as the message is deliberate, I'm not too worried. Well, currently other apps such as dhcpcd still log an error when the routing socket overflows but a more helpful message. I think we can just change it to: routing socket overflowed - will update interfaces Happy with that? Sure. To alleviate the issue we could also stop ntpd from listening to routing changes has that has no bearing on how it discovers interfaces and addresses as far as i can tell. Frank ok with that? Roy !DSPAM:6015c335157686319899926! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Routing socket issue?
On Sat, 30 Jan 2021, Roy Marples wrote: On 30/01/2021 15:12, Paul Goyette wrote: I thought we took care of the buffer-space issue a long time ago, but today I've gotten about a dozen of these: ... Jan 30 05:20:11 speedy ntpd[3146]: routing socket reports: No buffer space available I recently adding a patch to enable the diagnostic AND take action on it. We can change the upstream default from LOG_ERR to LOG_DEBUG or maybe their custom DPRINTF though if you think that would help reduce the noise. Not concerned about noise, just wanted to make sure we didn't have a regression slip by. As long as the message is deliberate, I'm not too worried. Perhaps LOG_DEBUG would be better, though, as well as some indication of what "action" is taken and whether or not the action was successful? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Routing socket issue?
I thought we took care of the buffer-space issue a long time ago, but today I've gotten about a dozen of these: ... Jan 30 05:20:11 speedy ntpd[3146]: routing socket reports: No buffer space available ... ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: crash in amd64 -current
On Fri, 22 Jan 2021, Christos Zoulas wrote: In article , Paul Goyette wrote: With sources updated a few hours ago (2021-01-21 at 17:17:48 UTC) I am getting the following crash as soon as it tries to start syslogd: Also, why the heck does savecore(8) complain when I use the -N option? # savecore -fN /netbsd.bad.gdb savecore: dumpdev /dev/console is tty; override kernel Seems that the dump device it finds by reading the kernel namelist from /netbsd.bad.gdb ends up being /dev/console... Is the machine you are running gdb the same as the machine that produced the dump? because the dev_t it read from the kernel namelist matched the dev_t for the console on the local machine in /dev. Same machine. The dump was produced by a ddb ``sync'' command from a 9.99.78 kernel, and savecore(8) was running on a 9.99.77 kernel-plus- userland; that's why I specified the -N. It seems that savecore actually copied some info correctly without the -N option, and crash(8) was able to get a stack-trace. But gdb(1) was unable to provide a stack trace. This is with a custom kernel, with many device drivers loaded at run- time. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
crash in amd64 -current
With sources updated a few hours ago (2021-01-21 at 17:17:48 UTC) I am getting the following crash as soon as it tries to start syslogd: breakpoint() at breakpoint+0x5 vpanic() at vpanic+0x156 snprintf() at snprintf kqueue_check() at kqueue_check+0x183 kevent1() at kevent1+0x49f sys___kevent50() at sys___kevent50+0x33 syscall() at syscall+0x23e --- syscall (number 435) --- syscall+0x23e: Also, why the heck does savecore(8) complain when I use the -N option? # savecore -fN /netbsd.bad.gdb savecore: dumpdev /dev/console is tty; override kernel ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: Problem with ``build.sh install-image'' on amd64 (with various *DEBUG* options)
This seems to have been pilot error on my part (failure to clean up properly after initial failure). On Fri, 15 Jan 2021, Paul Goyette wrote: On Fri, 15 Jan 2021, Paul Goyette wrote: I'm trying to build an install-image from a release that was built with MKDEBUG=yes MKKDEBUG=yes MKDEBUGLIB=yes all enabled. Oh, I also have the KERNEL_DIR=yes option enabled. I was not too surprised when nbmakefs complained that the file system required size of 1515634688 (1450 MB) exceeded the configured size of 1488977920 (1420 MB) - an increase of 30 MB. So I changed distrib/amd64/installimage/Makefile to change INSTIMAGEMB from 1550 to 1580 (an increase of 30 MB). Now, I'm getting an error from nbgpt which I don't know how to resolve: ... rm -f work.efi /build/netbsd-local/tools/x86_64/amd64/bin/nbmakefs -M 128m -m 128m -B 1234 -t msdos -o F=32,c=1 work.efi work.efidir Creating `work.efi' work.efi: 258078 sectors in 258078 FAT32 clusters (512 bytes/cluster) MBR type: 11 bps=512 spc=1 res=32 nft=2 mid=0xf0 spt=63 hds=255 hid=0 bsec=262144 bspf=2017 rdcl=2 infs=1 bkbs=2 Populating `work.efi' Image `work.efi' complete create GPT image... dd if=work.mbr of=work.gpt skip=$((3235840 - 2048)) count=2048 0+0 records in 0+0 records out 0 bytes transferred in 0.001 secs (0 bytes/sec) cat work.mbr.truncated work.efi imgroot.fs work.gpt > work.img /build/netbsd-local/tools/x86_64/amd64/bin/nbgpt work.img biosboot -i 2 -c /build/netbsd-local/obj/amd64/distrib/amd64/installimage/work/usr/mdec/gptmbr.bin nbgpt: work.img: No secondary GPT header; run recover *** Failed target: NetBSD-9.99.77-amd64-install.img Any clues on how to fix this? ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+ !DSPAM:6001b22218604175613795! ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
