Network performance-problem
Hello, i am seeing a problem with 5.0-current (from 14.12.00) and a 3COM 3CCFE575CT Lancard (pc-cardbus) using the xl-driver. It goes as follows: I am using the 3COM-card in a 10MB-switched network. Occasionally someone is doing big network installs via multicast IP-packets. This is done with almost the full 10MB-Bandwidth. On all the other computers I have, I do see a big network-performance degration during that times, but they are still somewhat usable. This is true for HPUX 10.20 , 11.0 and NT 4.0 machines. My Laptop (HP OB4150) unfortunately is network- wise totally blocked during these times. In addition I am getting messages like: xl0: watchdog timeout xl0: watchdog timeout xl0: no carrier - transceiver cable problem? xl0: watchdog timeout xl0: watchdog timeout xl0: no carrier - transceiver cable problem? Why behaves my FreeBSD-machines worse then the other boxes? Any Ideas? TIA Michael Attached are the Kernel-Config-file and the dmesg output. -- ___ Michael ClassE-Mail: [EMAIL PROTECTED] E-Business Solution Division Phone: +49 7031 14-3707 Fax:+49 7031 14-4505 ___ Hewlett-Packard GmbH, PO Box 1430, Mailstop ESD2, 71004 Boeblingen Managing Directors: Rainer Geissel (Chairman),Rainer Erlat, Heribert Schmitz, Hans-Jochen Lueckefett, Fritz Schuller Chairman of the Supervisory Board: Joerg Menno Harms Commercial register: Amtsgericht Boeblingen HRB 4081 ___ Copyright (c) 1992-2000 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-CURRENT #2: Thu Dec 14 11:13:18 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/MCOBTEST Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (397.05-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x66a Stepping = 10 Features=0x183f9ff real memory = 201326592 (196608K bytes) avail memory = 191971328 (187472K bytes) Preloaded elf kernel "kernel" at 0xc03a5000. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 6 entries at 0xc00fdf60 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vga_pci0: mem 0xfec0-0xfecf,0xfe80-0xfebf,0xfd00-0xfdff irq 9 at device 0.0 on pci1 pci1: at 0.1 (no driver attached) pccbb0: at device 4.0 on pci0 pccbb0: PCI Memory allocated: 1802 pci_cfgintr_unique: hard-routed to irq 10 pci_cfgintr: 0:4 INTA routed to irq 10 cardbus0: on pccbb0 pccard0: <16-bit PCCard bus> on pccbb0 pccbb1: at device 4.1 on pci0 pccbb1: PCI Memory allocated: 18021000 pci_cfgintr_unique: hard-routed to irq 10 pci_cfgintr: 0:4 INTB routed to irq 10 cardbus1: on pccbb1 pccard1: <16-bit PCCard bus> on pccbb1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfcf0-0xfcff at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: irq 10 at device 7.2 on pci0 uhci0: Could not map ports device_probe_and_attach: uhci0 attach returned 6 pci0: at 7.3 (no driver attached) fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 pmtimer0 on isa0 unknown: can't assign resources unknown: can't assign resources pcm0: at port 0x220-0x22f,0x530-0x537,0x388-0x38f,0x120-0x121 irq 5 drq 0,1 on isa0 unknown: can't assign resources unknown: can't assign resources IP packet filtering initialized, divert enabled, rule-based forwarding enabled, default to accept, unlimited logging ata1-slave: ata_command: timeout waiting for intr ata1-slave: identify failed ad0: 9590MB [19485/16/63] at ata0-master UDMA33 acd0: DVD-ROM at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s1a pccbb0: card inserted: event=0x, state=3820 pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] pccbb0: pccbb_power: CARD_VCC_3V and CARD_VPP_VCC [11] TUPLE: LINKTARGET [3]: 43 49 53 Manufacturer ID: 01015752 TUPLE: CONFIG_CB [6]: 03 01 00 00 00 00 TUPLE: CFTABLE_ENTRY_CB [13]: 41 9a 01 b5 1e 01 b5 1e 02 30 ff ff 01 cardbus0: Opening BAR: type=IO, bar=10, len=0040 Product version: 5.0 Product n
dev/acpica/acpi.c - minor patch for cleaner poweroff
Hi,
I think you're the main maintainer of the ACPICA codebase (and yes, I know
that parts of it is imported from Intel). Attached is a trivial patch which
makes for cleaner testing for RB_POWEROFF in acpi_shutdown_final() - I've had
various kernel/userland routines invoke reboot sequences where the howto had
more bits set than RB_POWEROFF, e.g. RB_NOSYNC. With this patch, shutdown -p
works for me :)
Thanks for all the work on ACPICA :)
G'luck,
Peter
PS. Please CC: me in replies as I'm not on -current.
--
If I had finished this sentence,
Index: acpi.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi.c,v
retrieving revision 1.7
diff -u -r1.7 acpi.c
--- acpi.c 2000/12/12 14:20:27 1.7
+++ acpi.c 2000/12/18 14:55:43
@@ -657,7 +657,7 @@
{
ACPI_STATUSstatus;
-if (howto == RB_POWEROFF) {
+if (howto & RB_POWEROFF) {
printf("Power system off using ACPI...\n");
if ((status = AcpiSetSystemSleepState(ACPI_STATE_S5)) != AE_OK) {
printf("ACPI power-off failed - %s\n", acpi_strerror(status));
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Monday, 18th December 2000, "Donald J . Maddox" wrote: >On Mon, Dec 18, 2000 at 04:41:17PM +1000, Stephen McKay wrote: >> >> I expected some build tool expert to say "Just compile with these >> options". But they haven't. So I'll see if the bits have rotted, >> or whether we can keep building ld.so instead of just including >> an age old binary. >Well, if you do manage to uncover the lost magic, please let me know :) It's getting a little more magic every day to generate a.out stuff, but not all that bad. Basically I built lib/csu/i386, gnu/lib/libgcc, lib/libc and libexec/rtld-aout, in order, with these settings: NOMAN=yup DESTDIR="" OBJFORMAT=aout MAKEOBJDIRPREFIX=/usr/obj/aout In each directory, I used make obj, make, make install. (By the way, there are a lot of twisty little passages in /usr/share/mk. One of them required me to add DESTDIR="", which should be a NOP.) The generated ld.so has bloated a bit :-) but works fine. So we could in principle build ld.so for every release. It's just a question of whether we should. I think we should. But it might be just as easy to copy it off the 3.3 CD every time. It's dead end stuff after all. Does the release engineer have an opinion? Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Tuesday, 19th December 2000, Stephen McKay wrote: >But it might be just as easy to copy it off the 3.3 CD every time. Oops! As I wrote earlier, 3.3 and onward have the broken ld.so. Good copies are found on 3.0 though to 3.2. Sorry for veering off the road there. :-) Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
$B>/$7$N$*6b$GBg6b$,
$BFMA3$N%a!<%k$9$_$^$;$s(B $B:G=i$G:G8e$G$9!#=EJ#$7$?J}$O!"K\Ev$K?=$7Lu$4$6$$$^$;$s!#(B $B$"$kF|;d$N=j$K0J2<$h$&$J!V(B4000$B1_$GBg6b$,P!K(B $B$3$l$O!"F~$i$J$-$cB;$G$9$h!#Ii$1$F$P$C$+$j$N%Q%A%s%3$d%.%c%s%V%k(B $B$r!"$d$k$h$j$O$?$C$?0l2s$N?69~$_$@$1$G!"$"$J$?$N?M@8>P$$$C$Q$J$7(B $BFI$s$G$_$k2ACM$O$"$k$H;W$$$^$9$h!#(B $B$4LBOG$G$7$?$i>C$7$F$/$@$5$$(B --$B!c;22CeHo32C$($F$7$^$C$??M$K$bF1$8$0$i$$$N6b$,Mh$F$k$s$@$m$&$H;W$&$s$@$h(B $B8e$m$N?M$,Ho32C$($F$^$?EPO?$9$k;~$O0lHV8e$K$J$k!#(B $B9T$-$D$1$PA0$b8e$m$b$J$$$s$@$h$M!#(B $B$G26$O!"#47n$N;q6b$G$^$?%A%c%l%s%8!*(B $B$?$^$C$?6b$G?7R2p!d(B--- $B9gK!E*$GLY$+$k%^%M!<%2!<%`EP>l(B $B4JC1$G$9!#>/$J$$;qK\6b$GBg6b$,/;qK\$GG|Bg$JMx1W$G$9!#!*!*(B $B#4#0#0#01_$N;qK\$G@($$Bg6b$,e$NBg6b!J#1#0#0K|1_0J>e!K$r?.H>5?$GBT$C$F$$$k$H!"MbF|$K#17o$N?69~$,M-$j$^$7$?!#(B $Be$N?69~$,!"KhF|!"B+$K$J$C$F(B $BMh$kMM$K$J$j$^$7$?!#(B $BGO/$J$/$H$b5.J}$NG/<}$h$j$bB?$/$J$k$O$:!D!#(B $B$3$l$G?M@8JQ$o$k$+$b!*M7$S?4$r$*;}$A$NJ}$@$1@'Hs;22C$7$F2<$5$$(B $BK!N'E*$K$OA4$/LdBj$"$j$^$;$s!J8e=R$7$^$9$,?7J9;fLL$G$be$2$i$l$F$^$9!#(B - $B"#;22CJ}K!!J$3$N%2!<%`$N$7$/$_>R2p4^$`!K"#(B $B#1!"$^$:!"2<5-#4?M$N8}:B$K$*6b$r?6$j9~$s$G$/$@$5$$!#(B $B!J6d9T$N<+F0?69~5!$G?6$j9~$_$^$9!##4?M$N8}:B$NItJ,$r(B $B0u:~$7$F$$$/$H3Z$G$9!#!K(B $B#2!"e$N?M$r:o=|$7$^$9!#!J0lHV>e$N8}:B$r:o=|$9$k$+$i!"(B $BK!N'$K?($l$J$$$G:Q$`$N$G$9!#$=$l$@$1$O@dBP$Ke$+$i=g$K?6$j$J$*$7$^$9!#(B $B!J$3$&$7$F=gHV$K>e$N?M$,H4$1$F$$$/$N$G0cK!@-$O$J$$!"$H$$$&(B $BJ[8n;N$NJ}$N@bL@$,$"$j$^$7$?!#!K(B $B#3!"$=$l$r!"$G$-$k$@$1$?$/$5$s%$%s%?!<%M%C%H$N7G<(HD$N%"%I%l%9(B $B$KAw$C$F$/$@$5$$!#$=$&$9$l$P!"$"$H$O$=$l$re0L$N?M$N8"Mx$,>C$($k$7(B $B$/$_$J$N$G2<$N?M$d8e$+$i;22C$7$??M$,ITMx$H$$$&$o$1$G$O$J$/>r7o(B $B$,A4$/F1$8$J$N$G$9!#:G=i$N#1=54V$G#1#07o0J>e$N?69~$,L5$$>l9g(B $B$O$b$&%R%H%U%s%P%j$7$^$9!#(B $B#4!"8e$O!"8=6b!o#1!$#0#0#01_$,?69~$^$l$k$N$rBT$D$@$1$G$9!#(B $B"#%j%9%H"#(B 1 $B%+%H%&%f%-%3!!==O;6d9T!!BgA>:,;YE9(B $BIaDL#1#1#4#7#6#9#1(B 2$B!!%$%H%&%3%&%$%A%m%&!!D+F|?.MQ6b8K!!@>Hx5W;YE9(B $B!!IaDL#2#1#1#6#0#1(B 3$B!!%J%+%`%i%?%/%d!!KLMN6d9T!!;%KZ1XFn8};YE9(B $B!!IaDL#3#5#2#5#5#1#7(B 4$B!!%+%o%@%^%5%d!!El3$6d9T!!A0$r:\$;$k$H!"(B $B>e0L$N?M$N?69~$_3NG'$G$P$l$FAJ$($i$l$?$j!"(B $B$$$m$$$m$J967b$rr7o$G<}1W$r4|BT(B $B$G$-$k$N$G$9$+$i!#;22C$7$F#2=54V$r2a$.$?:"$+$iJ?6Q$7$FA}2C$7(B $B$F$/$k$H$$$&OC$G$9!#KhF|8}:B;D9b$r3NG'$9$k$N$,3Z$7$/$J$kL4$N(B $B$h$&$J%2!=%`$K;22C$7$F!"@:?@E*$K4r$7$/$J$kF|!9$rAw$j$^$;$s$+(B $B:#$9$0%3%T!=$7$F!"5.J}$b;22C$7$FL4$re5-$N9TF0$r7+$jJV$;$P$N$G$9!#(B $B"';29M"'(B -$B$3$N%2!<%`$,!X0cK!!Y$H;W$o$l$F$$$kJ}$X!#(B-- $B$3$N%2!<%`$O0cK!$G$O$"$j$^$;$s!#(B $B;d$b0l1~;22C$9$k$KEv$C$F!"Hs9gK!$J%2!<%`$G$"$l$P(B $BEvA3HH:a$G$"$k$H9M$(!"EE;R%a!<%k$r;H$C$FK?J[8n;N(B $B$5$s$H!"$3$NFbMF$K$D$$$FAjCL$5$;$F$$$?$@$-$^$7$?!#(B $B$=$NOC$7$N7k2L$r!"$3$A$i$K$^$H$a$^$9!#(B $B!zL58BO":?9V!JDL>N!'$M$:$_9V!K$K$D$$$F!#(B $B>rJ8$K$h$l$P!"(B --- $B$3$NK!N'$K$*$$$F!VL58BO":?9V!W$H$O!"6bIJ$r=P$($s(B $B$9$k2CF~e$NG\N($r$b$D$FA}2C$9$k8eB3$N2CF~(B $B$l$NCJ3,$K1~$8$?8e=g0Le2s$k2A3[Kt$O?tNL$N6bIJ$rR2p$7$F$$$k%7%9%F%`$O!"@h$K;22C$7$?J}!J=g0L&K!$G$O$"$j$^$;$s!#(B $B0J2<$K=q$+$l$F$$$^$9$h$&$K2q0w$rAM;;<0$K3HBg$5$;$k$3$H$r>r7o$H(B $B$9$kL58BO":?9V$dO":?HNGde$N?M$,H4$1$F$$$/(B $B$N$G0cK!@-$O$"$j$^$;$s!#(B $B$M$:$_!>$3$&!ZAM9V![!E%+%&(B $B2q0w$rAM;;<0$K3HBg$5$;$k$3$H$r>r7o$H$7$F!"2CF~e$N6bA,$=$NB>$N7P:Q>e$NMx1W$rM?$($k0l$7$g$&$[$&!Z!=>&K!![!E%7%d%&%O%U(B (multilevelmarketingplan)$B>&IJHNGdJ}K!$N0l!#(B $BJ*IJHNGd6H&IJ$r:FHNGd$9$k$N:?J$+$iF@$i$l$kMx1W$r1B$K>&IJ$N9X(B $BF~$d&IJ$NHNGd
HEADSUP: Linksys cards need flag.
Hi folks, for mobile users. Linksys Fast Ethernet PCCARD cards supported by the ed driver now require the addition of flag 0x8 to their config line in pccard.conf(5). This flag is not optional. These Linksys cards will not be recognized without it. The old code tried to automatically probe for these cards. However, these probes sometimes caused non-Linksys cards to hang. I wanted to avoid introducing a new flag if I could, but I had no other solution. The description in pccard.conf(5) should be as follows: card "corega" "FEther PCC-TXF" config auto "ed" ? 0x8 I fixed all the entries for the Linksys type card that I could find in etc/defaults/pccard.conf. Please notify me if I have missed any. -- Toshihiko ARAI / [EMAIL PROTECTED] http://www.jp.FreeBSD.org/PAO/LAPTOP_SURVEY/index.html To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: test/review: /dev/console logging patch
On 18-Dec-00 Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, John Baldwin writes: >> >>On 17-Dec-00 Poul-Henning Kamp wrote: >>> >>> This patch is for the printf(9), log(9) & /dev/console stuff. >>> The result is that you can watch the output from /etc/rc in >>> your /var/log/messages. >>> >>> Poul-Henning >>> >>> >>> 1. Replace logwakeup() with msgbuftrigger++; There is little >>>point in calling a function to set a flag. >> >>Abstraction to keep other code from having to know the iternals of the log(9) >>device? Maybe use a #define for logwakeup() that does the msgbuftrigger++ to >>keep the abstraction w/o the overhead? > > But it was actually the other way around now :-) It was the log > device which had obfuscated the log/printf code because it needed > it's assistance to call selwakeup. > > I want the log/printf code to be as simple as possible, and to have > the smallest stack footprint possible... Ok, works for me. :) -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "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
debug build of libc_r
Hi, I'm seeing a crash related to libc_r. Could someone please instruct me as to how to build a debug version. Thanks, Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Tue, Dec 19, 2000 at 01:00:28AM +1000, Stephen McKay wrote: > So we could in principle build ld.so for every release. I would say "no". The building of a.out bits is getting harder as more and more framework pieces are removed. I don't quite fully understand the problem yet. Do you have a binary that shows the problem other than SimCity from a 3.x release CDROM? I don't have any 3.x CDROMs any more, so I'd have to wait a while until I can find one at the office. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
You don't need a CDROM... You can get it from: ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/commerce/games/SimCity/SimCity-3.6b.tgz On Mon, Dec 18, 2000 at 10:03:15AM -0800, David O'Brien wrote: > On Tue, Dec 19, 2000 at 01:00:28AM +1000, Stephen McKay wrote: > > So we could in principle build ld.so for every release. > > I would say "no". The building of a.out bits is getting harder as more > and more framework pieces are removed. I don't quite fully understand > the problem yet. Do you have a binary that shows the problem other than > SimCity from a 3.x release CDROM? I don't have any 3.x CDROMs any more, > so I'd have to wait a while until I can find one at the office. > > -- > -- David ([EMAIL PROTECTED]) > GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: debug build of libc_r
On Mon, Dec 18, 2000 at 12:01:19PM -0600, Peter Schultz wrote: > Hi, > > I'm seeing a crash related to libc_r. > Could someone please instruct me as > to how to build a debug version. cd /usr/src/lib/libc_r make clean DEBUG_FLAGS=-g3 make make install Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel Buffer overwrite debugging
I am having a problem with a device driver that uses physio
to transfer data to a SCSI adapter. Some times the after
passing the buffer to the CAM system, via xpt_action, the
buffer contents are modified. I've traced my driver and cannot
determine how this could be happening. I am running on a single
CPU Pentium II system with all system config defaults.
What I would like to do is to dynamically set a watch point
on the buffer used by the write system call for the duration
of sending the data to the SCSI adapter. I want to do this
dynamically instead of manually setting a breakpoint in the
code and manually setting the watch point, because the problem
occurs around the 90'th time, and I don't want SCSI bus timeouts
while typing the watch address.
I've examined the ddb code, and thought that if I emulated the
steps in db_trap() for the command of setting a watchpoint it
would work. However, it doesn't appear to be working.
What I've done is:
/* possible on data xfer >= 512 bytes */
if (condition for problem) {
db_watchpoint_cmd(bp->bio_addr, bp->bio_addr,
bp->bio_count, &"rw");
db_continue_cmd(0, 0, 0, &"w"):
db_restart_at_pc(FALSE);
}
When the buffer is done transmitting I do the following:
db_clear_watchpoints();
db_deletewatch_cmd(bp->bio_addr, bp->cio_addr,
bp->cio_count, &"rw");
db_continue_cmd(0, 0, 0, &"w");
db_restart_at_pc(FALSE);
My driver trace printf's show the data at bp->bio_addr was
changed from 0x601000a3 to 0x0. Additional traces show the
data from the first 200+ bytes is changed to zero.
Any guidance on how to use the ddb functions to debug this
problem are appreciated. Also, alternative methods to determine
what is overwriting the buffer. In looking at the data on a
SCSI bus analyzer, the entire buffer has been zero'ed out.
Thank you in advance for your help.
Jeff Fellin
MH 2A-352
(908) 582-7673
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
> The generated ld.so has bloated a bit :-) but works fine. So we could > in principle build ld.so for every release. It's just a question of > whether we should. I think we should. But it might be just as easy > to copy it off the 3.3 CD every time. It's dead end stuff after all. > > Does the release engineer have an opinion? If it's just for the compat3x distribution, I say check it into that part of lib/compat and be done with it. Uudecoding it each time is a lot easier than building it. Or are we talking about ld.so in some different context? - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bridging NT4 subnets
On Wed, 13 Dec 2000, John Miller wrote: > > I am having trouble setting up bridge between 2 subnets with NT4 servers on > either side. Both subnets are behind different firewalls for external > access. > Static Routes have been setup on each subnets firewalls to route traffic > through the bridge. Use WINS and save yourself the pain. Really. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Network performance-problem
In message <[EMAIL PROTECTED]> Michael Class writes: : xl0: no carrier - transceiver cable problem? : Why behaves my FreeBSD-machines worse then the other boxes? Any Ideas? My 3CCFE575CT doesn't have this problem, except when I'm using it with a bad cable. Maybe that's the problem? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: Linksys cards need flag.
In message <[EMAIL PROTECTED]> Toshihiko ARAI writes: : Linksys Fast Ethernet PCCARD cards supported by the ed driver now : require the addition of flag 0x8 to their config line in : pccard.conf(5). This flag is not optional. These Linksys cards will : not be recognized without it. I've added the above text to the UPDATING file. I should add that mergemaster will automatically upgrade their machines will have this fixed automatically. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Monday, 18th December 2000, Jordan Hubbard wrote: >> The generated ld.so has bloated a bit :-) but works fine. So we could >> in principle build ld.so for every release. It's just a question of >> whether we should. I think we should. But it might be just as easy >> to copy it off the 3.3 CD every time. It's dead end stuff after all. >> >> Does the release engineer have an opinion? > >If it's just for the compat3x distribution, I say check it into that >part of lib/compat and be done with it. Uudecoding it each time is a >lot easier than building it. Or are we talking about ld.so in some >different context? I hadn't noticed all the uuencoded things in lib/compat before. This is obviously the way to fix it. By the way, it's the compat22 distribution that needs fixing, and, as previously noted, it's the 3.2 CD that has the last fully working ld.so. I'll get onto committing a fix. Stephen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Network performance-problem
Michael Class wrote: > > Hello, > > i am seeing a problem with 5.0-current (from 14.12.00) and a 3COM > 3CCFE575CT Lancard (pc-cardbus) using the xl-driver. [snip] > Why behaves my FreeBSD-machines worse then the other boxes? Any Ideas? Make sure you are running with the TCP/IP NewReno optimisation turned off. There are bugs in the TCP/IP NewReno code that result in bad packets and hence lots of retransmission with generally reduced network performance. I think its meant to be the default now in -CURRENT (to have NewReno off) but I'm not sure if PHK has disabled it yet. $ cat /usr/local/etc/rc.d/nonewreno.sh #!/bin/sh sysctl -w net.inet.tcp.newreno=0 echo -n " no_newreno" $ sysctl net.inet.tcp.newreno net.inet.tcp.newreno: 0 One day hopefully NewReno may be fixed as it sounded worthwhile. See Poul's messages in the freebsd-current archives. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Network performance-problem
Michael Class wrote: > > Hello, > > i am seeing a problem with 5.0-current (from 14.12.00) and a 3COM > 3CCFE575CT Lancard (pc-cardbus) using the xl-driver. [snip] > Why behaves my FreeBSD-machines worse then the other boxes? Any Ideas? Make sure you are running with the TCP/IP NewReno optimisation turned off. There are bugs in the TCP/IP NewReno code that result in bad packets and hence lots of retransmission with generally reduced network performance. I think its meant to be the default now in -CURRENT (to have NewReno off) but I'm not sure if PHK has disabled it yet. $ cat /usr/local/etc/rc.d/nonewreno.sh #!/bin/sh sysctl -w net.inet.tcp.newreno=0 echo -n " no_newreno" $ sysctl net.inet.tcp.newreno net.inet.tcp.newreno: 0 One day hopefully NewReno may be fixed as it sounded worthwhile. See Poul's messages in the freebsd-current archives. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is compatibility for old aout binaries broken?
On Tue, Dec 19, 2000 at 03:08:25PM +1000, Stephen McKay wrote: > Our current problem is that an older ld.so has somehow been made part > of compat22. I'm now attempting to determine whether the ld.so on > the 3.2 CD contains the fix in rev 1.57 of rtld-aout/rtld.c, and if > so I'll just commit it in the compat22 directory. Please delay committing -- since it is UUENCODED, it is a bit repo bloat if we don't get it right. It doesn't seem right to put 3.x bits into the compat22 dist. By definition they are the wrong bits. My internet connection is down for the past day, and I only have limited connectivity right now. But I would like to look into this before anything is committed. - -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent -CURRENT kernel build problem...
Dear all... Has anyone noticed this problem? Or is it just happening to me? On make buildkernel (with -CURRENT just cvsuped a few minutes ago) and the generic config KERNEL; make depend; make; cycle, the kernel build failed with this message: -- cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../../include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 vers.c linking kernel agp_amd.o: In function `agp_amd_alloc_gatt': agp_amd.o(.text+0x67): undefined reference to `M_AGP' agp_amd.o(.text+0x89): undefined reference to `M_AGP' agp_amd.o(.text+0xd5): undefined reference to `M_AGP' agp_amd.o(.text+0x105): undefined reference to `M_AGP' agp_amd.o(.text+0x112): undefined reference to `M_AGP' agp_amd.o(.text+0x234): more undefined references to `M_AGP' follow *** Error code 1 Stop in /usr/src/sys/compile/DANTE. -- Please help, my kernel and userland is badly not in sync ;) Attached is my kernel config file. Thank you... Regards, John ident DANTE machine i386 cpu I686_CPU maxusers256 options INET options FFS options FFS_ROOT options SOFTUPDATES options COMPAT_43 options UCONSOLE options USERCONFIG options VISUAL_USERCONFIG options KTRACE options SYSVSHM options SYSVMSG options SYSVSEM options SHMMAX=33554432 options SHMALL=16384 options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV options ATA_STATIC_ID options ATA_ENABLE_ATAPI_DMA options USER_LDT options IPFILTER options IPFILTER_LOG options TCP_DROP_SYNFIN options TCP_RESTRICT_RST options VESA options NMBCLUSTERS=16384 options SC_DISABLE_REBOOT options NOBLOCKRANDOM device isa device pci device fdc device ata device atadisk device atapicd device atkbdc 1 device atkbd device psm device vga device splash device sc 1 device npx device apm device sio device ppc device ppbus device lpt device plip device ppi device miibus device xl device random device loop device ether device tun device pty device md device bpf device vn device snp device pcm device agp
