[altq 1020] Re: re: can't open altq device on NetBSD

[Kenjiro Cho <kjc@csl.sony.co.jp>]

Myrddin Emrys wrote:
> I'm not a programmer, but if I understand you correctly you are saying the
> error is in the userland code, not the kernel code? I'm not sure I
> recompiled the userland tools after redoing my kernel the most recent time,
> let's see if that's the issue... nope. Recompiled all the userland tools, no
> change. :-(
>
> I grepped all of the source code, and I didn't find EBUSY anywhere in the
> userland code. It's all in the device code, and to be honest, I could only
> understand in the most vague of ways what I was looking at. Functions can
> potentially return EBUSY from 4 different areas (.c files): altq_cdnr,
> _conf, _hfsc, and _subr.c. I'm assuming cdnr and hfsc are only relevant if I
> use the related queuing disciplines, so I ignored them. The altq_conf.c file
> was a confusing mishmash to me, but I did notice that altq_subr.c contained
> another possibly relevant occurrence of EBUSY.

The error is returned from the kernel and the userland code just
translates the error code into the error string.

> In the altq_attach() function, EBUSY can be returned. Judging by the name of
> the function, it sounds like something that would be happening in some kind
> of initializing routine. It contained code that implied its purpose is to
> attach a queuing discipline to an interface and initialize it somehow...
> could that be the source of the error?

If the error occurs at altq_attach(), you will get a different error
message.

"altqd: can't open altq device: Device busy" indicates:
> > It's from tbr_install() in libaltq/qop.c at open(/dev/altq/altq, O_RDWR).
> > The corresponding kernel code is altqopen() in sys/altq/altq_conf.c,
> > and it always returns 0 for opening /dev/altq/altq (cdev minor 0).

-Kenjiro