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 [3.8521542] root device: acpibat0: normal capacity on 'charge state' [469.5199856] use one of: re0 athn0 ddb halt reboot [469.5199856] root device: ```

@"anarchosax"#p14099 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"#p14101 [Here](https://pastebin.com/0Jn77bnK) 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"#p14099 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"#p14108 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"#p14107 I wasn't able to retrieve anything from the hard disk, which I presume is wd0. Actually it's `dk0`. From your `dmesg` output: ```text [ 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 ``` > @"anarchosax"#p14107 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: 1. Choose the correct [USB image](http://nycdn.netbsd.org/pub/NetBSD-daily/netbsd-10/latest/images/). There are 2 install images: a BIOS-only image and a standard one. Use the latter. 2. Turn off any CSM (BIOS compatibility mode) in the UEFI BIOS to not confuse the installer. 3. Create a (U)EFI ESP partition for the bootloader files. > @"pin"#p14108 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 ` 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"#p14110 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 ``` 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"#p14110 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"#p14111 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"#p14110 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](https://daemonforums.org/showthread.php?p=71528) 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**?

> @"pin"#p14113 Would you care to describe the details associated with this? Oh, that's simple enough: ```sh /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"#p14113 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"#p14113 [This](https://daemonforums.org/showthread.php?p=71528) didn't work. Tell me what you want done and I can post instructions... > @"pin"#p14113 `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"#p14113 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 `lseek`ing past their last byte and then writing.) > @"pin"#p14113 [...] 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: ```sh 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.)

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

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

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

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