WI Driver issues, compile of kernel dies, after fidling it drops to db
Dunno what I am doing wrong, maybe I am just missing something. I am trying to get my dlink wireless DWL 520 to compile. If I delete /usr/src/sys, and re cvsup to get clean sources (this is a source as of 4am eastern on the 12th April) and run make KERNCONF=HELB buildkernel, it always dies on the wi driver (which I believe is the driver for my card, with is prism 2 based) (listed at the very bottom is the content of my kernel config file). The card is a PCI card which believe is realy an isa card with a bridge to guts of the pcmcia wireless adapter tacked onto it. When I run the compile, it dies with the following error. /usr/src/sys/dev/wi/if_wi_pci.c:68: card_if.h: No such file or directory When I checked the module directory of /usr/src/sys/modules/wi the file card_if.h does not exist. I do a delete on the /usr/src/sys directory (I decided to keep a clean cvsup'd source in an outside directory which I move back each time), and do a search for card_if, and find that one exists, int the form of card_if.m in /usr/src/sys/dev/pccard/ . I run the following command to create the file. perl /usr/src/sys/kern/makeobjops.pl -h /usr/src/sys/dev/pccard/card_if.m I did this first, without realising to check /usr/src/sys/modules/wi which did have the card_if.h file when I compiled the kernel without the wi driver. After compiling without the wi driver, I noted quite a few card_if.h files located in misc directories, almost all identical. So I copied one of them to /usr/src/sys/modules/wi/ , put the wi driver back in and compiled, the compile ran through with little problems (the umass driver is another story) The following error is what I get when I try the if_wi.ko module Apr 12 06:02:54 helb kernel: module_register: module pccard/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pccard/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: module_register: module pci/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pci/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_mcastonly)! Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_iponly)! And it won't work, secondly when I goto remove the module.. Its pukes hard and drops me to the db prompt (I'm still semi new to the bleeding edge crap, usually I use stable, but what the hell, so I have no clue other then taking an image of the screen with my digital camera.. On how to dump a copy of the debug info to a file to add to this email) I also tried the awi driver for fun, it loaded fine, but did nothing, I could not talk to the card, and when I tried to kldunload it, it also dropped me to db And that is pretty much where I am at.. No idea where to go now except send off what I know and wait for someone to hopefully fix it :) Jason Ps, I also noted a few of these, not sure what they are unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0400 can't assign resources (port) unknown: PNP0501 can't assign resources (port) --- Hardware in the Machine --- Abit BP6 MB with 2 cpu's (working) Generic Linksys Ethernet card (working) Sound Blaster 16 pnp Vibra card (seems to be detected on boot, but no drivers compiled in yet) Dlink DWL 520 (not working, causing issues, this is what I am trying to get up and and running) Diamond Viper V770 Ultra 2 (seems to be working, X acting kinda funny sometimes though, need to kill moused else it cores on startx) -- Dmesg below -- FreeBSD 5.0-CURRENT #3: Fri Apr 12 04:43:33 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HELB Preloaded elf kernel /boot/kernel/kernel at 0xc03b8000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 369098752 (360448K bytes) avail memory = 354824192 (346508K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 9 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 11 IOAPIC #0 intpin 19 - irq 5 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fdef0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at
pam_rhost Re: rshd on 5.0-DP1
for what it's worth, i've set up a pam_rhost: ftp://ftp.cs.huji.ac.il/users/danny/pam_rhost To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
WI Driver issues, compile of kernel dies, after fidling it drops to db
Dunno what I am doing wrong, maybe I am just missing something. I am trying to get my dlink wireless DWL 520 to compile. If I delete /usr/src/sys, and re cvsup to get clean sources (this is a source as of 4am eastern on the 12th April) and run make KERNCONF=HELB buildkernel, it always dies on the wi driver (which I believe is the driver for my card, with is prism 2 based) (listed at the very bottom is the content of my kernel config file). The card is a PCI card which believe is realy an isa card with a bridge to guts of the pcmcia wireless adapter tacked onto it. When I run the compile, it dies with the following error. /usr/src/sys/dev/wi/if_wi_pci.c:68: card_if.h: No such file or directory When I checked the module directory of /usr/src/sys/modules/wi the file card_if.h does not exist. I do a delete on the /usr/src/sys directory (I decided to keep a clean cvsup'd source in an outside directory which I move back each time), and do a search for card_if, and find that one exists, int the form of card_if.m in /usr/src/sys/dev/pccard/ . I run the following command to create the file. perl /usr/src/sys/kern/makeobjops.pl -h /usr/src/sys/dev/pccard/card_if.m I did this first, without realising to check /usr/src/sys/modules/wi which did have the card_if.h file when I compiled the kernel without the wi driver. After compiling without the wi driver, I noted quite a few card_if.h files located in misc directories, almost all identical. So I copied one of them to /usr/src/sys/modules/wi/ , put the wi driver back in and compiled, the compile ran through with little problems (the umass driver is another story) The following error is what I get when I try the if_wi.ko module Apr 12 06:02:54 helb kernel: module_register: module pccard/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pccard/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: module_register: module pci/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pci/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_mcastonly)! Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_iponly)! And it won't work, secondly when I goto remove the module.. Its pukes hard and drops me to the db prompt (I'm still semi new to the bleeding edge crap, usually I use stable, but what the hell, so I have no clue other then taking an image of the screen with my digital camera.. On how to dump a copy of the debug info to a file to add to this email) I also tried the awi driver for fun, it loaded fine, but did nothing, I could not talk to the card, and when I tried to kldunload it, it also dropped me to db And that is pretty much where I am at.. No idea where to go now except send off what I know and wait for someone to hopefully fix it :) Jason Ps, I also noted a few of these, not sure what they are unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0400 can't assign resources (port) unknown: PNP0501 can't assign resources (port) --- Hardware in the Machine --- Abit BP6 MB with 2 cpu's (working) Generic Linksys Ethernet card (working) Sound Blaster 16 pnp Vibra card (seems to be detected on boot, but no drivers compiled in yet) Dlink DWL 520 (not working, causing issues, this is what I am trying to get up and and running) Diamond Viper V770 Ultra 2 (seems to be working, X acting kinda funny sometimes though, need to kill moused else it cores on startx) -- Dmesg below -- FreeBSD 5.0-CURRENT #3: Fri Apr 12 04:43:33 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HELB Preloaded elf kernel /boot/kernel/kernel at 0xc03b8000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 369098752 (360448K bytes) avail memory = 354824192 (346508K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 9 IOAPIC #0 intpin 17 - irq 10 IOAPIC #0 intpin 18 - irq 11 IOAPIC #0 intpin 19 - irq 5 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 8 entries at 0xc00fdef0 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA
Possible bug in /sys/i386/pci/pci_cfgreg.c
Hi Folks.
I spent some time tracking down my CardBus problem and found the
following:
In /sys/i386/pci/pci_cfgreg.c:
In Function: static int pci_cfgintr_linked(struct PIR_entry *pe, int pin):
There you can find this code (my changes included):
/* link destination mapped to a unique interrupt? */
/* if (powerof2(pi-irqs)) { // i changed this line to the next
line of code */
/* the reason is given below*/
/* On my system the CardBus bridge has no interrupt assigned (lazy BIOS I
would say).
So pi-irqs is 0. powerof2 returns true (which is wrong as ahown
below).
Then ffs returs 0. that - 1 gives an irq of -1 whis is totally wrong)
The if clause must evaluate to false if there is no interrut assigned
otherwise the system will panic during boot as I experineced it. */
/* I added pi-irqs != 0 */
if (powerof2(pi-irqs) pi-irqs != 0) {
irq = ffs(pi-irqs) - 1;
PRVERB((pci_cfgintr_linked: linked (%x) to hard-routed
irq %d\n,
pi-link, irq));
return(irq);
}
In my opinion the macro powerof2(x) defined in /sys/i386/sys/param.h is
correct
for all input values except 0 (zero).
Proof for zero being illegal input:
powerof2(0) = 0x)-1) (0x)) == 0)
= ((( 0x ) (0x)) == 0)
= ((0x ) == 0)
= true
Since zero is not a power of 2 the returnvalue of powerof2(0) is wrong.
This change may have implictions I do not forsee, so I leave to the
experts what should be done about it.
In my eyes a similar change may be useful in function
pci_cfgintr_unique(..,..).
Now, the system is booting without panic. It does assign an Interrupt for
the CardBus Bridge and my CardBus NIC is detected.
But all this didnt't sove my problem entirely. Although the network card
driver (dc) is loading it is still not configured the right way.
I get a watchdog timeout when trying to use the interface. The shown
MAC adres is also not correct.
I am eager to hear your comment on this issue.
This is my dmesg output with the above mentioned patch applied (boot -v):
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-DP1 #1: Fri Apr 12 12:22:33 GMT 2002
root@:/usr/src/sys/i386/compile/NEWCARD
Preloaded elf kernel /boot/kernel/kernel at 0xc0536000.
Calibrating clock(s) ... TSC clock: 450965769 Hz, i8254 clock: 1193032 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter i8254 frequency 1193182 Hz
CLK_USE_TSC_CALIBRATION not specified - using old calibration method
Timecounter TSC frequency 451024942 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (451.02-MHz 686-class CPU)
Origin = GenuineIntel Id = 0x681 Stepping = 1
Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real memory = 268369920 (262080K bytes)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0055d000 - 0x0ffe7fff, 262713344 bytes (64139 pages)
avail memory = 255537152 (249548K bytes)
bios32: Found BIOS32 Service Directory header at 0xc00fdb70
bios32: Entry = 0xfdb80 (c00fdb80) Rev = 0 Len = 1
pcibios: PCI BIOS entry at 0xf+0xdba1
pnpbios: Found PnP BIOS data at 0xc00f5de0
pnpbios: Entry = f:5744 Rev = 1.0
Other BIOS signatures found:
null: null device, zero device
random: entropy source
mem: memory I/O
Pentium Pro MTRR support enabled
pcibios: BIOS version 2.10
Using $PIR table, 6 entries at 0xc00f6420
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on
motherboard
pci0: physical bus=0
map[10]: type 3, range 32, base e000, size 26, enabled
found- vendor=0x8086, dev=0x7190, revid=0x03
bus=0, slot=0, func=0
class=06-00-00, hdrtype=0x00, mfdev=0
found- vendor=0x8086, dev=0x7191, revid=0x03
bus=0, slot=1, func=0
class=06-04-00, hdrtype=0x01, mfdev=0
found- vendor=0x8086, dev=0x7110, revid=0x02
bus=0, slot=7, func=0
class=06-01-00, hdrtype=0x00, mfdev=1
map[20]: type 4, range 32, base ffa0, size 4, enabled
found- vendor=0x8086, dev=0x7111, revid=0x01
bus=0, slot=7, func=1
class=01-01-80, hdrtype=0x00, mfdev=0
map[20]: type 4, range 32, base e800, size 5, enabled
found- vendor=0x8086, dev=0x7112, revid=0x01
bus=0, slot=7, func=2
class=0c-03-00, hdrtype=0x00, mfdev=0
intpin=d, irq=9
map[90]: type 4, range 32, base 0440, size 4, enabled
found- vendor=0x8086, dev=0x7113, revid=0x02
bus=0, slot=7, func=3
class=06-80-00, hdrtype=0x00, mfdev=0
map[10]: type 4, range 32, base ea00, size 8,
Re: alpha tinderbox failure
I see the same breakage here.
The breakage has nothing to do with -Werror. Recent commit by
Mike Barcroft to sys/*/endian.h is the culprit.
But the actual problem is with gdb. After a lot of experimenting
I've found that contrib/gdb.291/gdb/defs.h includes nm.h
(gnu/usr.bin/binutils/gdb/${MACHINE_ARCH}/nm.h) which are too
different between i386 and alpha. In the i386 case, nm.h
includes sys/types.h which exposes __BSD_VISIBLE (see how
these affect the *_ENDIAN macros in sys/*/endian.h). But not
in the alpha case. Applying this patch exposes the same bug
on i386:
%%%
Index: nm.h
===
RCS file: /home/ncvs/src/gnu/usr.bin/binutils/gdb/i386/nm.h,v
retrieving revision 1.10
diff -u -p -r1.10 nm.h
--- nm.h17 Aug 2000 16:27:26 - 1.10
+++ nm.h12 Apr 2002 13:36:40 -
@@ -133,7 +133,9 @@ extern int kernel_writablecore;
if (!strcmp(STR, kgdb)) \
kernel_debugging = 1;
+#if 0
#include sys/types.h
+#endif
#include sys/ptrace.h
#ifdef PT_GETDBREGS
%%%
The solution is to fix defs.h:
%%%
Index: defs.h
===
RCS file: /home/ncvs/src/contrib/gdb.291/gdb/defs.h,v
retrieving revision 1.3
diff -u -p -r1.3 defs.h
--- defs.h 11 Apr 2001 16:15:19 - 1.3
+++ defs.h 12 Apr 2002 13:53:37 -
@@ -841,6 +841,8 @@ extern void free ();
#ifdef HAVE_ENDIAN_H
#include endian.h
+#else
+#include sys/types.h
#endif
#if !defined (BIG_ENDIAN)
%%%
On Thu, Apr 11, 2002 at 09:54:48AM -0700, Dag-Erling Smorgrav wrote:
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/symmisc.c:
In function `maintenance_print_symbols':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/symmisc.c:540:
warning: assignment makes pointer from integer without a cast
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/symmisc.c:
In function `maintenance_print_psymbols':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/symmisc.c:777:
warning: assignment makes pointer from integer without a cast
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/symmisc.c:
In function `maintenance_print_msymbols':
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/symmisc.c:925:
warning: assignment makes pointer from integer without a cast
In file included from
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/sys/types.h:49,
from
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/symtab.c:40:
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/machine/endian.h:64:
warning: `LITTLE_ENDIAN' redefined
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/defs.h:851:
warning: this is the location of the previous definition
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/machine/endian.h:65:
warning: `BIG_ENDIAN' redefined
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/defs.h:847:
warning: this is the location of the previous definition
In file included from wait.h:93,
from
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/target.c:32:
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/machine/endian.h:64:
warning: `LITTLE_ENDIAN' redefined
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/defs.h:851:
warning: this is the location of the previous definition
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/machine/endian.h:65:
warning: `BIG_ENDIAN' redefined
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/defs.h:847:
warning: this is the location of the previous definition
In file included from
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/sys/types.h:49,
from
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/thread.c:35:
/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include/machine/endian.h:64:
warning: `LITTLE_ENDIAN' redefined
/.amd_mnt/freefall/host/d/home/des/tinderbox/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb.291/gdb/defs.h:851:
warning: this is the location of the previous definition
World broken?
I've seen this twice now on both alpha and sparc64. It looks to be related to
the ENDIAN macro changes:
=== usr.bin/ldd
/arch/sparc64/hosted/bin/gcc -O -pipe -Wall-c
/home/john/work/p4/sparc64/usr.bin/ldd/ldd.c
In file included from /home/john/work/p4/sparc64/usr.bin/ldd/ldd.c:36:
/usr/include/sys/wait.h:114: duplicate member `w_Filler'
/usr/include/sys/wait.h:115: duplicate member `w_Retcode'
/usr/include/sys/wait.h:116: duplicate member `w_Coredump'
/usr/include/sys/wait.h:117: duplicate member `w_Termsig'
/usr/include/sys/wait.h:132: duplicate member `w_Filler'
/usr/include/sys/wait.h:133: duplicate member `w_Stopsig'
/usr/include/sys/wait.h:134: duplicate member `w_Stopval'
/home/john/work/p4/sparc64/usr.bin/ldd/ldd.c: In function `main':
/home/john/work/p4/sparc64/usr.bin/ldd/ldd.c:141: warning: implicit declaration
of function `ntohl'
*** Error code 1
Stop in /home/john/work/p4/sparc64/usr.bin/ldd.
*** Error code 1
Stop in /home/john/work/p4/sparc64/usr.bin.
*** Error code 1
Stop in /home/john/work/p4/sparc64.
*** Error code 1
In sys/wait.h:
union wait {
int w_status; /* used in syscall */
/*
* Terminated process status.
*/
struct {
#if BYTE_ORDER == LITTLE_ENDIAN
unsigned intw_Termsig:7,/* termination signal */
w_Coredump:1, /* core dump indicator */
w_Retcode:8,/* exit code if w_termsig==0 */
w_Filler:16;/* upper bits filler */
#endif
#if BYTE_ORDER == BIG_ENDIAN
unsigned intw_Filler:16,/* upper bits filler */
w_Retcode:8,/* exit code if w_termsig==0 */
w_Coredump:1, /* core dump indicator */
w_Termsig:7;/* termination signal */
#endif
} w_T;
I guess all of those symbols are not defined or something and so have values of
0 and 0 == 0?
sys/wait.h includes machine/endian.h right before it defines this union, so
something must be broke in there.
--
John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: World broken?
Do we already have the in-tree toolchain capable of cross-building sparc64?
On Fri, Apr 12, 2002 at 10:24:31AM -0400, John Baldwin wrote:
I've seen this twice now on both alpha and sparc64. It looks to be related to
the ENDIAN macro changes:
=== usr.bin/ldd
/arch/sparc64/hosted/bin/gcc -O -pipe -Wall-c
/home/john/work/p4/sparc64/usr.bin/ldd/ldd.c
In file included from /home/john/work/p4/sparc64/usr.bin/ldd/ldd.c:36:
/usr/include/sys/wait.h:114: duplicate member `w_Filler'
/usr/include/sys/wait.h:115: duplicate member `w_Retcode'
/usr/include/sys/wait.h:116: duplicate member `w_Coredump'
/usr/include/sys/wait.h:117: duplicate member `w_Termsig'
/usr/include/sys/wait.h:132: duplicate member `w_Filler'
/usr/include/sys/wait.h:133: duplicate member `w_Stopsig'
/usr/include/sys/wait.h:134: duplicate member `w_Stopval'
/home/john/work/p4/sparc64/usr.bin/ldd/ldd.c: In function `main':
/home/john/work/p4/sparc64/usr.bin/ldd/ldd.c:141: warning: implicit declaration
of function `ntohl'
*** Error code 1
Stop in /home/john/work/p4/sparc64/usr.bin/ldd.
*** Error code 1
Stop in /home/john/work/p4/sparc64/usr.bin.
*** Error code 1
Stop in /home/john/work/p4/sparc64.
*** Error code 1
In sys/wait.h:
union wait {
int w_status; /* used in syscall */
/*
* Terminated process status.
*/
struct {
#if BYTE_ORDER == LITTLE_ENDIAN
unsigned intw_Termsig:7,/* termination signal */
w_Coredump:1, /* core dump indicator */
w_Retcode:8,/* exit code if w_termsig==0 */
w_Filler:16;/* upper bits filler */
#endif
#if BYTE_ORDER == BIG_ENDIAN
unsigned intw_Filler:16,/* upper bits filler */
w_Retcode:8,/* exit code if w_termsig==0 */
w_Coredump:1, /* core dump indicator */
w_Termsig:7;/* termination signal */
#endif
} w_T;
I guess all of those symbols are not defined or something and so have values of
0 and 0 == 0?
sys/wait.h includes machine/endian.h right before it defines this union, so
something must be broke in there.
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg37182/pgp0.pgp
Description: PGP signature
Re: Possible bug in /sys/i386/pci/pci_cfgreg.c
In message: Pine.GSO.4.44.0204121353110.3002-10@sunhalle19
Klaus Leibrandt [EMAIL PROTECTED] writes:
: Hi Folks.
:
: I spent some time tracking down my CardBus problem and found the
: following:
:
: In /sys/i386/pci/pci_cfgreg.c:
: In Function: static int pci_cfgintr_linked(struct PIR_entry *pe, int pin):
:
: There you can find this code (my changes included):
:
: /* link destination mapped to a unique interrupt? */
:
: /*if (powerof2(pi-irqs)) { // i changed this line to the next
: line of code */
: /* the reason is given below*/
:
: /* On my system the CardBus bridge has no interrupt assigned (lazy BIOS I
: would say).
:So pi-irqs is 0. powerof2 returns true (which is wrong as ahown
: below).
:Then ffs returs 0. that - 1 gives an irq of -1 whis is totally wrong)
:The if clause must evaluate to false if there is no interrut assigned
:otherwise the system will panic during boot as I experineced it. */
Ah, 0 is a *BOGUS* way of saying no interrupt assigned, per the PCI
spec. However, lots of BIOSes use it, so its meaning must be defined
in some other document I've never laid eyes on since more and more
places are using it.
0 should be mapped in the i386 level.
Try the following patch and let me know how it works for you. There
is also some code now in dev/pci/pci.c that should be removed (since
it is only a subset of this stuff):
if (cfg-intpin 0 cfg-intline != 255
-#ifdef __i386__
-cfg-intline != 0
-#endif
) {
if you have a new enough kernel.
Warner
Index: pci_cfgreg.c
===
RCS file: /cache/ncvs/src/sys/i386/pci/pci_cfgreg.c,v
retrieving revision 1.83
diff -u -r1.83 pci_cfgreg.c
--- pci_cfgreg.c16 Mar 2002 23:02:41 - 1.83
+++ pci_cfgreg.c12 Apr 2002 15:26:06 -
@@ -178,6 +178,7 @@
u_int32_t
pci_cfgregread(int bus, int slot, int func, int reg, int bytes)
{
+uint32_t line, pin;
#ifdef APIC_IO
/*
* If we are using the APIC, the contents of the intline register will probably
@@ -186,7 +187,6 @@
* attempts to read them and translate to our private vector numbers.
*/
if ((reg == PCIR_INTLINE) (bytes == 1)) {
- int pin, line;
pin = pci_do_cfgregread(bus, slot, func, PCIR_INTPIN, 1);
line = pci_do_cfgregread(bus, slot, func, PCIR_INTLINE, 1);
@@ -217,6 +217,18 @@
}
return(line);
}
+#else
+/*
+ * Some BIOS writers seem to want to ignore the spec and put
+ * 0 in the intline rather than 255 to indicate none. The rest of
+ * the code uses 255 as an invalid IRQ.
+ */
+if (reg == PCIR_INTLINE bytes == 1) {
+ line = pci_do_cfgregread(bus, slot, func, PCIR_INTLINE, 1);
+ pin = pci_do_cfgregread(bus, slot, func, PCIR_INTPIN, 1);
+ if (pin != 0 (line == 0 || line = 128))
+ return (255);
+}
#endif /* APIC_IO */
return(pci_do_cfgregread(bus, slot, func, reg, bytes));
}
@@ -394,14 +406,6 @@
(pci_get_slot(*childp) == device)
(pci_get_intpin(*childp) == matchpin)) {
irq = pci_get_irq(*childp);
- /*
-* Some BIOS writers seem to want to ignore the spec and put
-* 0 in the intline rather than 255 to indicate none. Once
-* we've found one that matches, we break because there can
-* be no others (which is why test looks a little odd).
-*/
- if (irq == 0)
- irq = 255;
if (irq != 255)
PRVERB((pci_cfgintr_search: linked (%x) to configured irq %d at
%d:%d:%d\n,
pe-pe_intpin[pin - 1].link, irq,
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: World broken?
John Baldwin [EMAIL PROTECTED] writes: I've seen this twice now on both alpha and sparc64. It looks to be related to the ENDIAN macro changes: [...] I guess all of those symbols are not defined or something and so have values of 0 and 0 == 0? sys/wait.h includes machine/endian.h right before it defines this union, so something must be broke in there. Yes, sys/cdefs.h wasn't being included on some archs. It should be fixed now. Sorry about the breakage. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Ruslan Ermilov [EMAIL PROTECTED] writes:
I see the same breakage here.
The breakage has nothing to do with -Werror. Recent commit by
Mike Barcroft to sys/*/endian.h is the culprit.
But the actual problem is with gdb. After a lot of experimenting
I've found that contrib/gdb.291/gdb/defs.h includes nm.h
(gnu/usr.bin/binutils/gdb/${MACHINE_ARCH}/nm.h) which are too
different between i386 and alpha. In the i386 case, nm.h
includes sys/types.h which exposes __BSD_VISIBLE (see how
these affect the *_ENDIAN macros in sys/*/endian.h). But not
in the alpha case. Applying this patch exposes the same bug
on i386:
[...]
David added sys/types.h to src/gnu/usr.bin/binutils/gdb/alpha/nm.h
19 hours ago, so the problem should no longer exist. I won't know for
another three hours (when my alpha is finished buildworld).
The solution is to fix defs.h:
%%%
Index: defs.h
===
RCS file: /home/ncvs/src/contrib/gdb.291/gdb/defs.h,v
retrieving revision 1.3
diff -u -p -r1.3 defs.h
--- defs.h11 Apr 2001 16:15:19 - 1.3
+++ defs.h12 Apr 2002 13:53:37 -
@@ -841,6 +841,8 @@ extern void free ();
#ifdef HAVE_ENDIAN_H
#include endian.h
+#else
+#include sys/types.h
#endif
#if !defined (BIG_ENDIAN)
%%%
I think machine/endian.h would be better here. It may not have
worked because of the missing sys/cdefs.h issue.
Sorry about the breakage.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
bsd.prog.mk 1.108 - 1.110
Hi! I'm really sorry for 8 hours of breakage between bsd.prog.mk,v 1.108 and bsd.prog.mk,v 1.110. (Testing with the -DNOCLEAN buildworld wasn't a good idea at all.) Sorry about that, it should be fixed now. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg37186/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
On Fri, Apr 12, 2002 at 12:12:12PM -0400, Mike Barcroft wrote:
Ruslan Ermilov [EMAIL PROTECTED] writes:
I see the same breakage here.
The breakage has nothing to do with -Werror. Recent commit by
Mike Barcroft to sys/*/endian.h is the culprit.
But the actual problem is with gdb. After a lot of experimenting
I've found that contrib/gdb.291/gdb/defs.h includes nm.h
(gnu/usr.bin/binutils/gdb/${MACHINE_ARCH}/nm.h) which are too
different between i386 and alpha. In the i386 case, nm.h
includes sys/types.h which exposes __BSD_VISIBLE (see how
these affect the *_ENDIAN macros in sys/*/endian.h). But not
in the alpha case. Applying this patch exposes the same bug
on i386:
[...]
David added sys/types.h to src/gnu/usr.bin/binutils/gdb/alpha/nm.h
19 hours ago, so the problem should no longer exist. I won't know for
another three hours (when my alpha is finished buildworld).
Heh, while I started looking at it, there was no this commit message
in my mailbox yet. :-)
I'm sure you realize that this commit fixed the breakage as a
side effect, and now the defs.h bug is hidden the same way as
for i386.
The solution is to fix defs.h:
%%%
Index: defs.h
===
RCS file: /home/ncvs/src/contrib/gdb.291/gdb/defs.h,v
retrieving revision 1.3
diff -u -p -r1.3 defs.h
--- defs.h 11 Apr 2001 16:15:19 - 1.3
+++ defs.h 12 Apr 2002 13:53:37 -
@@ -841,6 +841,8 @@ extern void free ();
#ifdef HAVE_ENDIAN_H
#include endian.h
+#else
+#include sys/types.h
#endif
#if !defined (BIG_ENDIAN)
%%%
I think machine/endian.h would be better here. It may not have
worked because of the missing sys/cdefs.h issue.
Yes, definitely this is better, now that you've fixed endian.h's.
The optimal solution IMO is to introduce HAVE_MACHINE_ENDIAN_N.
endian.h is pretty non-standard.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg37187/pgp0.pgp
Description: PGP signature
Re: alpha tinderbox failure
On Fri, Apr 12, 2002 at 12:12:12PM -0400, Mike Barcroft wrote: I think machine/endian.h would be better here. It may not have worked because of the missing sys/cdefs.h issue. We will never get that header included in the GDB sources -- it is totally FreeBSD (NetBSD also?) specific. It almost sounds like we have a bug in our headers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
David O'Brien [EMAIL PROTECTED] writes: On Fri, Apr 12, 2002 at 12:12:12PM -0400, Mike Barcroft wrote: I think machine/endian.h would be better here. It may not have worked because of the missing sys/cdefs.h issue. We will never get that header included in the GDB sources -- it is totally FreeBSD (NetBSD also?) specific. It almost sounds like we have a bug in our headers. Sort of. The way it historically built was by taking advantage of the fact that C allows multiple #define's if they are the same. My commit changed the definition of BYTE_ORDER to _BYTE_ORDER instead of LITTLE_ENDIAN or BIG_ENDIAN. The reason this didn't show up as a problem on i386 was because of a sys/types.h include (which includes machine/endian.h) earlier in the source file. machine/endian.h (apparently this is spelled endian.h on other systems) should always be included before fiddling with the byte order manifest constants. Your commit which included sys/types.h on alpha fixed this problem in the same way the i386 case is fixed. Where fixed is defined as a side-effect of fixing another problem. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Mike Barcroft [EMAIL PROTECTED] writes: Sort of. The way it historically built was by taking advantage of the fact that C allows multiple #define's if they are the same. My commit changed the definition of BYTE_ORDER to _BYTE_ORDER instead of LITTLE_ENDIAN or BIG_ENDIAN. Just a little correction. The problem is my commit changed the definition of BIG_ENDIAN from 4321 to _BIG_ENDIAN (which is defined as 4321). Similarly for LITTLE_ENDIAN. The BYTE_ORDER macro isn't touched in defs.h. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Fri, Apr 12, 2002 at 01:01:58PM -0400, Mike Barcroft wrote: the source file. machine/endian.h (apparently this is spelled endian.h on other systems) should always be included before fiddling Should we add a /usr/include/endian.h symlink to machine/endian.h ? if we are the odd-man-out? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: World broken?
On 12-Apr-2002 Ruslan Ermilov wrote: Do we already have the in-tree toolchain capable of cross-building sparc64? No, we need gcc3.1 in the tree for that. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Fri, Apr 12, 2002 at 10:16:59AM -0700, David O'Brien wrote: On Fri, Apr 12, 2002 at 01:01:58PM -0400, Mike Barcroft wrote: the source file. machine/endian.h (apparently this is spelled endian.h on other systems) should always be included before fiddling Should we add a /usr/include/endian.h symlink to machine/endian.h ? if we are the odd-man-out? That would work as well, but this is pretty non-standard. None of BSD/OS, NetBSD, and OpenBSD have this. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg37193/pgp0.pgp Description: PGP signature
RE: WI Driver issues, compile of kernel dies, after fidling it drops to db
I hate replying to my own posts.. Anyways.. It appears The machine I was using as a test machine Either does not support pci 2.2 or is hosed (I'm voting for the latter as the bios seems to be losing its settings every so often)... So you can ignore the long winded issues I type below, sorry if anyone started looking into the problem. Will try different machine and see what happens Jason -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jason Sent: Friday, April 12, 2002 7:38 AM To: Freebsd Current Subject: WI Driver issues, compile of kernel dies, after fidling it drops to db Dunno what I am doing wrong, maybe I am just missing something. I am trying to get my dlink wireless DWL 520 to compile. If I delete /usr/src/sys, and re cvsup to get clean sources (this is a source as of 4am eastern on the 12th April) and run make KERNCONF=HELB buildkernel, it always dies on the wi driver (which I believe is the driver for my card, with is prism 2 based) (listed at the very bottom is the content of my kernel config file). The card is a PCI card which believe is realy an isa card with a bridge to guts of the pcmcia wireless adapter tacked onto it. When I run the compile, it dies with the following error. /usr/src/sys/dev/wi/if_wi_pci.c:68: card_if.h: No such file or directory When I checked the module directory of /usr/src/sys/modules/wi the file card_if.h does not exist. I do a delete on the /usr/src/sys directory (I decided to keep a clean cvsup'd source in an outside directory which I move back each time), and do a search for card_if, and find that one exists, int the form of card_if.m in /usr/src/sys/dev/pccard/ . I run the following command to create the file. perl /usr/src/sys/kern/makeobjops.pl -h /usr/src/sys/dev/pccard/card_if.m I did this first, without realising to check /usr/src/sys/modules/wi which did have the card_if.h file when I compiled the kernel without the wi driver. After compiling without the wi driver, I noted quite a few card_if.h files located in misc directories, almost all identical. So I copied one of them to /usr/src/sys/modules/wi/ , put the wi driver back in and compiled, the compile ran through with little problems (the umass driver is another story) The following error is what I get when I try the if_wi.ko module Apr 12 06:02:54 helb kernel: module_register: module pccard/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pccard/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: module_register: module pci/if_wi already exists! Apr 12 06:02:54 helb kernel: Module pci/if_wi failed to register: 17 Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_mcastonly)! Apr 12 06:02:54 helb kernel: can't re-use a leaf (wi_cache_iponly)! And it won't work, secondly when I goto remove the module.. Its pukes hard and drops me to the db prompt (I'm still semi new to the bleeding edge crap, usually I use stable, but what the hell, so I have no clue other then taking an image of the screen with my digital camera.. On how to dump a copy of the debug info to a file to add to this email) I also tried the awi driver for fun, it loaded fine, but did nothing, I could not talk to the card, and when I tried to kldunload it, it also dropped me to db And that is pretty much where I am at.. No idea where to go now except send off what I know and wait for someone to hopefully fix it :) Jason Ps, I also noted a few of these, not sure what they are unknown: PNP0303 can't assign resources (port) unknown: PNP0f13 can't assign resources (irq) unknown: PNP0501 can't assign resources (port) unknown: PNP0700 can't assign resources (port) unknown: PNP0400 can't assign resources (port) unknown: PNP0501 can't assign resources (port) --- Hardware in the Machine --- Abit BP6 MB with 2 cpu's (working) Generic Linksys Ethernet card (working) Sound Blaster 16 pnp Vibra card (seems to be detected on boot, but no drivers compiled in yet) Dlink DWL 520 (not working, causing issues, this is what I am trying to get up and and running) Diamond Viper V770 Ultra 2 (seems to be working, X acting kinda funny sometimes though, need to kill moused else it cores on startx) -- Dmesg below -- FreeBSD 5.0-CURRENT #3: Fri Apr 12 04:43:33 EDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HELB Preloaded elf kernel /boot/kernel/kernel at 0xc03b8000. Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (367.50-MHz 686-class CPU) Origin = GenuineIntel Id = 0x665 Stepping = 5 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE, MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 369098752 (360448K bytes) avail memory = 354824192 (346508K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 IOAPIC #0 intpin 16 - irq 9
Vinum problems
I suffered a system crash earlier today running -current from April 10. I have a Vinum volume set up as a mirror, and during the reboot, I had to fsck it. Everything seemed normal (at least that's what I thought), but now my volume cannot be mounted. The output from 'vinum list' is as follows: 2 drives: D a State: up /dev/da3s1e A: 0/12288 MB (0%) D b State: up /dev/da4s1e A: 0/12288 MB (0%) 1 volumes: V mirrorState: down Plexes: 2 Size: 11 GB 2 plexes: P mirror.p0 C State: faulty Subdisks: 1 Size: 11 GB P mirror.p1 C State: faulty Subdisks: 1 Size: 11 GB 2 subdisks: S mirror.p0.s0 State: crashed D: aSize: 11 GB S mirror.p1.s0 State: crashed D: bSize: 11 GB The fact that it says the drives have 0% used greatly concerns me. Before I delve into this any further, is that a sign that everything I had is just gone? Or is there some hope of recovery? There is nothing in /var/log/vinum_hitsory or /var/log/messages that gives me any insight into what went wrong. -Patrick To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Kris Kennaway [EMAIL PROTECTED] writes:
It would be helpful to include more build context (i.e. not just the
stderr messages) so that it's possible to distinguish non-fatal
warnings (no -Werror) from fatal warnings (-Werror) or errors.
http://people.freebsd.org/~des/${arch}.log has everything you want.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Problem with rl
Hello I just installed FreeBSD 5.0-DP1 and for some reason my rl (ethernet device rl) card is detected but not installed, is this a known problem? perhaps theres something missing in device.hints? I'll give it a try to paste info from my dmesg but it's hard to write down with pencil/paper ;) /John To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sort and gperf
Hi, sort and gperf was not installed after make world. I think sort is easy to deal with, but I have no idea about gperf. Does this intend to be ? (On regular i386 platform, of course) sort: --- gnu/usr.bin/Makefile.orig Sat Apr 13 02:16:45 2002 +++ gnu/usr.bin/MakefileSat Apr 13 02:16:52 2002 @@ -1,7 +1,7 @@ # $FreeBSD: src/gnu/usr.bin/Makefile,v 1.62 2002/04/10 00:18:14 obrien Exp $ SUBDIR= awk bc binutils cpio dc dialog diff diff3 gperf \ - grep groff gzip man patch ptx rcs sdiff send-pr tar texinfo + grep groff gzip man patch ptx rcs sdiff send-pr sort tar texinfo .if !defined(NO_CVS) SUBDIR+=cvs gperf: (Only gperf.info.gz installed !?) /usr/src/gnu/usr.bin/gperf# make install === doc install-info --quiet --defsection=Programming development tools. --defentry=* Gperf: (gperf).The GNU perfect hash function generator. gperf.info /usr/share/info/dir install -c -o root -g wheel -m 444 gperf.info.gz /usr/share/info /usr/src/gnu/usr.bin/gperf# To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
