daily CVS update output
Updating src tree: P src/distrib/sets/lists/base32/ad.mipsn64eb P src/distrib/sets/lists/base32/ad.mipsn64el P src/external/cddl/osnet/dist/uts/common/fs/zfs/vdev.c P src/sys/arch/vax/vax/unimpl_emul.S P src/sys/ddb/db_proc.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 44132053 Apr 16 03:03 ls-lRA.gz
Re: unable to boot 10.0/amd64
> On Apr 15, 2024, at 2:57 PM, matthew green wrote: > > this might be the same as > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgnats.netbsd.org%2Fcgi-bin%2Fquery-pr-single.pl%3Fnumber%3D57153=05%7C02%7Cbrook%40biology.nmsu.edu%7C4e3a710638ae4a29190f08dc5d8ec577%7Ca3ec87a89fb84158ba8ff11bace1ebaa%7C1%7C0%7C638488114982587406%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C6%7C%7C%7C=2fo3KIFYLA3O3gOhd%2B8Q5gNBe%2BkyEC2EVrLLtkw4n%2Fo%3D=0 > > it's the same faulting function and similar offset... Yes, almost certainly the same. I can’t easily compare all the registers exactly (but could if it helps), but the description and other information appears to be the same. It’s a little hard to capture the last bits before the halt, but it looks to be the same as in the PR: ACPI handling of cpus. For what it’s worth, disabling ACPI allowed 10.0 to boot fine and so far it appears to be working. Are there other implications of doing that? I’m not sure how ACPI handling relates to the code in the PR, though. Perhaps it gives an idea. Cheers, Brook
Re: Upgrade of current pkgsrc fails due to gtk3 on 10.99
Riccardo Mottola writes: > *** pkg_chk reports the following packages need replacing, but they > are not installed: py311-tomli > *** Please read the errors listed above, fix the problem, > *** then re-run pkg_rolling-replace to continue. > # pkg_info | grep tomli > py310-tomli-2.0.1nb1 Lil' TOML parser > py39-tomli-2.0.1nb1 Lil' TOML parser This is pkg_rr inheriting pkg_chk's lack of grasping multi-version packages. > Does pkg_rr has a "cache" or is it fresh calculated information? There is no pkg_rr cache but rebuild, unsafe_depends and mismatch are stored as package variables. > Again python modules pain :) Yes, all flowing from python's lack of API compat. This may not help, but I recommmend: pkgin sk pkgin uk foo # for any kept foo that you don't actually want pkgin ar which gets rid of a lot of stuff that you don't need -- and don't need to rebuild. After that, if you have py310-foo, then make PYTHON_VERSION_REQD=310 replace in foo (or something very close to that as I haven't done this in months).
re: unable to boot 10.0/amd64
this might be the same as https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=57153 it's the same faulting function and similar offset... .mrg.
Re: unable to boot 10.0/amd64
Date:Mon, 15 Apr 2024 12:32:22 -0600 From:Brook Milligan Message-ID: <68be1f36-3f4e-4345-b629-96bd3f74f...@nmsu.edu> | >> kernel page fault trap, code 0 | >> Stopped in pid 0.0 (system) at netbsd:uvm_page_redim+0x2e9: addq $0x1,0(%?dx) | >> uvm_page_redim() at netbsd netbsd:uv_page_redim+0x2e9 | >> main() at netbsd:main+0x366 It might help if you could say what occurs just before this (the previous few lines). But, from your dmesg (from your 9.3) I see: vga0 at pci3 dev 4 function 0: vendor 102b product 0532 (rev. 0x0a) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0 If I have interpreted that correctly, that's an ancient Mattrox G200EW graphics card. 10 has LOTS of new video stuff in it (wholesale upgrades to the video drivers) and some of the older cards (and still some of the newer ones, unfortunately) don't work well, or at all. It is possible that one is just too old, and is no longer properly supported - certainly it is quite likely that no-one had one of those to test against. But this guess is only relevant if the system was configuring, or using, the graphics card at the time, if the crash happened while doing something else, then it is possible that card will work as well as it ever did. That's why it would be useful to know what was happening, just before the crash. kre
Re: unable to boot 10.0/amd64
> On Apr 15, 2024, at 12:25 PM, Jonathan A. Kollasch > wrote: > > On Mon, Apr 15, 2024 at 10:22:48AM -0600, Brook Milligan wrote: >> I’m trying to upgrade an amd64 system that has been running a version of 9.3 >> (same as release on ftp.netbsd.org). I untarred the 10.0 GENERIC kernel set >> (kern-GENERIC.tar.xz), untarred the 10.0 modules set (modules.tar.xz), and >> rebooted. The kernel starts to boot with a bunch of device driver messages, >> etc. Then it halts with the following message (hand transcribed here; ? >> character unreadable in second line): >> >> kernel page fault trap, code 0 >> Stopped in pid 0.0 (system) at netbsd:uvm_page_redim+0x2e9: addq $0x1,0(%?dx) >> uvm_page_redim() at netbsd netbsd:uv_page_redim+0x2e9 >> main() at netbsd:main+0x366 >> … >> > > Do you have the beginning (or most/all) of a 9.3 /var/run/dmesg.boot you > could share? > > Particularly curious about total RAM quantity and CPU count. Machine > info such model or cpu/chipset could also be useful. Thanks for the response. I have attached the full /var/run/dmesg.boot and the output of cpuctl identify 0 (there are a total of 32 CPUS, all the same). Note that this is all from 9.3. I hope this helps. Cheers, Brook dmesg.boot Description: Binary data cpuctl.0 Description: Binary data
Re: unable to boot 10.0/amd64
On Mon, Apr 15, 2024 at 10:22:48AM -0600, Brook Milligan wrote: > I’m trying to upgrade an amd64 system that has been running a version of 9.3 > (same as release on ftp.netbsd.org). I untarred the 10.0 GENERIC kernel set > (kern-GENERIC.tar.xz), untarred the 10.0 modules set (modules.tar.xz), and > rebooted. The kernel starts to boot with a bunch of device driver messages, > etc. Then it halts with the following message (hand transcribed here; ? > character unreadable in second line): > > kernel page fault trap, code 0 > Stopped in pid 0.0 (system) at netbsd:uvm_page_redim+0x2e9: addq $0x1,0(%?dx) > uvm_page_redim() at netbsd netbsd:uv_page_redim+0x2e9 > main() at netbsd:main+0x366 > … > Do you have the beginning (or most/all) of a 9.3 /var/run/dmesg.boot you could share? Particularly curious about total RAM quantity and CPU count. Machine info such model or cpu/chipset could also be useful.
Re: Upgrade of current pkgsrc fails due to gtk3 on 10.99
On Mon 15 Apr 2024 at 17:19:14 +0200, Riccardo Mottola wrote: > Does pkg_rr has a "cache" or is it fresh calculated information? It has a sort of cache, as hinted at by this: > rr> WARNING: mismatch variable not set due to permissions; > rr> mismatch status will not persist. where (if allowed) it sets a "mismatch" variable in the pkgdb on packages that are reported as mismatches. So the next time you don't need to run pkg_chk (the -u option) again. If the package gets deleted for some reason, the flag is deleted with it. So this would not explain your case, I think. > Riccardo -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
unable to boot 10.0/amd64
I’m trying to upgrade an amd64 system that has been running a version of 9.3 (same as release on ftp.netbsd.org). I untarred the 10.0 GENERIC kernel set (kern-GENERIC.tar.xz), untarred the 10.0 modules set (modules.tar.xz), and rebooted. The kernel starts to boot with a bunch of device driver messages, etc. Then it halts with the following message (hand transcribed here; ? character unreadable in second line): kernel page fault trap, code 0 Stopped in pid 0.0 (system) at netbsd:uvm_page_redim+0x2e9: addq $0x1,0(%?dx) uvm_page_redim() at netbsd netbsd:uv_page_redim+0x2e9 main() at netbsd:main+0x366 … The following lines look to be a bunch of register values. I’m not sure where to look next or what information would be useful, as this is something I have never encountered. Please advise. Thanks a lot. Cheers, Brook
Re: Upgrade of current pkgsrc fails due to gtk3 on 10.99
Hi Greg, once gtk3 was sorted out, pkg_rr completed. Yay. Then I did re-run it, to check, and I see this: RR> Checking for mismatched installed packages using pkg_chk rr> Installed: py311-tomli-2.0.1nb1 py311-tomli-2.0.1nb1 rr> WARNING: mismatch variable not set due to permissions; rr> mismatch status will not persist. RR> Excluding the following mismatched packages: rr> EXCLUDE=[] RR> Checking for rebuild-requested installed packages (rebuild=YES) RR> Checking for unsafe installed packages (unsafe_depends=YES) RR> Packages to rebuild: rr> MISMATCH_TODO=[py311-tomli] rr> REBUILD_TODO=[] rr> UNSAFE_TODO=[] RR> Building dependency graph for installed packages RR> Tsorting dependency graph *** pkg_chk reports the following packages need replacing, but they are not installed: py311-tomli *** Please read the errors listed above, fix the problem, *** then re-run pkg_rolling-replace to continue. possibly the package was installed but I removed it? Or is it getting confused between 3.10 and 3.11 Python versions: I have: # pkg_info | grep tomli py310-tomli-2.0.1nb1 Lil' TOML parser py39-tomli-2.0.1nb1 Lil' TOML parser Does pkg_rr has a "cache" or is it fresh calculated information? Again python modules pain :) Riccardo
Re: Upgrade of current pkgsrc fails due to gtk3 on 10.99
Hi Greg, Greg Troxel wrote: gtk3 is buggy. It tries to link against installed libs during the build, instead of only the libs being built. I did pkg_delete -f gtk3+ and then it builds fine. Actually fixing this is harder; you'll have to find where gtk3+'s build manages to have /usr/pkg/lib in the search path first. This sort of thing is gradually getting better, but it's hard. And, people that only pbulk don't hit it, so the set of motivated people is smaller. However, it will probably only take one person who is both motivated and has a round tuit to fix this. thanks for the tip... didn't thought of it, I was seeking for existing broken libraries, while the broken library was gtk3 itself. I too did pkg_delete -f gtk3+, then manually make_replace fails, because it is not installed. I used make_install and then: sudo pkg_admin set automatic=YES gtk3+-3.24.41nb2 I suppose that should be equivalent to make_replace of a dependency package. Now... let's restart pkg_rr and see where it goes! Riccardo
