re: CVS commit: src/sys/kern
"Andrew Doran" writes: > Module Name: src > Committed By: ad > Date: Mon Dec 9 21:02:10 UTC 2019 > > Modified Files: > src/sys/kern: kern_rwlock.c > > Log Message: > Expunge the panicstr checks, we don't need them. can you explain why? what sort of crash-time testing did you perform? thanks. .mrg.
Re: CVS commit: src/sys/kern
On Wed, Dec 11, 2019 at 09:06:33AM +1100, matthew green wrote: > "Andrew Doran" writes: > > Module Name:src > > Committed By: ad > > Date: Mon Dec 9 21:02:10 UTC 2019 > > > > Modified Files: > > src/sys/kern: kern_rwlock.c > > > > Log Message: > > Expunge the panicstr checks, we don't need them. > > can you explain why? Sure, I have developed a bit of a feel for it after years off watching the thing panic. The checks to not go too hard on the assertions once panicstr are set are pretty good in my experience - we don't want that to snowball. The ones that disable locking were of some kind of use (at least to me) back in 2007 before we had a decent LOCKDEBUG setup for the newlock2 primitives. So it sprang out of development requirements and an uncertainty about all how this new synchronization stuff was going to behave in practice more than a desire to do the right thing. On a uniprocessor or dual core box back then the panicstr checks didn't really seem to have many bad effects, but with more CPUs it often seems to make the crash much worse than it needs to be and I keep bumping into the effects of it. Here's a craptacular example: http://www.netbsd.org/~ad/ That's kind of amusing to look at and it's only my framebuffer memory but I worry that it could just as well be inodes or mbufs or anything else that belongs to the user, and I think that until the CPUs are locked up and activity stopped, the thing needs to keep working as properly as it can. > what sort of crash-time testing did you perform? That the system can be debugged and reset cleanly. If we've got code in DDB that hangs up or crashdups don't work then that's something we should fix. I've not run into any in a long time, they seem to get fixed. Do you have a particular concern or something else in mind? Cheers, Andrew
Re: CVS commit: src/sys/arch (multiboot2 support)
Paul Goyette wrote: > This commit seems to have broken amd64 booting! When booting into > a qemu environment (as set up by misc/py-anita), it just hangs while > printing the "progress numbers with the spinny cursor". Others on > irc/icb have indicated an immediate crash. I rolled back the change to sys/arch/amd64/conf/kern.ldscript, this should fix BIOS boot. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
Re: CVS commit: src/sys/arch (multiboot2 support)
Paul Goyette wrote: > This commit seems to have broken amd64 booting! When booting into > a qemu environment (as set up by misc/py-anita), it just hangs while > printing the "progress numbers with the spinny cursor". Others on > irc/icb have indicated an immediate crash. > > Seems like non-efi booting is borked. This is caused by sys/arch/amd64/conf/kern.ldscript 1.27-1.28 I will fix that within a few hours. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
re: CVS commit: src/sys/kern
> > > Log Message: > > > Expunge the panicstr checks, we don't need them. > > > > can you explain why? > > Sure, [ .. ] ah, wow. i didn't realise it had such a bad effect on cpus before they actually go properly down. we should probably work hard to make them go down faster if possible, though maybe that's already as good as it can be. > > what sort of crash-time testing did you perform? > > That the system can be debugged and reset cleanly. If we've got code in DDB > that hangs up or crashdups don't work then that's something we should fix. > I've not run into any in a long time, they seem to get fixed. > > Do you have a particular concern or something else in mind? i was also curious about crash dumps working, but mostly this change is about reducing true lossage during a crash. thanks. .mrg.
Re: CVS commit: src/sys/arch (multiboot2 support)
This commit seems to have broken amd64 booting! When booting into a qemu environment (as set up by misc/py-anita), it just hangs while printing the "progress numbers with the spinny cursor". Others on irc/icb have indicated an immediate crash. Seems like non-efi booting is borked. Module Name:src Committed By: manu Date: Tue Dec 10 02:06:07 UTC 2019 Modified Files: src/sys/arch/amd64/amd64: locore.S machdep.c src/sys/arch/amd64/conf: GENERIC files.amd64 kern.ldscript src/sys/arch/x86/x86: efi.c multiboot2.c Log Message: Add multiboot 2 support to amd64 kernel To generate a diff of this commit: cvs rdiff -u -r1.192 -r1.193 src/sys/arch/amd64/amd64/locore.S cvs rdiff -u -r1.342 -r1.343 src/sys/arch/amd64/amd64/machdep.c cvs rdiff -u -r1.548 -r1.549 src/sys/arch/amd64/conf/GENERIC cvs rdiff -u -r1.113 -r1.114 src/sys/arch/amd64/conf/files.amd64 cvs rdiff -u -r1.27 -r1.28 src/sys/arch/amd64/conf/kern.ldscript cvs rdiff -u -r1.20 -r1.21 src/sys/arch/x86/x86/efi.c cvs rdiff -u -r1.2 -r1.3 src/sys/arch/x86/x86/multiboot2.c ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
