NetBSD Problem Report #48579
From www@NetBSD.org Sat Feb 8 00:06:32 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 27596A646F
for <gnats-bugs@gnats.NetBSD.org>; Sat, 8 Feb 2014 00:06:32 +0000 (UTC)
Message-Id: <20140208000630.91A58A64AE@mollari.NetBSD.org>
Date: Sat, 8 Feb 2014 00:06:30 +0000 (UTC)
From: zbigniew2011@gmail.com
Reply-To: zbigniew2011@gmail.com
To: gnats-bugs@NetBSD.org
Subject: #34490 (kernel compile fails in `le_isa_intredge', no 'le' in kernel config)
X-Send-Pr-Version: www-1.0
>Number: 48579
>Category: kern
>Synopsis: #34490 (kernel compile fails in `le_isa_intredge', no 'le' in kernel config)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Feb 08 00:10:01 +0000 2014
>Last-Modified: Thu May 01 17:15:00 +0000 2014
>Originator: Zbigniew
>Release: 6.1.3
>Organization:
>Environment:
Forgot about "uname -a"... newest release on old BX motherboard and Pentium II/400 processor.
>Description:
I would to confirm the problem described in bug-report #34490. I think, I've found the cause:
While trying to prepare stripped-down kernel I met that problem. After a little investigation it turned out, that the problem is caused by commenting two (actually not necessary) lines:
nele0 at isa? port 0x320 irq 9 drq 7 # NE2100
le* at nele?
At first I blocked these lines, since I didn't want to use such devices (see the kernel configuration file), and that made research difficult.
The very similar problem occured, when I had "active" the lines describing FireWire adaptor:
# PCI IEEE1394 controllers
#fwohci* at pci? dev ? function ? # IEEE1394 Open Host Controller
[..]
#ieee1394if* at fwohci?
Really no idea, why I can't uncomment these two, to have the support for FireWire. This is the same kind of problem (something flawed in kernel configuration processing), therefore I've pasted it here.
(BTW: your bug-report formular should allow to attach the files directly here, IMHO)
>How-To-Repeat:
Use the kernel configuration file from http://dodane.pl/file/150416/MYKERNEL and compile the kernel using syssrc.tgz for 6.1.3.
1. Compile with no changes - there won't be any problems.
2. Comment out first two mentioned lines - you'll see the problem described in report #34490.
3. Comment out next two described lines - you'll see (in addition to the former ones) very similar errors related to fwohci.
>Fix:
The "workaround not fix" which I've found is, that there's a need to uncomment these first two lines to get rid of the problem (and avoid compilation of 1394 driver into kernel). Anyway: the first two lines apparently shouldn't be needed for proper kernel compilation, considering my choice of hardware in kernel configuration file. And the second two should be enough to have also FireWire compiled.
>Audit-Trail:
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',
no 'le' in kernel config)
Date: Sat, 8 Feb 2014 10:01:21 +0900
Your problem is not exactly same as #34490 (i.e. you got
different undefined symbols in error messages), right?
(it would always help to paste the exact errors you got)
Probably your problem is that you leave "bicc0 at isa? ..." line
while you comment out "le* at bicc?" line.
---
Izumi Tsutsui
From: Zbigniew <zbigniew2011@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge', no
'le' in kernel config)
Date: Sat, 8 Feb 2014 13:44:33 +0100
2014-02-08 2:05 GMT+01:00, Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>:
> The following reply was made to PR kern/48579; it has been noted by GNATS.
>
> From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
> To: gnats-bugs@NetBSD.org
> Cc: tsutsui@ceres.dti.ne.jp
> Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',
> no 'le' in kernel config)
> Date: Sat, 8 Feb 2014 10:01:21 +0900
>
> Your problem is not exactly same as #34490 (i.e. you got
> different undefined symbols in error messages), right?
> (it would always help to paste the exact errors you got)
IIRC it were the same error messages - that's why I could find the
former bug-report using Google - but having my kernel config you can
easily verify this. Even, if they were a bit different - the bug was
of the same nature.
> Probably your problem is that you leave "bicc0 at isa? ..." line
> while you comment out "le* at bicc?" line.
I'm not sure, but maybe - still: does there exist any relationship
between one and another? If BICC driver requires any headers, then it
should load it by itself - not relying on other driver ("maybe this
one is also selected, and the headers are already present").
Besides: why such problems aren't verified and reported during neither
of TWO former stages: "configure KERNEL", and "make depend"?
And what about strange FireWire driver problems?
--
regards,
Zbigniew
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',
no'le' in kernel config)
Date: Sat, 8 Feb 2014 22:10:37 +0900
The PR says only:
>> undefined references inside "le_isa_intredge" and "le_isa_attach"
and I got:
---
if_le_isa.o: In function `le_isa_intredge':
if_le_isa.c:(.text+0x18): undefined reference to `am7990_intr'
if_le_isa.c:(.text+0x24): undefined reference to `am7990_intr'
if_le_isa.o: In function `le_isa_attach':
if_le_isa.c:(.text+0x518): undefined reference to `lance_copytobuf_contig'
if_le_isa.c:(.text+0x522): undefined reference to `lance_copyfrombuf_contig'
if_le_isa.c:(.text+0x52c): undefined reference to `lance_copytobuf_contig'
if_le_isa.c:(.text+0x536): undefined reference to `lance_copyfrombuf_contig'
if_le_isa.c:(.text+0x540): undefined reference to `lance_zerobuf_contig'
if_le_isa.c:(.text+0x5df): undefined reference to `am7990_config'
*** [netbsd] Error code 1
---
No idea if they are same or not. Anyway exact error messages are
always appreciated, so that other users can also google it.
> > Probably your problem is that you leave "bicc0 at isa? ..." line
> > while you comment out "le* at bicc?" line.
>
> I'm not sure, but maybe - still: does there exist any relationship
> between one and another?
if_le_isa.c is pulled by "bicc at isa" line
via sys/dev/isa/files.isa:
http://nxr.netbsd.org/xref/src/sys/dev/isa/files.isa?r=1.163#238
and MI am7990 driver (requried by all lance based drivers) is
pulled by "le at bicc" line via sys/conf/files:
http://nxr.netbsd.org/xref/src/sys/conf/files?r=1.1082#676
Then enabling bicc without "le* at bicc?" pulls only if_le_isa.c
and it can't find MI lance functions.
> Besides: why such problems aren't verified and reported during neither
> of TWO former stages: "configure KERNEL", and "make depend"?
We can avoid errors wrap most code in if_le_isa.c with
#if NLE > 0 / #endif etc. but I'm not sure it's worth
to allow such "bicc without le" settings that would simply say
"le at bicc is not configured."
> And what about strange FireWire driver problems?
I can't reproduce any problem, probably due to differnt procedures.
---
Izumi Tsutsui
From: Zbigniew <zbigniew2011@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',
no'le' in kernel config)
Date: Sat, 8 Feb 2014 17:45:30 +0100
2014-02-08 14:15 GMT+01:00, Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>:
> The following reply was made to PR kern/48579; it has been noted by GNATS.
>
> From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
> To: gnats-bugs@NetBSD.org
> Cc: tsutsui@ceres.dti.ne.jp
> Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',
> no'le' in kernel config)
> Date: Sat, 8 Feb 2014 22:10:37 +0900
>
> The PR says only:
> >> undefined references inside "le_isa_intredge" and "le_isa_attach"
>
> and I got:
> ---
> if_le_isa.o: In function `le_isa_intredge':
> if_le_isa.c:(.text+0x18): undefined reference to `am7990_intr'
> if_le_isa.c:(.text+0x24): undefined reference to `am7990_intr'
> if_le_isa.o: In function `le_isa_attach':
> if_le_isa.c:(.text+0x518): undefined reference to `lance_copytobuf_contig'
> if_le_isa.c:(.text+0x522): undefined reference to
> `lance_copyfrombuf_contig'
> if_le_isa.c:(.text+0x52c): undefined reference to `lance_copytobuf_contig'
> if_le_isa.c:(.text+0x536): undefined reference to
> `lance_copyfrombuf_contig'
> if_le_isa.c:(.text+0x540): undefined reference to `lance_zerobuf_contig'
> if_le_isa.c:(.text+0x5df): undefined reference to `am7990_config'
> *** [netbsd] Error code 1
> ---
>
> No idea if they are same or not.
Yes, they look familar to me.
> Anyway exact error messages are
> always appreciated, so that other users can also google it.
My guess was, it would be worthy to fix these errors rather, instead
of leaving the problem to users and Google.
> > > Probably your problem is that you leave "bicc0 at isa? ..." line
> > > while you comment out "le* at bicc?" line.
> >
> > I'm not sure, but maybe - still: does there exist any relationship
> > between one and another?
>
> if_le_isa.c is pulled by "bicc at isa" line
> via sys/dev/isa/files.isa:
> http://nxr.netbsd.org/xref/src/sys/dev/isa/files.isa?r=1.163#238
>
> and MI am7990 driver (requried by all lance based drivers) is
> pulled by "le at bicc" line via sys/conf/files:
> http://nxr.netbsd.org/xref/src/sys/conf/files?r=1.1082#676
>
> Then enabling bicc without "le* at bicc?" pulls only if_le_isa.c
> and it can't find MI lance functions.
Well, maybe - but how do I know it reading the kernel configuration
file? Especially, when "config" and "make depend" reveal no errors?
> > Besides: why such problems aren't verified and reported during neither
> > of TWO former stages: "configure KERNEL", and "make depend"?
>
> We can avoid errors wrap most code in if_le_isa.c with
> #if NLE > 0 / #endif etc. but I'm not sure it's worth
> to allow such "bicc without le" settings that would simply say
> "le at bicc is not configured."
Yes: I can confirm, that when each of the following lines are commented out:
#nele0 at isa? port 0x320 irq 9 drq 7 # NE2100
#le* at nele?
#ntwoc0 at isa? port 0x300 irq 5 iomem 0xc8000 flags 1 # Riscom/N2 sync serial
#bicc0 at isa? port 0x320 irq 10 drq 7 # BICC IsoLan
...there is no "le-error" anymore.
But could you, please, tell me: how the user is supposed to know, that
"bicc requires le" in NetBSD's kernel configuration?
> > And what about strange FireWire driver problems?
>
> I can't reproduce any problem, probably due to differnt procedures.
The procedure is rather simple:
In the kernel configuration file - the one I sent - remove comment
from beginning of the line:
#fwohci* at pci? dev ? function ? # IEEE1394 Open Host Controller
There won't be any error during "config MYKERNEL" neither "make
depend" stages - but the compilation will fail with several
"fwohci"-related errors.
The problem is, it is marked as pci?-dependent only (which is
"switched on" already). My guess is, it needs another unrelated driver
included into config, which pulls some header files - right? Which
one?
--
regards,
Zbigniew
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',no'le'
in kernel config)
Date: Sun, 9 Feb 2014 02:41:18 +0900
> My guess was, it would be worthy to fix these errors rather, instead
> of leaving the problem to users and Google.
Incomplete reports make it harder to reproduce and confirm
the problem to be fixed. That's all.
> But could you, please, tell me: how the user is supposed to know, that
> "bicc requires le" in NetBSD's kernel configuration?
IMO users who will edit kernel config are suppored to notice
the "le at bicc" line has a parent "bicc at isa" line.
Furthermore, users don't have to disable unnecessary devices.
I.e. I'd say it's operational error and "don't do that."
> > > And what about strange FireWire driver problems?
> >
> > I can't reproduce any problem, probably due to differnt procedures.
>
> The procedure is rather simple:
>
> In the kernel configuration file - the one I sent - remove comment
> from beginning of the line:
>
> #fwohci* at pci? dev ? function ? # IEEE1394 Open Host Controller
>
> There won't be any error during "config MYKERNEL" neither "make
> depend" stages - but the compilation will fail with several
> "fwohci"-related errors.
In the PR you wrote:
>> 3. Comment out next two described lines - you'll see (in addition to the former ones) very similar errors related to fwohci.
and now you say remove one comment?
> The problem is, it is marked as pci?-dependent only (which is
> "switched on" already). My guess is, it needs another unrelated driver
> included into config, which pulls some header files - right? Which
> one?
If your claim is "kernel builds shouldn't fail if config(1) doesn't fail
even if only parent devices are enabled" it would be ideally correct,
but less worth to fix for me in these devices (unless patches are provided).
In that case, the kernel will just say "ieee1394if is not configured"
after the parent fwohci is attached and users can't use the target
devices anyway. It would be rather worse than link errors on build.
---
Izumi Tsutsui
From: Zbigniew <zbigniew2011@gmail.com>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',no'le'
in kernel config)
Date: Sat, 8 Feb 2014 19:07:01 +0100
2014-02-08 18:45 GMT+01:00, Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>:
> > But could you, please, tell me: how the user is supposed to know, that
> > "bicc requires le" in NetBSD's kernel configuration?
>
> IMO users who will edit kernel config are suppored to notice
> the "le at bicc" line has a parent "bicc at isa" line.
IMHO "le at bicc" means something like "le requires bicc" - and not
the opposite. But if it means, in fact, the opposite, then there's
something worthy a fix there, don't you think?
> Furthermore, users don't have to disable unnecessary devices.
> I.e. I'd say it's operational error and "don't do that."
Therefore what's the point of kernel configuration, if I'm supposed to
leave everything that I don't need there?
In NetBSD handbook you'll find: "Most NetBSD users will sooner or
later want to recompile their kernel, or compile a customized kernel.
This might be for several reasons". Well, if it is supposed to be done
"sooner or later" - and you, developers, realize this - IMHO it can be
even difficult, but it shouldn't be confusing, right?
> > > > And what about strange FireWire driver problems?
> > >
> > > I can't reproduce any problem, probably due to differnt procedures.
> >
> > The procedure is rather simple:
> >
> > In the kernel configuration file - the one I sent - remove comment
> > from beginning of the line:
> >
> > #fwohci* at pci? dev ? function ? # IEEE1394 Open Host Controller
> >
> > There won't be any error during "config MYKERNEL" neither "make
> > depend" stages - but the compilation will fail with several
> > "fwohci"-related errors.
>
> In the PR you wrote:
> >> 3. Comment out next two described lines - you'll see (in addition to the
> former ones) very similar errors related to fwohci.
> and now you say remove one comment?
Yes, to make it even easier for you to check, and to isolate the
problem; just one line instead of two. It's enough to uncomment just
this single line, and to try compilation. Did you verify?
> > The problem is, it is marked as pci?-dependent only (which is
> > "switched on" already). My guess is, it needs another unrelated driver
> > included into config, which pulls some header files - right? Which
> > one?
>
> If your claim is "kernel builds shouldn't fail if config(1) doesn't fail
> even if only parent devices are enabled" it would be ideally correct,
> but less worth to fix for me in these devices (unless patches are
> provided).
> In that case, the kernel will just say "ieee1394if is not configured"
> after the parent fwohci is attached and users can't use the target
> devices anyway. It would be rather worse than link errors on build.
Unfortunately, you seem to ignore, that I'm describing the confusion,
which is brought by messy description of the drivers' dependencies.
There is "le at bicc" - but I should know, that "it means the opposite
as well". There is "fwohci* at pci?" - but I should guess, what else
it needs for proper driver compilation, apart of pci switched on.
--
regards,
Zbigniew
From: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
To: gnats-bugs@NetBSD.org
Cc: tsutsui@ceres.dti.ne.jp
Subject: Re: kern/48579: #34490 (kernel compile fails in `le_isa_intredge',no'le'in
kernel config)
Date: Sun, 9 Feb 2014 05:02:00 +0900
> IMHO "le at bicc" means something like "le requires bicc" - and not
> the opposite.
The meaning is defined by config(9), not based on human language.
> But if it means, in fact, the opposite, then there's
> something worthy a fix there, don't you think?
I don't think so at all.
"le at bicc" just means "le is attached under bicc" and
"le might require some driver sources" per description of files.* files.
All meanings are described in config(9) and related man pages.
> > Furthermore, users don't have to disable unnecessary devices.
> > I.e. I'd say it's operational error and "don't do that."
>
> Therefore what's the point of kernel configuration, if I'm supposed to
> leave everything that I don't need there?
See below.
If you don't know what's wrong you can leave them as is.
If you want to solve problems in your own config file,
you should learn about config(9).
> > In the PR you wrote:
> > >> 3. Comment out next two described lines - you'll see (in addition to the
> > former ones) very similar errors related to fwohci.
> > and now you say remove one comment?
>
> Yes, to make it even easier for you to check, and to isolate the
> problem; just one line instead of two. It's enough to uncomment just
> this single line, and to try compilation. Did you verify?
In your first report, you wrote "Comment out next two described lines"
but they are already commented out in your MYKERNEL file.
The description "next two described lines" was also vague.
I enabled the two lines but no error.
Then you wrote "remove comment of fwohci" later so it confused me.
It's much simpler to provide exact config file that causes the problem
rather than verbose descriptions without quoting.
> Unfortunately, you seem to ignore, that I'm describing the confusion,
> which is brought by messy description of the drivers' dependencies.
What's your point that shouldn't be ignored?
1) just want to know what's wrong
2) config(1) should fail against inconsistent settings
3) kernel build shouldn't cause link errors even with inconsistent settings
4) config(9) should use more human instinctive grammer
5) or something else?
> There is "le at bicc" - but I should know, that "it means the opposite
> as well". There is "fwohci* at pci?" - but I should guess, what else
> it needs for proper driver compilation, apart of pci switched on.
You still don't mention what you exactly tried and what error you got.
I just "guess" your problem is
- you enabled "fwohci* at pci? dev ? function ?"
- and disabled "ieee1394if* at fwohci?" and all its children
- then got the following errors:
---
fwohci.o: In function `fwohci_set_intr':
fwohci.c:(.text+0x28b): undefined reference to `firewire_debug'
fwohci.o: In function `fwohci_set_bus_manager':
fwohci.c:(.text+0x644): undefined reference to `firewire_debug'
fwohci.o: In function `fwphy_rddata':
fwohci.c:(.text+0x793): undefined reference to `firewire_debug'
fwohci.c:(.text+0x7ce): undefined reference to `firewire_debug'
fwohci.c:(.text+0x814): undefined reference to `firewire_debug'
fwohci.o:fwohci.c:(.text+0xe0f): more undefined references to `firewire_debug' follow
fwohci.o: In function `fwohci_reset':
fwohci.c:(.text+0xed1): undefined reference to `fw_linkspeed'
fwohci.c:(.text+0xf4b): undefined reference to `fw_linkspeed'
fwohci.c:(.text+0xfb4): undefined reference to `firewire_debug'
fwohci.c:(.text+0x12fe): undefined reference to `fw_linkspeed'
fwohci.c:(.text+0x1328): undefined reference to `firewire_debug'
fwohci.o: In function `fwohci_arcv_swap.clone.5':
fwohci.c:(.text+0x19a2): undefined reference to `firewire_debug'
fwohci.o: In function `fwohci_db_free.clone.6':
fwohci.c:(.text+0x19f6): undefined reference to `fwdma_free_multiseg'
fwohci.c:(.text+0x19fe): undefined reference to `M_FW'
fwohci.o: In function `fwohci_db_init':
fwohci.c:(.text+0x1a67): undefined reference to `M_FW'
fwohci.c:(.text+0x1aba): undefined reference to `fwdma_malloc_multiseg'
fwohci.c:(.text+0x1c68): undefined reference to `fwdma_malloc'
fwohci.c:(.text+0x1d0b): undefined reference to `M_FW'
fwohci.o: In function `fwohci_irx_enable':
fwohci.c:(.text+0x2132): undefined reference to `firewire_debug'
fwohci.o: In function `fwohci_itxbuf_enable':
fwohci.c:(.text+0x2727): undefined reference to `firewire_debug'
fwohci.c:(.text+0x2836): undefined reference to `firewire_debug'
fwohci.c:(.text+0x29d4): undefined reference to `firewire_debug'
fwohci.o: In function `fwohci_start':
fwohci.c:(.text+0x3052): undefined reference to `firewire_debug'
fwohci.o:fwohci.c:(.text+0x30dc): more undefined references to `firewire_debug' follow
fwohci.o: In function `fwohci_txd':
fwohci.c:(.text+0x35d5): undefined reference to `fw_xfer_done'
fwohci.c:(.text+0x3823): undefined reference to `firewire_debug'
fwohci.c:(.text+0x38d8): undefined reference to `fw_xfer_done'
fwohci.o: In function `fwohci_arcv':
fwohci.c:(.text+0x3b12): undefined reference to `firewire_debug'
fwohci.c:(.text+0x3e20): undefined reference to `fw_rcv'
fwohci.c:(.text+0x40ef): undefined reference to `firewire_debug'
fwohci.o: In function `fwohci_init':
fwohci.c:(.text+0x45ac): undefined reference to `fwdma_alloc_setup'
fwohci.c:(.text+0x45f0): undefined reference to `fwdma_alloc_setup'
fwohci.c:(.text+0x4630): undefined reference to `fwdma_alloc_setup'
fwohci.c:(.text+0x4874): undefined reference to `fw_init'
fwohci.o: In function `fwohci_detach':
fwohci.c:(.text+0x48f2): undefined reference to `fwdma_free'
fwohci.c:(.text+0x491e): undefined reference to `fwdma_free'
fwohci.o: In function `fwohci_intr':
fwohci.c:(.text+0x4d2d): undefined reference to `firewire_debug'
fwohci.c:(.text+0x552e): undefined reference to `fw_busreset'
fwohci.c:(.text+0x5693): undefined reference to `M_FW'
fwohci.c:(.text+0x5722): undefined reference to `fw_drain_txq'
fwohci.c:(.text+0x5735): undefined reference to `fw_sidrcv'
fwohci.c:(.text+0x573d): undefined reference to `M_FW'
fwohci.o: In function `fwohci_resume':
fwohci.c:(.text+0x592e): undefined reference to `firewire_resume'
---
right?
In this case, the "firewire_debug" symbol in the error message is
declared in sys/dev/ieee1394/firewire.c and it's enabled only if
"ieee1394if" is enabled as defined in sys/dev/ieee1394/files.ieee1394:
http://nxr.netbsd.org/xref/src/sys/dev/ieee1394/files.ieee1394
There is no pci related problem as there is no isa problem
in the bicc at isa case.
That's what "exact error messages in reports" can provide.
The problem here is that parent devices assume that
there is at least one required child device and
implicitly refer symbols used/pulled by the children.
We can avoid such link errors to disable such all references
by dumb #if NFOO > 0 / #endif wrappers, but it provides
~no benefits to users as I wrote in the previous mail.
If you just want to continue to edit your favorite config files,
you only have to know two simple rules:
- If you disable a parent device, you have to all child devices,
otherwise config(1) complains "foo at bar is orphaned".
- If you disable leaf devices, don't leave their parent devices
without children, otherwise it could cause link errors during builds.
Then you can see leaving parents ("bicc at isa" or "fwohci at pci")
without children ("le at bicc" or "ieee1394if at fwohci") could be
problematic.
---
Izumi Tsutsui
From: Quentin Garnier <cube@cubidou.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: re: kern/48579
Date: Thu, 1 May 2014 17:14:52 +0000
config(5) allows for dependencies between elements precisely so that the
problem experienced by the submitter would not happen. If something is
wrong with the user's kernel configuration file, then config(1) should
emit an error. It seems to me like a perfectly fine expectation.
Concerning the fact that enabling bicc@isa but removing le@bicc does
not make sense, well, I would say that it is not up to config(1) to
decide of that. 'rm -Rf /' makes little sense either.
There is a lot of abuse, especially in the indirect configuration busses
of the parent/child dependency. This one is but one example.
The following patch will fix that issue by making bicc itself dependent
on the bus-independent le code. It also removes the then redundant
dependency of le@bicc.
Index: dev/isa/files.isa
===================================================================
RCS file: /cvsroot/src/sys/dev/isa/files.isa,v
retrieving revision 1.163
diff -u -u -r1.163 files.isa
--- dev/isa/files.isa 10 Jun 2013 07:14:02 -0000 1.163
+++ dev/isa/files.isa 1 May 2014 16:20:48 -0000
@@ -235,9 +235,9 @@
device nele {}
attach nele at isa
attach le at nele with le_nele: le24, isadma
-device bicc {}
+device bicc {}: le24
attach bicc at isa
-attach le at bicc with le_bicc: le24, isadma
+attach le at bicc with le_bicc: isadma
file dev/isa/if_le_isa.c nele | bicc
attach depca at isa with depca_isa
file dev/isa/depca_isa.c depca
The firewire issue is a little bit more complicated to entangle because
of all the inter-dependencies of all the firewire code and ultimately a
dependency on ieee1394if_cd, which only exists if ieee1394@fwbus is
selected. Making firewire.c, fwdma.c and fwcrom.c depend on fwbus helps
a lot but it still needs fwmem_{read,write}_quad from fwmem which in
turn depends on ieee1394if_cd.
--
Quentin Garnier - cube@cubidou.net
"See the look on my face from staying too long in one place
[...] every time the morning breaks I know I'm closer to falling"
KT Tunstall, Saving My Face, Drastic Fantastic, 2007.
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.