Re: the newer binutils
On Thu, May 04, 2000 at 03:18:38PM -0400, Donn Miller wrote: > I noticed that a newer version of binutils is in the source code tree > (2.91). Is there anything that needs to be set during the make world > to make 2.91 the default binutils? Uh... that would be 2.9.1 which is the version that is currently built. Other than eat up your disk space, I haven't done anything public with Binutils yet. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS, rl0 and Alpha
Of all the gin joints in all the towns in all the world, Gary Jennejohn
had to walk into mine and say:
> OK. Unfortunately, gdb core dumps when I try to analyze a crash dump
> with a debugging kernel :( Even worse, gdb core dumps when I try to
> run a debugging gdb in gdb to find out why gdb is core dumping when
> I try to debug a kernel with symbols :(( Wonderful.
I suspect this may have something to do with the way packets sometimes
wrap from the end of the RX buffer pool to the beginning. This might
result in fragmentation across multiple mbufs in some cases (I think).
If I squint hard enough, I can see a way for the data to end up misaligned
in one of the additional mbufs.
Try this patch. It's an untested hack (I don't have a RealTek card
in a test box right this second) but should fix the problem if it's
what I think it is.
-Bill
P.S.: Regardless, somebody should fix gdb.
--
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: [EMAIL PROTECTED] | Center for Telecommunications Research
Home: [EMAIL PROTECTED] | Columbia University, New York City
=
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"
=
*** if_rl.c.origSat Apr 29 14:15:10 2000
--- if_rl.c Thu May 4 22:16:31 2000
***
*** 913,919
goto fail;
}
! sc->rl_cdata.rl_rx_buf = contigmalloc(RL_RXBUFLEN + 32, M_DEVBUF,
M_NOWAIT, 0, 0x, PAGE_SIZE, 0);
if (sc->rl_cdata.rl_rx_buf == NULL) {
--- 911,917
goto fail;
}
! sc->rl_cdata.rl_rx_buf = contigmalloc(RL_RXBUFLEN + 1518, M_DEVBUF,
M_NOWAIT, 0, 0x, PAGE_SIZE, 0);
if (sc->rl_cdata.rl_rx_buf == NULL) {
***
*** 1122,1129
wrap = (sc->rl_cdata.rl_rx_buf + RL_RXBUFLEN) - rxbufpos;
if (total_len > wrap) {
m = m_devget(rxbufpos - RL_ETHER_ALIGN,
! wrap + RL_ETHER_ALIGN, 0, ifp, NULL);
if (m == NULL) {
ifp->if_ierrors++;
printf("rl%d: out of mbufs, tried to "
--- 1120,1132
wrap = (sc->rl_cdata.rl_rx_buf + RL_RXBUFLEN) - rxbufpos;
if (total_len > wrap) {
+ /*
+* Fool m_devget() into thinking we want to copy
+* the whole buffer so we don't end up fragmenting
+* the data.
+*/
m = m_devget(rxbufpos - RL_ETHER_ALIGN,
! total_len + RL_ETHER_ALIGN, 0, ifp, NULL);
if (m == NULL) {
ifp->if_ierrors++;
printf("rl%d: out of mbufs, tried to "
***
*** 1132,1145
m_adj(m, RL_ETHER_ALIGN);
m_copyback(m, wrap, total_len - wrap,
sc->rl_cdata.rl_rx_buf);
- if (m->m_len < sizeof(struct ether_header))
- m = m_pullup(m,
- sizeof(struct ether_header));
- if (m == NULL) {
- printf("rl%d: m_pullup failed",
- sc->rl_unit);
- ifp->if_ierrors++;
- }
}
cur_rx = (total_len - wrap + ETHER_CRC_LEN);
} else {
--- 1135,1140
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: NFS, rl0 and Alpha
Matthew Dillon writes: >:Thanks, but there is code in rl_rxeof() to align to a 32 bit boundary. >:If that weren't the case than I would expect the Alpha to panic with >:other IP applications, not just NFS. >: >:I don't know, NFS must be doing something weird. >: >:--- >:Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] > >NFS will realign the data payload for misaligned packets. > >I agree it sounds like an issue in the NFS code somewhere. Something >that is slipping through unnoticed. If someone can get a crash dump >and do a stack backtrace, or even a simple DDB 'trace', it should be >opssible to track the problem down. OK. Unfortunately, gdb core dumps when I try to analyze a crash dump with a debugging kernel :( Even worse, gdb core dumps when I try to run a debugging gdb in gdb to find out why gdb is core dumping when I try to debug a kernel with symbols :(( Wonderful. I've managed to produce 5 crash dumps so far. Trace in ddb shows that the kernel is panicing in various places, so Matt's thesis that it will be easy to pinpoint is apparently shot full of holes :( I've tried various combinations of nfs mounting with tcp, nfsv2, nfsv3, w=1024 and r=1024. Using TCP mounts makes the panic happen less quickly, but as soon as I `ls' a "big" directory the kernel panics. "Big" seems to be more than 10 or 15 entries. Anyway, here's some of the output from a trace in ddb: panic() at panic+0x100 trap() at trap+0x610 XentUna() at XentUna+0x200 [here a list of various locations in the nfs code from various panics] nfs_readdirrpc() at nfs_readdirrpc+0x10ec nfs_readdirrpc() at nfs_readdirrpc+0x12bc nfs_request() at nfs_request+0x79c nfs3_access_otw() at nfs3_access_otw+0x744 nfs_lookup() at [I didn't write down the offset] _GLOBAL_OFFSET_TABLE_ Looking at a disassembly of e.g. nfs_readdirrpc tells me nothing at all. The Alpha's assembly is highly non-transparent. Trying to figure where the corresponding line in the C-code is located is pretty much impossible without debugging symbols - but see above. Looks like I'll have to live without NFS. At least cvsup works so I can keep my src and ports up to date. BTW I'm not using any off-the-wall options to compile the kernel. Just -O -pipe. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
the newer binutils
I noticed that a newer version of binutils is in the source code tree (2.91). Is there anything that needs to be set during the make world to make 2.91 the default binutils? - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
gratuituous arp for multiple IP addresses
I was recently struck by this problem: Machine running 3.4-STABLE has multiple IP addresses on each of two network interfaces. IP addresses on network interfaces are exchanged for debugging. (de0 gets the IP addresses that de1 had, and vice versa). Machine is rebooted. Connectivity is now lost to secondary IP addresses on each interface, presumably because upstream router's arp cache still has old entries. Said router's arp timeout is long and said router is not under my control. Router administrator eventually forces a cache flush some time later, which restores connectivity. I think a possible solution would be for some future release of FreeBSD-CURRENT to send a gratuituous arp packet, at boot time, for each IP address on each interface. (It appears that FreeBSD does send a gratuituous arp but only for the primary IP address on each interface -- connectivity to the primary IP addresses was observed to be intact after the reboot.) Please correct me if I am making any wrong assumptions. -- Rahul Dhesi <[EMAIL PROTECTED]> (spam-filtered with RSS and ORBS) See my ORBS faq: http://www.rahul.net/dhesi/orbs.faq.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't assign resources
> > Could someone please either take a look at this, or give an > > authoritative comment as to why it's happening. This is the ISA PnP code reporting devices enumerated via the PnP BIOS. At the moment, our support code isn't smart enough to use either the PnP interface or the resource manager, so the unknown device claims these resources to prevent anyone else trying to use them. It's quite harmless, and once things are cleaned up, you won't even see the messages. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: can't assign resources
Trent Nelson wrote: > > Ted Sikora wrote: > > > Your right the addresses seem to be standard machine resources. Are you > > using SMP? The irq's are remapped on a SMP machine so maybe that's were > > the trouble lies? The PNP tag is what has me stumped. I replaced the isa > > cards with pci this evening out of curiosity...same thing. > > Nope, I'm using a UP kernel. Like you mention, I've also taken out my > only PCI card (fxp) and disabled the sound interface via the BIOS and I > get the same thing. I've toggled the `PnP OS' flag in my BIOS as well > which doesn't do anything. > > From what you've said and what I've experienced; I'm even more > convinced the problem's nothing to do with ISA/PCI devices. I'm going to > have a look at the code a bit more later on tonight... > > Another interesting point is the dmesg I get now after I set "int > bootverbose" to '1' in `/usr/src/sys/i386/i386/machdep.c'. I'd really > love to hear from a coding-type figure that could determine the severity > of a lot of the error messages reported. > > Ted, would it be possible to see a copy of your kernel? Also, what > motherboard do you have? > ABit BP6 2x400 Celerons @ 468Mhz or 6x78 The kernel bootup messages are attached. --Ted May 4 12:20:03 telecast /kernel: Copyright (c) 1992-2000 The FreeBSD Project. May 4 12:20:03 telecast /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 May 4 12:20:03 telecast /kernel: The Regents of the University of California. All rights reserved. May 4 12:20:03 telecast /kernel: FreeBSD 5.0-CURRENT #0: Thu May 4 09:54:48 EDT 2000 May 4 12:20:03 telecast /kernel: [EMAIL PROTECTED]:/usr/src/sys/compile/TELECAST May 4 12:20:03 telecast /kernel: Timecounter "i8254" frequency 1193182 Hz May 4 12:20:03 telecast /kernel: CPU: Pentium II/Pentium II Xeon/Celeron (467.98-MHz 686-class CPU) May 4 12:20:03 telecast /kernel: Origin = "GenuineIntel" Id = 0x665 Stepping = 5 May 4 12:20:03 telecast /kernel: Features=0x183fbff May 4 12:20:03 telecast /kernel: real memory = 67108864 (65536K bytes) May 4 12:20:03 telecast /kernel: avail memory = 61837312 (60388K bytes) May 4 12:20:03 telecast /kernel: Programming 24 pins in IOAPIC #0 May 4 12:20:03 telecast /kernel: IOAPIC #0 intpin 2 -> irq 0 May 4 12:20:03 telecast /kernel: FreeBSD/SMP: Multiprocessor motherboard May 4 12:20:03 telecast /kernel: cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 May 4 12:20:03 telecast /kernel: cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 May 4 12:20:03 telecast /kernel: io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 May 4 12:20:03 telecast /kernel: Preloaded elf kernel "kernel" at 0xc0365000. May 4 12:20:03 telecast /kernel: Pentium Pro MTRR support enabled May 4 12:20:03 telecast /kernel: npx0: on motherboard May 4 12:20:03 telecast /kernel: npx0: INT 16 interface May 4 12:20:03 telecast /kernel: pcib0: on motherboard May 4 12:20:03 telecast /kernel: pci0: on pcib0 May 4 12:20:03 telecast /kernel: pcib1: at device 1.0 on pci0 May 4 12:20:03 telecast /kernel: pci1: on pcib1 May 4 12:20:03 telecast /kernel: pci1: at 0.0 irq 16 May 4 12:20:03 telecast /kernel: isab0: at device 7.0 on pci0 May 4 12:20:03 telecast /kernel: isa0: on isab0 May 4 12:20:03 telecast /kernel: atapci0: port 0xf000-0xf00f at device 7.1 on pci0 May 4 12:20:03 telecast /kernel: ata1: at 0x170 irq 15 on atapci0 May 4 12:20:03 telecast /kernel: pci0: at 7.2 May 4 12:20:03 telecast /kernel: Timecounter "PIIX" frequency 3579545 Hz May 4 12:20:03 telecast /kernel: intpm0: port 0x5000-0x500f irq 9 at device 7.3 on pci0 May 4 12:20:03 telecast /kernel: intpm0: I/O mapped 5000 May 4 12:20:03 telecast /kernel: intpm0: intr IRQ 9 enabled revision -1072311040 May 4 12:20:03 telecast /kernel: smbus0: on intsmb0 May 4 12:20:03 telecast /kernel: smb0: on smbus0 May 4 12:20:03 telecast /kernel: intpm0: PM I/O mapped 4000 May 4 12:20:03 telecast /kernel: ed0: port 0xc400-0xc41f irq 19 at device 9.0 on pci0 May 4 12:20:03 telecast /kernel: ed0: supplying EUI64: 00:60:67:ff:fe:22:c8:84 May 4 12:20:03 telecast /kernel: ed0: address 00:60:67:22:c8:84, type NE2000 (16 bit) May 4 12:20:03 telecast /kernel: pcm0: port 0xc800-0xc83f irq 17 at device 13.0 on pci0 May 4 12:20:03 telecast /kernel: atapci1: port 0xd400-0xd4ff,0xd000-0xd003,0xcc00-0xcc07 irq 18 at device 19.0 on pci0 May 4 12:20:03 telecast /kernel: ata2: at 0xcc00 on atapci1 May 4 12:20:03 telecast /kernel: atapci2: port 0xe000-0xe0ff,0xdc00-0xdc03,0xd800-0xd807 irq 18 at device 19.1 on pci0 May 4 12:20:03 telecast /kernel: fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 May 4 12:20:03 telecast /kernel: fdc0: FIFO enabled, 8 bytes threshold May 4 12:20:03 telecast /kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 May 4 12:20:03 telecast /kernel: atkbdc0: at port 0x60,0x64 on isa0 May 4 12:20:03 telecast /kernel: atkbd0: irq 1 on atkbdc0
$B2>EPO?$O#57n#1#5F|$^$G!*:#$J$iA@$($k(B$B7n<}#1#2#0#0K|!*(B
$BFMA3%a!<%k$rAw$i$;$FD:$$$?$3$H$r?<$/$*OM$S$$$?$7$^$9!#(B$B6=L#$N$J$$J}$O$*5v$7$/$@$5$$!#$3$N$^$^:o=|$7$F$/$@$5$$!#(B$B$?$$$X$s?=$7Lu$4$6$$$^$;$s$G$7$?!#(B$B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B$B7n<}#1#2#0#0K|1_$N2DG=@-$b$"$k%S%C%0$J>pJs$r$*EA$($7$^$9!#(B $B#37n#3#1F|$+$i#57n#1#5F|$^$G2>EPO?$B:#$J$i2>EPO?$K;22C$G$-$k%i%9%H%A%c%s%9$G$9(B!$B:#!"2>EPO?$r$G$-$l$P!"$[$\2q7k$N>uBV$G$9!#(B $B8=:_$O$^$@?eLL2<$N3hF0$G$9$N$G@5<0H/I=$O$5$l$F$$$^$;$s$,(B$B?.$8$i$l$J$$F|K\$NBg4k6H$K$h$k;qK\!"5;=QDs7H$G%9%?!<%H$H$N>pJs$G$9!#(B $B#47n#2#6F|H/Gd$N!c#B!]#i#n#g!d$H!c$H$i$P!<$f!d(B$B#57n#1#0F|H/Gd$N!c#B!]#i#n#g!d$G5a?M9-9p$,7G:\$5$l$^$7$?!#(B$B$$$+$,$o$7$$CDBN$N%S%8%M%9$G$O@dBP$K$J$$$3$H$N>ZL@$G$b$"$j$^$9!#(B $B$O#S#T#A#R#W#E#B#2#1(B$B@5<0$J%S%8%M%9%9%?!<%H$O#2#0#0#0G/#77n$G$9!#(B $B#57n#1#5F|$^$G$N2>EPO?4|4VCf$OEPO?HqMQ$O$+$+$j$^$;$s!#(B$BL5NA$G2>EPO?$r:Q$^$;$F$*$-!"#67n#1F|%9%?!<%H$7$F$+$i$b!"(B$B$b$7!"ITK~$,$"$l$P%/!<%j%s%0%*%U!J#8F|4V!K$b$G$-$^$9!#(B $B8=CJ3,$G$O<+:n%[!<%`%Z!<%8Ey$G$N@kEA$O6X;_$5$l$F$^$9$7(B$B%i%j!<$d%_!<%F%#%s%0$N$h$&$J3hF0$b8=:_9T$o$l$F$$$^$;$s!#(B$B$f$($K8XBg$JI=8=$N4+M6$,HEMt$7$F$$$^$9$,OG$o$5$l$J$$$G$/$@$5$$!#(B $B$7$+$7$J$,$i!"%S%C%0$J%A%c%s%9$G$"$k$3$H$O4V0c$$$"$j$^$;$s!#(B$B$3$N%a!<%k$r$BEXNO$7$@$$$G!"7n<}#1#2#0#0K|1_$O==J,$K2DG=$J$O$:$G$9!#(B $B4pK\E*$K$O#2#0#M#B$N#H#P%9%Z!<%9$r%l%s%?%k$9$k%S%8%M%9$G$9!#(B$B%*%s%i%$%s%^%H%j%C%/%9$G$9$+$i!":81&$I$A$i$+$NJRJ}$N7ONs$K$O!"(B$B%@%&%s$,$+$C$F$K>e$+$i9_$j$F$-$^$9!#(B $B0J>e$N$h$&$K8=:_!c>R2pEPO?4|4V!d$N$?$a!"(B$BHs>o$K8B$i$l$?>pJs$NCf$GH=CG$7$F$$$?$@$/$7$+$"$j$^$;$s!#(B$B$=$l$G$b2r$C$F$$$?$@$1$kJ}$K$7$+%A%c%s%9$O$3$J$$$H$$$&$3$H$G$9!#(B $B%[!<%`%Z!<%8$K4X$7$F$N%3%_%C%7%g%s$O=5J'$$$G#3#0#0K|1_$^$G!#(B$BJs=7$N;YJ'J}K!$O%P%$%J%j!]$H%^%H%j%C%/%9!"%*!<%S%C%HJ}<0$G$9!#(B$B$o$+$k$R$H$K$O$o$+$k!"9M$($&$k:G9b$N%7%9%F%`$G$9!#(B==$B%5!<%S%9$NFbMF$O(B$B%$%s%?!<%M%C%H=i?4e5i$B$3$l$@$1B7$C$FG/2qHq(B\10,000$B!JF~2qHq(B\1,550$BJL!K$G$9!#(B $B-!#2#0%a%,0J>e$N%[!<%`%Z!<%8(B$B-"4JC1$G$*$7$c$l$J:n@.%D!<%k(B$B-#(BE$B%3%^!<%9(B$B-$%W%m%P%$%@!<%5!<%S%9(B$B-%40`z$J%+%9%?%^!<%5!<%S%9Ey(B$B$5$^$6$^$J6HBV$r4^$`Am9g%S%8%M%9$G$9!#(B $B2?EY$b?=$7>e$2$^$9$,(B$B8=:_$^$@2>EPO?$NJg=8$J$N$G$*6b$O$+$+$j$^$;$s!#(B$B#67n$N@$3&0l@F%0%i%s%I%*!<%W%s;~$KEPO?$9$k$+$I$&$+7h$a$F2<$5$$!#(B $BK\EPO?$N:]$NEPO?HqMQ$O!o#1#1(B,$B#5#0#0$@$1!JG/4V!K0l?M0l8}8BDj$G$9!#(B$B$?$@$7!"2q5BzI,MW!K$NEPO?$b#O#K$G$9!#(B$B2>EPO?$GM-Mx$J%]%8%7%g%s$N3NJ]$r$7$F$*$$$FM_$7$$$N$G$9!#(B=$BEPO?$N;EJ}$O4JC1$G$9!#(B$B$^$:$O!"%[!<%`%Z!<%8$r3+$$$F3NG'$7$F2<$5$$!#(B$BI,$:A4$F$r$*FI$_$$$?$@$-!"$4<+?H$N@UG$$G2>EPO?$K$*?J$_$/$@$5$$!#(B $B$?$@$7!"$b$O$d%"%/%;%9=8Cf$,$9$4$$>uBV$K$J$C$F$$$^$9$N$G!"(B$B$J$+$J$+7R$C$F$O$/$l$^$;$s!#$[$H$s$ICjA*$K6a$$$h$&$J>u67$G$9!#(B$B$=$l$@$1Bg$-$J%A%c%s%9$G$"$k$H!"3'$5$s$,G'<1$5$l$F$$$k$N$G$9!#(B $B%?%$%`%"%&%H$7$F!V#W#E#B>e$NLdBj!W$H$$$&%a%C%;!<%8$,I=<($5$l$F$b(B$B$"$-$i$a$:$K!"2?EY$b%H%i%$$7$??M$K$@$1!"9,1?$N=w?@$,Hy>P$_$^$9!#(B$B@h$KEPO?$G$-$l$P!"$=$l$@$1B?$/!">! $B$D$^$j!"$3$N%S%8%M%9$O!"$^$5$KAa$$$b$N>!$A$N>u67$G$9$N$G!"(B$B$_$J$5$s!"7R$,$k$^$G!"I,;`$G%"%/%;%9$5$l$F$$$k>u67$J$N$G$9!#(B$B$*$=$i$/F|K\A49q$K9-$^$k$N$O0l=V$G$7$g$&!#$=$N $B8=:_$N$H$3$m!"D+$N#3;~:"$+$iF1$8$/D+$N#8;~:"$^$G$J$i!"(B$B$^$@$J$s$H$+$9$s$J$j%"%/%;%9$G$-$k$h$&$G$9$,!"(B$B$=$l0J30$O$+$J$j87$7$/$J$j$^$9$N$G4hD%$C$F%"%/%;%9$7$F$/$@$5$$!#(B $BLk$N#1#1;~$r2a$.$k$H#1;~$^$G$O!"$[$H$s$I7R$,$i$J$/$J$C$F$-$^$9!#(B $B2qR2p$N#H#P!J$^$@!"$D$J$,$j$d$9$$!K(Bhttp://www.starweb21.com/ $B$+$J$i$:$h$/$*FI$_$/$@$5$$!#4V0c$C$?>pJs$,HEMt$7$F$$$k$h$&$G$9!#(B$BFC$KF~$j8}%Z!<%8$N%*%l%s%8?'$N!c(BWARNING$B!d$OI,?\$G$9!#(B$BF1$8%Z!<%8$N:8%5%$%I$K=D$K#5Ns$N%j%s%/$,$"$j$^$9!#(B$B>\:Y$NM}2r$O!"$3$A$i$+$i$*4j$$$7$^$9!#(B $B2>EPO?MQ$N#U#R#L!J$+$J$j$N=8Cf>uBV$G$9!K(Bhttp://www.starweb21.com/cp/kz $B2>EPO?$O!">R2p$B$4<+?H$N@UG$$G!"2>EPO?$O!"$3$A$i$+$i$*4j$$$7$^$9!#(B$BESCf$G!V1&!W!V:8!W$N7ONs$rA*Br$9$k>lLL$,=P$F$-$^$9$,!"(B$B8=:_!"Ev%0%k!<%W$O!V1&7ONs!W$r?d>)$7$F$$$^$9!#(B $B$J$*8f0l?M$NJ}$N#2=EEPO?$O$G$-$^$;$s!#(B$BH/3P$9$l$PEPO?C$7=hJ,$H$J$j$^$9!#(B$BF1$8=;=j$G$b!"$42HB2!"5Z$S!"?F8" $B$^$?!"K!?M$G$NJLEPO?$O2DG=$H$J$C$F$$$^$9!#(B $B5.J}$X$N%\!<%J%9?69~$_8}:BHV9f$OH>3Q$G$9!#(B$BEPO?$7$?=V4V$K?tL>$N%@%&%s$,>!$B#1IC$r6%$&EPO??t$H$$$&$N$OK\Ev$NOC$G$9!#$9$4$$$3$H$K$J$j$^$9!#(B $B;d$N%"%C%W$OFsF|$G#2#5?M$NJ}$,%@%&%s$K$9$0$D$$$?$H8@$C$F$$$^$9!#(B$B4hD%$C$F!":.$s$G$$$J$$;~4V!J8aA0!uCk4V!K$K%"%/%;%9$7$F$_$F2<$5$$!#(B$B2>EPO?$r$b$N$7$F!"$"$J$?$N?M@8$K?7$?$J%A%c%s%9$r2C$($F$/$@$5$$!#(B===$B$^$:2<$N2>EPO?(B URL$B%U%)!<%`$h$j!V:8!W7ONs$G2>EPO?$r$7$F$/$@$5$$!#(B$B2?EY$b8@$$$^$9$,!"D+$N#3;~$+$i!"D+$N#8;~$,A@$$L\$G$9!#(B$B$=$l0J30$N;~4V$O!"$[$H$s
Re: can't assign resources
Ted Sikora wrote: > Your right the addresses seem to be standard machine resources. Are you > using SMP? The irq's are remapped on a SMP machine so maybe that's were > the trouble lies? The PNP tag is what has me stumped. I replaced the isa > cards with pci this evening out of curiosity...same thing. Nope, I'm using a UP kernel. Like you mention, I've also taken out my only PCI card (fxp) and disabled the sound interface via the BIOS and I get the same thing. I've toggled the `PnP OS' flag in my BIOS as well which doesn't do anything. From what you've said and what I've experienced; I'm even more convinced the problem's nothing to do with ISA/PCI devices. I'm going to have a look at the code a bit more later on tonight... Another interesting point is the dmesg I get now after I set "int bootverbose" to '1' in `/usr/src/sys/i386/i386/machdep.c'. I'd really love to hear from a coding-type figure that could determine the severity of a lot of the error messages reported. Ted, would it be possible to see a copy of your kernel? Also, what motherboard do you have? Are there any other coding-type figures actually following this thread? > Ted Sikora > Jtl Development Group > [EMAIL PROTECTED] Regards, Trent. (dmesg w/ bootverbose=1 attached, please take a look!) Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Wed May 3 21:26:09 WST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/breaker_03May2000 Calibrating clock(s) ... TSC clock: 232779341 Hz, i8254 clock: 1193149 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 CPU: Pentium II/Pentium II Xeon/Celeron (232.79-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping = 3 Features=0x80f9ff real memory = 66977792 (65408K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00372000 - 0x03fd7fff, 63332352 bytes (15462 pages) avail memory = 60895232 (59468K bytes) bios32: Found BIOS32 Service Directory header at 0xc00fdb60 bios32: Entry = 0xfdb70 (c00fdb70) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb91 pnpbios: Found PnP BIOS data at 0xc00f5ff0 pnpbios: Entry = f:5904 Rev = 1.0 Other BIOS signatures found: ACPI: 000fa050 Preloaded elf kernel "kernel" at 0xc0359000. Pentium Pro MTRR support enabled md0: Malloc disk Creating DISK md0 Math emulator present npx0: on motherboard npx0: INT 16 interface pcib0: on motherboard found-> vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base f800, size 26, enabled found-> vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base ffa0, size 4, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=10 map[20]: type 1, range 32, base ef80, size 5, enabled found-> vendor=0x8086, dev=0x7113, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[90]: type 1, range 32, base 0440, size 4, enabled found-> vendor=0x1274, dev=0x1371, revid=0x06 class=04-01-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base ef00, size 6, enabled found-> vendor=0x8086, dev=0x1229, revid=0x08 class=02-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=9 map[10]: type 1, range 32, base febff000, size 12, enabled map[14]: type 1, range 32, base ee80, size 6, enabled map[18]: type 1, range 32, base fea0, size 20, enabled pci0: on pcib0 pcib1: at device 1.0 on pci0 found-> vendor=0x10de, dev=0x0020, revid=0x04 class=03-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=a, irq=11 map[10]: type 1, range 32, base fd00, size 24, enabled map[14]: type 1, range 32, base f300, size 24, enabled pci1: on pcib1 pci1: (vendor=0x10de, dev=0x0020) at 0.0 irq 11 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xffa0 ata0: ma
Re: NS DP83932 SONIC driver
On Thu, 4 May 2000, Motomichi Matsuzaki wrote: > And I wonder, Is there any ISA card using this chip? Dunno, but I've got some EISA boards that use it. > For both 5-current and 4-stable source codes (beta quality) are: > > http://triaez.kaisei.org/~mzaki/sonic/ I'll take a look. Thanks, a SONIC driver has been on my TODO for a long time now. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | This Space For Rent | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NS DP83932 SONIC driver
Hi. I ported SONIC ethernet driver into FreeBSD from NetBSD/pc98. The original driver (named 'sn') on NetBSD/pc98 is for several NEC C-bus(alike ISA) and PCMCIA card. There is already 'sn' driver on FreeBSD for SMC 9xxx series ethernet, so I renamed to 'snc' after "SONIC". Is there any objection to this name? And I wonder, Is there any ISA card using this chip? For both 5-current and 4-stable source codes (beta quality) are: http://triaez.kaisei.org/~mzaki/sonic/ Thank you. -- Motomichi Matsuzaki <[EMAIL PROTECTED]> Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
