Re: fxp(4) and lockups on RELENG_6_x
Krzysztof Kowalik <[EMAIL PROTECTED]> wrote: > We are running an (IRC) server that under high-rate traffic (ie. DDoS > attack) stops to respond to the network. The network remains locked up > even after the original attack stops. [...] And it turns out to be an usual PEBKAC. The system was running out of mbuf clusters, and after increasing kern.ipc.nmbclusters to a sane value things started to work as expected again. Since it's usually the first thing one changes on such a box, we didn't even think of checking it. Sorry for the noise. -- () ASCII Ribbon Campaign /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
fxp(4) and lockups on RELENG_6_x
Hello. We are running an (IRC) server that under high-rate traffic (ie. DDoS attack) stops to respond to the network. The network remains locked up even after the original attack stops. However running tcpdump (which switches the interface into promisc mode) unlocks networking and things work again. At the moment, we are running 6.2-RC1 cvsupped at Dec 10, with if_fxp.c from Nov 11 (previously, we had 6.1 for a while, having the same issues) if_fxp.c,v 1.240.2.10.2.1 2006/11/20 16:21:12 The same machine used to run FreeBSD 4.11 without any problems. Any help/pointers/suggestions would be appreciated. More hardware details: [EMAIL PROTECTED]:3:0: class=0x02 card=0x10408086 chip=0x12298086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet fxp0: port 0xc800-0xc83f mem 0xd902-0xd9020fff,0xd900-0xd901 irq 11 at device 3.0 on pci2 miibus0: on fxp0 fxp0: Ethernet address: 00:02:b3:90:65:86 interrupt total rate irq11: fxp067322 0 -- () ASCII Ribbon Campaign /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sun X86 servers
James O'Gorman <[EMAIL PROTECTED]> wrote: > Actually I'd be quite interested to know how they perform as well. I've > been contemplating the new Ultra 20 workstation to try and learn Solaris > on (but be able to run FreeBSD as well). For the Ultra 20, I can say it works pretty well with RELENG_6_1 (32-bit). % uname -mrs FreeBSD 6.1-PRERELEASE i386 % uptime 1:13PM up 121 days, 1 min, 2 users, load averages: 0,04 0,01 0,00 SATA, sound[1], USB, DVD burner, the weird nVidia's NIC, and the graphics card work without issues (so far). I do, however, added the second NIC (Intel PRO 10/100) as I don't exactly trust the nve(4) driver yet (even though it seems to work on this particular motherboard). There is no high load on the machine, just a workstation with X.org and KDE. [1] snd_ich -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST | /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient wedged
Brooks Davis <[EMAIL PROTECTED]> wrote: > What NIC are you using? fxp0: port 0xc000-0xc03f mem 0xdb121000-0xdb121fff,0xdb00-0xdb0f irq 11 at device 1.0 on pci2 > This particular issue sounds like a NIC returning corrupt packets for > some reason. Alternatively, the sending server could be producing corrupt > packets. Some tcpdump traces (preferably raw dumps) could be useful. As I said, I didn't see anything bad in the tcpdump. And since I really didn't have such issues before, and I don't see anything weird in any other place... I recompiled dhclient with "-g" and will tcpdump the traffic again, if I notice it eating 99% of CPU time again. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dhclient wedged
Brooks Davis <[EMAIL PROTECTED]> wrote: > This definitly sounds like something particular to your dhcp servers. > It would be nice if we could fix it, but without some debugging help > that's going to be pretty much impossible. [...] It happens to me quite often, too. The only thing related in the non-debug messages is: Jan 8 12:02:19 moneypenny dhclient[68091]: 5 bad IP checksums seen in 5 packets Jan 8 12:02:49 moneypenny last message repeated 743054 times Jan 8 12:04:50 moneypenny last message repeated 2951866 times Jan 8 12:14:51 moneypenny last message repeated 14457921 times Jan 8 12:24:52 moneypenny last message repeated 14812032 times Jan 8 12:34:53 moneypenny last message repeated 14770327 times Jan 8 12:44:55 moneypenny last message repeated 14748300 times Jan 8 12:51:44 moneypenny last message repeated 10037074 times ... which accounts for the CPU usage, I guess. I killed the "bad IP checksums" messages, so it doesn't annoy my syslog anymore, but it of course didn't fix the underlaying issue. I was looking at those packets with tcpdump once and didn't see anything obvious/bad there. And yes, I didn't have this problem with ISC client. And I surely use different cable provider, than the original poster ;) -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Fatal trap 12: page fault while in kernel mode
Hello.
While copying a few directories from one machine to my new notebook (tar
over ssh over wireless connection [if_iwi]), the notebook paniced with
the following:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x52535307
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc078bc08
stack pointer = 0x28:0xde4ae95c
frame pointer = 0x28:0xde4ae984
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 761 (bsdtar)
trap number = 12
panic: page fault
Uptime: 11m20s
Dumping 502 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 502MB (128464 pages) 486 470 454 438 422 406 390 374 358 342
326 310 294 278 262 246 230 214 198 182 166 150 134 118 102 86 70 54 38
22 6
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc0638202 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:399
#2 0xc0638498 in panic (fmt=0xc084e5a2 "%s")
at /usr/src/sys/kern/kern_shutdown.c:555
#3 0xc0807c30 in trap_fatal (frame=0xde4ae91c, eva=1381192455)
at /usr/src/sys/i386/i386/trap.c:831
#4 0xc080799b in trap_pfault (frame=0xde4ae91c, usermode=0,
eva=1381192455)
at /usr/src/sys/i386/i386/trap.c:742
#5 0xc08075d9 in trap (frame=
{tf_fs = 8, tf_es = -565575640, tf_ds = -1065943000, tf_edi =
-565515340, tf_esi = -1043806720, tf_ebp = -565515900, tf_isp =
-565515960, tf_ebx = -1039299392, tf_edx = 170, tf_ecx = 1, tf_eax =
1381191775, tf_trapno = 12, tf_err = 0, tf_eip = -1065829368, tf_cs =
32, tf_eflags = 66051, tf_esp = -1064527936, tf_ss = -565515812}) at
/usr/src/sys/i386/i386/trap.c:432
#6 0xc07f6dca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc078bc08 in ufsdirhash_lookup (ip=0xc20ec318,
name=0xc1c45810 "UPCII.TTF", namelen=9, offp=0x5253505f,
bpp=0x5253505f,
prevoffp=0x0) at /usr/src/sys/ufs/ufs/ufs_dirhash.c:409
#8 0xc078d480 in ufs_lookup (ap=0xde4aea80)
at /usr/src/sys/ufs/ufs/ufs_lookup.c:209
#9 0xc0816d64 in VOP_CACHEDLOOKUP_APV (vop=0x5253505f, a=0xaa)
at vnode_if.c:150
#10 0xc0682c9e in vfs_cache_lookup (ap=0x5253505f) at vnode_if.h:82
#11 0xc0816cf3 in VOP_LOOKUP_APV (vop=0xc08fbf40, a=0xde4aeb18)
at vnode_if.c:99
#12 0xc068722d in lookup (ndp=0xde4aeba0) at vnode_if.h:56
#13 0xc0686b6e in namei (ndp=0xde4aeba0) at
/usr/src/sys/kern/vfs_lookup.c:203
#14 0xc0694367 in kern_lstat (td=0xc1fea900,
path=0xaa , pathseg=170, sbp=0xde4aec74)
at /usr/src/sys/kern/vfs_syscalls.c:2102
#15 0xc0694303 in lstat (td=0xc1fea900, uap=0xde4aed04)
at /usr/src/sys/kern/vfs_syscalls.c:2086
#16 0xc0807f47 in syscall (frame=
{tf_fs = 59, tf_es = 4259899, tf_ds = -1078001605, tf_edi =
-1077941792, tf_esi = -1077941248, tf_ebp = -1077941560, tf_isp =
-565514908, tf_ebx = 134672409, tf_edx = 134586905, tf_ecx = 25, tf_eax
= 190, tf_trapno = 0, tf_err = 2, tf_eip = 672111379, tf_cs = 51,
tf_eflags = 658, tf_esp = -1077941860, tf_ss = 59}) at
/usr/src/sys/i386/i386/trap.c:976
#17 0xc07f6e1f in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:200
#18 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
The notebook runs GENERIC kernel of 6.0-RELEASE.
I don't know if it's known issue or not, nor it is reproducible. If
dmesg would be helpful, I can post it as well. I will keep the vmcore.0
for a while, too, just in case.
--
Krzysztof Kowalik | () ASCII Ribbon Campaign
Computer Center, AGH UST| /\ Support plain text e-mail
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4-way Xeon and "panic: spin lock held too long."
Hello. Today one of my boxes paniced with "panic: spin lock held too long." message -- it was online for 6 hours, under rather light load. Unfortunately, I wasn't able to get any more information, as the box got restarted by our staff. Is this, anyway, a known problem (I see two people mentioning it on freebsd-smp in May 2005) and, what's more important, how can it be fixed? The OS is 5.4-RELEASE-p7, the hardware: [...] CPU: Intel Pentium III Xeon (697.68-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6a1 Stepping = 1 Features=0x387fbff real memory = 1073676288 (1023 MB) avail memory = 1041125376 (992 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 3 cpu1 (AP): APIC ID: 0 cpu2 (AP): APIC ID: 1 cpu3 (AP): APIC ID: 2 MADT: Forcing active-low polarity and level trigger for SCI [...] SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! [...] Any ideas? -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Centre, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-RELEASE (amd64) on LSILogic 1030 / mpt controller.
Krzysztof Kowalik [EMAIL PROTECTED] wrote: [...] > > And 5-STABLE (installed snapshot from the end of January and upgraded to > > a recent -STABLE) works fine. I love to answer to myself. > And, despite my hopes, 5.4-RELEASE/amd64 does not work again. I think > I'm getting unlucky recently. And 6.0-BETA2 works fine. Did someone forget to merge some fixes for mpt from RELENG_5 to RELENG_5_4? Not that it really matters, if I can get 6.0 working on this box... -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-RELEASE (amd64) on LSILogic 1030 / mpt controller.
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > > > I'm trying, without success, to install the FreeBSD 5.3 on a Sun Fire > > > V40z (it's an amd64 box) on its LSILogic 1030 Ultra4 SCSI controller. > > Interesting. 5.3-RELEASE for x86 works on the same machine, same disks > > connected to the same controller without issues. > And 5-STABLE (installed snapshot from the end of January and upgraded to > a recent -STABLE) works fine. I love to answer to myself. And, despite my hopes, 5.4-RELEASE/amd64 does not work again. I think I'm getting unlucky recently. Will try 6.0-BETA2 on it now. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > [...] > cvsup-ing current 6.0-CURRENT right now, to check the giantless VFS once > again. It will probably take an hour to get it up and running. Unfortunately, 6.0-CURRENT didn't help at all. FreeBSD 6.0-CURRENT #0: Wed May 25 13:24:30 CEST 2005 [...] Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2000+ (1668.71-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc040 real memory = 1073725440 (1023 MB) avail memory = 1041891328 (993 MB) ACPI APIC Table: [...] pcm0: port 0xd800-0xd8ff at device 5.0 on pci0 [...] atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 [...] atapci0: port 0xd400-0xd407,0xd000-0xd003,0xb800-0xb807,0xb400-0xb403,0xb000-0xb00f mem 0xe580-0xe5803fff irq 19 at device 6.0 on pci0 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x9800-0x980f at device 17.1 on pci0 ata0: on atapci1 ata1: on atapci1 [...] ad0: 38166MB at ata0-master UDMA100 [...] # vmstat -i interrupt total rate irq1: atkbd0 704 2 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq12: psm0 7143 24 irq13: npx01 0 irq14: ata046427160 irq15: ata1 67 0 irq16: fxp0 284 0 irq17: pcm0 4414 15 lapic0: timer 575578 1991 Total 634630 2195 # sysctl -a|grep mpsafe debug.mpsafevfs: 1 debug.mpsafenet: 1 debug.mpsafevm: 1 The issues still exist. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > [...] > I will try to put my hands on the mentioned AMD box once again, to run > some current 6.0 on it. OK, got the box. I ran a 5.4-RELEASE, identical (as I just restored dumps of my current workstation on it) as the one not giving problems on Intel-based system. Regardless of the state of USB, I can observe the mentioned issues (scattered sound, lagging mouse in X, etc while untarring firefox's sources). With USB, vmstat -i shows: interrupt total rate irq1: atkbd0 904 2 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq8: rtc 56478127 irq12: psm0 4912 11 irq13: npx01 0 irq14: ata0 8529 19 irq15: ata1 63 0 irq16: fxp0 uhci1 437384987 irq17: pcm0 1576 3 irq0: clk 441323996 Total 951182 2147 ... and without it: interrupt total rate irq1: atkbd0 164 1 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq8: rtc 19340127 irq12: psm0 7005 46 irq13: npx01 0 irq14: ata018731123 irq15: ata1 61 0 irq16: fxp0 132 0 irq17: pcm0 2448 16 irq0: clk 151117994 Total 199011 1309 cvsup-ing current 6.0-CURRENT right now, to check the giantless VFS once again. It will probably take an hour to get it up and running. If you have any more ideas, while I still have the box, I'd be willing to try, time permitting. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway [EMAIL PROTECTED] wrote: > > I didn't see any visible difference, in the given scenario of > > uncompressing firefox's sources, when tried mpsafevfs's patches when > > they got announced on [EMAIL PROTECTED] > There have been a *lot* of changes in this area since the initial > patches (i.e. continued removal of Giant), so you'd really need to > re-test on a recent version of 6.0 to be definitive. Could be. Though given my present experience with 5.4-RELEASE, where I have no problems on my current hardware, I'd assume the issues I used to observe were not really VFS/Giant related. And yes, I ruled the USB issue out as well. I will try to put my hands on the mentioned AMD box once again, to run some current 6.0 on it. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway [EMAIL PROTECTED] wrote: > [...] One obvious guess is that it's due to VFS being under Giant, > which causes lots of contention with other subsystems that also > require Giant, and therefore introduces latency. If so, you'd see a > substantial performance improvement on 6.0 with debug.mpsafevfs=1. I didn't see any visible difference, in the given scenario of uncompressing firefox's sources, when tried mpsafevfs's patches when they got announced on [EMAIL PROTECTED] The funny thing is, that I saw it on my Athlon XP box *very* visibly, while I it's quite ok on my current workstation, which is Celeron based (and yes, it's much slower, CPU wise, than the Athlon machine). Perhaps some funny chipset issue? Old box: FreeBSD 5.3-RELEASE #2: Wed Nov 17 00:19:56 CET 2004 [...] ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2000+ (1668.71-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc040 real memory = 1073725440 (1023 MB) avail memory = 1041154048 (992 MB) [...] emu10kx0: port 0x9400-0x941f irq 19 at device 12.0 on pci0 pcm0: on emu10kx0 pcm0: [...] atapci0: port 0xa400-0xa40f,0xa800-0xa803,0xb000-0xb007,0xb400-0xb403,0xb800-0xb807 mem 0xe680-0xe6803fff irq 19 at device 6.0 on pci0 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0x8400-0x840f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 ad0: 152627MB [310101/16/63] at ata0-master UDMA100 ad1: 190782MB [387621/16/63] at ata0-slave UDMA100 ar0: 57220MB [7294/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad5 at ata2-slave [...] New box: FreeBSD 5.4-RELEASE-p1 #0: Sat May 14 18:43:25 CEST 2005 [...] CPU: Intel(R) Celeron(TM) CPU1200MHz (1202.73-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383f9ff real memory = 536805376 (511 MB) avail memory = 515629056 (491 MB) [...] atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 [...] pcm0: port 0xe000-0xe03f,0xdc00-0xdcff irq 7 at device 31.5 on pci0 pcm0: [...] ad0: 76319MB [155061/16/63] at ata0-master UDMA100 ad1: 152627MB [310101/16/63] at ata0-slave UDMA100 [...] So they are, unfortunately, a little bit different machines. And no, I had no chance to try 5.4-RELEASE on the amd one. In general, I find 5.4-RELEASE performing better, if I can say that without doing any real benchmarking, than any previous 5.x. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-RELEASE (amd64) on LSILogic 1030 / mpt controller.
David O'Brien [EMAIL PROTECTED] wrote: > So the end result is that FreeBSD/amd64 5.3-RELEASE won't work for you, > but 5.4-RELEASE will. Correct? Assuming that nothing bad happens before the release, yes, it will work with 5.4-RELEASE. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-RELEASE (amd64) on LSILogic 1030 / mpt controller.
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > > I'm trying, without success, to install the FreeBSD 5.3 on a Sun Fire > > V40z (it's an amd64 box) on its LSILogic 1030 Ultra4 SCSI controller. > Interesting. 5.3-RELEASE for x86 works on the same machine, same disks > connected to the same controller without issues. > [...] And 5-STABLE (installed snapshot from the end of January and upgraded to a recent -STABLE) works fine. I love to answer to myself. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.3-RELEASE (amd64) on LSILogic 1030 / mpt controller.
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > I'm trying, without success, to install the FreeBSD 5.3 on a Sun Fire > V40z (it's an amd64 box) on its LSILogic 1030 Ultra4 SCSI controller. > [...] Interesting. 5.3-RELEASE for x86 works on the same machine, same disks connected to the same controller without issues. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.3-RELEASE (amd64) on LSILogic 1030 / mpt controller.
Hello, I'm trying, without success, to install the FreeBSD 5.3 on a Sun Fire V40z (it's an amd64 box) on its LSILogic 1030 Ultra4 SCSI controller. It goes well, the kernel detects disks properly, creates the partitions, but dies after trying to copy files to /stand. [...] mpt0: time out in request index=0xf8 sequence=0x03a3 mpt0: Statys 0001; Mask 0001; Doorbell 2400 request state On Chip SCSI IO Request @ 0x67652ae0 Chain Offset0x00 MsgFlags0x00 MsgContext 0x00ed Bus:0 TargetID0 SenseBufferLength 32 LUN:0x0 Control 0x0100 WRITE SIMPLEQ DataLength 0x0800 SenseBufAddr0xe3f3bbe0 CDB[0:6]0a 02 00 6b 04 00 SE32 0x68040c30: Addr=0xc62c0800 FlagsLength=0xd5000800 HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST [...] The output is copied by hand, so there can be some small typos, even though I tried to recheck it ;) ACPI, no ACPI and Safe mode make no difference, installation dies in the same place. Anyone any ideas? PS, cross-posted to freebsd-amd64. Regards, -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance issues in 5.3-RELEASE.
Ronald Klop [EMAIL PROTECTED] wrote: > > For what I have seen everybody uses snd_emu10k1. Since I use my onboard > soundcard (snd_ess* (not MPSAFE)) I have less problems with my sound under > disk load. > [...] No, I don't. I use and_emu10kx, which behaves far better under high load than the standard snd_emu10k1. > Oh, I saw a post a while ago on stable@ or on current@ about a buffer in > emu10k1. If it was increased it had less problems. [...] Yes, I've read those mails, though it's not sound-under-load issue. Not only and not mainly. It's more that the interactive work in X(org) under the high i/o in certain cases (like the mentioned untaring) is getting painful. Regards, -- There is no satisfaction in hanging a man who does not object to it. -- G.B. Shaw ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Performance issues in 5.3-RELEASE.
Hello, Recently I took some time to upgrade my home 4.9 system to 5.3-RELEASE (fortunately, taking full system dump before, so I can easily get back). In fact just after upgrading I ran into the weird issue during installation for firefox port. When firefox-1.0-source.tar.bz2 is getting untared, the system starts to be *slow*: any music starts to be jittered and the cursor in X stalls from time to time for ~1 second. And I never had this issue before with 4.x serie. I tried to boot with an without ACPI, with GENERIC kernel, with my "own" kernel configuration (GENERIC with removed unused SCSI/RAID/NIC drivers) both with and without PREEMPTION[1]. Without any visible change in system's behaviour. %uname -a FreeBSD bzzzt.borys.lan 5.3-RELEASE FreeBSD 5.3-RELEASE #2: Wed Nov 17 00:19:56 CET 2004 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/BZZZT i386 # atacontrol list ATA channel 0: Master: ad0 ATA/ATAPI revision 7 Slave: ad1 ATA/ATAPI revision 6 ATA channel 1: Master: acd0 ATA/ATAPI revision 5 Slave: acd1 ATA/ATAPI revision 0 ATA channel 2: Master: ad4 ATA/ATAPI revision 5 Slave: ad5 ATA/ATAPI revision 5 ATA channel 3: Master: no device present Slave: no device present # atacontrol mode 0 Master = UDMA100 Slave = UDMA100 # atacontrol mode 1 Master = UDMA33 Slave = UDMA33 # atacontrol mode 2 Master = UDMA100 Slave = UDMA100 dmesgs from ACPI boot on "custom" kernel attached. Is there anything I missed and therefore I should try/tune or any other informations that are needed and I missed them? [1] yes, SCHED_4BSD Regards, Krzysztof Kowalik -- As a computer, I find your faith in technology amusing. Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 1073725440 (1023 MB) Physical memory chunk(s): 0x1000 - 0x0009cfff, 638976 bytes (156 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c26000 - 0x3edcbfff, 1041915904 bytes (254374 pages) avail memory = 1041154048 (992 MB) bios32: Found BIOS32 Service Directory header at 0xc00f1e70 bios32: Entry = 0xf17b0 (c00f17b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0x17e0 pnpbios: Found PnP BIOS data at 0xc00f9a40 pnpbios: Entry = f:9a70 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: active-high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00040010 LDR: 0x0100 DFR: 0x0fff lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff null: io: random: mem: Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=30991106) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00f1d90 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded05A 0x02 3 4 5 7 9 10 11 12 embedded0
