Re: New "ahcisata0 port 1: device present" messages with NetBSD 9
from Izumi Tsutsui: > > > The problem here doesn't happen once after disabling NCQ by > > > "hw.wd2.use_ncq=0" in /etc/sysctl.conf. > > Excerpt from Simon Burge: > > > For now, I'm running with this in /etc/rc.d/sysctl0 (should be run > > > before fsck of /): > > Maybe this sysctl has to be in place from the outset, before user gets to > > the login prompt? > sysctl.conf(5) is handled by /etc/rc.d/sysctl, after > /etc/rc.d/fsck is done. If the SSD firmware NCQ bugs are > triggered during fsck(8), sysctl.conf setting doesn't help. > That's all. > > So I appended to /etc/sysctl.conf for NetBSD 8.99.51 amd64 and i386 > > hw.wd1.use_ncq=0 > > and rebooted to make the change take effect. > > Even so, it can take many hours to several days for the hard drive > > crash to occur, so it is too early to see if this will work on a > > Western Digital Green hard drive. > I'm not sure if there is any evidence that says certain WD drives > have bugs around NCQ functions. Maybe Simon Burge's details are inaccurately stated? I don't know but tried it anyway. Some things have to be done by the init system to take effect. This is true in Unix and quasi-Unix, DOS (C:\CONFIG.SYS), OS/2 and successors (C:\CONFIG.SYS), and I would guess MS-Windows as well. The idea that preventing the hard drive crash by putting "hw.wd1.use_ncq=0" in /etc/sysctl.conf is, for my situation, hypothesis and not confirmed. I had the notion that the hard drive crash would not happen when at a root console, but that proved wrong, the crash occurred, but took some days. My experience with WD Green hard drives is sufficiently unfavorable that I wouldn't want to buy such a hard drive ever again, and I guess enough other customers' experience was enough to prompt WD to discontinue the Green line. Tom
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)
> On Jan 14, 2020, at 2:37 PM, Christos Zoulas wrote:
>
> So what's the short term solution?
>
> - Don't define {MIN,MAX}_PAGE_SIZE on m68k?
> - Define a different constant?
> - Add a define to tell uvm to ignore {MIN,MAX}_PAGE_SIZE?
#ifdef _KERNEL, define {MIN,MAX}_PAGE_SIZE to a constant that matches the
system. For !_KERNEL, define MIN_PAGE_SIZE as 4096 and MAX_PAGE_SIZE as 8192.
Seems like that would do the trick.
-- thorpej
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)
> On Jan 14, 2020, at 10:16 AM, Christos Zoulas wrote: > > We do this to save space, but as you say, not important for now. Perhaps > the expedient solution is to define MALLOC_PAGE_SIZE... I'd rather keep the use of these constants separate... who knows what they might be used for in the future? Optimize #ifdef _KERNEL as-needed... -- thorpej
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)
On Jan 14, 8:54am, thor...@me.com (Jason Thorpe) wrote: -- Subject: Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/inclu | | | > On Jan 14, 2020, at 8:41 AM, Izumi Tsutsui wrot= | e: | >=20 | >> b) Modules should be built such that they can use a non-fixed PAGE_SIZE.= | | >=20 | > No, this is not necessary, because modules are built for each $MACHINE | > and (a) each $MACHINE has fixed PAGE_SIZE. | | Yes, understood. I think it would eventually be a nice idea to make module= | s $MACHINE_ARCH-sharable, but it's not critical for now. We do this to save space, but as you say, not important for now. Perhaps the expedient solution is to define MALLOC_PAGE_SIZE... christos
Re: New "ahcisata0 port 1: device present" messages with NetBSD 9
> > The problem here doesn't happen once after disabling NCQ by > > "hw.wd2.use_ncq=0" in /etc/sysctl.conf. > > Excerpt from Simon Burge: > > > For now, I'm running with this in /etc/rc.d/sysctl0 (should be run > > before fsck of /): > > Maybe this sysctl has to be in place from the outset, before user gets to the > login prompt? sysctl.conf(5) is handled by /etc/rc.d/sysctl, after /etc/rc.d/fsck is done. If the SSD firmware NCQ bugs are triggered during fsck(8), sysctl.conf setting doesn't help. That's all. > So I appended to /etc/sysctl.conf for NetBSD 8.99.51 amd64 and i386 > hw.wd1.use_ncq=0 > and rebooted to make the change take effect. > > Even so, it can take many hours to several days for the hard drive > crash to occur, so it is too early to see if this will work on a > Western Digital Green hard drive. I'm not sure if there is any evidence that says certain WD drives have bugs around NCQ functions. --- Izumi Tsutsui
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)
> On Jan 14, 2020, at 8:41 AM, Izumi Tsutsui wrote: > >> b) Modules should be built such that they can use a non-fixed PAGE_SIZE. > > No, this is not necessary, because modules are built for each $MACHINE > and (a) each $MACHINE has fixed PAGE_SIZE. Yes, understood. I think it would eventually be a nice idea to make modules $MACHINE_ARCH-sharable, but it's not critical for now. -- thorpej
Re: MAX_PAGE_SIZE for m68k (Re: CVS commit:src/sys/arch/arm/include/arm32)
> > The arm PAGE_SIZE_{MIN,MAX} should go away after nick eliminates the
> > need for the 8K pages. This leaves us with m68k to deal with...
> > Do modules work on m68k?
Yes, at least on NetBSD/news68k 9.0_RC1:
(though something wrong in modunload(8))
---
# uname -a
NetBSD 9.0_RC1 NetBSD 9.0_RC1 (GENERIC) #0: Wed Nov 27 16:14:52 UTC 2019
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/news68k/compile/GENERIC news68k
# modstat | grep ext2fs
# modload ext2fs
# modstat | grep ext2fs
ext2fs vfs filesys -0 47856 ufs
# dd if=/dev/zero of=/tmp/img bs=1m count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 1.260 secs (832203 bytes/sec)
# vnconfig vnd0 /tmp/img
newfs_ext2fs -I /dev/rvnd0c
/dev/rvnd0c: 1.0MB (2048 sectors) block size 1024, fragment size 1024
using 1 block groups of 8.0MB, 8192 blks, 128 inodes.
super-block backups (for fsck_ext2fs -b #) at:
# mount_ext2fs /dev/vnd0a /mnt
# mount
/dev/sd0a on / type ffs (log, local)
/dev/sd0g on /usr type ffs (log, local)
/dev/vnd0a on /mnt type ext2fs (local)
# umount /mnt
# modunload ext2fs
# mount_ext2fs /dev/vnd0a /mnt
# umount /mnt
# modunload ext2fs
[ 853.1800080] WARNING: module error: module `ext2fs' not found
modunload: ext2fs: No such file or directory
# mount_ext2fs /dev/vnd0a /mnt
# mount
/dev/sd0a on / type ffs (log, local)
/dev/sd0g on /usr type ffs (log, local)
/dev/vnd0a on /mnt type ext2fs (local)
# ls -l /mnt
total 12
drwx-- 2 root wheel 12288 Jan 14 16:10 lost+found
#
---
Note there is something wrong around ksyms(4) on NetBSD/sun3 9.0_RC1...
---
# uname -a
NetBSD 9.0_RC1 NetBSD 9.0_RC1 (MODULAR) #0: Tue Jan 14 23:20:20 JST 2020
tsutsui@mirage:/s/netbsd-9/src/sys/arch/sun3/compile/MODULAR sun3
# modload ext2fs
[ 50.9300220] kobj_checksyms, 988: [ext2fs]: linker error: symbol `memcpy' not
found
[ 50.9700220] kobj_checksyms, 988: [ext2fs]: linker error: symbol `memcmp' not
found
[ 51.0200220] WARNING: module error: unable to affix module `ext2fs', error 8
modload: ext2fs: Exec format error
# savecore
savecore: (null): _version not in namelist
#
---
(IIRC it worked when I tweaked symbols to share module binaries
between sun3 and sun3x...)
> > Should modules be shared between kernels with
> > different page sizes? Then perhaps we don't need a new constant?
>
> On m68k, I think the following two statements are true:
>
> a) The platform should use a constant PAGE_SIZE to the extent possible
> because it's a slow platform.
Yes, and this is already true.
> b) Modules should be built such that they can use a non-fixed PAGE_SIZE.
No, this is not necessary, because modules are built for each $MACHINE
and (a) each $MACHINE has fixed PAGE_SIZE.
> But (b) also requires that all of the OTHER non-same constants on m68k
> are avoided (take a closer look at for example).
> Those probably should be properly hidden from module builds so that
> we can at least *catch* such cases.
(b) is not necessary, so it's simply okay to have a macro that represents
"maximum page size for the ${MACHINE_ARCH}" for jemalloc(3), isn't it?
---
Izumi Tsutsui
