I experienced similar problems with NetBSD 9.3 amd64 BIOS version, so CD_ROM and card reader are disabled. Having learned from past experience, I zeroed out the hard disk using dd. The install went without a problem. Unfortunately I am unable to boot into the system to look at dmesg or use sysinst. The computer is a Dell Vostro 3350 i7 laptop with a 1.8 TB hard disk. The errors at boot are as follows: [3.8521542] swwdog0: software watchdog initiatlized [3.8521542] WARNING: 1 error whilee detecting hardware; check system log. [3.8521542] boot device <unknown> [3.8521542] root device: acpibat0: normal capacity on 'charge state' [469.5199856] use one of: re0 athn0 ddb halt reboot [469.5199856] root device: if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); }

anarchosax Can you drop into the command-line from the USB-installer and retrieve /boot.cfg and /etc/fstab from the HDD? Post the dmesg output also (On NetBSD, the same kernel is used for both installation and normal use, so the messages will roughly be the same.) And, if you can update your BIOS, do so.

rvp Here is dmesg. Unfortunately, I wasn't able to retrieve anything from the hard disk, which I presume is wd0. I have tried using the usual mount command, as in: # mount -t ext2fs /dev/wd0 /mnt/hd but it is clear that I have got something wrong with the partition type and / or mount point. I also tried ffs, lfs, as well as mount without specifying a partition type...

anarchosax I zeroed out the hard disk using dd Not related to your issue but doing this is a waste of your time. It's enough to zero out the first Mb of the disk. If you feel unsure, zero out the first two or three Mb.

pin I have speculated about that as well, however it is always a step forward when a problem can be identified, particularly as I used three hours computer time zeroing out the disk before the install. Personally, I think that the issue may have something to do with the entropy section of the install. In my case, I copied over the result of the command by hand, from another computer. The instructions state that after you have completed your input, you need to return and refresh, I believe was the term that was used. However, I was never provided with an opportunity to return to the entropy section to refresh the key (?) data (?) and I couldn't find any relevant section in either the utility or config menu in sysinst.

anarchosax I wasn't able to retrieve anything from the hard disk, which I presume is wd0. Actually it's dk0 . From your dmesg output: [ 2.245912] wd0: GPT GUID: 20fedeae-8e96-4489-83b8-02f5556d2730 [ 2.245912] dk0 at wd0: "83c710bb-b1ff-43c3-b596-39825bf37ea1", 3890440192 blocks at 2048, type: ffs [ 2.245912] dk1 at wd0: "6c04e87c-8f3c-4363-b484-af10e2e98af7", 16586895 blocks at 3890442240, type: swap if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } anarchosax I also tried ffs, lfs, as well as mount without specifying a partition type... The native partition type is ffs , but, on NetBSD (esp. with UEFI partitions, you can omit the type: the system will infer the correct type from the GPT table--as seen above) OK, I can tell you why your system won't boot, but, not how you got there: On GPT partitioned disks, NetBSD creates wedges for each partition in the GPT: dk0 , dk1 , ... as seen above. On MBR partitioned disks, NetBSD creates slices for each partition defined in the (NetBSD) disklabel: wd0a , wd0b , ... for ATA disks (SCSI disks would go: sdNa , etc. where N is a disk number.) It looks like you have a GPT-partitioned disk, but, for a UEFI BIOS to boot from this disk, you need an additional ESP partition--an MS-DOS or VFAT formatted partition--containing the \EFI\BOOT\BOOTX64.EFI , or, \EFI|BOOT\BOOTIA32.EFI UEFI bootloader files. This doesn't exist and, I don't know why it wasn't created during your install. Try the install again, taking care to: Choose the correct USB image . There are 2 install images: a BIOS-only image and a standard one. Use the latter. Turn off any CSM (BIOS compatibility mode) in the UEFI BIOS to not confuse the installer. Create a (U)EFI ESP partition for the bootloader files. pin but doing this is a waste of your time. It's enough to zero out the first Mb of the disk. If you feel unsure, zero out the first two or three Mb. For OP's disk, with only NetBSD to be installed I agree. Zeroing-out the 1st MB would suffice. But, there is a caveat: if you want to install NetBSD in some existing free space on an already partitioned disk, you may have to zero-out the 1st MB of that free space too: I had bizarre issues with sysinst while trying to install a test NetBSD partition on some free space I had on my GPT disk. I had previously created (and deleted) other partitions in that same space and sysinst got horribly confused because it read some old data from that "free" space (I guess because it uses gpt -b <blocknr> for some of these operations). I only got sysinst to work by wiping the "free" space--which is not easy because, well, free space doesn't have a wedge associated with it so you can't go dd if=/dev/zero of=/dev/rdkN bs=1m count=1 . You first have to create a wedge, wipe it, then delete it. (The other alternative is to calculate the correct offset for a dd seek=NN , but, I get muddled with the difference between seek= and skip= and block numbers vs. sector nums. and other arcana...)

rvp I had bizarre issues with sysinst while trying to install a test NetBSD partition on some free space I had on my GPT disk. No shit, tell me about it. I had this nice layout with a working install /boot/efi/EFI 512Mb /Void Linux 10Gb Linux swap 10Gb Unlocated space 440Gb if(window.hljsLoader && !document.currentScript.parentNode.hasAttribute('data-s9e-livepreview-onupdate')) { window.hljsLoader.highlightBlocks(document.currentScript.parentNode); } I did a semi-automatic install of Void without installing Grub, then chrooted into the installed system from the live USB and installed rEFInd boot manager. After manually fixing fstab and pointing rEFInd to the installed kernel (by default it will be set to boot the live USB kernel), I had a Grub-free working system. Then I installed NetBSD-HEAD to the free space telling sysinst not to install the bootloader. But, sysinst messed-up the disk geometry and wedges leaving the system unbootable. So yeah, no shit! 🙄 I've cleaned the disk which, now has only NetBSD on legacy mode. rvp I only got sysinst to work by wiping the "free" space--which is not easy because, well, free space doesn't have a wedge associated with it Too late 🙁

pin we should write something with NetBSD boot loader which can allow install of other OSes alongside like back in day Ubuntu did in windows. people could install Ubuntu within windows by having partition and auto bootmenu addition of ubuntu

rvp You first have to create a wedge, wipe it, then delete it. Would you care to describe the details associated with this? Mind you, the EFI implementation on my laptop is rather shitty, I have to specify a custom path to the .efi file, else it won't boot. This didn't work. First of all gparted can not create a FFSv2 partition but, most importantly dkctl wd0 listwedges simply says there are no wedges. Or, maybe this is exactly what you found out in your try above. EDIT: with the risk of hijacking this post, dd seek looks rather useful but, you better get your maths right, e.g. dd if=/dev/zero bs=4096 seek=7 count=2 of=??? will write zeros starting at 7*4096 or, 28672Mb. I would need to be rather accurate to figure out what to write for my 512Mb + 10Gb + 10Gb Besides, I still need to write it to ... where ?

NetBSD 10 BETA amd64 refuses to boot after hard disk install.

Jay Maybe ...

rvp

pin Would you care to describe the details associated with this?

Oh, that's simple enough:

/tmp# gpt show -l wd0
      start       size  index  contents
          0          1         PMBR
          1          1         Pri GPT header
          2         32         Pri GPT table
         34       2014         Unused
       2048     614400      1  GPT part - EFI
     616448    1228800      2  GPT part - Basic data partition
    1845248     262144      3  GPT part - Microsoft reserved partition
    2107392       8192      4  GPT part - FreeBSD_EFI
    2115584  104857600      7  GPT part - FreeBSD_13.1
  106973184    8390656      8  GPT part - FreeBSD_swap
  115363840      16384      9  GPT part - NetBSD_EFI
  115380224   41943040     10  GPT part - NetBSD_main
  157323264   10485760     11  GPT part - NetBSD_swap
  167809024   20971520     12  GPT part - Linux_backup
  188780544      16384     13  GPT part - OpenBSD_EFI
  188796928   62914560     14  GPT part - OpenBSD_7.2
  251711488  104857600     15  GPT part - NetBSD_test
  356569088   19470336         Unused
  376039424    8388608      5  GPT part - Ubuntu_swap
  384428032  592343040      6  GPT part - Ubuntu_19.04
  976771072       2063         Unused
  976773135         32         Sec GPT table
  976773167          1         Sec GPT header
/tmp# gpt add -a 1m -l NetBSD_xxx -s 10m wd0
/dev/rwd0: Partition 16 added: 49f48d5a-b10e-11dc-b99b-0019d1879648 356569088 20480
/tmp# gpt show -i 16 wd0
Details for index 16:
Start: 356569088 (170G)
Size: 20480 (10M)
Type: ffs (49f48d5a-b10e-11dc-b99b-0019d1879648)
GUID: 00000000-0000-0000-0000-000000000000
Label: NetBSD_xxx
Attributes: None
/tmp# dkctl wd0 listwedges
/dev/rwd0: 16 wedges:
dk0: EFI, 614400 blocks at 2048, type: msdos
dk1: Basic data partition, 1228800 blocks at 616448, type: 
dk2: Microsoft reserved partition, 262144 blocks at 1845248, type: 
dk3: FreeBSD_EFI, 8192 blocks at 2107392, type: msdos
dk6: FreeBSD_13.1, 104857600 blocks at 2115584, type: ffs
dk7: FreeBSD_swap, 8390656 blocks at 106973184, type: swap
dk8: NetBSD_EFI, 16384 blocks at 115363840, type: msdos
dk9: NetBSD_main, 41943040 blocks at 115380224, type: ffs
dk10: NetBSD_swap, 10485760 blocks at 157323264, type: swap
dk11: Linux_backup, 20971520 blocks at 167809024, type: ext2fs
dk12: OpenBSD_EFI, 16384 blocks at 188780544, type: msdos
dk13: OpenBSD_7.2, 62914560 blocks at 188796928, type: 
dk14: NetBSD_test, 104857600 blocks at 251711488, type: ffs
dk15: NetBSD_xxx, 20480 blocks at 356569088, type: ffs
dk4: Ubuntu_swap, 8388608 blocks at 376039424, type: 
dk5: Ubuntu_19.04, 592343040 blocks at 384428032, type: ext2fs
/tmp# dd if=/dev/zero of=/dev/rdk15 bs=1m
dd: /dev/rdk15: end of device
11+0 records in
10+0 records out
10485760 bytes transferred in 0.417 secs (25145707 bytes/sec)
/tmp# gpt remove -L NetBSD_xxx wd0
/dev/rwd0: Partition 16 removed
/tmp# ^D

pin I have to specify a custom path to the .efi file, else it won't boot.

Yeah. Same on mine, but, that's OK--it's a one time setup.

pin This didn't work.

Tell me what you want done and I can post instructions...

pin dd seek looks rather useful but, you better get your maths right,

Oh yeah! You'll trash some partition if you're off by even a single sector--which is why I avoid this method.

pin Besides, I still need to write it to ... where?

wd0--the whole disk.

You can't use any other device here because the kernel checks the start/end of any lseek/read/write operations on devices. (Regular files, you can extend by lseeking past their last byte and then writing.)

pin [...] will write zeros starting at 7*4096 or, 28672Mb.

Correct, but, to preserve sanity, I prefer to not fiddle with bs=. The default for bs is 512 bytes and (logical) sectors on a disk are also the same size, so you can just use some command-line arithmetic for the count= argument. For example:

dd if=/dev/zero of=/dev/rwd0 oseek=NNNNN count=$(( (10*1024*1024) / 512 ))

That will write 10MB worth of sectors starting at sector no. NNNNN--which you can take directly from a gpt show output. (And, writing 10MB 512-blocks at a time is acceptable.)

rvp Arghh, I see what the problem is now 👿

If you want to know, I used gparted to pre-make the partitions and gparted only boots in legacy mode on this machine.

Then, I installed Void in EFI mode but, of course the partition table is not GPT, as it was created in legacy mode. I should have formated the disk from the Void image to create a GPT partition table.

No wonder gpt show -l wd0 and dkctl wd0 listwedges output nothing. 🤦‍♂️

rvp Tell me what you want done and I can post instructions

I guess there's no need for it anymore but, honestly I don't know if I have the patience to start everything from scratch. I'm no longer using pre-compiled binaries, instead I'm building everything from source, and I'm only missing a web-browser.

If I start from scratch, it's at least a couple of days work and compile to get back to where I'm now 😫

anarchosax

After having zeroed out the hard disk, I again installed the NetBSD 10 amd64 BETA system, only to again be met by a similar set of messages to what this thread started with (first post). I have again posted dmesg here. I am again unable to boot into the system at all, so the dmesg is (again) from the install USB. Not sure where to go from here. Odd that there are so many problems compared to NetBSD 9.3, but I guess that is why it is beta...

rvp

anarchosax I am again unable to boot into the system at all

Not surprising. Looks like there are no wedges on wd0 at all. Which disk did you install onto?

[     2.092450] wd0 at atabus0 drive 0
[     2.092450] wd0: <ST2000LM007-1R8174>
[     2.092450] wd0: drive supports 16-sector PIO transfers, LBA48 addressing
[     2.092450] wd0: 1863 GB, 4134422 cyl, 15 head, 63 sec, 512 bytes/sect x 3907029168 sectors (4096 bytes/physsect; first aligned sector: 8)
[     2.222450] wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100), WRITE DMA FUA, NCQ (32 tags)
[     2.252450] wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) (using DMA), NCQ (31 tags)

There are 2 wedges on one of your USB storage devices, but, I assume this is the installer disk.

[     3.852444] sd0 at scsibus0 target 0 lun 0: <Generic, Flash Disk, 8.07> disk removable
[     3.852444] sd0: fabricating a geometry
[     3.852444] sd0: 59200 MB, 59200 cyl, 64 head, 32 sec, 512 bytes/sect x 121241600 sectors
[     3.852444] sd0: fabricating a geometry
[     3.872443] sd0: GPT GUID: 935e6375-7b84-4ebf-a950-39c26c9746bc
[     3.872443] dk0 at sd0: "EFI system", 262144 blocks at 2048, type: msdos
[     3.872443] dk1 at sd0: "f35c4b2b-0e43-4ba8-ade9-fa7bb3864b72", 4853760 blocks at 264192, type: ffs

anarchosax

rvp This is particularly a problem with 10 beta, but has also occurred with 9.3. This computer is particularly finicky with NetBSD, and why I end up spending so much time zeroing out the data between installs. I used to experience similar problems with installing Linux many moons ago, and it drove people crazy. It is a BIOS computer, but gives off a GPT vibe for some older installers. Nothing to adjust in the BIOS.

I installed on wd0.

rvp

anarchosax It is a BIOS computer, but gives off a GPT vibe

OK. Help sysinst out by creating GPT partitions then. In the installer, drop into a command prompt, then create 3 partitions: EFI ESP (VFAT-formatted for the bootloader files), NetBSD swap, NetBSD FFS. Then Ctrl-D back into the installer and install onto the FFS wedge you just created. sysinst should do the rest.

Something like this should work:

# Create GPT
gpt create -A wd0

# Add EFI ESP (formatted later)
gpt add -a 1m -i 1 -s 300m -t efi -l NetBSD_EFI wd0
gpt biosboot -L NetBSD_EFI wd0      # XXX: needed on UEFI?

# Add NetBSD swap
gpt add -a 1m -i 2 -s 16g -t swap -l NetBSD_swap wd0

# Add NetBSD /
gpt add -a 1m -i 3 -s 100g -l NetBSD_root wd0
gpt set -a bootme -i 3 wd0         # XXX: needed?

# List wedges to find out the wedge device of the `NetBSD_EFI' partition
# we created earlier as newfs_msdos does not understand the
# NAME=LABEL/UUID syntax.
dkctl wd0 listwedges

# Replace NN with the no. of the wedge device with GPT label `NetBSD_EFI'
newfs_msdos /dev/rdkNN

# Copy UEFI bootloader files
mount -t msdos NAME=NetBSD_EFI /targetroot
mkdir -p /targetroot/EFI/boot
cp -v /usr/mdec/*.efi /targetroot/EFI/boot
umount /targetroot

# Format / (probably not needed)
newfs -O 2 NAME=NetBSD_root

Adjust the sizes as necessady, of course.

anarchosax

rvp # Create GPT
gpt create -A wd0

This command refuses to do anything, saying that it detects an MBR. I have again checked the computer BIOS, and there is no UEFI anything, no CSM or "legacy boot" entry.

rvp

anarchosax This command refuses to do anything, saying that it detects an MBR.

Use the -f (force) command. As the gpt says:

     gpt create [-AfP] [-p partitions]
             The create command allows the user to create a new (empty) GPT.
             By default, one cannot create a GPT when the device contains a
             MBR, however this can be overridden with the -f option.  If the
             -f option is specified, an existing MBR is destroyed and any par-
             titions described by the MBR are lost.

anarchosax A reinstall of NetBSD 10 BETA amd64 over the Linux install

I can't figure out what "directly over" a Linux install means here. There are many ways this could not work as you expected it to. Using the USB install image, can you post the output of:

fdisk wd0
disklabel wd0
gpt show -l wd0
sysctl machdep.bootmethod

We may be able to make that NetBSD install boot.

anarchosax

I just installed Q4OS, a Debian Linux derivative on the Vostro, and there was absolutely no problem installing at all. My working assumption is that this is something related directly to the sysinst.

A reinstall of NetBSD 10 BETA amd64 over the Linux install, gave all of the correct signals regarding registering the MBR, and the setup of the slices/partitions. The install went perfectly, but when I attempted to boot into the newly installed NetBSD system, the same problem occurred again…

Edit—-
I have now used nwipe, dd zeroing of the hard disk, and installing NetBSD 10 BETA amd64 directly over a Linux install. sysinst has consistently refused to cooperate in all scenarios…

anarchosax

rvp Use the -f (force) command.

OK, I added the -f flag and went through your instructions. Everything appeared to function without a problem. I reentered the installer. At "What would you like to do?", I chose "a: Use existing GPT partitions". NetBSD_root is shown with the flags "I" and "B". I added "mount point: /", but otherwise left the "current values" for the partition without changing anything (else). I then choose "Partition sizes ok". I then choose to install NetBSD on wd0. I get the following:

Status: Finished
Command: /sbin/fsck_msdos -p -q /dev/dk3
Hit enter to continue

Which I do. Then I get the following:

Status: Command failed
Command: /sbin/mount -tmsdos /dev/dk3 /targetrootNO NAME
Hit enter to continue

On the next screen I get:

mount of device /dev/dk3 on NO NAME failed

Edit---
Interestingly, I exited sysinst to the command line again and ran:
dkctl wd0 listwedges
as I thought that maybe the numbering of the partitions had changed. The response that I got was:
/dev/rwd0: no wedges configured
Reentering sysinst, the "GPT partitions for wd0" are still listed.

rvp

anarchosax NetBSD_root is shown with the flags "I" and "B".

Try removing the B flag from that partition.

With the commands I provided, we've already done everything needed for the UEFI BIOS to boot the kernel. In fact, if you copy a /boot.cfg, and /netbsd to dk3, the kernel should load. Then it will panic because /bin/init is missing.

If you need to start from scratch (not needed really, just the newfs stuff will suffice now-- and even that can be skipped because nothing was written by sysinst so far.), do:

gpt destroy wd0

rvp

OK, I did 3 different installs onto another USB flash drive.

UEFI mode, after wiping 1MB at the beginning and the end of the drive (to erase any secondary GPT)

Told sysinst to use the standard partition sizes. In the screen which it presented, I reduced the size of the msdos (UEFI ESP) and swap partitions (4MB and 50MB resp.--the flash drive is only 500MB). Chose a minimal install, and everything went fine. Could boot directly from the USB flash drive.

UEFI mode. told sysinst to use the existing GPT partitions.

Made sure to do a newfs (as indicated by the N flag) for both the msdos and / partitions.
This too worked just fine.

CSM (BIOS) mode (verified using machdep.bootmethod) after wiping drive.

sysinst naturally wanted to create an MBR here. I told it I wanted GPT. This time it only created 2 partitions instead of 3: / and swap. Didn't let me add an msdos partition; and I told it to skip installing any rubbish bootblocks(why? I told you I wanted GPT...)

As expected, with no ESP containing the UEFI bootloader files, and no MBR bootblocks either, the drive didn't boot. But, this is GPT, so it's easy to fix: Deleted swap, made it smaller, squeezed in a small 4MB UEFI ESP partition, formatted it, copied the /usr/mdec/boot*.efi files into /efi/boot/. and hey presto! now it's a bootable drive.

So, my question is: what does

sysctl machdep.bootmethod

print on this system of yours?

anarchosax

rvp
Still unable to install a system.
I went through the entire process again, and everything looks as it should, as far as I can see. I am again using "existing GPT partitions".

sysctl machdep.bootmethod gives me:
machdep.bootmethod = BIOS

The NetBSD_root keeps reappearing as a partition to boot, even when the "boot" flag is removed. I assume the problem lies somewhere with the NetBSD_EFI partition:

NetBSD_EFI
type: MSDOS
mount: Yes
mount options: 
mount point: /NO NAME
Label: NetBSD_EFI

My knee jerk reaction is to change "mount point" to /EFI/boot, but I am not really sure what is going on here:

rvp sysinst naturally wanted to create an MBR here. I told it I wanted GPT. This time it only created 2 partitions instead of 3: / and swap. Didn't let me add an msdos partition; and I told it to skip installing any rubbish bootblocks(why? I told you I wanted GPT...)

As expected, with no ESP containing the UEFI bootloader files, and no MBR bootblocks either, the drive didn't boot. But, this is GPT, so it's easy to fix: Deleted swap, made it smaller, squeezed in a small 4MB UEFI ESP partition, formatted it, copied the /usr/mdec/boot*.efi files into /efi/boot/. and hey presto! now it's a bootable drive.

rvp

anarchosax sysctl machdep.bootmethod gives me:
machdep.bootmethod = BIOS

If bootmethod is BIOS, then don't create GPT partitions on this system. Go for an MBR (+disklabel) install.

anarchosax My knee jerk reaction is to change "mount point" to /EFI/boot, but I am not really sure what is going on here:

What that means is:

a) If bootmethod = BIOS, then sysinst prefers to create MBR partitions, and botches a GPT installed if forced to.

b) My firmware boots fine with either partitioning scheme (GPT or MBR) in both UEFI and CSM (ie. BIOS) modes, so fixing sysinst's mistakes was easy.

anarchosax I rebooted the system, configured the system, and on a second reboot - I am back to where I was before. The system refuses to boot again, with the same error messages.

This puzzles me. Why fail on the second boot?

Since your machdep.bootmethod is BIOS, do an MBR install now. Forget about GPT for now. (And, with the MBR partitioning scheme, you don't need any kind of MSDOS partition for the UEFI bootloader files. Just make sure to install the standard bootblocks--ie. let sysinst do its own thing.)
Can you take pictures of each of your BIOS setup "pages"?
And also, make a short movie of the screen when the system refuses to boot? Use the highest resolution and the highest frame rate possible. I want to see if there are any other messages from the OS when it tries to boot from the disk (instead off of the USB flash).

Send both to me (same username as here) c/o SDF punto ORG

anarchosax

*#%! I changed the mount point, I got the system installed, I rebooted the system, configured the system, and on a second reboot - I am back to where I was before. The system refuses to boot again, with the same error messages.

anarchosax

Hmm. Now this is very interesting. I was so busy futzing around with taking pictures, that I forgot to install pkgin and pkgsrc. As long as I didn't install either, the system functioned without problems. As soon as I installed them using sysinst, all of a sudden, I could no longer boot from the hard disk. The boot process can no longer find the disk.

Google Drive

rvp

anarchosax I forgot to install pkgin and pkgsrc. As long as I didn't install either, the system functioned without problems.

No it's nothing to do with pkgin or pkgsrc. I know exactly what's going on. In the movie you can see this:

[...]
ahcisata0: port 0: device present, speed: 6.0Gb/s
ahcisata0 port 0: setting WDCTL_RST failed for drive 0
[...]

In the 10.x branch, various delays in the kernel were shortened to speed-up the boot process. Most devices work fine with the shorter delays, but, some old HW doesn't. The HDD in my own laptop used to fail sporadically like this before I patched it. Compile a kernel with this patch (make sure you copy it exactly--tabs shouldn't be changes to spaces, for instance):

ahcisata_pci.diff

--- ahcisata_pci.c.orig	2022-10-12 12:50:02.000000000 +0000
+++ ahcisata_pci.c	2023-03-05 07:45:49.724994000 +0000
@@ -206,6 +206,8 @@
 	    AHCI_QUIRK_BADPMP },
 
     /* extra delay */
+	{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_6SERIES_AHCI_2,
+	    AHCI_QUIRK_EXTRA_DELAY },
 	{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_C600_AHCI,
 	    AHCI_QUIRK_EXTRA_DELAY },
 	{ PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_7SER_MO_SATA_AHCI,

(I'll send this patch in also when I get the time.)

Apply as user bld:

cd /usr/src/sys/dev/pci/			# move to correct dir.
patch -p0 -C < /tmp/ahcisata_pci.diff		# check if patch applies
patch -p0 -Vnone < /tmp/ahcisata_pci.diff	# apply patch for real

anarchosax

rvp (I'll send this patch in also when I get the time.)

I had been waiting with this issue until I had a successful compile on my Huawei, but as that isn't the case yet, I will try with the Dell. I downloaded the latest NetBSD-10.0_BETA-amd64-install.img (17 March). Has your patch been folded into the code yet, or should I prepare for compiling the kernel? I ask mainly, so that I try to avoid a reboot and loose the ability of booting into the system again, after the new install...

rvp

anarchosax Has your patch been folded into the code yet [...]?

No. You have to tell me that it works first...

EDIT: Try the kernel here. It is the latest -HEAD GENERIC with the amdgpu DRMKMS driver and the AHCI driver patch compiled in. (There are also 2 kernel files with the debugging symbols left in--in case the kernel blows up and you have to send backtraces in the bug report.)

« Previous Page