> Here they are (for netbsd-8). I can boot -d with them [...]
I just noticed that I still have these patches locally.
Any chances to get them into -8? Should I file a PR?
> So there seems to be something seriously amiss with I2C on -8 (and -9).
After fixing that, it boots again (with the adopted pmap changes).
Nevertheless, someone should review them, of course.
> Why not take spdmem out of your kernel config for now and test the
> pmap patches ?
It then panics in dbcool_chip_ident(). So there seems to be something seriously
amiss with I2C on -8 (and -9).
> Why not take spdmem out of your kernel config for now and test the
> pmap patches ?
Yes, could do that next week (ENOTIME currently). Anything special to test?
I've no idea what the code does resp. when it gets used.
wrote:
>> I‘ve backported the fixes, will post them later.
>
>Here they are (for netbsd-8). I can boot -d with them, but because of
>the spdmem panics, I can't tell whether the machine would run with them.
Why not take spdmem out of your kernel config for now and test the
pmap patches ?
> I‘ve backported the fixes, will post them later.
Here they are (for netbsd-8). I can boot -d with them, but because of the
spdmem panics, I can't tell whether the machine would run with them.
Someone(TM) should review them and request a pullup, please.
Not sure what to
> Am 12.11.2020 um 20:41 schrieb Andreas Gustafsson :
>
> t's probably easier to revert src/sys/arch/x86/x86/db_memrw.c 1.6
I‘ve backported the fixes, will post them later.
> It's probably easier to revert src/sys/arch/x86/x86/db_memrw.c 1.6.
As far as I understood (which may well be wrong) the fixes fixed a real
problem that only surfaced on that change by chance and might have other
consequences?
Edgar Fuß wrote:
> I had a look at the relevant commits
> src/sys/arch/x86/include/pmap.h 1.100
> src/sys/arch/x86/x86/pmap.c 1.330
> src/sys/arch/xen/x86/xen_pmap.c 1.31
> but unfortunately am unable to back-port the second one to -8.
> I know nothing about pmap, and the
> This looks like PR 53311.
Ah, thanks!
> The commit where that problem started (src/sys/arch/x86/x86/db_memrw.c 1.6)
> was pulled up to to the -8 branch, and apparently the commits that fixed it
> were not.
I currently seem to attract pull-ups that mess up things.
I had a look at the relevant
Edgar Fuß wrote:
> Real hardware (AMD64), 8.2_STABLE from yesterday, custom config.
This looks like PR 53311. The commit where that problem started
(src/sys/arch/x86/x86/db_memrw.c 1.6) was pulled up to to the -8
branch, and apparently the commits that fixed it were not.
--
Andreas Gustafsson,
On Thu, 12 Nov 2020, Edgar Fu? wrote:
Hello again.
In about the third nesting level of what I wanted to do in the first place,
I tried "boot netbsd -d" in the secondary boot. It loads the kernel, then
complains about the ffs module missing (I don't use modules and don't have
an 8.2 directory
Hello again.
In about the third nesting level of what I wanted to do in the first place,
I tried "boot netbsd -d" in the secondary boot. It loads the kernel, then
complains about the ffs module missing (I don't use modules and don't have
an 8.2 directory on that machine), clears the screen,
13 matches
Mail list logo
