NetBSD Problem Report #49470
From www@NetBSD.org Sun Dec 14 18:52:26 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id E38F6A5809
for <gnats-bugs@gnats.NetBSD.org>; Sun, 14 Dec 2014 18:52:25 +0000 (UTC)
Message-Id: <20141214185223.7D34AA6567@mollari.NetBSD.org>
Date: Sun, 14 Dec 2014 18:52:23 +0000 (UTC)
From: tuotila@gmx.com
Reply-To: tuotila@gmx.com
To: gnats-bugs@NetBSD.org
Subject: NetBSD 7 BETA reboots after bootloader (HP 2133)
X-Send-Pr-Version: www-1.0
>Number: 49470
>Category: port-amd64
>Synopsis: NetBSD 7 BETA reboots after bootloader (HP 2133)
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: andvar
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Dec 14 18:55:00 +0000 2014
>Closed-Date: Wed Sep 04 03:53:58 +0000 2024
>Last-Modified: Wed Sep 04 03:53:58 +0000 2024
>Originator: Terho Uotila
>Release: 7.0_BETA 201412140250Z and earlier
>Organization:
>Environment:
Linux h2133 3.2.0-4-686-pae #1 SMP Debian 3.2.63-2+deb7u1 i686 GNU/Linux
(from different OS on same machine)
>Description:
Trying to install 7.0 beta i386 using usb image on HP 2133 Mini-Note, boot loader works as expected, but after spinners have finished and green text should appear, screen blanks instead and then machine reboots (or power cycles, whichever is correct term, if there's difference)
All 3 install menu options have same result (normal, no acpi, no acpi+no smp).
Cpu is VIA C7-M, which should be i386 compatible (and indeed, at least Debian works, see uname above, as well as original Windows Vista)
>How-To-Repeat:
Boot install media from usb stick or sd card
>Fix:
>Release-Note:
>Audit-Trail:
From: Kaz Blocks <kazbloxmc@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/49470
Date: Fri, 6 Jul 2018 18:06:10 -0400
--00000000000013395405705bdf9c
Content-Type: text/plain; charset="UTF-8"
Still happens as of NetBSD 8.0 with the USB installer image for the second
release candidate. I'm ticked off at why this issue maybe happening.
--00000000000013395405705bdf9c
Content-Type: text/html; charset="UTF-8"
<div dir="ltr">Still happens as of NetBSD 8.0 with the USB installer image for the second release candidate. I'm ticked off at why this issue maybe happening.<br></div>
--00000000000013395405705bdf9c--
From: Kaz Blocks <kazbloxmc@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/49470
Date: Fri, 6 Jul 2018 18:30:42 -0400
--000000000000d53d1e05705c36f3
Content-Type: text/plain; charset="UTF-8"
I think I found the cause. This appears to be a native boot issue! Booting
through the Multiboot protocol via any supported loader has no issues
whatsoever. From here on, I can install NetBSD 8.
--000000000000d53d1e05705c36f3
Content-Type: text/html; charset="UTF-8"
<div dir="ltr">I think I found the cause. This appears to be a native boot issue! Booting through the Multiboot protocol via any supported loader has no issues whatsoever. From here on, I can install NetBSD 8.<br></div>
--000000000000d53d1e05705c36f3--
From: Matthias Petermann <mp@petermann-it.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP Compaq
6005 Pro / AMD Phenom II)
Date: Mon, 9 Dec 2019 10:21:30 +0100
Hello,
actually one of my questions was stupid - sure I should connect a serial
console which I did now.
It prints to com1 before it reboots:
> boot
command(s): rndseed /var/db/entropy-file;boot
default boot twice, skipping...
18611144+666816+1430336 [886041+1244328+888626]=0x16e1aa8
WARNING: couldn't open /var/db/entropy-file
WARNING: 1 module failed to load
How do I find out which module failed to load here?
Kind regards
Matthias
From: Matthias Petermann <mp@petermann-it.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP Compaq
6005 Pro / AMD Phenom II)
Date: Mon, 9 Dec 2019 13:16:42 +0100
This is the message I sent before (forgot to put the Re: in front of the
subject)
---
Hello,
while researching a boot problem I came across this bug report. It
pretty much describes the same problem that I observed with NetBSD
9.0_RC1 on a slightly old HP Compaq 6005 Pro desktop with AMD Phenom II
cpu. I have already removed all additional cards, swapped RAM, started
without disks, reset BIOS to default values and turned off everything
exotic - nothing helps. Is this type of problem specific to HP machines,
or rather generic? Is there anything else that you can try besides using
another bootloader? Is it worth it to try to boot NetBSD with a serial
console on this device, or is that too early to even see anything on the
console? The device has in principle a serial interface on board.
I'm aware that debugging hardware that you do not have on-site is
difficult and time-consuming. I do not expect anyone else to spend a lot
of time here either. I would be interested anyway why exactly this
device makes such problems, possibly fix it and learn something on
NetBSD. So I will be very thankful for any pointers.
Kind regards
Matthias
From: Andrius V <vezhlys@gmail.com>
To: Matthias Petermann <mp@petermann-it.de>
Cc: Paul Goyette <paul@whooppee.com>, install-manager@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP Compaq
6005 Pro / AMD Phenom II)
Date: Mon, 9 Dec 2019 23:08:08 +0200
Hi,
It is quite unlikely that your issue is related to the original bug
report since hardware was VIA based (VIA C7-M+VN896) HP 2133 netbook.
The typical actions I would try to do: 1) boot without ACPI/SMP
enabled (boot -12) 2) if you're booting using USB media, you can try
to change some relevant USB options (speed let's say, depends on BIOS)
or try to boot from non USB media (CD, netboot or install it to HDD on
the compatible machine and attach it to your system). If any of those
boot, you can check dmesg output for potentially unsupported hardware.
Finally you can try to boot older releases to see if it worked before.
Otherwise you are probably out of luck (playing with some BIOS options
like switching between AHCI/IDE modes may help but not necessarily).
P.S. gnats-bugs@netbsd.org should be added as one of email addresses.
On Mon, Dec 9, 2019 at 9:18 PM Matthias Petermann <mp@petermann-it.de> wrot=
e:
>
> resent mail, removed tuotila@gmx.com from cc (address seams to be not
> existing anymore)
>
> ---
>
> Hi,
>
> Am 09.12.2019 um 14:38 schrieb Paul Goyette:
> >> WARNING: 1 module failed to load
> >>
> >> How do I find out which module failed to load here?
> >
> > Almost certainly, this is a failure to load the ffs filesystem,
> > since the filesystem module is already built-in to the kernel.
> >
> > The message can safely be ignored.
>
> That's bad news ;-) So there is no known way to debug this further. I
> wish I had more knowledge on possible causes. The box boots without any
> issue into Slackware Linux. I should try a BIOS upgrade and/or try a
> NetBSD version older than the one where the issue was first reported.
>
> Kind regards
> Matthias
>
> --
> Matthias Petermann <mp@petermann-it.de> | www.petermann-it.de
> Innovative IT-L=C3=B6sungen, Systemintegration, Linux/FreeBSD/Unix-Suppor=
t
> Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 991
>
From: Matthias Petermann <mp@petermann-it.de>
To: Andrius V <vezhlys@gmail.com>
Cc: Paul Goyette <paul@whooppee.com>, install-manager@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP Compaq
6005 Pro / AMD Phenom II)
Date: Wed, 11 Dec 2019 09:48:58 +0100
This is a cryptographically signed message in MIME format.
--------------ms060002070308040909030109
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi Andrius,
thanks for your response. You are right, the issue maps not exactly to=20
the reported problem as a different CPU is installed.
Anyway, the following actions did not succeed so far:
- booting with boot -12
- booting from SATA hard drive with pre-installed NetBSD
- USB options not configurable in BIOS
- older Release NetBSD 6.0 did also not boot (hangs at the second=20
spinner 123456\ but does not reboot)
- switching from AHCI to legacy/native IDE mode
- Booting FreeBSD 11.2 also hangs in primary bootstrap
Especially the fact that FreeBSD doesn't boot either led me to [1]
I will try to find out if I get to the point where I could debug into=20
the kernel from my serial console...
Kind regards
Matthias
[1]=20
http://freebsd.1045724.x6.nabble.com/boot-hang-with-certain-Phenom-II-cpu=
-models-td6300528.html
Am 09.12.2019 um 22:08 schrieb Andrius V:
> Hi,
>=20
> It is quite unlikely that your issue is related to the original bug
> report since hardware was VIA based (VIA C7-M+VN896) HP 2133 netbook.
> The typical actions I would try to do: 1) boot without ACPI/SMP
> enabled (boot -12) 2) if you're booting using USB media, you can try
> to change some relevant USB options (speed let's say, depends on BIOS)
> or try to boot from non USB media (CD, netboot or install it to HDD on
> the compatible machine and attach it to your system). If any of those
> boot, you can check dmesg output for potentially unsupported hardware.
> Finally you can try to boot older releases to see if it worked before.
> Otherwise you are probably out of luck (playing with some BIOS options
> like switching between AHCI/IDE modes may help but not necessarily).
>=20
> P.S. gnats-bugs@netbsd.org should be added as one of email addresses.
>=20
>=20
>=20
> On Mon, Dec 9, 2019 at 9:18 PM Matthias Petermann <mp@petermann-it.de> =
wrote:
>>
>> resent mail, removed tuotila@gmx.com from cc (address seams to be not
>> existing anymore)
>>
>> ---
>>
>> Hi,
>>
>> Am 09.12.2019 um 14:38 schrieb Paul Goyette:
>>>> WARNING: 1 module failed to load
>>>>
>>>> How do I find out which module failed to load here?
>>>
>>> Almost certainly, this is a failure to load the ffs filesystem,
>>> since the filesystem module is already built-in to the kernel.
>>>
>>> The message can safely be ignored.
>>
>> That's bad news ;-) So there is no known way to debug this further. I
>> wish I had more knowledge on possible causes. The box boots without an=
y
>> issue into Slackware Linux. I should try a BIOS upgrade and/or try a
>> NetBSD version older than the one where the issue was first reported.
>>
>> Kind regards
>> Matthias
>>
>> --
>> Matthias Petermann <mp@petermann-it.de> | www.petermann-it.de
>> Innovative IT-L=C3=B6sungen, Systemintegration, Linux/FreeBSD/Unix-Sup=
port
>> Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 991
>>
--=20
Matthias Petermann <mp@petermann-it.de> | www.petermann-it.de
Innovative IT-L=C3=B6sungen, Systemintegration, Linux/FreeBSD/Unix-Suppor=
t
Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 991
--------------ms060002070308040909030109
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CyowggUSMIID+qADAgECAhEAirqoQ8X0aFKaaV1Hd5jsWzANBgkqhkiG9w0BAQsFADCBljEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAyMTQwMDAw
MDBaFw0yMDAyMTQyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEm1wQHBldGVybWFubi1pdC5k
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ89o28jLMDqxmqguWEXTStPuWpT
YLobZcPvsnkUZtwe08adQea0fiCqVfaXwoPea9daPzKPv1gdCT+EAbDiblHgUyGmWxQp4bVN
hSkjlYK01AQ4UhYHeMZDjxv+1OCKc2YBupsEwu2jcOgkKR4KYIwE3tGFeJQkbXhnn/m1ZMbm
le+Q5rmhuAVVu9s8MWsV0NSuUoArQDaG3+JwwiTndW3bpb6AvNoMZT63VFM8agpHkXmNn+Vb
+3fmyoooNos4W851B3Ggmryuz+qsXOtu1GzQMWlou6RI0c3L+w00zwWBFE/dgbfM1p9z7aMc
ihLj7EXbpOfCk4oIfTUC5BBv8fkCAwEAAaOCAcswggHHMB8GA1UdIwQYMBaAFAnA8vwL2pTb
X/4r36iZQs/J4K0AMB0GA1UdDgQWBBSoZTz69WkTCE3XK7Rzkv7xli5dnjAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwQAYD
VR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdv
LmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYB
BQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29S
U0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzAB
hhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAdBgNVHREEFjAUgRJtcEBwZXRlcm1hbm4taXQu
ZGUwDQYJKoZIhvcNAQELBQADggEBAKhczJE2bDol7fH5zA9khUMaWCUdIO4jc6aJofNd8e6L
pnShgpugjh7Vm7Z4sYIfzzcuetHkbkSRakMOHO8uw69vHcDHpwBbZ4iafy8sd11CTE5I6VN7
PUUa9eyprtqK5z29ts5sAVzL7uIk2UyZdSJ4ubiUiSZfL+4itvaaid0Vaoewyl31MHCFcgRa
tkBs8wDopVHlugaKKTmPfAvYap/VNm0+vsGHz+Nqh2xuy1M/DqjgcH04hYbf54Yk98Jm1lPG
hPNxSs8e3rExkRGxUMr8hrtOi1uD91qoTg0w++IxrhuCKcY+V/2nFkZLywG9+CMpMaYvbJ67
1tom4Ps/qsMwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqGSIb3DQEBDAUA
MIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5
IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRy
dXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAwMDBaFw0zMDEy
MzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMT
NVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno1jvm2pK/KxBO
qhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK8dtK56NCSrq4
iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0kN+oHox+L9aV1
rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee1sLTHsLtpiK9
OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8kHPo5fZl5u1B
0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAUU3m/WqorSs9U
gOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4GA1UdDwEB/wQE
AwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2NybC51c2Vy
dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHYGCCsG
AQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VTRVJU
cnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADdF9d6HBA4kMjj
sb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou74TZ/XTarHG8z
dMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0sZYx4rXD6+cq
Fq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJJIXwKjYA6VUR
/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUHxvBz9OfYWUiX
u09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZeroXaecG03i3m
M7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85F2w2ZpXfP+w8
q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymUE0pwi/KDaiYB
15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uYdBEQkkDc+lKB
1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe5W8mybM2JzGC
BDUwggQxAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz
dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV
BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAirqoQ8X0aFKaaV1Hd5jsWzANBglghkgBZQMEAgEFAKCCAlkwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjExMDg0ODU4WjAvBgkqhkiG9w0B
CQQxIgQg9d7vc0bbsSNi+gA1PSMZWxojIkPyaPO5n5aX4uSWWfowbAYJKoZIhvcNAQkPMV8w
XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvQYJKwYBBAGCNxAE
MYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw
DgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNl
Y3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA
irqoQ8X0aFKaaV1Hd5jsWzCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNV
BAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCKuqhDxfRoUpppXUd3mOxbMA0GCSqG
SIb3DQEBAQUABIIBAHoXCTjY+dZZrD4lgDHgz7XK0HqAlh/t1cdd2UMb3pYH3IUV6UjvvbIt
6j/i1ENDork7DnjMNA7RPvup6JMUtXG1cubKisN4mF6t7ez2ZWNyRao8crL6E2HLk+YZWSl3
U9f7dr5q4b2NrDlxrKjSZeJWMdvGm/m627lalekFIONmNzi5MZrRy47Sr2uObqDZWCsv6Q2j
X5XC2e2tzAla91WAgYUr/S/X1lS8KtFpgzxFskCbTTxiUGFBdGTdGnhgrHjVHxpFpSfsk9AI
r4dV8pvTWg666c9MbCmcEesgTLOlshRcVLYc6P/I9M6NQJnmF671PHM2pC26ukQvC3x8lvsA
AAAAAAA=
--------------ms060002070308040909030109--
From: Andrew Doran <ad@netbsd.org>
To: Matthias Petermann <mp@petermann-it.de>
Cc: Andrius V <vezhlys@gmail.com>, Paul Goyette <paul@whooppee.com>,
install-manager@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP
Compaq 6005 Pro / AMD Phenom II)
Date: Wed, 11 Dec 2019 10:59:09 +0000
Hi,
I understand it's quite difficult to do if you don't have a working build
environment, and getting the kernels in place is tough too, but assuming
that your machine actually gets into the kernel and crashes there rather
than the boot loader, and you are determined to find the problem...
If I wanted to debug this I would try sprinkling printf()s in the kernel's
main() in src/sys/kern/init_main.c, after the call to consinit().
If a machine does not even get that far, or it reboots so quickly that the
messages cannot be read, I keep this assembly function around to dump into
src/sys/arch/amd64/amd64/locore.S (or i386, it should assemble correctly on
both) and then call it from C code. It produces long beeps from the speaker
and by counting the beeps and following a process of approximate bisection I
can figure out where it's going wrong.
http://www.netbsd.org/~ad/keep/beep.S
It is an awful lot of work though...
Andrew
On Wed, Dec 11, 2019 at 09:48:58AM +0100, Matthias Petermann wrote:
> thanks for your response. You are right, the issue maps not exactly to the
> reported problem as a different CPU is installed.
>
> Anyway, the following actions did not succeed so far:
>
> - booting with boot -12
> - booting from SATA hard drive with pre-installed NetBSD
> - USB options not configurable in BIOS
> - older Release NetBSD 6.0 did also not boot (hangs at the second spinner
> 123456\ but does not reboot)
> - switching from AHCI to legacy/native IDE mode
> - Booting FreeBSD 11.2 also hangs in primary bootstrap
>
> Especially the fact that FreeBSD doesn't boot either led me to [1]
>
> I will try to find out if I get to the point where I could debug into the
> kernel from my serial console...
>
> Kind regards
> Matthias
>
>
> [1] http://freebsd.1045724.x6.nabble.com/boot-hang-with-certain-Phenom-II-cpu-models-td6300528.html
>
> Am 09.12.2019 um 22:08 schrieb Andrius V:
> > Hi,
> >
> > It is quite unlikely that your issue is related to the original bug
> > report since hardware was VIA based (VIA C7-M+VN896) HP 2133 netbook.
> > The typical actions I would try to do: 1) boot without ACPI/SMP
> > enabled (boot -12) 2) if you're booting using USB media, you can try
> > to change some relevant USB options (speed let's say, depends on BIOS)
> > or try to boot from non USB media (CD, netboot or install it to HDD on
> > the compatible machine and attach it to your system). If any of those
> > boot, you can check dmesg output for potentially unsupported hardware.
> > Finally you can try to boot older releases to see if it worked before.
> > Otherwise you are probably out of luck (playing with some BIOS options
> > like switching between AHCI/IDE modes may help but not necessarily).
> >
> > P.S. gnats-bugs@netbsd.org should be added as one of email addresses.
> >
> >
> >
> > On Mon, Dec 9, 2019 at 9:18 PM Matthias Petermann <mp@petermann-it.de> wrote:
> > >
> > > resent mail, removed tuotila@gmx.com from cc (address seams to be not
> > > existing anymore)
> > >
> > > ---
> > >
> > > Hi,
> > >
> > > Am 09.12.2019 um 14:38 schrieb Paul Goyette:
> > > > > WARNING: 1 module failed to load
> > > > >
> > > > > How do I find out which module failed to load here?
> > > >
> > > > Almost certainly, this is a failure to load the ffs filesystem,
> > > > since the filesystem module is already built-in to the kernel.
> > > >
> > > > The message can safely be ignored.
> > >
> > > That's bad news ;-) So there is no known way to debug this further. I
> > > wish I had more knowledge on possible causes. The box boots without any
> > > issue into Slackware Linux. I should try a BIOS upgrade and/or try a
> > > NetBSD version older than the one where the issue was first reported.
> > >
> > > Kind regards
> > > Matthias
> > >
> > > --
> > > Matthias Petermann <mp@petermann-it.de> | www.petermann-it.de
> > > Innovative IT-L?sungen, Systemintegration, Linux/FreeBSD/Unix-Support
> > > Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 991
> > >
>
> --
> Matthias Petermann <mp@petermann-it.de> | www.petermann-it.de
> Innovative IT-L?sungen, Systemintegration, Linux/FreeBSD/Unix-Support
> Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 991
>
From: Matthias Petermann <mp@petermann-it.de>
To: Andrew Doran <ad@netbsd.org>
Cc: Andrius V <vezhlys@gmail.com>, Paul Goyette <paul@whooppee.com>,
install-manager@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
gnats-bugs@netbsd.org
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP Compaq
6005 Pro / AMD Phenom II)
Date: Wed, 11 Dec 2019 12:11:44 +0100
This is a cryptographically signed message in MIME format.
--------------ms050909090704060501050900
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi Andrew,
thanks for sharing your thoughts on this issue! I have a working build=20
environment and adding this printf()s following your excellent guide=20
seems like an easy exercise so far. I will try this first and report any =
findings here as soon as I can.
Kind regrads
Matthias
Am 11.12.2019 um 11:59 schrieb Andrew Doran:
> Hi,
>=20
> I understand it's quite difficult to do if you don't have a working bui=
ld
> environment, and getting the kernels in place is tough too, but assumin=
g
> that your machine actually gets into the kernel and crashes there rathe=
r
> than the boot loader, and you are determined to find the problem...
>=20
> If I wanted to debug this I would try sprinkling printf()s in the kerne=
l's
> main() in src/sys/kern/init_main.c, after the call to consinit().
>=20
> If a machine does not even get that far, or it reboots so quickly that =
the
> messages cannot be read, I keep this assembly function around to dump i=
nto
> src/sys/arch/amd64/amd64/locore.S (or i386, it should assemble correctl=
y on
> both) and then call it from C code. It produces long beeps from the sp=
eaker
> and by counting the beeps and following a process of approximate bisect=
ion I
> can figure out where it's going wrong.
>=20
> http://www.netbsd.org/~ad/keep/beep.S
>=20
> It is an awful lot of work though...
>=20
> Andrew
>=20
>=20
> On Wed, Dec 11, 2019 at 09:48:58AM +0100, Matthias Petermann wrote:
>=20
>> thanks for your response. You are right, the issue maps not exactly to=
the
>> reported problem as a different CPU is installed.
>>
>> Anyway, the following actions did not succeed so far:
>>
>> - booting with boot -12
>> - booting from SATA hard drive with pre-installed NetBSD
>> - USB options not configurable in BIOS
>> - older Release NetBSD 6.0 did also not boot (hangs at the second spin=
ner
>> 123456\ but does not reboot)
>> - switching from AHCI to legacy/native IDE mode
>> - Booting FreeBSD 11.2 also hangs in primary bootstrap
>>
>> Especially the fact that FreeBSD doesn't boot either led me to [1]
>>
>> I will try to find out if I get to the point where I could debug into =
the
>> kernel from my serial console...
>>
>> Kind regards
>> Matthias
>>
>>
>> [1] http://freebsd.1045724.x6.nabble.com/boot-hang-with-certain-Phenom=
-II-cpu-models-td6300528.html
>>
>> Am 09.12.2019 um 22:08 schrieb Andrius V:
>>> Hi,
>>>
>>> It is quite unlikely that your issue is related to the original bug
>>> report since hardware was VIA based (VIA C7-M+VN896) HP 2133 netbook.=
>>> The typical actions I would try to do: 1) boot without ACPI/SMP
>>> enabled (boot -12) 2) if you're booting using USB media, you can try
>>> to change some relevant USB options (speed let's say, depends on BIOS=
)
>>> or try to boot from non USB media (CD, netboot or install it to HDD o=
n
>>> the compatible machine and attach it to your system). If any of those=
>>> boot, you can check dmesg output for potentially unsupported hardware=
=2E
>>> Finally you can try to boot older releases to see if it worked before=
=2E
>>> Otherwise you are probably out of luck (playing with some BIOS option=
s
>>> like switching between AHCI/IDE modes may help but not necessarily).
>>>
>>> P.S. gnats-bugs@netbsd.org should be added as one of email addresses.=
>>>
>>>
>>>
>>> On Mon, Dec 9, 2019 at 9:18 PM Matthias Petermann <mp@petermann-it.de=
> wrote:
>>>>
>>>> resent mail, removed tuotila@gmx.com from cc (address seams to be no=
t
>>>> existing anymore)
>>>>
>>>> ---
>>>>
>>>> Hi,
>>>>
>>>> Am 09.12.2019 um 14:38 schrieb Paul Goyette:
>>>>>> WARNING: 1 module failed to load
>>>>>>
>>>>>> How do I find out which module failed to load here?
>>>>>
>>>>> Almost certainly, this is a failure to load the ffs filesystem,
>>>>> since the filesystem module is already built-in to the kernel.
>>>>>
>>>>> The message can safely be ignored.
>>>>
>>>> That's bad news ;-) So there is no known way to debug this further. =
I
>>>> wish I had more knowledge on possible causes. The box boots without =
any
>>>> issue into Slackware Linux. I should try a BIOS upgrade and/or try a=
>>>> NetBSD version older than the one where the issue was first reported=
=2E
>>>>
>>>> Kind regards
>>>> Matthias
>>>>
>>>> --
>>>> Matthias Petermann <mp@petermann-it.de> | www.petermann-it.de
>>>> Innovative IT-L?sungen, Systemintegration, Linux/FreeBSD/Unix-Suppor=
t
>>>> Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 99=
1
>>>>
>>
>> --=20
>> Matthias Petermann <mp@petermann-it.de> | www.petermann-it.de
>> Innovative IT-L?sungen, Systemintegration, Linux/FreeBSD/Unix-Support
>> Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 991
>>
>=20
>=20
--=20
Matthias Petermann <mp@petermann-it.de> | www.petermann-it.de
Innovative IT-L=C3=B6sungen, Systemintegration, Linux/FreeBSD/Unix-Suppor=
t
Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 991
--------------ms050909090704060501050900
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CyowggUSMIID+qADAgECAhEAirqoQ8X0aFKaaV1Hd5jsWzANBgkqhkiG9w0BAQsFADCBljEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs
Zm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBD
bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xOTAyMTQwMDAw
MDBaFw0yMDAyMTQyMzU5NTlaMCMxITAfBgkqhkiG9w0BCQEWEm1wQHBldGVybWFubi1pdC5k
ZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ89o28jLMDqxmqguWEXTStPuWpT
YLobZcPvsnkUZtwe08adQea0fiCqVfaXwoPea9daPzKPv1gdCT+EAbDiblHgUyGmWxQp4bVN
hSkjlYK01AQ4UhYHeMZDjxv+1OCKc2YBupsEwu2jcOgkKR4KYIwE3tGFeJQkbXhnn/m1ZMbm
le+Q5rmhuAVVu9s8MWsV0NSuUoArQDaG3+JwwiTndW3bpb6AvNoMZT63VFM8agpHkXmNn+Vb
+3fmyoooNos4W851B3Ggmryuz+qsXOtu1GzQMWlou6RI0c3L+w00zwWBFE/dgbfM1p9z7aMc
ihLj7EXbpOfCk4oIfTUC5BBv8fkCAwEAAaOCAcswggHHMB8GA1UdIwQYMBaAFAnA8vwL2pTb
X/4r36iZQs/J4K0AMB0GA1UdDgQWBBSoZTz69WkTCE3XK7Rzkv7xli5dnjAOBgNVHQ8BAf8E
BAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwQAYD
VR0gBDkwNzA1BgwrBgEEAbIxAQIBAQEwJTAjBggrBgEFBQcCARYXaHR0cHM6Ly9zZWN0aWdv
LmNvbS9DUFMwWgYDVR0fBFMwUTBPoE2gS4ZJaHR0cDovL2NybC5zZWN0aWdvLmNvbS9TZWN0
aWdvUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBigYIKwYB
BQUHAQEEfjB8MFUGCCsGAQUFBzAChklodHRwOi8vY3J0LnNlY3RpZ28uY29tL1NlY3RpZ29S
U0FDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCMGCCsGAQUFBzAB
hhdodHRwOi8vb2NzcC5zZWN0aWdvLmNvbTAdBgNVHREEFjAUgRJtcEBwZXRlcm1hbm4taXQu
ZGUwDQYJKoZIhvcNAQELBQADggEBAKhczJE2bDol7fH5zA9khUMaWCUdIO4jc6aJofNd8e6L
pnShgpugjh7Vm7Z4sYIfzzcuetHkbkSRakMOHO8uw69vHcDHpwBbZ4iafy8sd11CTE5I6VN7
PUUa9eyprtqK5z29ts5sAVzL7uIk2UyZdSJ4ubiUiSZfL+4itvaaid0Vaoewyl31MHCFcgRa
tkBs8wDopVHlugaKKTmPfAvYap/VNm0+vsGHz+Nqh2xuy1M/DqjgcH04hYbf54Yk98Jm1lPG
hPNxSs8e3rExkRGxUMr8hrtOi1uD91qoTg0w++IxrhuCKcY+V/2nFkZLywG9+CMpMaYvbJ67
1tom4Ps/qsMwggYQMIID+KADAgECAhBNlCwQ1DvglAnFgS06KwZPMA0GCSqGSIb3DQEBDAUA
MIGIMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLSmVyc2V5
IENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEuMCwGA1UEAxMlVVNFUlRy
dXN0IFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xODExMDIwMDAwMDBaFw0zMDEy
MzEyMzU5NTlaMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMT
NVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjztlApB/975Rrno1jvm2pK/KxBO
qhq8gr2+JhwpKirSzZxQgT9tlC7zl6hn1fXjSo5MqXUfItMltrMaXqcESJuK8dtK56NCSrq4
iDKaKq9NxOXFmqXX2zN8HHGjQ2b2Xv0v1L5Nk1MQPKA19xeWQcpGEGFUUd0kN+oHox+L9aV1
rjfNiCj3bJk6kJaOPabPi2503nn/ITX5e8WfPnGw4VuZ79Khj1YBrf24k5Ee1sLTHsLtpiK9
OjG4iQRBdq6Z/TlVx/hGAez5h36bBJMxqdHLpdwIUkTqT8se3ed0PewDch/8kHPo5fZl5u1B
0ecpq/sDN/5sCG52Ds+QU5O5EwIDAQABo4IBZDCCAWAwHwYDVR0jBBgwFoAUU3m/WqorSs9U
gOHYm8Cd8rIDZsswHQYDVR0OBBYEFAnA8vwL2pTbX/4r36iZQs/J4K0AMA4GA1UdDwEB/wQE
AwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD
BDARBgNVHSAECjAIMAYGBFUdIAAwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2NybC51c2Vy
dHJ1c3QuY29tL1VTRVJUcnVzdFJTQUNlcnRpZmljYXRpb25BdXRob3JpdHkuY3JsMHYGCCsG
AQUFBwEBBGowaDA/BggrBgEFBQcwAoYzaHR0cDovL2NydC51c2VydHJ1c3QuY29tL1VTRVJU
cnVzdFJTQUFkZFRydXN0Q0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1
c3QuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQBBRHUAqznCFfXejpVtMnFojADdF9d6HBA4kMjj
sb0XMZHztuOCtKF+xswhh2GqkW5JQrM8zVlU+A2VP72Ky2nlRA1GwmIPgou74TZ/XTarHG8z
dMSgaDrkVYzz1g3nIVO9IHk96VwsacIvBF8JfqIs+8aWH2PfSUrNxP6Ys7U0sZYx4rXD6+cq
Fq/ZW5BUfClN/rhk2ddQXyn7kkmka2RQb9d90nmNHdgKrwfQ49mQ2hWQNDkJJIXwKjYA6VUR
/fZUFeCUisdDe/0ABLTI+jheXUV1eoYV7lNwNBKpeHdNuO6Aacb533JlfeUHxvBz9OfYWUiX
u09sMAviM11Q0DuMZ5760CdO2VnpsXP4KxaYIhvqPqUMWqRdWyn7crItNkZeroXaecG03i3m
M7dkiPaCkgocBg0EBYsbZDZ8bsG3a08LwEsL1Ygz3SBsyECa0waq4hOf/Z85F2w2ZpXfP+w8
q4ifwO90SGZZV+HR/Jh6rEaVPDRF/CEGVqR1hiuQOZ1YL5ezMTX0ZSLwrymUE0pwi/KDaiYB
15uswgeIAcA6JzPFf9pLkAFFWs1QNyN++niFhsM47qodx/PL+5jR87myx5uYdBEQkkDc+lKB
1Wct6ucXqm2EmsaQ0M95QjTmy+rDWjkDYdw3Ms6mSWE3Bn7i5ZgtwCLXgAIe5W8mybM2JzGC
BDUwggQxAgEBMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz
dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNV
BAMTNVNlY3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBAhEAirqoQ8X0aFKaaV1Hd5jsWzANBglghkgBZQMEAgEFAKCCAlkwGAYJKoZIhvcNAQkD
MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMjExMTExMTQ0WjAvBgkqhkiG9w0B
CQQxIgQgMlWLjXd8MNuoJqzcyaif/7YGaaQcovfvFdN6b+4GBw0wbAYJKoZIhvcNAQkPMV8w
XTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIA
gDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvQYJKwYBBAGCNxAE
MYGvMIGsMIGWMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw
DgYDVQQHEwdTYWxmb3JkMRgwFgYDVQQKEw9TZWN0aWdvIExpbWl0ZWQxPjA8BgNVBAMTNVNl
Y3RpZ28gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEA
irqoQ8X0aFKaaV1Hd5jsWzCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZYxCzAJBgNVBAYTAkdC
MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGDAWBgNV
BAoTD1NlY3RpZ28gTGltaXRlZDE+MDwGA1UEAxM1U2VjdGlnbyBSU0EgQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQCKuqhDxfRoUpppXUd3mOxbMA0GCSqG
SIb3DQEBAQUABIIBAIjnRQXUeAE5/rGZDhWeWrdgKtwz7aZq/mblClQWOlRmdXhncKzq67qV
Mz/tvPQ2b/zYVSz9x8quxQAg5BlQWUvsYDJvn4NrORHz4R84EPJMUfXFpPgZ69O4/mmOchVJ
lcbQnGAlvGWLWB0CufkYdbRRfVwmAeG9a4A3CeuYVTF1K7M4bTgzMWDVMUff7IYUQl1VChb3
Y7r1MR3NfTLQ89oR0gqg09j+pamEmuAd3fjiNpNKhozStqX9GH9LuVozLVRyoToHnxOgv27Y
CEgwl49UXj8qD12K6F8qpfPSq+7xL8ntFF2EbUxMiFPFuzr0pzwrSFuCYfOqylHBjoujNXEA
AAAAAAA=
--------------ms050909090704060501050900--
From: Matthias Petermann <mp@petermann-it.de>
To: Andrew Doran <ad@netbsd.org>
Cc: Andrius V <vezhlys@gmail.com>, Paul Goyette <paul@whooppee.com>,
install-manager@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
gnats-bugs@netbsd.org
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP Compaq
6005 Pro / AMD Phenom II)
Date: Thu, 12 Dec 2019 07:02:00 +0100
Hello Andrew,
here is what I did today:
- put printf after consinit() --> did not print out something (even not
to serial console), it reboots after
> boot
command(s): boot netbsd
18611208+666816+1430336 [886040+1244352+888633]=0x16e1ac0
- added the beep.S and appropriate calls after consinit() and at the
beginning of main() --> did not beep on the affected machine, but does
beep two times as expected on a different machine
So my assumption so far is, that the main function of init_main.c is not
reached. Can you give me a hint who (which C file) is calling main() and
where the interfacing between the boot loader and the kernel is
happening? Can the beep method be applied to the boot loader, too?
Kind regards
Matthias
From: Matthias Petermann <mp@petermann-it.de>
To: Andrew Doran <ad@netbsd.org>
Cc: Andrius V <vezhlys@gmail.com>, Paul Goyette <paul@whooppee.com>,
install-manager@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
gnats-bugs@netbsd.org
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP Compaq
6005 Pro / AMD Phenom II)
Date: Fri, 13 Dec 2019 11:40:22 +0100
Hi Andrew,
thanks again for your guidance. As you recommended I applied the
dobeep() calls also to the assembly part (locore.S).
The results are similiar. On the affected system - no beeps are heard
at all, instead it reboots immediately and without noticeably delay
after the line looking like this:
18611208+666816+1430336 [886040+1244352+888633]=0x16e1ac0
On the other test machine (different vendor) the same kernel produces
the beeps as expected, while taking noticeably longer until the green
messages occur (I assume this is intended and caused by the beeps). So
it seems to not even enter the kernel. You mentioned you might have some
hint how to apply the debugging code to the boot loader, which I would
like to come back to now.
Kind regards
Matthias
From: Andrew Doran <ad@netbsd.org>
To: Matthias Petermann <mp@petermann-it.de>
Cc: Andrius V <vezhlys@gmail.com>, Paul Goyette <paul@whooppee.com>,
install-manager@netbsd.org, gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org, gnats-bugs@netbsd.org
Subject: Re: install/49470: NetBSD 9.0 RC1 reboots after bootloader (HP
Compaq 6005 Pro / AMD Phenom II)
Date: Sat, 14 Dec 2019 21:15:21 +0000
Matthias,
On Fri, Dec 13, 2019 at 11:40:22AM +0100, Matthias Petermann wrote:
> occur (I assume this is intended and caused by the beeps). So it seems to
> not even enter the kernel. You mentioned you might have some hint how to
> apply the debugging code to the boot loader, which I would like to come back
> to now.
I would start looking at exec_netbsd() in sys/arch/i386/stand/lib/exec.c.
This is used by both i386 and amd64. Presumably the failure is occuring at
some point during the execution of this function.
exec_netbsd() ends up calling startprog() which is defined in
lib/startprog.S, which incidentally would be a good place to put the code
for dobeep().
You could use printf() in the boot loader just as easily, but if it's
resetting and clearing the screen instantaly perhaps dobeep() is a better
choice.
It has been 10+ years since I built the bootloader by hand but I think it's
a case of running "make" in sys/arch/i386/stand or some variation thereof,
and if I remember correctly the executable you're looking for is "boot".
Andrew
From: Kaz Blocks <kazbloxmc@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/49470
Date: Sun, 1 Mar 2020 02:11:26 -0500
--00000000000014b44a059fc5c8a6
Content-Type: text/plain; charset="UTF-8"
https://i.ibb.co/0D0xWVb/D3-E59-EDF-1-C72-4-A9-D-89-DD-681-A8-D5-B1002.jpg
I found the culprit! It appears to be not a module issue, but something to
do with memory allocation.
--00000000000014b44a059fc5c8a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><a href=3D"https://i.ibb.co/0D0xWVb/D3-E59-EDF-1-C72-4-A9-=
D-89-DD-681-A8-D5-B1002.jpg">https://i.ibb.co/0D0xWVb/D3-E59-EDF-1-C72-4-A9=
-D-89-DD-681-A8-D5-B1002.jpg</a><div>I found the culprit! It appears to be =
not a module issue, but something to do with memory allocation.</div></div>
--00000000000014b44a059fc5c8a6--
Responsible-Changed-From-To: install-manager->port-amd64-manager
Responsible-Changed-By: martin@NetBSD.org
Responsible-Changed-When: Sun, 01 Mar 2020 08:38:59 +0000
Responsible-Changed-Why:
x86 bootloader specific problem (or MD kernel issue)
Responsible-Changed-From-To: port-amd64-manager->port-amd64-maintainer
Responsible-Changed-By: martin@NetBSD.org
Responsible-Changed-When: Sun, 15 Mar 2020 09:30:52 +0000
Responsible-Changed-Why:
typo in role account
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: tuotila@gmx.com, kazbloxmc@gmail.com
Subject: Re: install/49470
Date: Tue, 2 Jul 2024 13:33:53 +0300
On Sun, Mar 1, 2020 at 10:33=E2=80=AFAM Kaz Blocks <kazbloxmc@gmail.com> wr=
ote:
>
> The following reply was made to PR install/49470; it has been noted by GN=
ATS.
>
> From: Kaz Blocks <kazbloxmc@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: install/49470
> Date: Sun, 1 Mar 2020 02:11:26 -0500
>
> --00000000000014b44a059fc5c8a6
> Content-Type: text/plain; charset=3D"UTF-8"
>
> https://i.ibb.co/0D0xWVb/D3-E59-EDF-1-C72-4-A9-D-89-DD-681-A8-D5-B1002.j=
pg
> I found the culprit! It appears to be not a module issue, but something =
to
> do with memory allocation.
>
> --00000000000014b44a059fc5c8a6
> Content-Type: text/html; charset=3D"UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> <div dir=3D3D"ltr"><a href=3D3D"https://i.ibb.co/0D0xWVb/D3-E59-EDF-1-C7=
2-4-A9-=3D
> D-89-DD-681-A8-D5-B1002.jpg">https://i.ibb.co/0D0xWVb/D3-E59-EDF-1-C72-4=
-A9=3D
> -D-89-DD-681-A8-D5-B1002.jpg</a><div>I found the culprit! It appears to =
be =3D
> not a module issue, but something to do with memory allocation.</div></d=
iv>
>
> --00000000000014b44a059fc5c8a6--
>
>
It is reproducible on Biostar Viotech 3100+ with VIA C7-D CPU on the
install image. Same install kernel does boot on the installed system.
As another workaround, reducing ACPI version to v2 (from v3) in the
BIOS also makes system boot from the install image. The issue seems to
be introduced between before NetBSD 7, since NetBSD 6.x releases still
boot. Will try to investigate a bit if I can find something.
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/49470
Date: Mon, 22 Jul 2024 09:40:20 +0300
Hi,
On Tue, Jul 2, 2024 at 1:53=E2=80=AFPM Andrius V <vezhlys@gmail.com> wrote:
>
> The following reply was made to PR port-amd64/49470; it has been noted by=
GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc: tuotila@gmx.com, kazbloxmc@gmail.com
> Subject: Re: install/49470
> Date: Tue, 2 Jul 2024 13:33:53 +0300
>
> It is reproducible on Biostar Viotech 3100+ with VIA C7-D CPU on the
> install image. Same install kernel does boot on the installed system.
> As another workaround, reducing ACPI version to v2 (from v3) in the
> BIOS also makes system boot from the install image. The issue seems to
> be introduced between before NetBSD 7, since NetBSD 6.x releases still
> boot. Will try to investigate a bit if I can find something.
>
Initial analysis:
The issue seems to have started with switch to gcc 4.8
(https://github.com/NetBSD/src/commit/ad33dd774c2fe8beb41c96d1d29aef4ebce3f=
5cb
and https://github.com/NetBSD/src/commit/f8008b9438a836d85ee0b14cb56ee82966=
fd8216).
It prints this log and reboots:
booting hd0a:netbsd (howto 0xa0000)
22005524+593000+742296 [1003696+1091430+13604]=3D0x1846608
[ 1.0000000] cpu_rng: via
[ 1.0000000] pmap_kenter_pa: mapping already present
It reboots on memcpy() call, I assume because both source and
destination pointers are NULL (printed them out for testing):
https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf3580=
/sys/kern/subr_kcpuset.c#L351
which in turn was called from pmap_tlb_shootdown() ->
kcpuset_copy(ci->ci_tlb_cpuset, kcpuset_running)
https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf3580=
/sys/arch/x86/x86/x86_tlb.c#L289
And finally shootdown was called from kenter funciton -
pmap_kenter_pa() in the "/* This should not happen. */" path:
https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf3580=
/sys/arch/x86/x86/pmap.c#L1056
This typically happens if arguments are passed to the boot command
(e.g. boot netbsd or boot netbsd -vx), but boots properly without
passing the kernel (e.g. boot or boot -vx), but it's not always the
case for all my setups (it is an opposite in one setup, where system
is installed in sd media (a bit older release)). If it boots, it
doesn't enter the unexpected path in kenter function.
It happens only if ACPI version is set to v3.0 in BIOS. It boots in
all combinations I have tried if ACPI version is set to v2.0 or v1.0.
I see it is likely at least two issues:
No checks before memcpy() or kcpuset_copy() that values are null and I
guess some additional asserts are needed here as a band-aid before one
of these calls?
Another issue is the root cause why this unintended path is taken,
somehow related to ACPI version and boot command. Is it also some kind
of undesirable optimization, maybe CPU bug or something else, I still
need to understand.
Regards,
Andrius V
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: install/49470
Date: Mon, 22 Jul 2024 09:51:06 +0300
On Mon, Jul 22, 2024 at 9:40=E2=80=AFAM Andrius V <vezhlys@gmail.com> wrote=
:
>
> Hi,
>
> On Tue, Jul 2, 2024 at 1:53=E2=80=AFPM Andrius V <vezhlys@gmail.com> wrot=
e:
>
> Initial analysis:
> The issue seems to have started with switch to gcc 4.8
> (https://github.com/NetBSD/src/commit/ad33dd774c2fe8beb41c96d1d29aef4ebce=
3f5cb
> and https://github.com/NetBSD/src/commit/f8008b9438a836d85ee0b14cb56ee829=
66fd8216).
>
> It prints this log and reboots:
> booting hd0a:netbsd (howto 0xa0000)
> 22005524+593000+742296 [1003696+1091430+13604]=3D0x1846608
> [ 1.0000000] cpu_rng: via
> [ 1.0000000] pmap_kenter_pa: mapping already present
>
> It reboots on memcpy() call, I assume because both source and
> destination pointers are NULL (printed them out for testing):
> https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf35=
80/sys/kern/subr_kcpuset.c#L351
> which in turn was called from pmap_tlb_shootdown() ->
> kcpuset_copy(ci->ci_tlb_cpuset, kcpuset_running)
> https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf35=
80/sys/arch/x86/x86/x86_tlb.c#L289
> And finally shootdown was called from kenter funciton -
> pmap_kenter_pa() in the "/* This should not happen. */" path:
> https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf35=
80/sys/arch/x86/x86/pmap.c#L1056
>
> This typically happens if arguments are passed to the boot command
> (e.g. boot netbsd or boot netbsd -vx), but boots properly without
> passing the kernel (e.g. boot or boot -vx), but it's not always the
> case for all my setups (it is an opposite in one setup, where system
> is installed in sd media (a bit older release)). If it boots, it
> doesn't enter the unexpected path in kenter function.
To complement this, for ACPI v2.0, it also enters the condition but
values are not null for memcpy and crash doesn't happen.
>
> It happens only if ACPI version is set to v3.0 in BIOS. It boots in
> all combinations I have tried if ACPI version is set to v2.0 or v1.0.
>
> I see it is likely at least two issues:
> No checks before memcpy() or kcpuset_copy() that values are null and I
> guess some additional asserts are needed here as a band-aid before one
> of these calls?
>
> Another issue is the root cause why this unintended path is taken,
> somehow related to ACPI version and boot command. Is it also some kind
> of undesirable optimization, maybe CPU bug or something else, I still
> need to understand.
>
> Regards,
> Andrius V
From: Andrius V <vezhlys@gmail.com>
To: gnats-bugs@netbsd.org
Cc: Taylor R Campbell <riastradh@netbsd.org>
Subject: Re: install/49470
Date: Fri, 16 Aug 2024 00:50:03 +0300
On Mon, Jul 22, 2024 at 9:45=E2=80=AFAM Andrius V <vezhlys@gmail.com> wrote=
:
>
> The following reply was made to PR port-amd64/49470; it has been noted by=
GNATS.
>
> From: Andrius V <vezhlys@gmail.com>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: install/49470
> Date: Mon, 22 Jul 2024 09:40:20 +0300
>
> Hi,
>
>
> Initial analysis:
> The issue seems to have started with switch to gcc 4.8
> (https://github.com/NetBSD/src/commit/ad33dd774c2fe8beb41c96d1d29aef4ebc=
e3f=3D
> 5cb
> and https://github.com/NetBSD/src/commit/f8008b9438a836d85ee0b14cb56ee82=
966=3D
> fd8216).
>
> It prints this log and reboots:
> booting hd0a:netbsd (howto 0xa0000)
> 22005524+593000+742296 [1003696+1091430+13604]=3D3D0x1846608
> [ 1.0000000] cpu_rng: via
> [ 1.0000000] pmap_kenter_pa: mapping already present
>
> It reboots on memcpy() call, I assume because both source and
> destination pointers are NULL (printed them out for testing):
> https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf3=
580=3D
> /sys/kern/subr_kcpuset.c#L351
> which in turn was called from pmap_tlb_shootdown() ->
> kcpuset_copy(ci->ci_tlb_cpuset, kcpuset_running)
> https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf3=
580=3D
> /sys/arch/x86/x86/x86_tlb.c#L289
> And finally shootdown was called from kenter funciton -
> pmap_kenter_pa() in the "/* This should not happen. */" path:
> https://github.com/NetBSD/src/blob/ee4113b4927055cea72b04191634f65fc3bf3=
580=3D
> /sys/arch/x86/x86/pmap.c#L1056
>
> This typically happens if arguments are passed to the boot command
> (e.g. boot netbsd or boot netbsd -vx), but boots properly without
> passing the kernel (e.g. boot or boot -vx), but it's not always the
> case for all my setups (it is an opposite in one setup, where system
> is installed in sd media (a bit older release)). If it boots, it
> doesn't enter the unexpected path in kenter function.
>
> It happens only if ACPI version is set to v3.0 in BIOS. It boots in
> all combinations I have tried if ACPI version is set to v2.0 or v1.0.
>
> I see it is likely at least two issues:
> No checks before memcpy() or kcpuset_copy() that values are null and I
> guess some additional asserts are needed here as a band-aid before one
> of these calls?
>
> Another issue is the root cause why this unintended path is taken,
> somehow related to ACPI version and boot command. Is it also some kind
> of undesirable optimization, maybe CPU bug or something else, I still
> need to understand.
>
> Regards,
> Andrius V
>
Hi,
After many additional debugging sessions and big help from Taylor I
narrowed down the issue to the bi_getmemmap() call, or more
specifically to getmementry(&i, buf)
(https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/biosmemx.S#87)
This method invokes BIOS call and fills the buffer[5] with defined
values. For some reason though, with ACPI 3.0 it actually seems to get
6 values,
thus leading stack corruption (overflow(?)). The sixth value is always
1, and is set after each and every call.
All other buf values [0-4] and number of iterations match completely
the ones when ACPI 2.0 is set.
Workaround can be allocating more memory to buf, for example setting
buf size to 6 (buf[6]):
https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/bootinfo_memmap.c#4=
0
In more detailed flow:
Bootloader executes exec_netbsd()
it calls common_load_kernel()
https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#495
it loads kernel file and sets marks[MARK_MAX] (MARK_MAX=3D6) values
(mainly in loadfile logic):
https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#416
It calls bi_getmemmap();
https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#436
It calls getmementry(&i, buf) multiple times which returns values
beyond 20 bytes allocated.
After return bi_getmemmap(); all marks[] values are corrupted in
common_load_kernel()
Wrong image_end value is set because of that
https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/exec.c#455
After return to exec_netbsd() most marks[] value become OK, except
sometimes marks[MARK_END], which still can be corrupted but closer to
original value.
Invalid image_end leads to wrong atdevbase and PDPpaddr in kernel,
leading to other failures if the value is high.
(which finally leads to instant reboot as described in previous emails)
(Sorry, if some terminology is incorrect)
What I don't know in this situation:
1. Why BIOS calls returns "sixth" value and why it is always 1. Is it
a BIOS bug or something else, I can't tell..
2. Not sure what would the correct way to fix the issue:
should getmementry() assembly change somehow prevent on exceeding
allocated space, even if BIOS returns more than necessary info?
some special kludge for this specific case?
or like workaround, give buf[] more memory "just in case"?
Something other options?
Advice is welcome.
Regards,
Andrius V
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Andrius V <vezhlys@gmail.com>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: install/49470
Date: Thu, 15 Aug 2024 23:10:35 +0000
> Date: Fri, 16 Aug 2024 00:50:03 +0300
> From: Andrius V <vezhlys@gmail.com>
>=20
> After many additional debugging sessions and big help from Taylor I
> narrowed down the issue to the bi_getmemmap() call, or more
> specifically to getmementry(&i, buf)
> (https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/biosmemx.S#87)
> This method invokes BIOS call and fills the buffer[5] with defined
> values. For some reason though, with ACPI 3.0 it actually seems to get
> 6 values,
> thus leading stack corruption (overflow(?)). The sixth value is always
> 1, and is set after each and every call.
> All other buf values [0-4] and number of iterations match completely
> the ones when ACPI 2.0 is set.
Amazing! Thanks for doing the work to dig into this!
With that clue, I poked around a little bit and found this fragment on
wiki.osdev.org:
`The format of an entry is 2 uint64_t's and a uint32_t in the 20
byte version, plus one additional uint32_t in the 24 byte ACPI 3.0
version.'
https://wiki.osdev.org/Detecting_Memory_(x86)#BIOS_Function:_INT_0x15,_E=
AX_=3D_0xE820
I looked at the page history to see where this came from, and found
that from 2008 when the page was first written until 2023(!), the text
read:
`The format of an entry is 2 uint64_t's and a uint32_t in the 20
byte version, plus one additional uint32_t in the 24 byte ACPI 3.0
version (but nobody has ever seen a 24 byte one).'
https://wiki.osdev.org/index.php?title=3DDetecting_Memory_(x86)&oldid=3D=
27401#BIOS_Function:_INT_0x15,_EAX_=3D_0xE820
The edit comment says: `I have found an bios that use 24 byte entrie
for int 0x15 function 0xe820'
This page was a rewrite of an earlier page, whose last edition says:
ACPI 3.0 notes
...
* A 32 bit set of flags ("Extended Attibutes") has been appended to
the end of the 20 byte structure, making it 24 bytes.
https://wiki.osdev.org/index.php?title=3DHow_Do_I_Determine_The_Amount_O=
f_RAM&oldid=3D4759#Counting_RAM_using_the_BIOS
I looked up INT 15h E820h in the ACPI 3.0 spec, and it says:
Table 14-2 Input to the INT 15h E820h Call
...
ES:DI Buffer Pointer Pointer to an Address Range Descriptor
structure that the BIOS fills in.
ECX Buffer Size The length in bytes of the structure
passed to the BIOS. The BIOS fills in
the number of bytes of the structure
indicated in the ECX register,
maximum, or whatever amount of the
structure the BIOS implements. The
minimum size that must be supported by
both the BIOS and the caller is 20
bytes. Future implementations might
extend this structure.
...
Table 14-4 Address Range Descriptor Structure
Offset Name Description
...
16 Type Address type of this range
20 Extended Attributes See Table 14-5
https://uefi.org/sites/default/files/resources/ACPI_3.pdf#page=3D404
So this ACPI 3.0 system is probably just ignoring the size we passed
in ecx (which is definitely 20, not 24!), which is rude, but there's
probably not much we can do to convince the firmware vendor to ship
updates to these decade-old laptops.
> Workaround can be allocating more memory to buf, for example setting
> buf size to 6 (buf[6]):
> https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/bootinfo_memmap.c=
#40
So yes, I think that is the correct thing to do here.
Now, the BIOS is obviously violating the rules here -- we passed in a
buffer size of 20 bytes, and it wrote out 24 bytes. In principle if
we wanted to hear about the extended attributes, we could also change
getmementry to set ecx=3D24, but that's a much riskier change.
(It might even be reasonable to make a struct out of this -- not
really sure why we use an array on the stack -- but refactoring this
isn't as important as avoiding the stack buffer overrun!)
So I suggest we just change `int buf[5]' to `int buf[6]' in:
- bi_getmemmap in bootinfo_memmap.c
- getextmemx in getextmemx.c
- the comment over getmementry in biosmemx.S
(and make sure there's no sizeof(buf) that changes).
We should also put a reference to all this bug, the relevant part of
the ACPI 3.0 spec, and the wiki.osdev.org page in comments so the next
person to stumble upon buf[6] doesn't change it back to buf[5] or
wonder what that extra word is doing!
From: "Andrius Varanavicius" <andvar@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/49470 CVS commit: src/sys/arch/i386/stand/lib
Date: Sat, 17 Aug 2024 08:38:31 +0000
Module Name: src
Committed By: andvar
Date: Sat Aug 17 08:38:31 UTC 2024
Modified Files:
src/sys/arch/i386/stand/lib: biosmemx.S bootinfo_memmap.c getextmemx.c
Log Message:
Allocate buf[6] instead of buf[5] to work around buggy firmware, which may
write mementry to 24 bytes instead 20 requested with ACPI 3.0 enabled,
causing corrupted stack and wrong marks[] values in common_load_kernel().
This in turn was leading to erroneous caluclations and memory addresses.
This eventually may result in null pointer dereference in the kernel and sudden
reboot for VIA based systems.
Commit should fix boot issues for VIA C7-M based HP 2133 Mini-Note,
mentioned in the original bug report. For AMD based HP Compaq 6005 Pro
discussed in a separate thread, the issue may be different.
Tested on my VIA C7-D based Biostar Viotech 3100+ motherboard.
needs-pullups to 9, 10.
PR install/49470
To generate a diff of this commit:
cvs rdiff -u -r1.11 -r1.12 src/sys/arch/i386/stand/lib/biosmemx.S
cvs rdiff -u -r1.6 -r1.7 src/sys/arch/i386/stand/lib/bootinfo_memmap.c
cvs rdiff -u -r1.10 -r1.11 src/sys/arch/i386/stand/lib/getextmemx.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
Responsible-Changed-From-To: port-amd64-maintainer->andvar
Responsible-Changed-By: andvar@NetBSD.org
Responsible-Changed-When: Sat, 17 Aug 2024 09:12:21 +0000
Responsible-Changed-Why:
State-Changed-From-To: open->needs-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Sat, 17 Aug 2024 09:12:21 +0000
State-Changed-Why:
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/49470 CVS commit: src/sys/arch/i386/stand/lib
Date: Sat, 24 Aug 2024 20:23:12 +0000
Module Name: src
Committed By: riastradh
Date: Sat Aug 24 20:23:12 UTC 2024
Modified Files:
src/sys/arch/i386/stand/lib: biosmemx.S bootinfo_memmap.c getextmemx.c
Log Message:
i386/stand/lib: Nix trailing whitespace and tidy comments a bit.
No functional change intended.
PR port-amd64/49470: NetBSD 7 BETA reboots after bootloader (HP 2133)
To generate a diff of this commit:
cvs rdiff -u -r1.12 -r1.13 src/sys/arch/i386/stand/lib/biosmemx.S
cvs rdiff -u -r1.7 -r1.8 src/sys/arch/i386/stand/lib/bootinfo_memmap.c
cvs rdiff -u -r1.11 -r1.12 src/sys/arch/i386/stand/lib/getextmemx.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Tue, 27 Aug 2024 21:47:39 +0000
State-Changed-Why:
[pullup-9 #1884] and [pullup-10 #815]
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/49470 CVS commit: [netbsd-10] src/sys/arch/i386/stand/lib
Date: Tue, 3 Sep 2024 15:23:41 +0000
Module Name: src
Committed By: martin
Date: Tue Sep 3 15:23:41 UTC 2024
Modified Files:
src/sys/arch/i386/stand/lib [netbsd-10]: biosmemx.S bootinfo_memmap.c
getextmemx.c
Log Message:
Pull up following revision(s) (requested by andvar in ticket #815):
sys/arch/i386/stand/lib/bootinfo_memmap.c: revision 1.7
sys/arch/i386/stand/lib/bootinfo_memmap.c: revision 1.8
sys/arch/i386/stand/lib/getextmemx.c: revision 1.11
sys/arch/i386/stand/lib/getextmemx.c: revision 1.12
sys/arch/i386/stand/lib/biosmemx.S: revision 1.12
sys/arch/i386/stand/lib/biosmemx.S: revision 1.13
Allocate buf[6] instead of buf[5] to work around buggy firmware, which may
write mementry to 24 bytes instead 20 requested with ACPI 3.0 enabled,
causing corrupted stack and wrong marks[] values in common_load_kernel().
This in turn was leading to erroneous caluclations and memory addresses.
This eventually may result in null pointer dereference in the kernel and sudden
reboot for VIA based systems.
Commit should fix boot issues for VIA C7-M based HP 2133 Mini-Note,
mentioned in the original bug report. For AMD based HP Compaq 6005 Pro
discussed in a separate thread, the issue may be different.
Tested on my VIA C7-D based Biostar Viotech 3100+ motherboard.
PR install/49470
i386/stand/lib: Nix trailing whitespace and tidy comments a bit.
No functional change intended.
PR port-amd64/49470: NetBSD 7 BETA reboots after bootloader (HP 2133)
To generate a diff of this commit:
cvs rdiff -u -r1.11 -r1.11.8.1 src/sys/arch/i386/stand/lib/biosmemx.S
cvs rdiff -u -r1.6 -r1.6.26.1 src/sys/arch/i386/stand/lib/bootinfo_memmap.c
cvs rdiff -u -r1.10 -r1.10.84.1 src/sys/arch/i386/stand/lib/getextmemx.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/49470 CVS commit: [netbsd-9] src/sys/arch/i386/stand/lib
Date: Tue, 3 Sep 2024 15:29:05 +0000
Module Name: src
Committed By: martin
Date: Tue Sep 3 15:29:05 UTC 2024
Modified Files:
src/sys/arch/i386/stand/lib [netbsd-9]: biosmemx.S bootinfo_memmap.c
getextmemx.c
Log Message:
Pull up following revision(s) (requested by andvar in ticket #1884):
sys/arch/i386/stand/lib/bootinfo_memmap.c: revision 1.7
sys/arch/i386/stand/lib/bootinfo_memmap.c: revision 1.8
sys/arch/i386/stand/lib/getextmemx.c: revision 1.11
sys/arch/i386/stand/lib/getextmemx.c: revision 1.12
sys/arch/i386/stand/lib/biosmemx.S: revision 1.12
sys/arch/i386/stand/lib/biosmemx.S: revision 1.13
Allocate buf[6] instead of buf[5] to work around buggy firmware, which may
write mementry to 24 bytes instead 20 requested with ACPI 3.0 enabled,
causing corrupted stack and wrong marks[] values in common_load_kernel().
This in turn was leading to erroneous caluclations and memory addresses.
This eventually may result in null pointer dereference in the kernel and sudden
reboot for VIA based systems.
Commit should fix boot issues for VIA C7-M based HP 2133 Mini-Note,
mentioned in the original bug report. For AMD based HP Compaq 6005 Pro
discussed in a separate thread, the issue may be different.
Tested on my VIA C7-D based Biostar Viotech 3100+ motherboard.
PR install/49470
i386/stand/lib: Nix trailing whitespace and tidy comments a bit.
No functional change intended.
PR port-amd64/49470: NetBSD 7 BETA reboots after bootloader (HP 2133)
To generate a diff of this commit:
cvs rdiff -u -r1.10 -r1.10.20.1 src/sys/arch/i386/stand/lib/biosmemx.S
cvs rdiff -u -r1.5.70.1 -r1.5.70.2 \
src/sys/arch/i386/stand/lib/bootinfo_memmap.c
cvs rdiff -u -r1.10 -r1.10.58.1 src/sys/arch/i386/stand/lib/getextmemx.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: andvar@NetBSD.org
State-Changed-When: Wed, 04 Sep 2024 03:53:58 +0000
State-Changed-Why:
pullups applied to netbsd-9, 10 (7, 8 unsupported by now).
HP AMD system discussed in a separate thread was untested,
if still applicable, new PR should be created.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.51 2026/08/10 02:28:17 riastradh Exp $
$NetBSD: gnats_config.sh,v 1.10 2026/05/13 22:00:09 riastradh Exp $
Copyright © 1994-2026
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home