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.

NetBSD Home
NetBSD PR Database Search

(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.