Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplay tty devices
tls@ wrote:
> On Fri, Apr 12, 2024 at 09:13:17AM -0400, Thor Lancelot Simon wrote:
> > On Sat, Apr 06, 2024 at 11:56:27PM +0900, Izumi Tsutsui wrote:
> > >
> > > I'd like to add new APIs to use wskbd(4) input on non-wsdisplay
> > > tty devices, especially news68k that can use a putchar function
> > > provided by firmware PROM as a kernel console device.
> >
> > Wouldn't a tty be a better abstraction for this? Lots of minicomputers
> > had incredibly dumb serial consoles.
>
> I think the above is not clear. To rephrase my question: what is the
> wscons layer actually adding here? Would it not be simpler to interface
> at the tty layer instead?
- The tty layer requires both getchar() and putchar().
- For a glass console, completely different two drivers are necessary,
i.e. keyboard driver for getchar() and display driver for putchar().
- On news68k, it's not easy to implement framebuffer driver due to
lack of information, but we can use a putchar() function provided
by a NEWS PROM firmware because it also supports VT emulation.
- On the other hand, we cannot use getchar() function provided by a
NEWS PROM firmware for useland because it uses busy loop to wait
keyboard input. But we already has a wskbd driver for NEWS machines.
- So I would like propose adding APIs "to use wskbd driver just for
keyboard inputs" for non-wscons(4) tty drivers
See sys/arch/sun3/dev/kd.c for another example that use
"PROM function for putchar() to display and
sys/dev/sun/kbd.c via zs(4) for getchar() from keyboard".
https://github.com/NetBSD/src/blob/6053b8d/sys/arch/sun3/dev/kd.c
---
static void
kdstart(struct tty *tp)
{
struct clist *cl;
int s1, s2;
s1 = splsoftclock();
s2 = spltty();
if (tp->t_state & (TS_BUSY|TS_TTSTOP|TS_TIMEOUT))
goto out;
cl = >t_outq;
if (ttypull(tp)) {
if (kd_is_console) {
tp->t_state |= TS_BUSY;
if ((s1 & PSL_IPL) == 0) {
/* called at level zero - update screen now. */
splx(s2);
kd_putfb(tp);
[...]
}
[...]
/*
* Put text on the screen using the PROM monitor.
* This can take a while, so to avoid missing
* interrupts, this is called at splsoftclock.
*/
static void
kd_putfb(struct tty *tp)
{
char buf[PUT_WSIZE];
struct clist *cl = >t_outq;
char *p, *end;
int len;
while ((len = q_to_b(cl, buf, PUT_WSIZE-1)) > 0) {
/* PROM will barf if high bits are set. */
p = buf;
end = buf + len;
while (p < end)
*p++ &= 0x7f;
(romVectorPtr->fbWriteStr)(buf, len);
}
}
[...]
/*
* Our "interrupt" routine for input. This is called by
* the keyboard driver (dev/sun/kbd.c) at spltty.
*/
void
kd_cons_input(int c)
{
struct kd_softc *kd = _softc;
struct tty *tp;
/* XXX: Make sure the device is open. */
tp = kd->kd_tty;
if (tp == NULL)
return;
if ((tp->t_state & TS_ISOPEN) == 0)
return;
(*tp->t_linesw->l_rint)(c, tp);
}
---
sys/arch/news68k/news68k/romcons.c has the similar implementation:
https://github.com/tsutsui/netbsd-src/blob/c74b64a/sys/arch/news68k/news68k/romcons.c
---
static void
romcons_start(struct tty *tp)
{
int s, len;
uint8_t buf[BURSTLEN];
s = spltty();
if (tp->t_state & (TS_TIMEOUT | TS_BUSY | TS_TTSTOP)) {
splx(s);
return;
}
tp->t_state |= TS_BUSY;
splx(s);
len = q_to_b(>t_outq, buf, BURSTLEN);
s = splhigh();
rom_write(1, buf, len);
splx(s);
s = spltty();
tp->t_state &= ~TS_BUSY;
if (ttypull(tp)) {
tp->t_state |= TS_TIMEOUT;
callout_schedule(>t_rstrt_ch, 1);
}
splx(s);
}
[...]
#if NWSKBD > 0
static void
romcons_kbdinput(device_t self, int ks)
{
struct romcons_softc *sc = device_private(self);
struct tty *tp;
KASSERT(sc != NULL);
tp = sc->sc_tty;
if (tp && (tp->t_state & TS_ISOPEN))
(*tp->t_linesw->l_rint)(ks, tp);
}
#endif
---
Izumi Tsutsui
Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplayttydevices
uwe@ wrote: > > On the other hand, news68k (and sun) machines have putchar() > > that also handles virtual terminal ops like backspace, CR/LF, > > and even scrolling at the bottom of screen. In this case > > no VT emulation layer is necessary in the kernel side, > > so kernel's putc(9) just calls firmware's putchar(), > > and for userland processes we can simply pass translated > > wskbd inputs to line discipline of the tty device. > > > > That's the reason why I proposed to add register/deregister > > APIs to pass wskbd data to romcons tty device. > > > > What do you think about this case? > > Add trivial wsemul_none (or wsemul_delegate, or whatever a suitable > name might be) that does even less than wsemul_dumb and only ever uses > putchar to pass chars to the firmware emulator? I considered about it when I tried to implement news68k ROM console driver, but I gave it up because: - wscons(9) was the most complicated driver with undocumented APIs (struct wsemul_ops etc.) - wsdisplay(9) would pull a lot of unnecessary sources like wsdisplay.c etc. (for screen ops) while TERM=wsvt25 could not be used - there was no sample implementation using "putchar() with VT emulation" - on the other hand there were simple implementation for PROM console functions (sys/arch/sun3/dev/kd.c and sys/dev/ofw/ofcons.c etc.) and actually it was quite simple to connect wskbd(4) to "romcons" driver Thanks, --- Izumi Tsutsui
Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplayttydevices
macallan@ wrote: > On Sun, 7 Apr 2024 14:49:42 +0900 > Izumi Tsutsui wrote: > > > macallan@ wrote: > > > > > > I'd like to add new APIs to use wskbd(4) input on non-wsdisplay > > > > tty devices, especially news68k that can use a putchar function > > > > provided by firmware PROM as a kernel console device. > > > > > > > > # Details > > > > > > > > The news68k machines have various framebuffer options, but > > > > most of them are not "dumb" framebuffer that can be handled > > > > by raspos(9) but some of them have own processors (68000 etc.) > > > > to handle various acceleration etc. so it's difficult to implement > > > > framebuffer drivers. > > > > > > You can use wsdisplay without rasops or a mappable framebuffer. > > > Examples would be things like newport or crmfb on sgimips. > > > > It looks both newport and crmfb has copy and erase ops. > > As I wrote another post, news68k PROM only provides putchar() function > > (At least there is no info other framebuffer ops). > > There is already code in vcons which uses putchar() to implement > copy*() ( to avoid slow fb reads ), using it for erase*() is trivial. > > > This means all pseudo terminal ops (backspace, clear screen etc.) > > are handled by the PROM. I still wonder if wscons(9) provides > > proper interface in such case. > > With vcons you can implement pretty much everything using just putchar > - since there's a character and attribute buffer you just do your > operations on the buffer and update the screen character by character. > For copy operations on dumb framebuffers this is usually faster since > it avoids framebuffer reads which can be painfully slow. Genfb uses a > lot of tricks like that. > Not the intended use when I wrote it, but it's a welcome side effect. > In fact I wrote colour and virtual console support for STI like that, > didn't commit it because it interferes with the early console support > which I have no way to test. STI has no inverse operation ( or any ROP > support at all ) so I implemented cursor() using putchar. > > > > > To support "text only" framebuffer console, we can use putchar > > > > functions provided by the firmware PROM. > > > > > > Does it let you draw characters wherever you want with colours of > > > inverse attrubute? > > > If so, that's enough for wsdisplay - sti on hppa does just that. > > > > Probably no color or inverse ops, unless PROM putchar() supports > > proper escape sequence of them. > > Oh, so it's an entire terminal emulation, not just something that lets > you draw characters? Ah, maybe I see misunderstandings among us. In sgimips crmfb and newport cases, a putchar() function provided by the firmware just draws a character (glyph) at the cursor or specified position. All virtual terminal emulation ops are done in wsdisplay(9) and vcons(9) layer and MD drivers just draw characters (or whitespace) per vcons pseudo text VRAM attributes. On the other hand, news68k (and sun) machines have putchar() that also handles virtual terminal ops like backspace, CR/LF, and even scrolling at the bottom of screen. In this case no VT emulation layer is necessary in the kernel side, so kernel's putc(9) just calls firmware's putchar(), and for userland processes we can simply pass translated wskbd inputs to line discipline of the tty device. That's the reason why I proposed to add register/deregister APIs to pass wskbd data to romcons tty device. What do you think about this case? Thanks, --- Izumi Tsutsui
Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplay ttydevices
macallan@ wrote: > > I'd like to add new APIs to use wskbd(4) input on non-wsdisplay > > tty devices, especially news68k that can use a putchar function > > provided by firmware PROM as a kernel console device. > > > > # Details > > > > The news68k machines have various framebuffer options, but > > most of them are not "dumb" framebuffer that can be handled > > by raspos(9) but some of them have own processors (68000 etc.) > > to handle various acceleration etc. so it's difficult to implement > > framebuffer drivers. > > You can use wsdisplay without rasops or a mappable framebuffer. > Examples would be things like newport or crmfb on sgimips. It looks both newport and crmfb has copy and erase ops. As I wrote another post, news68k PROM only provides putchar() function (At least there is no info other framebuffer ops). This means all pseudo terminal ops (backspace, clear screen etc.) are handled by the PROM. I still wonder if wscons(9) provides proper interface in such case. kd_cons_input() in sys/arch/sun3/dev/kd.c has the similar storategy https://github.com/NetBSD/src/blob/2722c57/sys/arch/sun3/dev/kd.c#L401-L419 https://github.com/NetBSD/src/blob/2722c57/sys/dev/sun/kbd.c#L733-L746 but sun3 port doesn't use wscons. (yet?) > > To support "text only" framebuffer console, we can use putchar > > functions provided by the firmware PROM. > > Does it let you draw characters wherever you want with colours of > inverse attrubute? > If so, that's enough for wsdisplay - sti on hppa does just that. Probably no color or inverse ops, unless PROM putchar() supports proper escape sequence of them. Thanks, --- Izumi Tsutsui
Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplay tty devices
uwe@ wrote:
> On Sat, Apr 06, 2024 at 23:56:27 +0900, Izumi Tsutsui wrote:
>
> > To support "text only" framebuffer console, we can use putchar
> > functions provided by the firmware PROM.
>
> Is that a console-typewriter--like device without addressable cursor
> terminal emulation? Can you use wsemul_dumb to avoid rasops ? It
> still uses copy/erase, but with trivial argument values that can be
> reversed back to puchar calls for tab/lf (from a very quick look).
The PROM provides (at least I can use) only a "putchar()" function.
No other framebuffer ops like bitblt.
For now I cannot find any proper implementation example in such case..
> > The attached patch provides new two APIs
> > - wskbd_consdev_kbdinput_register()
> > - wskbd_consdev_kbdinput_deregister()
> > to allow a kernel to use wskbd(9) for non-wsdisplay tty device.
>
> AFAIU, there's nothing console-specific in this (except that it's
> first use is going to be for a console), so may be it would be better
> to drop the "consdev" from the name?
Hmm.
Actually it is not a "console" device (by sys/dev/cons.c) of the kernel,
but I just intended it as a "screen console (not a serial one)".
What name should we use in such case?
dispdev? scrndev? putchar?
"wskbd_ttyinput_register()" and "ttydev" (for members) or something?
> > Index: sys/dev/wscons/wskbd.c
> > ===
> > RCS file: /cvsroot/src/sys/dev/wscons/wskbd.c,v
> > retrieving revision 1.143
> > diff -u -p -d -r1.143 wskbd.c
> > --- sys/dev/wscons/wskbd.c 5 Feb 2019 10:04:49 - 1.143
> > +++ sys/dev/wscons/wskbd.c 6 Apr 2024 06:59:50 -
> [...]
> > @@ -706,6 +709,24 @@ wskbd_input(device_t dev, u_int type, in
> > }
> > #endif
> >
> > +#if NWSDISPLAY == 0
> > + if (sc->sc_translating) {
>
> The #endif above is for NWSDISPLAY > 0, so may be get rid of the
> ifdefs and use plain ifs?
It looks wskbd(9) assumes always attached to wsdisplay(9) (ttyE?)
if wsdisplay(4) is configured (in the above #if NWSDISPLAY >0 block)
even if no wsdisplay(4) devices are actually attached.
In my news68k case, I thought we should not override the current
assumptions even in the wskbd_consdev_kbdinput_register() case.
I have a feeling we should have separate 'if (sc->sc_translating)'
blocks for both case. Maybe we can simply use #else like:
#if NWSDISPLAY > 0
[send kbd inputs to wsdisplay_kbdinput() and return unconditionally]
#else
[send kbd inputs to sc_consdev_kbdinput() and return if it's registered]
#endif
Thanks,
---
Izumi Tsutsui
[RFC] new APIs to use wskbd(4) input on non-wsdisplay tty devices
->sc_consdev = NULL;
+}
+
static int
wskbd_translate(struct wskbd_internal *id, u_int type, int value)
{
Index: sys/dev/wscons/wskbdvar.h
===
RCS file: /cvsroot/src/sys/dev/wscons/wskbdvar.h,v
retrieving revision 1.19
diff -u -p -d -r1.19 wskbdvar.h
--- sys/dev/wscons/wskbdvar.h 2 Sep 2012 21:14:56 - 1.19
+++ sys/dev/wscons/wskbdvar.h 6 Apr 2024 06:59:50 -
@@ -104,6 +104,14 @@ device_t wskbd_hotkey_register(device_t,
voidwskbd_hotkey_deregister(device_t);
/*
+ * Callbacks from the keyboard driver to non-wscons console drivers.
+ */
+typedef void (wskbd_consdev_kbdinput)(device_t, int);
+device_t wskbd_consdev_kbdinput_register(device_t, wskbd_consdev_kbdinput *,
+device_t);
+void wskbd_consdev_kbdinput_deregister(device_t);
+
+/*
* set a translation table for scancodes in event mode
* parameters are a pointer to the table and its length
* pass length zero to turn translation off
Index: sys/arch/news68k/conf/GENERIC
===
RCS file: /cvsroot/src/sys/arch/news68k/conf/GENERIC,v
retrieving revision 1.133
diff -u -p -d -r1.133 GENERIC
--- sys/arch/news68k/conf/GENERIC 26 Apr 2019 21:40:31 - 1.133
+++ sys/arch/news68k/conf/GENERIC 6 Apr 2024 06:59:50 -
@@ -202,7 +202,7 @@ ss* at scsibus? target ? lun ? # SCSI s
uk*at scsibus? target ? lun ? # unknown SCSI devices
# PROM console support
-#romcons0 at mainbus0
+romcons0 at mainbus0
#
# accept filters
Index: sys/arch/news68k/conf/INSTALL
===
RCS file: /cvsroot/src/sys/arch/news68k/conf/INSTALL,v
retrieving revision 1.65.4.1
diff -u -p -d -r1.65.4.1 INSTALL
--- sys/arch/news68k/conf/INSTALL 10 Feb 2020 18:28:33 - 1.65.4.1
+++ sys/arch/news68k/conf/INSTALL 6 Apr 2024 06:59:50 -
@@ -134,7 +134,7 @@ st* at scsibus? target ? lun ? # SCSI t
cd*at scsibus? target ? lun ? # SCSI CD-ROMs
# PROM console support
-#romcons0 at mainbus0
+romcons0 at mainbus0
# Misc.
pseudo-device bpfilter# Berkeley Packet Filter
Index: sys/arch/news68k/news68k/romcons.c
===
RCS file: /cvsroot/src/sys/arch/news68k/news68k/romcons.c,v
retrieving revision 1.3
diff -u -p -d -r1.3 romcons.c
--- sys/arch/news68k/news68k/romcons.c 25 Jul 2014 08:10:34 - 1.3
+++ sys/arch/news68k/news68k/romcons.c 6 Apr 2024 06:59:50 -
@@ -37,6 +37,8 @@
#include
__KERNEL_RCSID(0, "$NetBSD: romcons.c,v 1.3 2014/07/25 08:10:34 dholland Exp
$");
+#include "wskbd.h"
+
#include
#include
#include
@@ -47,6 +49,9 @@ __KERNEL_RCSID(0, "$NetBSD: romcons.c,v
#include
#include
+#if NWSKBD > 0
+#include
+#endif
#include
#include
@@ -59,6 +64,8 @@ struct romcons_softc {
struct callout sc_poll_ch;
int sc_flags;
#defineCONS_POLL 1
+
+ device_t sc_kbdinput_dv;
};
#defineBURSTLEN128 /* max number of bytes to write in one
chunk */
@@ -79,7 +86,10 @@ dev_type_ioctl(romcons_ioctl);
dev_type_tty(romcons_tty);
dev_type_poll(romcons_poll);
-void romcons_kbdinput(int);
+#if NWSKBD > 0
+static void romcons_attach_deferred(device_t);
+static void romcons_kbdinput(device_t, int);
+#endif
const struct cdevsw romcons_cdevsw = {
.d_open = romcons_open,
@@ -129,8 +139,35 @@ romcons_attach(device_t parent, device_t
aprint_normal("\n");
callout_init(>sc_poll_ch, 0);
+
+#if NWSKBD > 0
+ config_defer(self, romcons_attach_deferred);
+#endif
}
+#if NWSKBD > 0
+static void
+romcons_attach_deferred(device_t self)
+{
+ struct romcons_softc *sc;
+ device_t wskbd_dev;
+
+ sc = device_private(self);
+ KASSERT(sc != NULL);
+
+ /* XXX assume only one keyboard at wskbd0 */
+ wskbd_dev = device_lookup(_cd, 0);
+ if (wskbd_dev == NULL) {
+ aprint_error_dev(self, "no wskbd0 is attached\n");
+ return;
+ }
+
+ /* attach wskbd hook for tty(4) of userland processes */
+ sc->sc_kbdinput_dv =
+ wskbd_consdev_kbdinput_register(wskbd_dev, romcons_kbdinput, self);
+}
+#endif
+
static void romcons_start(struct tty *);
static int romcons_param(struct tty *, struct termios *);
static void romcons_pollin(void *);
@@ -294,17 +331,19 @@ romcons_pollin(void *aux)
callout_reset(>sc_poll_ch, 1, romcons_pollin, sc);
}
-void
-romcons_kbdinput(int ks)
+#if NWSKBD > 0
+static void
+romcons_kbdinput(device_t self, int ks)
{
- struct romcons_softc *sc;
+ struct romcons_softc *sc = device_private(self);
struct tty *tp;
- sc = device_lookup_private(_cd, 0);
+ KASSERT(sc != NULL);
tp = sc->sc_tty;
if (tp && (tp->t_state & TS_ISOPEN))
(*tp->t_linesw->l_rint)(ks, tp);
}
+#endif
void
romcons_cnprobe(struct consdev *cd)
---
Thanks,
---
Izumi Tsutsui
pagedaemon spins due to KVM shortage on NetBSD/i386 10.0_BETA?
Recently I observed excessive CPU loads due to pagedaemon spin on NetBSD/i386 10.0_BETA GENERIC from daily snapshot: --- % uname -a NetBSD mirage 10.0_BETA NetBSD 10.0_BETA (GENERIC) #0: Thu Jul 27 18:10:25 UTC 2023 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/i386/compile/GENERIC i386 % top -n load averages: 1.23, 1.24, 1.10; up 6+17:26:3722:13:37 107 processes: 18 runnable, 84 sleeping, 2 stopped, 3 on CPU CPU states: 9.6% user, 0.0% nice, 27.2% system, 0.5% interrupt, 62.6% idle Memory: 2001M Act, 980M Inact, 73M Wired, 170M Exec, 964M File, 27M Free Swap: 8972M Total, 1403M Used, 7569M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPUCPU COMMAND 0 root 1260 0K 35M CPU/2423:09 99.02% 99.02% [system] 7312 tsutsui 430 2250M 598M CPU/3100:13 14.89% 14.89% firefox 25088 tsutsui 410 712M 179M parked/1 123:01 10.50% 10.50% firefox 15769 tsutsui 430 815M 203M parked/0 17:03 0.49% 0.49% firefox 8897 tsutsui 430 595M 139M parked/3 1:09 0.39% 0.39% firefox 16559 tsutsui 430 460M 37M parked/0 0:01 0.10% 0.10% firefox 833 tsutsui 430 153M 58M RUN/3 61:31 0.00% 0.00% X 2943 tsutsui 85082M 6488K select/0 6:49 0.00% 0.00% jwm 21097 tsutsui 850 728M 108M RUN/0 4:33 0.00% 0.00% firefox 3434 tsutsui 85087M 4652K poll/1 3:31 0.00% 0.00% pulseaudio [...] % top -t -n load averages: 0.89, 1.17, 1.12; up 6+17:33:2522:20:25 839 threads: 20 idle, 4 runnable, 784 sleeping, 2 stopped, 27 zombie, 2 on CPU CPU states: 7.5% user, 0.0% nice, 27.9% system, 0.2% interrupt, 64.2% idle Memory: 2003M Act, 980M Inact, 80M Wired, 170M Exec, 964M File, 18M Free Swap: 8972M Total, 1403M Used, 7569M Free PID LID USERNAME PRI STATE TIME WCPUCPU NAME COMMAND 0 170 root 126 CPU/2368:23 99.02% 99.02% pgdaemon [system] 7312 12379 tsutsui 42 parked/3 19:30 5.22% 5.22% WRRenderB firefox 7312 25622 tsutsui 85 poll/029:34 4.98% 4.98% Renderer firefox 7312 7312 tsutsui 43 parked/3 24:02 4.10% 4.10% MainThrea firefox 25088 10023 tsutsui 42 parked/1 29:57 3.42% 3.42% - firefox 0 171 root 124 syncer/3 25:05 3.22% 3.22% ioflush [system] 25088 7474 tsutsui 43 parked/0 30:13 2.83% 2.83% - firefox 833 833 tsutsui 43 RUN/1 59:01 1.51% 1.51% - X [...] % vmstat -m Memory resource pool statistics NameSize Requests Fail Releases Pgreq Pgrel Npage Hiwat Minpg Maxpg Idle amappl52 4170200 380857 96085 875 960 0 inf0 anonpl20 69687350 6372592 5721 642 5079 5591 0 inf0 ataspl 104 124141720 124141721413 1 2 0 inf1 biopl17641315041310 316 315 144 0 inf0 buf16k 16896 1780 1672723 410 0 inf0 buf1k 1536 430 43 2 1 1 2 0 inf1 buf2k 2560 300 30 2 1 1 2 0 inf1 buf32k 32768 28212026146 5075 3980 1095 2481 0 inf0 buf4k 460869567068547 3488 3372 116 1626 0 inf0 buf512b 1024 36030 3602 3 2 1 3 0 inf0 buf64k 65536 800 9 0 9 9 0 inf1 buf8k 8704 2900 2751916 3 7 0 inf0 bufpl17660606057485 1519 1229 290 1112 0 inf0 cwdi 192 26230 251717 9 810 0 inf0 dirhash 340 6200 32230 42627 0 inf0 dirhashblk 2048 37360 1324 1767 561 1206 1206 0 inf0 ehcixfer 208302 1 0 1 1 0 inf0 ehcixfer 208302 1 0 1 1 0 inf0 execargs262144 1158600 115860 157 156 1 3 0161 extent24 10540 982 1 0 1 1 0 inf0 fcrpl108 500 46 2 0 2 2 2 inf1 fdfile6460424055279 232 14191 145 0 inf0 ffsdino2 260 186220085580 7533 197 7336 7347 0 inf0 ffsino 196 186240085600 560599 5506 5510 0 inf0 file 12841127039246 114417381 0 inf0 filedesc 704 26090 250399693041 0 inf0 fstlwp64 61320 546114 01414 0 inf0 icmp 20 8450 8453434 0 1 0 inf0 icmp6 2055706055706 441 440 1 1 0 inf1 in4pcbpl 192 50520 4954
Re: SCSI Polled io fixes for mac68k with PDMA enabled.
> I've found while working with mac68k that devices that require polled io scsi > transfers would fail with sbc pdma (pseudo dma) would fail when reading and > writing to the respective device. > > I've found that virtual devices for rascsi and the scsi2sd drives would fail > using pdma. For virtual disks they would fail always when writing to the > device, reads were ok. > > For virtual ethernet devices they would fail for reading and writing. It looks more detailed information is necessary. - How does it fail? Lost interrupts? Generic SCSI xfer errors? - Does the mac68k sbc (with MI ncr5380sbc) work with other real SCSI devices (at least on your machine)? - Per obio/sbc_obio.c SBC_INTR and SBC_RESELECT are disabled on MACIIFX and MACPB500 (maybe no working interrupts). https://github.com/NetBSD/src/blob/43d029e4b58545fb46624a260279892a85d8a211/sys/arch/mac68k/obio/sbc_obio.c#L131 Does PDMA work on other machines (i.e. with working interrupts)? - Furthermore, why do you check XS_CTL_POLL instead of SBC_INTR in sc_options? - Does the RaSCSI etc. work with GENERIC (not GENERICSBC)? I don't know a history why mac68k has both MI ncr5380 (GENERICSBC) and the own NCR5380 driver (GENERIC with dev/mac68k5380.c) for years. - I wonder if these SCSI emulation devices using GPIO controled by own software comply various xfer timings defined in SCSI spec. (I have a drive with IDE-SCSI converter that emit errors on news68k SCSI with MI ncr5380) - I also wonder if the first byte of write xfer should be written on manualy PDMA write, as eps_dma_go() in mac68k/obio/esp.c https://github.com/NetBSD/src/blob/43d029e4b58545fb46624a260279892a85d8a211/sys/arch/mac68k/obio/esp.c#L564 --- Izumi Tsutsui
Re: Removing extsrc: (was Re: Proposal: Deprecate (or rename) extsrc/)
lukem@ wrote: > | (Also, if I recall correctly, "extsrc/" without much consultation). There was a proposal on tech-toolchain: https://mail-index.netbsd.org/tech-toolchain/2009/11/29/msg000790.html but I could not imagine a typical usecase at that time. > I only received support for removing extsrc. > There were no comments to retain as-is or to retain with a different > directory name. I agree name-complete conflicts are always annoying and I'd also favor your proposal. Thanks, --- Izumi Tsutsui
Re: cpu_rootconf() vs booted_device issues
mrg@ wrote: > cpu_rootconf problems.most of these only need to have eg > "if (booted_device) return;" added to a function usually > called findroot() or set_root_device(): : > atari > - also checks RB_ASKNAME, which means no default will be set > (consider removing this check here) As commented in the its cpu_rootconf(), it's inside of "#if defined(MEMORY_DISK_HOOKS)" and necessary for the atari specific "auto load mdroot image from floppy on the first open" for installation, after md(4) has been changed to be dynamically configured: https://mail-index.netbsd.org/source-changes/2010/11/11/msg014346.html https://nxr.netbsd.org/xref/src/sys/arch/atari/atari/autoconf.c?r=1.71#91 "ustarfs based multiple install floppies for atari" is in my todo list, but it requires more detailed info about TOS (an atari's native OS) internal BIOS functions for raw I/O accesses.. --- Izumi Tsutsui
Re: timecounters
manu@ wrote: > The NetBSD kernel can use multiple timecounters for time keeping, the > choices available are shown by sysctl kern.timecounter.choice, and > the chosen timecounter is decided by kern.timecounter.hardware. > > It seems the alternatives, their pros and cons, are not documented. > Did I miss it? All I found is PHK's paper referenced from timecounter(9), > which documents TSC, i8254 and ACPI. I think it would be nice to add > a few words about the available timecounters. IIUC, the essencial part about these counters is in timecounter(9): >> A timecounter is a binary counter which has two properties: >> o it runs at a fixed, known frequency; and >> o it has sufficient bits to not roll over in less than >> approximately max(2 msec, 2/HZ seconds) (the value 2 here is >> really 1 + delta, for some indeterminate value of delta). I.e. - All MD counters have these properties - Impliclitly higher frequency and larger bits are preferred - tc_quality in each struct timecounter implicitly describes priorities > clockinterrupt: not documented at all? See sys/kern/kern_clock.c This seems a rough counter by hardclock(9). It's avaliable on all systems, so used as timecouneter(9) on machines that have no MD binary counters. Describing all MD counters is not so bad idea, but maybe we rather want proper documentation in www.netbsd.org or timecounter(9)? (Note I asked kardel@ about timecounter implementation many years ago and that was the reason why I imported and updated timecouneter(9) man pages per OpenBSD's tc_init(9)..) --- Izumi Tsutsui
Re: patch for am7930 audio
> > By the way, I'm not so familiar to sparc. > > audioamd(4) has many assembly code (though they look very old stuff). > > For what it's worth...I don't know what "very old" means to you, but I > see no assembly code in arch/sparc/dev/audioamd* on 5.2 (the .c > datestamped 2010, the .h, 2005). It's in sparc/sparc/amd7930intr.s. --- Izumi Tsutsui
Re: New "ahcisata0 port 1: device present" messages with NetBSD 9
> After patch: > > wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 > (Ultra/133) (using DMA), WRITE DMA FUA EXT : > tsutsui - are you able to test the patch too? Disabled as expected on netbsd-9. Please go ahead. --- ahcisata0 at pci0 dev 18 function 0: vendor 1002 product 4380 (rev. 0x00) ahcisata0: ignoring broken port multiplier support ahcisata0: ignoring broken NCQ support ahcisata0: AHCI revision 1.10, 4 ports, 32 slots, CAP 0xb3209f83 ahcisata0: interrupting at ioapic0 pin 22 atabus0 at ahcisata0 channel 0 atabus1 at ahcisata0 channel 1 atabus2 at ahcisata0 channel 2 atabus3 at ahcisata0 channel 3 : ahcisata0 port 0: device present, speed: 3.0Gb/s ahcisata0 port 1: device present, speed: 3.0Gb/s ahcisata0 port 2: device present, speed: 3.0Gb/s ahcisata0 port 3: device present, speed: 1.5Gb/s : wd0 at atabus0 drive 0 wd0: wd0: drive supports 16-sector PIO transfers, LBA48 addressing wd0: 1863 GB, 3876021 cyl, 16 head, 63 sec, 512 bytes/sect x 3907029168 sectors wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) w/PRIO wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), WRITE DMA FUA EXT wd1 at atabus1 drive 0 wd1: wd1: drive supports 16-sector PIO transfers, LBA48 addressing wd1: 1863 GB, 3876021 cyl, 16 head, 63 sec, 512 bytes/sect x 3907029168 sectors wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) w/PRIO wd1(ahcisata0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), WRITE DMA FUA EXT wd2 at atabus2 drive 0 wd2: wd2: drive supports 1-sector PIO transfers, LBA48 addressing wd2: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), WRITE DMA FUA, NCQ (32 tags) wd2(ahcisata0:2:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA), WRITE DMA FUA EXT atapibus0 at atabus3: 1 targets cd0 at atapibus0 drive 0: cdrom removable cd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) cd0(ahcisata0:3:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133) (using DMA) : --- Izumi Tsutsui
Re: MAX_PAGE_SIZE for m68k (Re: CVScommit:src/sys/arch/arm/include/arm32)
Override the PAGE_* definitions to be compile-time constants. + * Use common m68k definitions to define PAGE_SIZE and related constants. */ -#definePAGE_SHIFT PGSHIFT -#definePAGE_SIZE (1 << PAGE_SHIFT) -#definePAGE_MASK (PAGE_SIZE - 1) +#include /* * USRSTACK is the top (end) of the user stack. Index: sys/arch/mvme68k/include/vmparam.h === RCS file: /cvsroot/src/sys/arch/mvme68k/include/vmparam.h,v retrieving revision 1.37 diff -u -p -d -r1.37 vmparam.h --- sys/arch/mvme68k/include/vmparam.h 28 Jun 2019 15:17:44 - 1.37 +++ sys/arch/mvme68k/include/vmparam.h 15 Jan 2020 17:13:02 - @@ -46,13 +46,9 @@ */ /* - * hp300 pmap derived m68k ports can use 4K or 8K pages. - * The page size is specified by PGSHIFT in . - * Override the PAGE_* definitions to be compile-time constants. + * Use common m68k definitions to define PAGE_SIZE and related constants. */ -#definePAGE_SHIFT PGSHIFT -#definePAGE_SIZE (1 << PAGE_SHIFT) -#definePAGE_MASK (PAGE_SIZE - 1) +#include /* * USRSTACK is the top (end) of the user stack. Index: sys/arch/news68k/include/vmparam.h === RCS file: /cvsroot/src/sys/arch/news68k/include/vmparam.h,v retrieving revision 1.22 diff -u -p -d -r1.22 vmparam.h --- sys/arch/news68k/include/vmparam.h 28 Jun 2019 15:17:44 - 1.22 +++ sys/arch/news68k/include/vmparam.h 15 Jan 2020 17:13:02 - @@ -46,13 +46,9 @@ */ /* - * hp300 pmap derived m68k ports can use 4K or 8K pages. - * The page size is specified by PGSHIFT in . - * Override the PAGE_* definitions to be compile-time constants. + * Use common m68k definitions to define PAGE_SIZE and related constants. */ -#definePAGE_SHIFT PGSHIFT -#definePAGE_SIZE (1 << PAGE_SHIFT) -#definePAGE_MASK (PAGE_SIZE - 1) +#include /* * USRSTACK is the top (end) of the user stack. Index: sys/arch/next68k/include/vmparam.h === RCS file: /cvsroot/src/sys/arch/next68k/include/vmparam.h,v retrieving revision 1.26 diff -u -p -d -r1.26 vmparam.h --- sys/arch/next68k/include/vmparam.h 28 Jun 2019 15:17:44 - 1.26 +++ sys/arch/next68k/include/vmparam.h 15 Jan 2020 17:13:02 - @@ -53,13 +53,9 @@ */ /* - * hp300 pmap derived m68k ports can use 4K or 8K pages. - * The page size is specified by PGSHIFT in . - * Override the PAGE_* definitions to be compile-time constants. + * Use common m68k definitions to define PAGE_SIZE and related constants. */ -#definePAGE_SHIFT PGSHIFT -#definePAGE_SIZE (1 << PAGE_SHIFT) -#definePAGE_MASK (PAGE_SIZE - 1) +#include /* * USRSTACK is the top (end) of the user stack. Index: sys/arch/sun3/include/vmparam.h === RCS file: /cvsroot/src/sys/arch/sun3/include/vmparam.h,v retrieving revision 1.37 diff -u -p -d -r1.37 vmparam.h --- sys/arch/sun3/include/vmparam.h 7 Jan 2013 16:58:09 - 1.37 +++ sys/arch/sun3/include/vmparam.h 15 Jan 2020 17:13:03 - @@ -32,12 +32,9 @@ #define __USE_TOPDOWN_VM /* - * We use 8K pages on both the sun3 and sun3x. Override PAGE_* - * to be compile-time constants. + * Use common m68k definitions to define PAGE_SIZE and related constants. */ -#definePAGE_SHIFT 13 -#definePAGE_SIZE (1 << PAGE_SHIFT) -#definePAGE_MASK (PAGE_SIZE - 1) +#include #defineUSRSTACKkernbase/* for modules */ #defineUSRSTACK3 KERNBASE3 /* for asm not in modules */ Index: sys/arch/x68k/include/vmparam.h === RCS file: /cvsroot/src/sys/arch/x68k/include/vmparam.h,v retrieving revision 1.39 diff -u -p -d -r1.39 vmparam.h --- sys/arch/x68k/include/vmparam.h 28 Jun 2019 15:17:44 - 1.39 +++ sys/arch/x68k/include/vmparam.h 15 Jan 2020 17:13:03 - @@ -46,13 +46,9 @@ */ /* - * hp300 pmap derived m68k ports can use 4K or 8K pages. - * The page size is specified by PGSHIFT in . - * Override the PAGE_* definitions to be compile-time constants. + * Use common m68k definitions to define PAGE_SIZE and related constants. */ -#definePAGE_SHIFT PGSHIFT -#definePAGE_SIZE (1 << PAGE_SHIFT) -#definePAGE_MASK (PAGE_SIZE - 1) +#include /* * USRSTACK is the top (end) of the user stack. --- Izumi Tsutsui
Re: New "ahcisata0 port 1: device present" messages with NetBSD 9
> > 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? https://mail-index.netbsd.org/netbsd-bugs/2020/01/12/msg065427.html https://mail-index.netbsd.org/tech-kern/2020/01/13/msg025939.html He just said got errors on > wd0: > wd1: but no errors on non-SSD > wd2: even when NCQ was not disabled. Of course there might be possible bugs on the WDC drives, though. --- Izumi Tsutsui
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)
> > 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
Re: New "ahcisata0 port 1: device present" messages with NetBSD 9
jdolecek@ wrote: > > problem with Samsung EVO 860 disks and AMD SB710/750 chipsets. The > > problem also occurs on Windows and Linux with these drives and chipsets. : > If they are known broken, seems we indeed need to add a quirk entry to > disable NCQ for these drives, and push it into NetBSD 9.0 branch. > > I'll make the change this week. Note mine is: >> ahcisata0 at pci0 dev 18 function 0: vendor 1002 product 4380 (rev. 0x00) >> ahcisata0: ignoring broken port multiplier support >> ahcisata0: AHCI revision 1.10, 4 ports, 32 slots, CAP >> 0xf3209f83 >> 000:18:0: ATI Technologies SB600 SATA Controller (SATA mass storage, AHCI >> 1.0) Note it already has AHCI_QUIRK_BADPM, but the Samsung EVO 860 NCQ problem should be an independent quirk? https://nxr.netbsd.org/xref/src/sys/dev/ic/ahcisatavar.h?r=1.23#57 https://nxr.netbsd.org/xref/src/sys/dev/pci/ahcisata_pci.c?r=1.56#59 --- Izumi Tsutsui
Re: New "ahcisata0 port 1: device present" messages with NetBSD 9
mueller6725@ wrote: > Would "sysctl hw.wd2.use_ncq=0" from the command line have the same effect? > What about "sysctl -w hw.wd2.use_ncq=0" ? What is the effect of "-w" here? "man 8 sysctl" says > -wSets the MIB style name given to the value given. i.e. it just means "write a value". Maybe some man page (wd(4)?) should mention what MID nob is provided? I found it on reading src/sys/dev/ata/wd.c:wd_sysctl_attach(): https://nxr.netbsd.org/xref/src/sys/dev/ata/wd.c?r=1.453#2184 > I have a similar problem getting "error reading fsbn ..." messages on a > Western Digital Green hard drive, The error could be caused by various reasons, including real errors. I just confirmed by try and errors: - all power voltages were ok - replacing SATA cable didn't help - it only occured on 9.0_RC1 but not 8.1 - disableing NCQ did show differences > I do not get this problem with NetBSD 7.99.1 or with FreeBSD. No idea here. --- Izumi Tsutsui
Re: New "ahcisata0 port 1: device present" messages with NetBSD 9
(maybe I should also put this into the PR) > ahcisata0 port 1: device present, speed: 3.0Gb/s > > for the two attached SSDs, seemingly triggered by disk activity. These > SSDs are running as a RAIDframe mirror. Unpacking the 9.0_RC1 sets with > the new kernel triggered around 50 of these, as well as a few "soft > error (corrected)" messages like these: > > wd0a: error writing fsbn 15440256 of 15440256-15440271 (wd0 bn 15452544; > cn 15329 tn 14 sn 30), xfer 330, retry 0 : > Second, can this be fixed assuming it's a software issue? :) I have similar problems, as filed in PR/54790. https://gnats.netbsd.org/54790 No "ahcisata0 port 1: device present, speed: 3.0Gb/s" but many soft errors. No error on NetBSD 8.1 GENERIC. The problem here doesn't happen once after disabling NCQ by "hw.wd2.use_ncq=0" in /etc/sysctl.conf. One interesting point: Yours are > wd0: > wd0: drive supports 1-sector PIO transfers, LBA48 addressing > wd0: 931 GB, 1938021 cyl, 16 head, 63 sec, 512 bytes/sect x 1953525168 sectors > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), > WRITE DMA FUA, NCQ (32 tags) > wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 > (Ultra/133) (using DMA), NCQ (31 tags) Mine is also Samsung SSD 860 EVO: > wd2: > wd2: drive supports 1-sector PIO transfers, LBA48 addressing > wd2: 465 GB, 969021 cyl, 16 head, 63 sec, 512 bytes/sect x 976773168 sectors > wd2: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), > WRITE DMA FUA, NCQ (32 tags) > wd2(ahcisata0:2:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 > (Ultra/133) (using DMA), NCQ (31 tags) No errors on the following drives on my other machine: > wd0 at atabus0 drive 0 > wd0: > wd0: drive supports 2-sector PIO transfers, LBA48 addressing > wd0: 953 GB, 1984533 cyl, 16 head, 63 sec, 512 bytes/sect x 2000409264 sectors > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), > WRITE DMA FUA, NCQ (32 tags) > wd0(ahcisata0:0:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 > (Ultra/133) (using DMA), NCQ (31 tags) > wd1 at atabus1 drive 0 > wd1: > wd1: drive supports 16-sector PIO transfers, LBA48 addressing > wd1: 223 GB, 465141 cyl, 16 head, 63 sec, 512 bytes/sect x 468862128 sectors > wd1: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 6 (Ultra/133), > WRITE DMA FUA, NCQ (32 tags) > wd1(ahcisata0:1:0): using PIO mode 4, DMA mode 2, Ultra-DMA mode 6 > (Ultra/133) (using DMA), NCQ (31 tags) There might be some device quirk around NCQ of Samsung SSD 860 EVO? --- Izumi Tsutsui
Re: Help with a bug in mmap
jmcneill@ wrote: > On Wed, 31 Oct 2018, Taylor R Campbell wrote: > > > For the moment, as a provisional workaround to make progress, you can > > probably get by with `pa << PGSHIFT', where pa is the physical (byte) > > I think this should be `pa >> PGSHIFT`, or even better use `atop(pa)`. Some MACHINE_ARCHs use paddr_t for an mmap cookie: https://nxr.netbsd.org/xref/src/sys/dev/usb/udl.c?r=1.22#675 --- 675 /* XXX we need MI paddr_t -> mmap cookie API */ 676 #if defined(__aarch64__) 677 #define PTOMMAP(paddr) aarch64_btop((char *)paddr) 678 #elif defined(__alpha__) 679 #define PTOMMAP(paddr) alpha_btop((char *)paddr) 680 #elif defined(__arm__) 681 #define PTOMMAP(paddr) arm_btop((u_long)paddr) 682 #elif defined(__hppa__) 683 #define PTOMMAP(paddr) btop((u_long)paddr) 684 #elif defined(__i386__) || defined(__x86_64__) 685 #define PTOMMAP(paddr) x86_btop(paddr) 686 #elif defined(__m68k__) 687 #define PTOMMAP(paddr) m68k_btop((char *)paddr) 688 #elif defined(__mips__) 689 #define PTOMMAP(paddr) mips_btop(paddr) 690 #elif defined(__powerpc__) 691 #define PTOMMAP(paddr) (paddr) 692 #elif defined(__sh__) 693 #define PTOMMAP(paddr) sh3_btop(paddr) 694 #elif defined(__sparc__) 695 #define PTOMMAP(paddr) (paddr) 696 #elif defined(__sparc64__) 697 #define PTOMMAP(paddr) atop(paddr) 698 #elif defined(__vax__) 699 #define PTOMMAP(paddr) btop((u_int)paddr) 700 #endif 701 702 return PTOMMAP(paddr); --- Izumi Tsutsui
Re: Unused functions in kernels
Krister Walfridsson wrote: > On Sun, 5 Jun 2016, Izumi Tsutsui wrote: > > > It should be static instead? (note fpu_cordic.c was added in 2013) > > https://nxr.netbsd.org/search?q=fpu_cordit2=src > > It is only used when CORDIC_BOOTSTRAP is defined (i.e. when running as a > standalone applicaion), so it should probably be moved into that section. Ah, I see. I'll ask isaki@ (the author of the cordic based trigonometric FPE functions) if it should be wraped by the bootstrap. > > I wonder if others are really unused. > > DCIU() is referred in sun3/sun3/sys_machdep.c and sun3/sun3/trap.c. > > _Idle() is referred in sun3/sun3/clock.c, via an awful cast. > > etc. etc. > > DCIU() seems to be re-defined in sys/arch/m68k/include/cacheops.h >#define DCIU() DCIU_20() > so it does not seem like DCIU() from locore.s is used (and the kernel > built when I #if 0:ed it...) Ah. This one might be missed m68k cacheops cleanup, http://mail-index.netbsd.org/source-changes/2002/11/02/0062.html but maybe we need double check why functions in sun3/locore.s were not removed.. > For _Idle, it looks like its use is protected by LED_IDLE_CHECK in > clock.c, and LED_IDLE_CHECK is not set in in the GENERIC kernel... Note _Idle is not a function but an address, as well as eintrcnt etc. > That said, there are cases where my tool incorrectly claims symbols are > unused: > [..] There are more possible concerns: * some ports have multiple GENERIC like kernels (sun3 also has GENERIC3X for 68030 based sun3x machines) * some symbols are also prepared for userland binaries, like pmap(1) (which required kernel_text etc.) and vmstat(1) (that still refers historical eintrnames and eintrcnt) etc. * some debug functions are designed to be called from ddb prompt after panic in the driver (like osiop_dump_trace() in sys/dev/ic/osiop.c etc) * device drivers might have MI hooks which will be called some specific MD startup functions (like vga_reset() in sys/dev/ic/vga_subr.c) Probably it's still better to use i386/conf/ALL rather than (poor and rarely to be tested) Tier-II GENERIC, though there are some exclusive options even in conf/ALL.. --- Izumi Tsutsui
Re: Unused functions in kernels
> But there are other cases where the functions are really dead. Such as > fpu_cordit2() :) It should be static instead? (note fpu_cordic.c was added in 2013) https://nxr.netbsd.org/search?q=fpu_cordit2=src I wonder if others are really unused. DCIU() is referred in sun3/sun3/sys_machdep.c and sun3/sun3/trap.c. _Idle() is referred in sun3/sun3/clock.c, via an awful cast. etc. etc. -- Izumi Tsutsui
Re: uvm vm_physseg trimming
cherry@ wrote: > >>>>> "tsutsui" == Izumi Tsutsui <tsut...@ceres.dti.ne.jp> writes: > > tsutsui> cherry@ wrote: > >> Please find below a patch to remove .avail_(start|end) from > >> struct vm_physseg > > tsutsui> What's advantage of these changes? > > tsutsui> Changing MD APIs could often cause botches on poor tierII > tsutsui> ports.. > > On cursory glance, I can't seem to find a port that uses the > avail_start/avail_end members in the way intended by uvm. Instead they > seem to redundantly adjust both .start & .avail_start (mostly wrt > pmap_steal_memory(9) ). > > I'm implementing an API to dynamically add and remove physical memory > segments at page granularity. Simplifying the api will make things > easier. It's not absolutely essential, but "nice to have". Probably it's better to propose the new API first (even without actual code). As per our commit guideline, such major API changes require Core's approval. IMO, we can still keep the "start" and "end" args in uvm_page_physload(9) as dummy to keep API/ABI (to avoid extra diffs and possible botches) even after these two members will be removed from the struct vm_physseg. > >> I couldn't find a reason for them to be used redundantly, but I > >> may be wrong. Are there port specific uses for these ? > > tsutsui> It looks: - start and end are intended to represent > tsutsui> "existing" memory regions - avail_start and avail_end > tsutsui> represent free memory regions (to be used by vm) but most > tsutsui> MD code didn't pass the former ones. > > Yes, this is what I noticed, and thus the patch. > > I'd be keen to hear from ports that are affected by this patch. I guess currently no ports depend on the physcal start and end members. I have just remenbered that I wondered if I should handle them when I wrote sun3x MACHINE_NEW_NONCONTIG patch and worked on news68k port, to handle RAM regions that were reserved for PROM monitors. (IIRC it affected the "total memory" value in dmesg) --- Izumi Tsutsui
Re: uvm vm_physseg trimming
cherry@ wrote: > Please find below a patch to remove .avail_(start|end) from > struct vm_physseg What's advantage of these changes? Changing MD APIs could often cause botches on poor tierII ports.. > I couldn't find a reason for them to be used redundantly, but I may be > wrong. Are there port specific uses for these ? It looks: - start and end are intended to represent "existing" memory regions - avail_start and avail_end represent free memory regions (to be used by vm) but most MD code didn't pass the former ones. --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: On Mar 13, 3:30am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/distrib/common/bootimage | christos@ wrote: | | Why are they broken? The INSTALL kernel has ptyfs now? This is the | wrong fix in the long run... | | BTW no one takes PR install/47774 (and the following thread) even after 6.0. | http://mail-index.netbsd.org/source-changes-d/2012/09/thread1.html#005236 Well, do we have a consensus on how do we want to do this? No particular comment implies no consensus? 1. make mount_ptyfs mandatory and run it via mi code (where?) 2. mount ptyfs in sysinst using c code, and remove all the MD hacks. 3. fallback to mount ptyfs via direct mount(2) in sysinst only when openpty(3) fails, so that poor Tier II ports still use old way without file-system PTYFS and we don't have to touch a number of crunch lists to add mount_ptyfs(8). That's what my PR/47774 intended. --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: | 3. fallback to mount ptyfs via direct mount(2) in sysinst only when |openpty(3) fails, so that poor Tier II ports still use old way |without file-system PTYFS and we don't have to touch a number of |crunch lists to add mount_ptyfs(8). That's what my PR/47774 intended. I was trying to avoid carrying over the old pty code around forever, and having all the ports doing it in a unified way. It sounds a bit paranoiac (i.e. best or nothing strategy) for me. I guess it does not matter too much for the installer, but it does add complexity... I think if you remove COMPAT_BSDTTY and just have PTYFS the code is only a few K larger. - there are so many ramdisk lists - some ports still have 1440KB restriction due to installation floppy - few people will bother to maintain such lists just for installer The point of my PR is unfortunately we always lack man power, as no one have take a look at the problem even after 6.0. If you can sweep all image list files and kernel config files without regressions, it's fine for me. --- Izumi Tsutsui
Re: CVS commit: src/distrib/common/bootimage
christos@ wrote: | - there are so many ramdisk lists | - some ports still have 1440KB restriction due to installation floppy These are detected during build... It is a bit annoying to shrink ever growing kernels... sun2 and sun3 have size restriction due to bootloader, for example. (Of course I know these poor ports should retire in near future) | - few people will bother to maintain such lists just for installer | | The point of my PR is unfortunately we always lack man power, | as no one have take a look at the problem even after 6.0. | | If you can sweep all image list files and kernel config files | without regressions, it's fine for me. There is no way to test many of those things. What I was suggesting was: 1. kill ipty from all the MAKEDEV lists 2. add mount(PTYFS) to sysinst. 3. add file-system PTYFS to all the kernels. If the floppies fit, then it has a good chance to work... What can go wrong? (famous last words) The 3. add file-system PTYFS to all the kernels seems a bit hard as we saw on PR/46812 and PR/47123 (we had to add ipty or opty into all MD MAKEDEV). I can see your reasonable goal, but we need to consider pros and cons. That's all. --- Izumi Tsutsui
sysctl weirdness on m68k
On NetBSD/atari, luna68k and x68k, kernels print the following sysctl_createv errors during boot: --- NetBSD 6.99.49 (ATARITT) #243: Sat Jul 26 21:45:00 JST 2014 tsutsui@mirage:/usr/src/sys/arch/atari/compile/ATARITT Atari TT (m68030 CPU/MMU mc68882 FPU) total memory = 69632 KB avail memory = 64744 KB sysctl_createv: sysctl_locate(multicast) returned 2 sysctl_createv: sysctl_locate(multicast_kludge) returned 2 mainbus0 (root) : --- NetBSD 6.99.49 (GENERIC) #214: Sat Jul 26 21:42:32 JST 2014 tsutsui@mirage:/usr/src/sys/arch/luna68k/compile/GENERIC LUNA-II (MC68040 CPU+MMU+FPU, 4k on-chip physical I/D caches) total memory = 65536 KB avail memory = 60700 KB sysctl_createv: sysctl_locate(multicast) returned 2 sysctl_createv: sysctl_locate(multicast_kludge) returned 2 mainbus0 (root) : --- NetBSD 6.99.49 (GENERIC) #211: Sun Jul 27 00:13:08 JST 2014 tsutsui@mirage:/usr/src/sys/arch/x68k/compile/GENERIC X68030 (m68030 CPU/MMU, m68881 FPU, 24MHz clock) on XM6i v0.44 total memory = 140 MB avail memory = 133 MB sysctl_createv: sysctl_locate(multicast) returned 2 sysctl_createv: sysctl_locate(multicast_kludge) returned 2 mainbus0 (root) : --- Is there anyone who also sees these sysctl_createv: sysctl_locate(multicast) returned 2 messages on other ports? --- Izumi Tsutsui
Re: sysctl weirdness on m68k
palle@ wrote: On Sat, 26 Jul 2014, John Klos wrote: NetBSD 6.99.46 (BRIGGS-$Revision: 6.999 $) #0: Tue Jul 8 22:01:50 UTC 2014 j...@chi.ziaspace.com:/usr/current/obj-mac68k/sys/arch/mac68k/compile/BRIGGS Apple Macintosh Quadra 610 (68040) cpu: delay factor 1601 fpu: mc68040 total memory = 260 MB avail memory = 249 MB sysctl_createv: sysctl_locate(multicast) returned 2 sysctl_createv: sysctl_locate(multicast_kludge) returned 2 Same on current sparc64: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 6.99.49 (GENERIC.UP) #49: Sat Jul 26 07:27:36 CEST 2014 pa...@odin.lyckegaard.dk:/home/palle/data/netbsd/palle-sparc64-sun4v/build/sparc64/objdir/sys/arch/sparc64/compile/GENERIC.UP total memory = 1024 MB avail memory = 988 MB sysctl_createv: sysctl_locate(multicast) returned 2 sysctl_createv: sysctl_locate(multicast_kludge) returned 2 timecounter: Timecounters tick every 10.000 msec mainbus0 (root): SUNW,Sun-Blade-100 (Sun Blade 100): hostid 8304ad4f cpu0 at mainbus0: SUNW,UltraSPARC-IIe @ 502 MHz, CPU id 0 Thank you for your reports. I've filed a PR as kern/49036. --- Izumi Tsutsui
Re: The root partition inside a slice.
Why now NetBSD can has the root partition only on beginning of a slice? For instance: boot hd0e:netbsd can't find the root if the hd0e is inside a slice and hasn't a dos partition twin. Which NetBSD version? NetBSD x86 6.1.4 can't handle it and you need the following change (which I'm using for my custom 6.1.4 amd64 kernel): http://www.nerv.org/~ryo/netbsd/netbsd/?q=id:20130428T143256Z.b623c8487cf2235d829e0daff70cca59b1b79df8 6.2 will include this fix. --- Izumi Tsutsui
Re: The root partition inside a slice.
I have tried the current(69940) i386 kernel. It's not helped. I have the root partition on ld0e and bootloader on ld0a. Can you also show your boot.cfg? Does it have rndseed /var/db/entropy-file; boot hd0e:netbsd ? If so, probably you have to remove rndseed command from it. IIRC, the current x86 bootloader has a bug: - rndseed (and modules) always tries to open the partition a - once the partition a is opened the bootloader sets it as a root partition into bootinfo even if it isn't opened for loading a kernel http://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/biosdisk.c?r=1.43#781 --- Izumi Tsutsui
Re: Patch: cprng_fast performance - please review.
tls@ wrote:
@@ -160,6 +160,7 @@ include crypto/cast128/files.cast128
--- /dev/null 1 Jan 1970 00:00:00 -
+++ crypto/hc128/hc128.c 17 Apr 2014 03:17:18 -
:
+static inline uint32_t
+pack_littleendian(const uint8_t *v)
+{
+#ifdef LITTLE_ENDIAN
+ return *((const uint32_t*)v);
+#else
+ return (uint32_t)v[3] 24
+ | (uint32_t)v[2] 16
+ | (uint32_t)v[1] 8
+ | (uint32_t)v[0];
+#endif
+}
LITTLE_ENDIAN != x86
This should simply be le32dec(9) otherwise
it will cause unaligned trap on arm and mips etc.
+static inline void
+unpack_littleendian(uint32_t value, uint8_t *v)
+{
+#if BYTE_ORDER == LITTLE_ENDIAN
+ *((uint32_t*)v) = value;
+#else
+ int i;
+ for(i = 0; i 4; ++i) {
+ v[i] = value (i * 8);
+ }
+#endif
+}
This should also be le32enc(9), if the byteswap is really necessary.
---
Izumi Tsutsui
Re: Patch: cprng_fast performance - please review.
campbell+netbsd-tech-kern@ wrote:
+void
+hc128_init(hc128_state_t *state, const uint8_t *key, const uint8_t *iv)
+{
+ unsigned int i;
+ uint32_t w[1280], *p = state-p, *q = state-q;
5 KB on the stack is a lot! Granted, this is a leaf routine which in
our case will be called only in a softint handler, but still.
Note the caller of this hc128_init() is:
+static void
+cprng_fast_randrekey(cprng_fast_ctx_t *ctx)
+{
+ uint8_t key[16], iv[16];
+ hc128_state_t tempstate;
+ int s;
+
+ int have_initial = rnd_initial_entropy;
+
+ cprng_strong(kern_cprng, key, sizeof(key), FASYNC);
+ cprng_strong(kern_cprng, iv, sizeof(iv), FASYNC);
+ /* Rekey the hc128 state - expensive, don't do this at splhigh. */
+ hc128_init(ctx-hc128, key, iv);
The hc128_state_t is declared as:
+typedef struct
+{
+ uint32_t p[512];
+ uint32_t q[512];
+ uint16_t i;
+} hc128_state_t;
so it already consumes 4KB stack.
I'm afraid 9KB stack on rekeying is fatal on most ports.
I wonder if we should also consider speed vs memory
especially for embedded users.
---
Izumi Tsutsui
Re: Patch: cprng_fast performance - please review.
tls@ wrote: Note the caller of this hc128_init() is: I'm afraid 9KB stack on rekeying is fatal on most ports. Well, the cipher should hardly ever get rekeyed. The rekeying intervals could be considerably larger; I did not want to increase them too much compared to the old implementation. We can kmem_alloc these structures instead. If it's replaced kmem_alloc(9), it's okay for me. (on NetBSD/x68k there are so many kernel stack overflow on loads) I wonder if we should also consider speed vs memory especially for embedded users. It's 9K per CPU, total. Seems OK, no? I have no idea, but depend on pros and cons if it is not on stack? --- Izumi Tsutsui
Re: 4byte aligned com(4) and PCI_MAPREG_TYPE_MEM
msaitoh@ wrote: (2014/02/15 1:58), Izumi Tsutsui wrote: I'd suggest to clarify what problems you are trying to solve and consider how it should be solved, before updating your patch. The problems you mentioned are: (1) merge initialization of sparse register mappings (with 4 byte stride) Right. (2) defer consinit() for puc com to use uvm_km_alloc() in it Right though the real goal is not to defer consinit but to support memory mapped I/O in com(4). It's unclear what's your plan of migration from the temporary workaround in your patch to the real goal. And, (3) Almost all drivers don't clear struct com_regs regs. It's not a real bug but should be cleard for further change. Can you describe this more specific? In which part of your patch? What does clear mean? All softc stuff is allocated by kmem_zalloc(9) and com_regs for console are allocated as static. Your patch is trying to solve them by: (1) change COM_INIT_REGS() (and comprobe1()) APIs to pass stride byte (2) add an MI extent_initted global variable and check it in MD consinit() My vote is: (1) leave existing APIs and handle the quirk in MD attachment (2) add an x86 specific MD variable to defer consinit() till cpu_startup() I think static int iniited variable is used to do that, but there is no way to know whether extent_init() (or uvm_init()) is called or not. No reason to reuse such stupid MD workaround. You can simply remove it and add and check a new MD bool global variable that will be set in MD cpu_startup(). Because: (1) - it's really pain to change the MI APIs (so many attachments and most of them will rarely be tested unfortunately) - only three or four attachments can share the new API while such embedded devices often might have more other quirks Before writing that patch, I wrote another patch which did't change the arguments of COM_INIT_REGS(). We have two choices a) Use COM_INIT_REGS() for all drivers. b) Copy COM_INIT_REGS() and modify to support 4 byte stride. I couldn't decice which one was better or not. COM_INIT_REGS() is a macro for the standard (contiguous byte) layout. It's pain to change it as I wrote before. Now I think not change the argument and make a new macro is better than adding new argument, because considering the byte order is not required for 1 byte slide devices. If there is standard 4-byte stride layout it would be worth to add a new macro, but I doubt that there is any such standard. You can not use #if BYTE_ORDER in the common macro because byte lane wiring and its addressing are hardware implementation dependent, not endianness dependent (as seen in PCI implementation). - even if stride handling is really necessary in MI part, it's much better to prepare new wrap functions, like wdcprobe1() and wdcprobe() in wdc.c (i.e. prepare a new COM_INIT_REGS_STRIDE() macro with a new arg and make exiting COM_INIT_REGS() macro use it) (2) - it's unclear what functions actually require the extent_init() (I guess uvm_init() is enough to call uvm_km_alloc()) Me neither... I had thought that uvm_init() was enough, but someone advived me that exten_init() should be called. - in general MI code assumes that console devices are properly mapped by MD bootstrap or its firmware Yes. But, it's little hard to make such mapping as PCI bus_space_tag and handle in eary boot stage. - some ports already has MD flags to switch malloc(9) or static memory in early device mappings and initialization It can be used, but IMHO, checking whether bus_space_map() can be called is more generic than it. My point is: If you have the real goal (early MD init for the console devices) but you'd like to add temporary workaround for now, such workaround should not be put into MI sources. as suggested in my vote: (2) add an x86 specific MD variable to defer consinit() till cpu_startup() I don't see benefit to add MI initted global variable into the MI extent. (it's still better to add an is_initted like function than global) --- Izumi Tsutsui
Re: 4byte aligned com(4) and PCI_MAPREG_TYPE_MEM
I'd suggest to clarify what problems you are trying to solve and consider how it should be solved, before updating your patch. The problems you mentioned are: (1) merge initialization of sparse register mappings (with 4 byte stride) (2) defer consinit() for puc com to use uvm_km_alloc() in it Your patch is trying to solve them by: (1) change COM_INIT_REGS() (and comprobe1()) APIs to pass stride byte (2) add an MI extent_initted global variable and check it in MD consinit() My vote is: (1) leave existing APIs and handle the quirk in MD attachment (2) add an x86 specific MD variable to defer consinit() till cpu_startup() Because: (1) - it's really pain to change the MI APIs (so many attachments and most of them will rarely be tested unfortunately) - only three or four attachments can share the new API while such embedded devices often might have more other quirks - even if stride handling is really necessary in MI part, it's much better to prepare new wrap functions, like wdcprobe1() and wdcprobe() in wdc.c (i.e. prepare a new COM_INIT_REGS_STRIDE() macro with a new arg and make exiting COM_INIT_REGS() macro use it) (2) - it's unclear what functions actually require the extent_init() (I guess uvm_init() is enough to call uvm_km_alloc()) - in general MI code assumes that console devices are properly mapped by MD bootstrap or its firmware - some ports already has MD flags to switch malloc(9) or static memory in early device mappings and initialization Just my two cents, --- Izumi Tsutsui
Re: 4byte aligned com(4) and PCI_MAPREG_TYPE_MEM
msaitoh@ wrote:
Registers of Quark X1000's com are 4byte aligned.
Some other machines have such type of device, so
I modified COM_INIT_REGS() macro to support both
byte aligned and 4byte aligned. This change reduce
special modifications done in atheros, rmi and
marvell drivers.
Some bus_space(9) implementation handles such sparse space
mappings and that was the reason why the COM_REGMAP was introduced.
Is it checked properly?
(though probably it's time to make COM_REGMAP default anyway)
What should I do?
One of the solution is to check whether extent_init() was called
or not. There is no easy way to know it, so I added a global
variable extent_initted. Is it acceptable?
Some ports have MD such initted variable and check it MD internal
functions so I wonder if it's ok to have MI global variable.
(IIRC there was similar discussion when MI genfb support was added)
Index: dev/ic/comvar.h
===
RCS file: /cvsroot/src/sys/dev/ic/comvar.h,v
retrieving revision 1.78
diff -u -p -r1.78 comvar.h
--- dev/ic/comvar.h 3 Oct 2013 13:23:03 - 1.78
+++ dev/ic/comvar.h 9 Feb 2014 17:43:24 -
:
-#ifdef COM_REGMAP
+#ifndef COM_NO_REGMAP
What is the reason to make the flag reversed?
+ uint32_tcr_flags;
+#define COM_REGS_ALIGN4 0x01
ALIGN4 seems a bit confusing. 4BYTE_STRIDE or other name?
+#if BYTE_ORDER == BIG_ENDIAN
+#define COM_INIT_REGS_OFFSET 3
+#else
+#define COM_INIT_REGS_OFFSET 0
+#endif
As Dennis Ferguson wrote, I doubt this will work on PCI based ones.
IIRC PCI spec requires that the same byte registers must be
accecced via the same addresses on both endian.
Such byte lane offset adjust ment is required only if
- byte registers are wired to LSByte in 32bit bus
- byte lane wiring are swapped by hardware (like osiop(4))
but most (all?) PCI bus_space(9) implementations swap
byteorder of PCI access by software (i.e. in MD bus_space(9)).
I don't know what's done on bi-endian SoC chips, but I think
such byte lane offset should be switched by MD flags like
COM_REGS_ALIGN4.
--- dev/ic/com.c 22 Dec 2013 18:20:46 - 1.322
+++ dev/ic/com.c 9 Feb 2014 17:43:24 -
:
-comprobe1(bus_space_tag_t iot, bus_space_handle_t ioh)
+comprobe1(bus_space_tag_t iot, bus_space_handle_t ioh, int align)
This new arg should also be stride rather than align?
--- dev/pci/puc.c 7 Feb 2014 11:51:00 - 1.37
+++ dev/pci/puc.c 9 Feb 2014 17:43:24 -
@@ -206,8 +206,13 @@ puc_attach(device_t parent, device_t sel
sc-sc_bar_mappings[i].t, sc-sc_bar_mappings[i].h,
sc-sc_bar_mappings[i].a, sc-sc_bar_mappings[i].s)
== 0);
- if (sc-sc_bar_mappings[i].mapped)
+ if (sc-sc_bar_mappings[i].mapped) {
+ if (type == PCI_MAPREG_TYPE_IO)
+ aprint_normal_dev(self, I/O\n);
+ else
+ aprint_normal_dev(self, MEM\n);
continue;
+ }
Wrong Indent (or unnecessary debug printf)?
--- dev/pci/puccn.c 26 Jan 2014 10:54:24 - 1.13
+++ dev/pci/puccn.c 9 Feb 2014 17:43:24 -
:
@@ -86,8 +87,9 @@ static bus_addr_t pucgdbbase;
* resuming the search where it left off, never retrying the same adaptor.
*/
+#include machine/pio.h
I doubt we can pull this MD header in MI driver.
+ COM_INIT_REGS(sc-sc_regs, iot, ioh, iobase, sizeof(uint8_t));
I wonder which is better explicit 1 or sizeof(uint8_t)
if this means stride. (you use 1 and 4 in com_puc.c)
--- arch/hp300/dev/com_dio.c28 Apr 2008 20:23:19 - 1.8
+++ arch/hp300/dev/com_dio.c9 Feb 2014 17:43:21 -
At least arch/hp300/dev/com_frodo.c was missed?
---
Izumi Tsutsui
Re: 4byte aligned com(4) and PCI_MAPREG_TYPE_MEM
mrg@ wrote: Such byte lane offset adjust ment is required only if - byte registers are wired to LSByte in 32bit bus - byte lane wiring are swapped by hardware (like osiop(4)) but most (all?) PCI bus_space(9) implementations swap byteorder of PCI access by software (i.e. in MD bus_space(9)). FYI: not all -- sparc64 either maps PCI space as little endian or uses little endian accesses, both of which give you the byte swapped data directly. Even in that case, the hardware checks access width and all byte accesses can be done at the same address as the little endian machines by complicated hardware (i.e. #if BYTE_ORDER in the patch won't work), right? --- Izumi Tsutsui
Re: serial console and genfb
jakllsch@ wrote: Attached is a patch to genfb to make it possible to have serial console but still have genfb enabled. I'm slightly worried this will break genfb console on non-x86 machines however, so I'd like some testing. At the very least a list of machines that need testing would be useful. Probably it's rather better to fix sys/arch/x86/pci/pci_machdep.c http://nxr.netbsd.org/xref/src/sys/arch/x86/pci/pci_machdep.c?r=1.63#940 not to set the is_console device property unconditionally. (should check lookup_bootinfo(BTINFO_CONSOLE) instead as consinit() does?) --- Izumi Tsutsui
Re: amd64 hangs during boot
=Kernel from freshly built sources from this morning on amd64 hangs =during boot. = =Last message: = =xhci0: xhci_open addr 0 depth 0 port 0 speed 3 I got that when I tried booting a -current installer. Disabling the USB 3 host controller in BIOS allowed it to boot, though obviously without the xhci. xhci was just recently added to GENERIC which is why you are seeing it now. cvs log says: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/xhci.c#rev1.1 Add work-in-progress xhci(4) driver code. and the author said: http://mail-index.netbsd.org/source-changes-d/2013/10/23/msg006179.html I would like to state at this time that I am not directly responsible for any unexpected whatevers due to this change. So adding xhci into GENERIC looks a bit stupid and it should be reverted. --- Izumi Tsutsui
Re: MACHINE_ARCH on NetBSD/evbearmv6hf-el current
As described in http://gnats.netbsd.org/48193 and http://gnats.netbsd.org/48215 . pkg_add on NetBSD/evbearm*hf fails with, for example, pkg_add: NetBSD/earmv6hf 6.99.23 (pkg) vs. NetBSD/earm 6.99.23 (this host) error. What is solution? This problem discourages my pkgsrc development on Raspberry Pi. It was broken by matt@ and no response for a month in recent discussion: http://mail-index.netbsd.org/tech-userlevel/2013/09/18/msg007954.html The essencial problem is: How to determine whether current environment is hardfloat or softfloat? By static MACHINE_ARCH, or dynamic sysctl(3)? If dynamic sysctl(3) is prefered, which node? MACHINE_ARCH=earmhf was initially introduced into build.sh and bsd.*.mk: http://mail-index.netbsd.org/source-changes/2013/02/03/msg041159.html http://mail-index.netbsd.org/source-changes/2013/02/03/msg041160.html but there was no changes against MACHINE_ARCH values in machine/param.h. This initially caused the problem mentioned in PR/48193 (i.e. inconsistent MACHINE_ARCH between uname(1) and bsd.own.mk): http://mail-index.netbsd.org/netbsd-bugs/2013/09/08/msg034148.html PR/48193 pointed out no hf definitions in MACHINE_ARCH in param.h: http://mail-index.netbsd.org/netbsd-bugs/2013/09/10/msg034174.html http://mail-index.netbsd.org/netbsd-bugs/2013/09/14/msg034184.html After that, exec_elf.h was changed to have machine_arch info in the ELF note: http://mail-index.netbsd.org/source-changes/2013/09/10/msg047399.html http://mail-index.netbsd.org/source-changes/2013/09/10/msg047400.html http://mail-index.netbsd.org/source-changes/2013/09/10/msg047401.html And sysctl(9) for machine_arch was introduced to return the value dynamically instead of static MACHINE_ARCH in machine/param.h: http://mail-index.netbsd.org/source-changes/2013/09/10/msg047416.html http://mail-index.netbsd.org/netbsd-bugs/2013/09/14/msg034185.html But there was a report the above sysctl change didn't help the problem: http://mail-index.netbsd.org/netbsd-bugs/2013/09/14/msg034194.html Then make(1) was changed to use the sysctl machine_arch instead of MACHINE_ARCH from machine/param.h: http://mail-index.netbsd.org/source-changes/2013/09/14/msg047577.html But pkg_add(1) has the same problem as make(1) (i.e. it uses MACHINE_ARCH from machine/param.h): http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034225.html matt claimed it was a separate issue and PR/48215 was filed: http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034226.html http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034229.html Then matt also claimed pkg_add(1) problem was a tools issue: http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034230.html I asked about the strategy how to determine sf or hf: http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034234.html Then matt claimed his changes solved the PR/48193 and further discussion should go in tech-* lists instead of gnats: http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034240.html http://mail-index.netbsd.org/netbsd-bugs/2013/09/16/msg034244.html After that removal of MACHINE_ARCH was proposed in tech-userlevel: http://mail-index.netbsd.org/tech-userlevel/2013/09/16/msg007949.html I replied that it could cause inconsistency (emips is MACHINE_ARCH=mipseb but softfloat) and it might also require many changes to third party applications like pkg_add(1): http://mail-index.netbsd.org/tech-userlevel/2013/09/18/msg007954.html Then everything stalls. All these MACHINE_ARCH=earmhf* changes were committed without discussion, and it looks all changes were introduced without proper considerations. (though I don't know if changes by core members need prior approvals or not) --- Izumi Tsutsui
Re: MACHINE_ARCH on NetBSD/evbearmv6hf-el current
By static MACHINE_ARCH, or dynamic sysctl(3)? If dynamic sysctl(3) is prefered, which node? hw.machine_arch which has been defined for a long long time. Yes, defined before sf vs hf issue arised, and you have changed the definition (i.e. make it dynamic) without public discussion. That's the problem. --- Izumi Tsutsui
Re: MACHINE_ARCH on NetBSD/evbearmv6hf-el current
By static MACHINE_ARCH, or dynamic sysctl(3)? If dynamic sysctl(3) is prefered, which node? hw.machine_arch which has been defined for a long long time. Yes, defined before sf vs hf issue arised, and you have changed the definition (i.e. make it dynamic) without public discussion. That's the problem. It was already dynamic (it changes for compat_netbsd32). Then you also changed hw.machine_arch implementation but didn't notice MACHINE_ARCH in machine/param.h at that time? You proposed MACHINE_ARCH removal later, but you have never answered my question in that thread. You have never show your whole design how to handle hf vs sf and the current problem was caused by your changes. How can you solve it? --- Izumi Tsutsui
Re: MACHINE_ARCH on NetBSD/evbearmv6hf-el current
I wrote: By static MACHINE_ARCH, or dynamic sysctl(3)? If dynamic sysctl(3) is prefered, which node? hw.machine_arch which has been defined for a long long time. Yes, defined before sf vs hf issue arised, and you have changed the definition (i.e. make it dynamic) without public discussion. That's the problem. It was already dynamic (it changes for compat_netbsd32). Then you also changed hw.machine_arch implementation but didn't notice MACHINE_ARCH in machine/param.h at that time? You proposed MACHINE_ARCH removal later, but you have never answered my question in that thread. http://mail-index.netbsd.org/source-changes/2013/10/26/msg048721.html Module Name: src Committed By:matt Date:Sat Oct 26 18:07:52 UTC 2013 Modified Files: src/sys/arch/arm/include: param.h Log Message: Use CPP symbols to determine the right MACHINE_ARCH Matt, you have changed your mind and committed different fix without posting any messages to tech-* mailing list. Please stop that. Please post whole your strategy first before random bandaid fixes. You have not answered about other sf/hf ports like mips and sh. --- Izumi Tsutsui
Re: Why do we need lua in-tree again? Yet another call for actualevidence, please. (was Re: Moving Lua source codes)
marc@ wrote: Me and others are giving answers. It just seem so that it is not the answers some people want to hear. Probably many people want to see an actual sample implementation, like a dumb device driver that blinks LEDs via GPIO etc. using integrated Lunatik APIs, like computer textbooks. What Lua is good for as been discussed many times, there are presentation slides around etc. People who don't use lua (including me) won't see what Lua is good for without studying lua... --- Izumi Tsutsui
Re: CVS commit: src/sys/lib/libunwind
joerg@ wrote: On Wed, Oct 16, 2013 at 11:36:18AM +, Martin Husemann wrote: On Mon, Oct 14, 2013 at 01:14:58AM +, Joerg Sonnenberger wrote: Module Name: src Committed By: joerg Date: Mon Oct 14 01:14:58 UTC 2013 Added Files: src/sys/lib/libunwind: AddressSpace.hpp CREDITS.TXT DwarfInstructions.hpp DwarfParser.hpp LICENSE.TXT Makefile.inc Registers.hpp UnwindCursor.hpp dwarf2.h libunwind.cxx unwind.h unwind_registers.S Log Message: Add a heavily modified version of Apple's libunwind as released under MIT license in libc++abi. At the moment, only x86 support is tested. A stealth import is no use in bypassing the standard questions: - where has this import been publically discussed? The need was mentioned a number of times in various threads about libc++ and clang. Why do you always hide actual pointers (mailing list archive URLs etc.) to the prior discussions you claim? That's the reason why people think and complain your commit is a stealth import. Anyway, our commit guidelines explicitly require Core's approval before adding a new package into base. You violate the rule. That's the enough reason to revert your commit without discussion. -- Izumi Tsutsui
Re: CVS commit: src/sys/lib/libunwind
On Oct 17, 2013, at 4:57 AM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: Anyway, our commit guidelines explicitly require Core's approval before adding a new package into base. You violate the rule. That's the enough reason to revert your commit without discussion. He did get core's approval and core did require some changes to the import. We did ask why not sys/external and other things. Given the reasons given, we thought sys/lib/libunwind was the best place so it can be used both in the kernel and userland. Then approval without public discussion? It looks most core members always consider only technical points and often ignore all other things, like communication, procedures, and marketing issue etc. It really disappoints other developers and many users... --- Izumi Tsutsui
Re: com(4) and LSI bug workaround
Then can you revert your changes? Is it better to revirt right now? Why not? Your current code doesn't work as expected. You changed the original code without confirmation. Your guess was wrong and the original code looks correct. I see no reason to keep current code. Isn't it much simpler and explicit to call such a MD workaround function directly from comintr() and wrap those blocks with #if COM_XXXMDname 0 / #endif with needs-flag declaration in the config(9) file? I think that I should check not by needs-flag but by COM_TYPE_. Since ARMADAXP has some PCIe, com should be able to be attached there. What makes you think the com at PCIe will also have the same quirk? If the quirks is not chip specific, the workaround function should also be in the MI com.c, then no need to wrap them with #ifdef. COM_TYPE_APBUART or COM_TYPE_SNPS or ... ? In ARMADAXP case I don't see any reason to put #ifdef at all. If IIR_BUSY is returned we should always check the USR register. It's no worth to have a separate mvuart_armadaxp_workaround() function you suggested. Please let me confirm. Is it wrong although I understood that you desired #ifdef ARMADAXP ... #endif? : I just said #ifdef with a flag was still better than dumb function pointers in MI softc. For now I don't see any reason to add any MD functions called from MI com.c. Revert your changes first, then propose your next changes (COM_TYPE names etc.) against the original one, not against sources you broke. --- Izumi Tsutsui
Re: com(4) and LSI bug workaround
Then can you revert your changes? Is it better to revirt right now? Why not? Done. Thanks. Your current code doesn't work as expected. You changed the original code without confirmation. Your guess was wrong and the original code looks correct. hmm... This problem influences only ARMADAXP. And nobody noticed until I reported. Furthermore, the problem of LCR(com.c r1.312) before that and nobody reported. Probably ARMADAXP is not used in many cases. Probably you should read the commit guideline again and/or consult your sponsors. Even if we have few users, leaving a wrong comment like this http://nxr.netbsd.org/xref/src/sys/dev/marvell/com_mv.c?r=1.6#187 is a quite bad thing. I agree that the hardware design is quite awful, but it's documented, not a bug. --- Izumi Tsutsui
Re: com(4) and LSI bug workaround
First of all, your guess has no evidence and actually it seems incorrect. There are some articles that indicate it's a documented future: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/203948 Yes. Although that those are not the things for 16750 understood me, I did not know that it was IP of Synopsys DesignWare. And although his mail does not have a corroboration which is a fact, either, probably it is right. Then can you revert your changes? Isn't it much simpler and explicit to call such a MD workaround function directly from comintr() and wrap those blocks with #if COM_XXXMDname 0 / #endif with needs-flag declaration in the config(9) file? I think that I should check not by needs-flag but by COM_TYPE_. Since ARMADAXP has some PCIe, com should be able to be attached there. What makes you think the com at PCIe will also have the same quirk? If the quirks is not chip specific, the workaround function should also be in the MI com.c, then no need to wrap them with #ifdef. COM_TYPE_APBUART or COM_TYPE_SNPS or ... ? In ARMADAXP case I don't see any reason to put #ifdef at all. If IIR_BUSY is returned we should always check the USR register. It's no worth to have a separate mvuart_armadaxp_workaround() function you suggested. --- Izumi Tsutsui
Re: com(4) and LSI bug workaround
It looks meaningless that the (*sc_vendor_workaround)() hook function is inside of MD if (sc-sc_type == COM_TYPE_ARMADAXP) statement. Isn't it simpler to prepare a MD hook function that returns (possible pre-processed) IIR register value that can be used to check if the interrupt for the device is pending or not? I performed operation to a com register into com.c. I think that it is not so brief to return the value of both IIR(u_char) and an error moreover. Sorry I don't understand what you mean. Do you think the name of sc_vendor_workaround is really appropriate for the function that is called only in COM_TYPE_ARMADAXP case? The requirement in the MI interrupt handler is just whether interrupts are pending or not, isn't it? --- Izumi Tsutsui
Re: re(4) MAC address
I found out that NetBSD's re(4) driver is reading the MAC from EEPROM while PPCBoot and Linux are reading it from the chip's ID-registers (RTK_IDRn). What is correct? This is a Realtek 8169S: Probably it's defined by hardware vendors, not chip. The old RTL8139 (RTL8169 has compat mode) seems to read MAC address from EEPROM and those values are stored into RTK_IDRn registers. I guess some NAS vendors overwrite RTK_IDn registers by firmware to avoid extra EEPROM configurations during production. We can change values per hardware by adding device properties (prop_dictionary(3)) calls (like sys/dev/pci/if_wm.c etc). --- Izumi Tsutsui
Re: re(4) MAC address
Frank Wille wrote: Probably it's defined by hardware vendors, not chip. The old RTL8139 (RTL8169 has compat mode) seems to read MAC address from EEPROM and those values are stored into RTK_IDRn registers. Who writes it into the IDRn registers? The firmware? The driver? Or the chip itself? When the chip does that automatically, then re(4) should depend on RTK_IDRn and not on the EEPROM. IIRC RTL8139 doc says the chip reads the values from EEPROM automatically. We should follow what 8169 doc specifies, but I don't have 8169 docs. I guess some NAS vendors overwrite RTK_IDn registers by firmware to avoid extra EEPROM configurations during production. You may be right. I found a modification in the PPCBoot source, which reads the environment variable ethaddr and copies it to RTK_IDRn. But the EEPROM seems to have a valid contents (only the last three bytes differ) and I wonder why it is not used. Probably all NASes has the same values in EEPROM? (i.e. no re's EEPROM write operations during manufacture) We can change values per hardware by adding device properties (prop_dictionary(3)) calls (like sys/dev/pci/if_wm.c etc). Yes. I added a mac-address property to sk(4) myself, some time ago. But re(4) doesn't support it yet. You can add it if necessary, to avoid unexpected changes on other NICs. --- Izumi Tsutsui
Re: call for testing: completing the device/softc split
everyone please feel free to commit any part of this stuff separately. I've committed MD part of ews4800mips, hp300, luna68k, news68k, newsmips, pmax, sun2, sun3, and x68k. --- Izumi Tsutsui
Re: call for testing: completing the device/softc split
matt@ wrote: On Oct 10, 2012, at 10:55 AM, Izumi Tsutsui wrote: I wrote: ite chnages seem to cause silent hang at early bootstrap at least on XM6i, so I'll check it on real X68030 with serial console later. (IIRC atari's ite also had annoying quirks around console probe code..) I've also fixed and committed x68k ite. It has a static struct softc for early console, so we should also prepare a static struct device after it's split out from softc. Oh well. No. Just use a softc size of 0 and set self-dv_private to the static softc in the attach and sc-sc_dev to self as well Hmm. If the driver requires whole members in the static softc, probably it's right. But I guess the current implementation of the ite driver is a result of kludges to adapt ancient drivers (derived from HPBSD) to 4.4BSD newconfig. The only necessary stuff for early console seems struct grf_softc that is copied in iteattach (as struct rasops_info in modern wscons drivers), but struct device is still referred in iteinit() etc only to get a device unit number, which is not necessary for console. Anyway, the ite drivers should be replaced by wscons in future and troubles during early console are really annoying, so I'd like to keep changes minimum on device_t/softc split. Thanks, --- Izumi Tsutsui
Re: call for testing: completing the device/softc split
It would be nice to split the patch into two parts, cosmetic only changes (struct device * - device_t, device_xname() macro etc) and actual split (CFATTACH_DECL - CFATTACH_DECL_NEW with softc) that could have many pitfalls. (conversion between device_t and softc via (void *) casts/pointers) yea, that would have been a better way to go about it, but at this point the changes are pretty hopelessly intertwined. separating them by hand now just isn't practical. No problem, but I'd like to commit the following x68k ones - sys/arch/x68k/dev/ite.c - sys/arch/x68k/dev/itevar.h - sys/arch/x68k/dev/mha.c (which would be fatal) separately so that I can use one commit log to pullup request to netbsd-6. I also noticed that this patch fixes a problem on sparc, booting a -current sparc GENERIC + QUEUEDEBUG hits an assertion about the alldevs list being corrupted, whereas with this patch it's fine. it wasn't obvious exactly what I fixed though. Some device_t/softc conversions in sys/arch/sparc/dev/fd.c and sys/arch/sparc/sparc/memecc.c seem fatal. Good catch :-) --- Izumi Tsutsui
Re: call for testing: completing the device/softc split
No problem, but I'd like to commit the following x68k ones - sys/arch/x68k/dev/ite.c - sys/arch/x68k/dev/itevar.h - sys/arch/x68k/dev/mha.c (which would be fatal) separately so that I can use one commit log to pullup request to netbsd-6. sure, go right ahead. mha.c is done. ite chnages seem to cause silent hang at early bootstrap at least on XM6i, so I'll check it on real X68030 with serial console later. (IIRC atari's ite also had annoying quirks around console probe code..) I also noticed that this patch fixes a problem on sparc, booting a -current sparc GENERIC + QUEUEDEBUG hits an assertion about the alldevs list being corrupted, whereas with this patch it's fine. it wasn't obvious exactly what I fixed though. Some device_t/softc conversions in sys/arch/sparc/dev/fd.c and sys/arch/sparc/sparc/memecc.c seem fatal. Good catch :-) cool, I'll split those out and commit them separately too. or you can do it if you'd like. These are also committed. (at least no crash on qemu, though it doesn't have these devices) Thanks! --- Izumi Tsutsui
Re: call for testing: completing the device/softc split
I wrote: ite chnages seem to cause silent hang at early bootstrap at least on XM6i, so I'll check it on real X68030 with serial console later. (IIRC atari's ite also had annoying quirks around console probe code..) I've also fixed and committed x68k ite. It has a static struct softc for early console, so we should also prepare a static struct device after it's split out from softc. Oh well. (IIRC there were several such devices that required extra struct device and softc, like sys/dev/sbus/esp_sbus.c) --- Izumi Tsutsui
Re: call for testing: completing the device/softc split
chs@ wrote:
I put together a patch to complete the device/softc split
for the remaining drivers in the tree. the patch is at:
http://ftp.netbsd.org/pub/NetBSD/misc/chs/diff.devsoftc.8
+++ sys/arch/amiga/amiga/autoconf.c 9 Oct 2012 02:53:15 -
@@ -156,34 +156,52 @@ matchname(const char *fp, const char *sp
* always tell the difference betwean the real and console init
* by checking for NULL.
*/
+struct qq {
+int q;
+int c;
+} qq;
Debug leftover?
+++ sys/dev/pci/if_devar.h 26 Sep 2012 23:44:22 -
@@ -487,7 +487,7 @@ struct _tulip_softc_t {
#endif /* _BSDI_VERSION 199401 */
#endif /* __bsdi__ */
#if defined(__NetBSD__)
-struct device tulip_dev; /* base device */
+device_t tulip_dev;/* base device */
Some more macro?
#define tulip_unit tulip_dev.dv_unit
Or it's time to obsolete de driver?
It would be nice to split the patch into two parts,
cosmetic only changes (struct device * - device_t,
device_xname() macro etc) and actual split
(CFATTACH_DECL - CFATTACH_DECL_NEW with softc)
that could have many pitfalls. (conversion between
device_t and softc via (void *) casts/pointers)
(though actually you've caught some botches in x68k ;-)
---
Izumi Tsutsui
Re: Adding a new file system
agc@ wrote: I recently started writing a file system for some specific use-cases, and had to make a number of changes. There was a request that I write up the steps that needed to be taken, and so this tries to outline them. : 1. the file system code itself - src/sys/fs/NEWfs/* : 7. add and populate src/sbin/newfs_NEWfs and makefs(8) for distribution? It's efficient to design kernel and newfs sources to share them with makefs too. v7fs is a good example. (and it's so annoying to write makefs -t msdos with current implementations..) --- Izumi Tsutsui
Re: mlockall() and small memory systems
I have not tried the test, but ntpd(8) on m68k machines (with less than 32MB) always complains mlockall() failed. --- Izumi Tsutsui
Re: ncr53c9x fallout from asserting kernel lock in scsipi_base
matt@ wrote: On Mar 9, 2012, at 7:53 AM, Manuel Bouyer wrote: On Fri, Mar 09, 2012 at 04:44:54PM +0100, Martin Husemann wrote: On Fri, Mar 09, 2012 at 04:39:08PM +0100, Manuel Bouyer wrote: if ncr53c9x is not MP-safe, it should be running under the KERNEL_LOCK itself, and so should not need to take it before calling back in scsipi. Where is that dealt with? I.e. where is the lock taken before the attach function is called? This I don't know. Maybe it's not taken when running autoconf. If that's true I'm surprised there isn't more issues than this ... Since attach is usually called when the system is cold, there are no other CPUs running so the system is effectively in KERNEL_LOCK(). Rather than fix the driver, maybe init_main should take out KERNEL_LOCK() until it exits cold state. What about hot-plug? (we have esp at pcmcia) --- Izumi Tsutsui
Re: 6.0_BETA: Extreamly slow newfs_ext2fs on 60Gb USB stick
cheusov@ wrote: On Fri, Mar 2, 2012 at 8:01 PM, Izumi Tsutsui tsut...@ceres.dti.ne.jp wrote: For a number of reasons I decided to use ext2 filesystem on 60Gb memory stick. : Unfortunately newfs_ext2fs works extreamly slowly newfs_ext2fs(8) was intended to prepare boot partitions for Linux based appliances (like cobalt) without GPLed tools, so its implementation is quite dumb and it doesn't have any I/O optimazations. ... Your patch solved the problem. Committed. Thanks. If it is good to commit, it would be nice to see it in netbsd-6. I'll send a pullup request later. --- Izumi Tsutsui
Re: 6.0_BETA: Extreamly slow newfs_ext2fs on 60Gb USB stick
For a number of reasons I decided to use ext2 filesystem on 60Gb memory
stick.
:
Unfortunately newfs_ext2fs works extreamly slowly
newfs_ext2fs(8) was intended to prepare boot partitions for
Linux based appliances (like cobalt) without GPLed tools,
so its implementation is quite dumb and it doesn't have
any I/O optimazations.
There are two possible problems:
(1) newfs_ext2fs(8) has too many zero'ing ops to erase possible
superblock backup leftovers
- The attached patch (which makes newfs_ext2fs(8) zap fewer block)
omits most write ops.
(2) ext2fs has a fixed block group (cylinder group in FFS) size
so large fs will have too many sparse block group structures
to be initialized
- Using REV1 (newfs_ext2fs -O 1) could reduce blocks
superblock backups) to be written during initialization.
Trying mke2fs in e2fsprogs (available in pkgsrc) might also be worth.
---
Izumi Tsutsui
Index: mke2fs.c
===
RCS file: /cvsroot/src/sbin/newfs_ext2fs/mke2fs.c,v
retrieving revision 1.14
diff -u -p -r1.14 mke2fs.c
--- mke2fs.c10 Sep 2010 15:51:20 - 1.14
+++ mke2fs.c2 Mar 2012 16:30:03 -
@@ -124,7 +124,7 @@ __RCSID($NetBSD: mke2fs.c,v 1.14 2010/0
#include extern.h
static void initcg(uint);
-static void zap_old_sblock(daddr_t);
+static void zap_old_sblock(int);
static uint cgoverhead(uint);
static int fsinit(const struct timeval *);
static int makedir(struct ext2fs_direct *, int);
@@ -552,7 +552,7 @@ mke2fs(const char *fsys, int fi, int fo)
if (!Nflag) {
static const uint pbsize[] = { 1024, 2048, 4096, 0 };
- uint pblock, epblock;
+ uint pblock;
/*
* Validate the given file system size.
* Verify that its last block can actually be accessed.
@@ -566,19 +566,23 @@ mke2fs(const char *fsys, int fi, int fo)
/*
* Ensure there is nothing that looks like a filesystem
* superblock anywhere other than where ours will be.
-* If fsck_ext2fs finds the wrong one all hell breaks loose!
*
-* XXX: needs to check how fsck_ext2fs programs even
-* on other OSes determine alternate superblocks
+* Ext2fs superblock is always placed at the same SBOFF,
+* so we just zap possible first backups.
*/
for (i = 0; pbsize[i] != 0; i++) {
- epblock = (uint64_t)bcount * bsize / pbsize[i];
- for (pblock = ((pbsize[i] == SBSIZE) ? 1 : 0);
- pblock epblock;
- pblock += pbsize[i] * NBBY /* bpg */)
- zap_old_sblock((daddr_t)pblock *
- pbsize[i] / sectorsize);
+ pblock = (pbsize[i] BBSIZE) ? 0 : 1; /* 1st dblk */
+ pblock += pbsize[i] * NBBY; /* next bg */
+ /* zap first backup */
+ zap_old_sblock(pblock * pbsize[i]);
}
+ /*
+* Also zap possbile FFS magic leftover to prevent
+* kernel vfs_mountroot() and bootloadres from mis-recognizing
+* this file system as FFS.
+*/
+ zap_old_sblock(8192); /* SBLOCK_UFS1 */
+ zap_old_sblock(65536); /* SBLOCK_UFS2 */
}
if (verbosity = 3)
@@ -769,9 +773,9 @@ initcg(uint cylno)
* Zap possible lingering old superblock data
*/
static void
-zap_old_sblock(daddr_t sec)
+zap_old_sblock(int sblkoff)
{
- static daddr_t cg0_data;
+ static int cg0_data;
uint32_t oldfs[SBSIZE / sizeof(uint32_t)];
static const struct fsm {
uint32_t offset;
@@ -793,24 +797,25 @@ zap_old_sblock(daddr_t sec)
return;
/* don't override data before superblock */
- if (sec SBOFF / sectorsize)
+ if (sblkoff SBOFF)
return;
if (cg0_data == 0) {
cg0_data =
((daddr_t)sblock.e2fs.e2fs_first_dblock + cgoverhead(0)) *
- sblock.e2fs_bsize / sectorsize;
+ sblock.e2fs_bsize;
}
/* Ignore anything that is beyond our filesystem */
- if (sec = fssize)
+ if (sblkoff / sectorsize = fssize)
return;
/* Zero anything inside our filesystem... */
- if (sec = sblock.e2fs.e2fs_first_dblock * bsize / sectorsize) {
+ if (sblkoff = sblock.e2fs.e2fs_first_dblock * bsize) {
/* ...unless we will write that area anyway */
- if (sec = cg0_data)
+ if (sblkoff = cg0_data)
/* assume iobuf is zero'ed here */
- wtfs(sec, roundup(SBSIZE, sectorsize
Re: patch: MFSv3 support (libsa) for boot2 (i386)
Here're updated patches. Tested on sparc (build only). Gnats ID is lib/45796. Looks like a lot of replicated code from elsewhere in libsa. You really ought to manage to factor out a lot of the common bits. Can you mention more specific sources/functions? libsa is all about code size, performance is secondary. libsa.a library might become bigger, but unused stuff won't linked into the target standalone programs unless MINIXv3FS is explicitly specified in conf.c etc. Current ufs.c is a factored out source (for ffsv1/ffsv2/lfsv1/lfsv2), but compiled binaries are not unified anyway. (sys/arch/i386/stand/lib/biosdisk.c should have #ifdef SUPPORT_MINIXFS3 though) --- Izumi Tsutsui
Re: Second stage bootloader (i386) hangs on ls command for ext2
Hi, Evgeniy Ivanov wrote: Izumi, thank you for reviewing! New patches are attached. : I think it's better to use a positive LIBSA_ENABLE_LS_OP option rather than LIBSA_NO_LS_OP, and make whole (fs_ops)-ls op part optional because - there are many primary bootloaders (bootxx_foo) which don't need the ls op and have size restrictions (alpha, atari, pmax ...) - there are few bootloaders which support command prompt mode where the `ls' op is actually required (some ports don't have even getchar()) Done. We also have to check all other non-x86 bootloaders which refer ufs_ls(). (ews4800mips, ia64, landisk, x68k, zaurus etc) Done. I'm not able to check though, but the modification is trivial and almost the same as for i386. Committed all changes (with several fixes for ews4800mips and x68k) http://mail-index.NetBSD.org/source-changes/2011/12/25/msg02.html Thank you for your great work! Now it's time for someone[TM] to try PR/30866 :-) http://gnats.NetBSD.org/30866 --- Izumi Tsutsui
Re: patch: MFSv3 support (libsa) for boot2 (i386)
Here're patches to implement MINIX File System v3 support in libsa. Support for MFS is added to the boot2 for i386. Could you also file this patch to database via send-pr? (patch in PR, calling for review on tech list) http://www.NetBSD.org/support/send-pr.html With a quick glance, 'mfs' in NetBSD means memory based file system (in sys/ufs/mfs) so other name (which implies MINIX) would be better. --- Izumi Tsutsiu
Re: Second stage bootloader (i386) hangs on ls command for ext2
Hi, Evgeniy Ivanov wrote: I have not checked if their readdir() API can be applicable our current ls implementation, but what do you think about this idea, i.e. file system independent ls command using fs dependent readdir() ops? readdir looks better as fs_ops, but if it requires too much modification in our current implementation, ls in fs_ops could be a interim workaround. I don't like having ls in fs_ops either and I agree, that readdir similar to the OpenBSD's one would be better. Ideally, libsa (at least fs_ops) shouldn't produce any output, it's up to boot loader to printf. The difference is in two parts: fs dependent part should work with an external buffer (OpenBSD way, they copy name and then do stat) or return a dirent pointer into internal buffer (to have the output they get, calling stat() is required, but to keep our current ls output it might be skipped). The second is printing the data. Ls should use readdir(), but If we leave it in libsa::ls() we will not have any benefits from readdir(). And moving it to the bootloaders is not a very easy task, because there're plenty of them (and no way to test changes for non-i386 arch). I think we could leave current approach as interim workaround. Ok, I agree current OpenBSD's libsa readdir implementation (without opendir/seekdir/closedir) is incomplete to bother to integrate only for ls ops. I'll integrate your patch this weekend unless someone provides better alternative implementation. --- Izumi Tsutsui
Re: Second stage bootloader (i386) hangs on ls command for ext2
Hi, Izumi, thank you for reviewing! New patches are attached. : Here is a fix for the issue. Independent on what fs partition contains, ufs_ls() was called. Because of ext2 and ufs similarity it worked successfully in some cases. Now I'm told that OpenBSD has introduced readdir ops in libsa fs_ops: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/lib/libsa/readdir.c And at least OpenBSD/zaurus uses these readdir ops for ls command: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/zaurus/stand/zboot/cmd.c?rev=1.3 I have not checked if their readdir() API can be applicable our current ls implementation, but what do you think about this idea, i.e. file system independent ls command using fs dependent readdir() ops? readdir looks better as fs_ops, but if it requires too much modification in our current implementation, ls in fs_ops could be a interim workaround. We also have to check all other non-x86 bootloaders which refer ufs_ls(). (ews4800mips, ia64, landisk, x68k, zaurus etc) Done. I'm not able to check though, but the modification is trivial and almost the same as for i386. I'll take these tier II ports anyway. Thanks. --- Izumi Tsutsui
Re: Second stage bootloader (i386) hangs on ls command for ext2
Evgeniy Ivanov wrote:
Here is a fix for the issue. Independent on what fs partition
contains, ufs_ls() was called. Because of ext2 and ufs similarity it
worked successfully in some cases.
netbsd_boot2_ls_fix.diff
Fix ls command used in second stage bootloader.
:
Could someone please review and commit it?
Looks good, but one concern.
--- a/sys/arch/i386/stand/bootxx/Makefile.bootxx
+++ b/sys/arch/i386/stand/bootxx/Makefile.bootxx
@@ -87,7 +87,8 @@ CPPFLAGS+= -DLIBSA_SINGLE_FILESYSTEM=xxfs \
-Dblkdevioctl(x,y,z)=EINVAL \
-Dblkdevclose(f)=0 \
-Ddevopen(f,n,fl)=(*(fl)=(void *)n,0) \
--DLIBSA_NO_DISKLABEL_MSGS
+-DLIBSA_NO_DISKLABEL_MSGS \
+-DLIBSA_NO_LS_OP
:
--- a/sys/arch/i386/stand/libsa/nfs.c
+++ b/sys/arch/i386/stand/libsa/nfs.c
:
+__compactcall void
+nfs_ls(struct open_file *f, const char *pattern)
+{
+#if !defined(LIBSA_NO_LS_OP)
+printf(Currently ls command is unsupported by nfs\n);
+#endif
+return;
+}
I think it's better to use a positive LIBSA_ENABLE_LS_OP option rather
than LIBSA_NO_LS_OP, and make whole (fs_ops)-ls op part optional because
- there are many primary bootloaders (bootxx_foo) which don't need
the ls op and have size restrictions (alpha, atari, pmax ...)
- there are few bootloaders which support command prompt mode where
the `ls' op is actually required (some ports don't have even getchar())
We also have to check all other non-x86 bootloaders which refer ufs_ls().
(ews4800mips, ia64, landisk, x68k, zaurus etc)
---
Izumi Tsutsui
Re: Using event counters with network interfaces, is there a reason they're all ifdefed out of mainline use?
drivers. Is there a reason all of these counting facilities are not enabled by default in GENERIC kernels? Does using these counters impose such a performance penalty that general use was deemed too crippling? Do you try any benchmark? (by ttcp(1) etc.) During mec(4) (on sgimips O2) debugging, enabling evcnts made network xfer notably slower, but probably it depends on how many counters the driver has and how often they are called. I think we need benchmark results per interfaces rather than blindly enabling counters, because most ordinary users don't care driver internals but just visible xfer rates. --- Izumi Tsutsui
Re: USB contigmalloc()
wiz@ wrote: Matthew Dillon implemented a solution for USB/graphics cards problem stemming from the fact that some time after the boot, they can't acquire enough contiguous memory. http://thread.gmane.org/gmane.os.dragonfly-bsd.kernel/14431 Anyone interested in porting it or implementing something similar? :) I think allocating physically contiguous large memory is a bad design and I doubt reserving 16MB physical memory at boot time is acceptable for all machines with USB. Anyway, currently our udl(4) doesn't require such allocation, but has more other problems: http://cvsweb.NetBSD.org/bsdweb.cgi/src/sys/dev/usb/udl.c#rev1.1 --- Izumi Tsutsui
Re: Patch to add support for crazy Realtek 8139-based cards
Very recently I have managed to get my hands on a pretty odd RTL8139 card which does not identify with the system well, because it reports 0x0001 as vendor ID. On Linux it worked because Linux already detects such cards, while NetBSD doesn't. - Can you show actual board vendor name of that card? (to denote quirks in sources) - Is that card recognized properly on supported OS, i.e. MS Windows? - If yes, does it work with Windows default driver or vendor's driver? - If it works on Windows, what does the device manager show, especially PCI vendor and product IDs? If the board vendor intentionally sets its PCI vendor ID to 0x0001, we can add such odd ID into rtk_pci_devs[] in if_rtk_pci.c. But if it's caused by broken EEPROM or bad drivers which badly overwrite EEPROM data, we should not accept random ID numbers. --- Izumi Tsutsui
Re: proposed additions to sys/conf/std
jakllsch@ wrote: I propose adding pseudo-device drvctl and/or options BUFQ_PRIOCSCAN to src/sys/conf/std. - Can't drvctl device be module(7)? If yes it should be into each GENERIC or MONOLITHIC. - Most GENERIC already have commented out options BUFQ_PRIOCSCAN, http://mail-index.NetBSD.org/source-changes/2005/06/09/0048.html so just uncommenting it would be easier for now. (most INSTALL or DISKLESS kernels don't need it) BTW is there any benchmark numbers around these bufq(9) options? I wonder if it's still efficient even on modern HDD with large cache, or even SSD. --- Izumi Tsutsui
Re: wdisplay pixel format
We do, and that's how the xf86-video-wsfb driver works. I had to fix wsfb driver for 1bpp framebuffer http://mail-index.NetBSD.org/source-changes/2011/07/22/msg024891.html and I still wonder what is a generic format of 4bpp framebuffers that common dix part expects... --- Izumi Tsutsui
Re: UDL driver X11 support
jakllsch wrote: On Fri, Jul 22, 2011 at 03:04:42PM +0200, Piotr Adamus wrote: Hello all, could I obtain information if udl driver support X11 for Displaylink devices 1x0/1x5? I am planning to by perhaps UGA-2K-A and I would like to be sure if it works under X11. Should work via xf86-video-wsfb. No. (see cvs log) --- Izumi Tsutsui
Re: add DIAGNOSTIC back to GENERIC/INSTALL
rmind@ wrote: Otherwise, not getting information from DDB is just counter-productive, plus we get not very useful reports, when backtrace is missing. FYI, OpenBSD puts the following message on entering ddb: --- db_printf(RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!\n); #ifdef MULTIPROCESSOR db_printf(IF RUNNING SMP, USE 'mach ddbcpu #' AND 'trace' ON OTHER PROCESSORS, TOO.\n); #endif db_printf(DO NOT EVEN BOTHER REPORTING THIS WITHOUT INCLUDING THAT INFORMATION!\n); --- Izumi Tsutsui
Re: enforcing page color matches
I'm using a MIPS 74K which needs strict page-coloring enforcement (4 colors for its Icache and 2 colors for its Dcache) so this is important to me. VCEI/VCED handlers on R4400 would also be useful to catch aliases. --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
} The topic is how to add 8th type and currently fd.c uses hardcoded '8'. Actually, the topic is asking what the purpose of FDUNIT and FDTYPE is. That question has been answered. The original question is: http://mail-index.NetBSD.org/tech-kern/2011/05/03/msg010454.html sys/dev/isa/fd.c defines FDUNIT and FDTYPE as DIV/MOD 8. etc/MAKEDEV uses makedisk_p16 for fd*. Who's right? As I'm just adding a ninth (ten-sector) fd_type, I prefer the 16 version. I said changing DEV/MOD number in fd.c required all users to update existing fd device nodes under /dev. (note i386 uses makedisk_p16high that handles OLDMAXPARTITIONS) } If we can simply change it to 16, why did we introduce complicated } __HAVE_OLD_DISKLABEL for harddisks? Again, disklabels have nothing to do with floppies, or conversely, the letter part of the floppy unit has nothing to do with partitions. FDUNIT and FDTYPE are calculated from device minor using the hardcoded DEV/MOD number, as MI DISKUNIT and DISKPART for harddrives. __HAVE_OLD_DISKLABEL was introduced to add magics in MD DISKUINT() and DISKPART() macro to avoid renumbering existing old device minors on MAXPARTITION bump. Current MI MAKEDEV.tmpl treats floppy device minors as harddrives. If someone[TM] will maintain MAKEDEV scripts and write doc/UPDATING properly, no problem for me. --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
} FDUNIT and FDTYPE are calculated from device minor using the } hardcoded DEV/MOD number, as MI DISKUNIT and DISKPART for harddrives. } __HAVE_OLD_DISKLABEL was introduced to add magics in MD DISKUINT() } and DISKPART() macro to avoid renumbering existing old device minors } on MAXPARTITION bump. } Current MI MAKEDEV.tmpl treats floppy device minors as harddrives. Again, I don't see your point. You're talking about a major bug in MAKEDEV where it treats floppy drives the same as hard drives. They aren't the same and the letters in the unit number don't have the same meaning. If we fix kernels to use DISKUNIT() and DISKPART() macro for FDUNIT() and FDTYPE(), we can bump a number of fd types to MAXPARTITIONS with no further changes. Nothing needs to be done by users in that case. I thought it was acceptable workaround because paying extra costs against correctness of such obsolete device was worthless and we had much more important problems on modern devices. --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
} for FDUNIT() and FDTYPE(), we can bump a number of fd types } to MAXPARTITIONS with no further changes. Floppies don't use partitions, so I don't see what MAXPARTITIONS has to do with anything. #define MAXFDTYPES MAXPARTIONS in that case? Disk partitions and floppy types are different thing, but both DISKPART() and FDTYPE() macros represent how to assign device minors for different properties in the same physical unit. I don't think it so broken to have a merged macro for the assignment, but if you will implement correct method as you claim, I won't object. --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
The problem is that there might be some ports whose MAXPARTITIONS is still 8 and such ports can't use type 8. --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
On Wed, May 04, 2011 at 08:50:10PM +0900, Izumi Tsutsui wrote: The problem is that there might be some ports whose MAXPARTITIONS is still 8 and such ports can't use type 8. Why not? It is not used as a partiton of fd*. MAKEDEV is already wrong for those ports, the fd nodes probably should have special case handling. On i386: --- % ls -l fd1* brw-r- 1 root operator 2, 8 May 7 2003 fd1a brw-r- 1 root operator 2, 9 May 7 2003 fd1b brw-r- 1 root operator 2, 10 May 7 2003 fd1c brw-r- 1 root operator 2, 11 May 7 2003 fd1d brw-r- 1 root operator 2, 12 May 7 2003 fd1e brw-r- 1 root operator 2, 13 May 7 2003 fd1f brw-r- 1 root operator 2, 14 May 7 2003 fd1g brw-r- 1 root operator 2, 15 May 7 2003 fd1h brw-r- 1 root operator 2, 524296 May 7 2003 fd1i brw-r- 1 root operator 2, 524297 May 7 2003 fd1j brw-r- 1 root operator 2, 524298 May 7 2003 fd1k brw-r- 1 root operator 2, 524299 May 7 2003 fd1l brw-r- 1 root operator 2, 524300 May 7 2003 fd1m brw-r- 1 root operator 2, 524301 May 7 2003 fd1n brw-r- 1 root operator 2, 524302 May 7 2003 fd1o brw-r- 1 root operator 2, 524303 May 7 2003 fd1p --- on amd64: --- # ls -l fd1* brw-r- 1 root operator 2, 16 May 4 23:31 fd1a brw-r- 1 root operator 2, 17 May 4 23:31 fd1b brw-r- 1 root operator 2, 18 May 4 23:31 fd1c brw-r- 1 root operator 2, 19 May 4 23:31 fd1d brw-r- 1 root operator 2, 20 May 4 23:31 fd1e brw-r- 1 root operator 2, 21 May 4 23:31 fd1f brw-r- 1 root operator 2, 22 May 4 23:31 fd1g brw-r- 1 root operator 2, 23 May 4 23:31 fd1h brw-r- 1 root operator 2, 24 May 4 23:31 fd1i brw-r- 1 root operator 2, 25 May 4 23:31 fd1j brw-r- 1 root operator 2, 26 May 4 23:31 fd1k brw-r- 1 root operator 2, 27 May 4 23:31 fd1l brw-r- 1 root operator 2, 28 May 4 23:31 fd1m brw-r- 1 root operator 2, 29 May 4 23:31 fd1n brw-r- 1 root operator 2, 30 May 4 23:31 fd1o brw-r- 1 root operator 2, 31 May 4 23:31 fd1p # --- So current isa/fd.c can't handle the second drive on ports where (MAXPARTITIONS != 8 !__HAVE_OLD_DISKLABEL). For compatibility with longstanding inconsistent MAKEDEV(8), it might be better to use DISKUNIT() and DISKPART() for FDUNIT() and FDTYPE() as other disks, so that we don't have to have special device minor handling for each MD fd device in MI MAKEDEV.tmpl script. --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
So, instead of fixing the very broken MAKEDEV script, you want to mangle multiple floppy drivers? At the end of the day, MAKEDEV is broken, it should not be treating floppy drives like hard drives. The unit letters don't have the same meaning and never have. There are two options, fixing kernels, or fixing /dev nodes on existing disks (not only MAKEDEV script). I'm afraid few developers will maintain MAKEDEV script properly, and few users will rerun /dev/MAKEDEV on upgrade. Nowadays floppy is almost dead, so we don't have to care about compatibility, though... --- Izumi Tsutsui
Re: sys/dev/isa/fd.c FDUNIT/FDTYPE
The kernels aren't broken and don't require fixing. The topic is how to add 8th type and currently fd.c uses hardcoded '8'. If we can simply change it to 16, why did we introduce complicated __HAVE_OLD_DISKLABEL for harddisks? --- Izumi Tsutsui
Re: New boothowto flag to prevent raid auto-root-configuration
Note that especially for the install CD setup, a rootstring passed from boot.cfg is *not* possible, as we do not know which CD drive is used for booting. FYI, see also PR port-i386/39998 and x86_autoconf.c: /* * XXX * There is no proper way to detect which unit is * recognized as a bootable CD-ROM drive by the BIOS. * Assume the first unit is the one. */ I.e. currently only root on cd0a works on x86 GENERIC anyway. --- Izumi Tsutsui
Re: remove sparse check in vnd
yamt@ wrote: i'd like to remove the sparseness check in vnd because there's no problem to use a sparse files on nfs. We really want vnd on sparse files for emulator images... --- Izumi Tsutsui
Re: turning off COMPAT_386BSD_MBRPART in disklabel
PR 44496 notes that COMPAT_386BSD_MBRPART is still enabled in disklabel(8), even though it was turned off by default in the kernel early in 4.99.x. The PR also notes that it's not harmless to leave it on. I'm inclined to turn it off in disklabel(8) right now. There's no particular reason to have it there if the kernel doesn't support it, and since fixing up a really old disk doesn't require disklabel(8), only fdisk(8) there doesn't seem to be any upgrade/compatibility argument to have it in -6. I wonder if it's worth to add a sysctl knob that returns whether the running kernel has options COMPAT_386BSD_MBRPART or not and make disklabel(8) refer it. --- Izumi Tsutsui
Re: Dates in boot loaders on !x86
That depends. Some platforms dropped them completely. It is much simpler to consistently drop it. Indeed. I'd like to know if there is any particular case that date strings in bootloader helped users tracking problem, or annoying examples on x86 bootloaders without date strings. I think it's enough to bump a version number on possible functional changes. Fewer changes on boot than kernels. --- Izumi Tsutsui
Re: Dates in boot loaders on !x86
i386 and amd64 dropped the date in the boot loaders a while ago to ensure that builds are reproducable. Some platforms are currently not including the date as well, but many remain in the old ways. This makes it harder to compare consecutive builds with patches for unexpected output changes, so either the various platforms should honour MKREPRO or drop the output completely. Attached is an untested mechanical patch to do the former, - atari uses cvs $Revision BTW (should we replace it with newvers ones?) - ews4800mips diff is not necessary? (I have removed date strings) - I'd like to remove date strings completly at least from arc, as an author but I wonder if there is any point in keeping the date. IMO date strings are not so important because bootloader is not so configurable (i.e. daily build's one should work as well as local ones) and it isn't easy to log bootloader's strings without serial console, which is uncommon for non-geek users. --- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
It would be nice if ELF kernel image holds modules_enabled value in note section which allows LIBSA to tell whether the target kernel is MODULAR or not. modular kernels don't *have* to have modules loaded via the boot loader. so what i think you're really after is a flag that says we want to try to load modules in the loader. Modular kernels have to have module(s) loaded via the bootloader if the kernels don't have builtin modules for the root file system, where the kernel is loaded from. All other modules can be loaded from the root file system after mountroot(). So necessary info might be which file-system modules are builtin? (though I'm not sure if options NFS_BOOT_DHCP requires bpf(4) module or not) --- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
So necessary info might be which file-system modules are builtin? LIBSA does heuristics to find rootfs type and then stats to see it can be loaded from a local or remote store. It checks a file system type where the kernel is loaded (as sys/arch/i386/stand/lib/exec.c:command_load_kernel() does), not the root file system. (they are identical in most case though) Necessary info is if the loaded kernel has modules for the file system. --- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
The most interesting part of module preload facility is to allow miniroot.kmod. This eliminates the necessity to build a separate INSTALL kernel which holds mdimage inside. That's what i386 did and miniroot.kmod was loaded via boot.cfg(5) like distrib/i386/cdroms/installcd/boot.cfg.in in netbsd-5. (-current doesn't use miniroot.kmod and use cd9660 root fs) Modules loaded by the bootloader are handled in module_init_md() as x86/x86_machdep.c inside #ifdef MODULAR so if the kernel doesn't have MODULAR I think loaded modules are simply ignored. -- Izumi Tsutsui
Re: modules_enabled in kernel ELF note section
MODULAR miniroot.kmod would be benefitial to small embedded NetBSD products. miniroot.kmod is, in essense, a kind of root on md0 switch. options MEMORY_DISK_DYNAMIC ? MODULAR-aware LIBSA can choose to switch the target md0 image whose content is stripped down userland. We have to move boot.cfg(5) support and loading module functions from i386/stand to MI libsa, I think. --- Izumi Tsutsui
Re: BCM5809S support in bnx(4) and brgphy(4)
I have ported various modifications from OpenBSD and FreeBSD to bnx(4)
and brgphy(4) (see attach).
:
--- sys/dev/mii/brgphy.c 27 Nov 2010 17:42:04 - 1.56
+++ sys/dev/mii/brgphy.c 30 Nov 2010 23:58:49 -
:
#include dev/pci/if_bgereg.h
-#if 0
#include dev/pci/if_bnxreg.h
-#endif
:
+ if (device_is_a(parent, bnx)) {
+ struct bnx_softc *bnx_sc = device_private(parent);
:
+ if (bnx_sc-bnx_phy_flags BNX_PHY_2_5G_CAPABLE_FLAG) {
We should not refer struct bnx_softc in brgphy.c
because mii devices can be configured without PCI
and bnx_softc contains PCI specific stuff.
Your patch might break GENERIC on zaurus, which
has mii via on-chip USB but no PCI bus.
To pass bnx_foo_flag values from parent bnx(4) to child brgphy(4),
we need the following two changes
- use device properties (proplib) to pass flag values
- split if_bnxreg.h and move PCI specific stuff
(Device State Data, debug macro etc.) into (new) if_bnxvar.h
as done on past brgphy(4) changes for bge(4) by msaitoh@:
http://mail-index.NetBSD.org/current-users/2009/04/20/msg009101.html
http://mail-index.NetBSD.org/source-changes/2009/04/23/msg220278.html
--- sys/dev/pci/if_bnxreg.h 19 Jan 2010 22:07:00 - 1.10
+++ sys/dev/pci/if_bnxreg.h 30 Nov 2010 23:58:54 -
:
+#if BYTE_ORDER == BIG_ENDIAN
+ u_int16_t tx_bd_vlan_tag;
+ u_int16_t tx_bd_flags;
+#else
u_int16_t tx_bd_flags;
u_int16_t tx_bd_vlan_tag;
+#endif
It would be clearer to use one uint32_t member with shift ops
for bd_flags and bd_vlan_tag rather than two uint16_t members
with reorder #ifdef while the above one will also work...
---
Izumi Tsutusi
Re: BCM5809S support in bnx(4) and brgphy(4)
Also, there is a comment above saying that: /* * The following data structures are generated from RTL code. * Do not modify any values below this line. */ IMO all members fetched via PCI bus master should be uint32_t if hardware supports byte swap ops since swap is always done against each uint32_t. -u_int16_t tx_bd_flags; -u_int16_t tx_bd_vlan_tag; +u_int32_t tx_bd_flags_vtag; +#define VAL_HIGH(val) (((val) 0x) 16) +#define VAL_LOW(val) ((val) 0x) +#if BYTE_ORDER == BIG_ENDIAN +#define TX_BD_VLAN_TAG(tx_bd) VAL_HIGH((tx_bd)-tx_bd_flags_vtag) +#define TX_BD_FLAGS(tx_bd) VAL_LOW ((tx_bd)-tx_bd_flags_vtag) +#else +#define TX_BD_VLAN_TAG(tx_bd) VAL_LOW ((tx_bd)-tx_bd_flags_vtag) +#define TX_BD_FLAGS(tx_bd) VAL_HIGH((tx_bd)-tx_bd_flags_vtag) +#endif : Looks messy :/ Well, no need to use #if BYTE_ORDER if we use uint32_t with shift ops because word swap is done by hardware. (that's the reason why we have to swap uint16_t members by #ifdef) Anyway, no problem to leave them as is to sync FreeBSD/OpenBSD. --- Izum iTsutsui
Re: BCM5809S support in bnx(4) and brgphy(4)
What swap is done by what hardware? Some bus masters like bnx(4) and epic(4) treat host's memory as BE if it's configured so. No byteswap against DMA descripters is necessary in the driver in such case. Using two uint16_t members against a uint32_t descripter requires extra ifdefs to switch BE and LE environments as bitfield in structure. Sigh. I really need to get off my butt and add a bunch of bus_dma accessors (like the bus_space ones but for DMA buffers) to solve this problem optimally across all architectures. I guess you are thinking about extra support for bus controller that supports byteswap ops, not individual bus masters. --- Izumi Tsutsui
Re: pmap_mmap
md(4) mmap has to return mdpgno of char md_root_image[]. I can get physical address of md_root_image[] by pmap_extract(9). There's no API to convert physical address to mdpgno (opposite of pmap_phys_address(9)). Well, there is awful implementation in sys/dev/usb/udl.c. What I ended up is pmap_mmap(9), which is exactly ap(), but made public. Does this sound right? Probably it's time to remove mmap cookie type as pmap(9) says since we have separate paddr_t and vaddr_t? paddr_t pmap_phys_address(paddr_t cookie) : The existence of this function is highly dubious, and it is expected that this function will be removed from the pmap API in a future release of NetBSD. --- Izumi Tsutsui
Re: mutexes, locks and so on...
Ooo. Really friendly here. Yes, excellent idea. Drive people away. That will surely help. Please remind me again, why would people in general want to run NetBSD instead of Linux or FreeBSD? It's good thing to keep support for old machines with MI API. It's bad thing to complain about MI API to keep support for old machines. If the API isn't really MI anymore, is it still not ok to complain about? If there is no reasonable alternative, it means EOL of that machine, as 80386. --- Izumi Tsutsui
