Re: Freebsd 8.0 kmem map too small
Hello, I'd like to add another instance of similar problems. I recently updated my FreeBSD amd64 box with ZFS root and 8GB RAM from 8-STABLE (as of Mar 1st) to 8.1-PRERELEASE (as of May 27th). After that, my box started to crash every couple of days due to kmem_map too small. Here is a (last week) screenshot of Munin graph about the memory usage of the box: http://eron.info/munin-memory.png In by month graph, a white gap at the end of Week 20 is the update period from 8-STABLE to 8.1-PRERELEASE I mentioned above. Before the upgrade, the system was rock solid without any kmem tuning in loader.conf (vm.kmem_size was around 2.7GB IIRC). After the update, I could see that more wired memory was assigned, and then steep drop (crash) occured. by day graph shows my experiment to bump vm.kmem_size=12G (recommended somewhere in this thread) and explicitly limit vfs.zfs.arc_max=2G. I was surprised because the wired memory quickly increased over 5GB... Then I noticed that the default value of vfs.zfs.zio.use_uma was 1 on amd64, so I turned it off and removed other memory tunings (kmem_size and arc_max) in loader.conf on Tuesday at 16:00 and rebooted. It seems that the usage of wired memory was stablized and no crash since then with the default kmem_size and arc_max. Does anyone have any idea about this behavior? My wild guess is that ZFS/UMA code is not stable on amd64 too, and it should be turned off by default for 8.1-RELEASE maybe Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freebsd 8.0 kmem map too small
On Tue, 8 Jun 2010 02:54:44 -0700, Jeremy Chadwick free...@jdc.parodius.com said: I realise you're talking about amd64, but I'm not sure how UMA is getting enabled on i386 to begin with. It does look like it's enabled on amd64 by default. I believe that this thread had been started before this tunable was introduced on May 24th. Before that, ZIO_USE_UMA was used to control the use of UMA, and it was enabled unconditionally in /usr/src/sys/modules/zfs. -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
TSO and pf(4) reply-to/route-to combination problem
Hello, Could anyone who knows the TCP/IP stack well please review kern/144311? In summary, on a multi-homed server I have a trouble when using pf(4) 'reply-to' to return reply packets of incoming TCP connections to the incoming interface. When TSO is enabled on the interface which is used for the default route, redirecting packets to other interfaces using 'reply-to'(or 'route-to') causes massive 'ICMP unreachable - need to frag' storm on lo0 (up to 10Mbytes/sec on my server). The problem doesn't happen when TSO is disabled on the default NIC. I reproduced the problem on msk(4) and em(4), so I guess it is not device specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=144311 Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vge problem
On Thu, 10 Dec 2009 16:08:49 -0800, Pyun YongHyeon pyu...@gmail.com said: While reading the code again I found some suspicious part which could be related with your issue. The controller's CMZ field has 3bits so it can handle 7 fragments of a TX frame. However, controller wants to see number of fragments + 1 in this field which means we can't use all 7 fragments in a TX descriptor. I changed the patch to reduce number of TX fragments to 6. Does the following patch make any difference for you? http://people.freebsd.org/~yongari/vge/vge.busdma.diff3 I'm sorry I was away from the console during last weekend Today I booted new kernel with diff3 patch, and did a couple of tests (massive thumbnail loading and csup). All of them worked as expected and no Send-Q stack observed, so I believe the problem is fixed by this patch. I really appreciate your swift update! Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vge problem
On Tue, 8 Dec 2009 10:08:36 -0800, Pyun YongHyeon pyu...@gmail.com said: Ok, now I'm ready to boot a DDB enabled kernel to try kernel debugging on my PC. I can't read email during debugging my PC under current configuration, so could you please tell me any specific instructions to collect information you need? I'm reading the Handbook now, but I'm not very sure... Sorry, another user also reported similar problem in my patch. I have to look closely before doing any further testing. Since I've ordered the controller I would get access to hardware in near future. I'll let you know when I have a working patch. Oh, that's fine. I dug up an old fxp(4) card. Still one vge(4) remains up, but I can live with it until you can make a working patch Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vge problem
On Fri, 4 Dec 2009 10:43:01 -0800, Pyun YongHyeon pyu...@gmail.com said: before I replaced vge(4). I guess the system froze while initializing vge(4), but I'm not really sure actually. Yes, that's also possible. But I can't explain how the patch can freeze the box. Another user also reported the similar vge(4) issue in private mail and tried the same patch and he could successfully boot with patched vge(4). Unfortunately the issue does not seem to fix his issue. I'm still working on it. What can I do to narrow the cause of problems? Is it useful to build kernel with options KDB and DDB? Yes. Ok, now I'm ready to boot a DDB enabled kernel to try kernel debugging on my PC. I can't read email during debugging my PC under current configuration, so could you please tell me any specific instructions to collect information you need? I'm reading the Handbook now, but I'm not very sure... Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vge problem
On Fri, 4 Dec 2009 09:36:01 -0800, Pyun YongHyeon pyu...@gmail.com said: After I rebooted with the new kernel, the boot sequence stopped just after setting hostname. Setting hostname: elvenbow.cc.kyushu-u.ac.jp msk0: Uncorrectable PCI Express error vge0: link state changed to DOWN msk0: link state changed to DOWN (stop) The system didn't completely freeze. I can push Scroll Lock and Page Up/Down to browse the boot messages, but sometimes it stopped responding to my input for a second. Ctrl-C had no effect and I had to hit the reset button. Now my PC is synchronizing degraded gmirror volume...(ouch) I'm not sure why it would get stuck. You touched only vge(4), right? Yes, I only touched vge(4). I believe that msk0: Uncorretable PCI Express error wasn't relevant to the freeze because it also happened before I replaced vge(4). I guess the system froze while initializing vge(4), but I'm not really sure actually. What can I do to narrow the cause of problems? Is it useful to build kernel with options KDB and DDB? Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
vge problem (Re: 8.0R TCP connection stall with large Send-Q)
On Thu, 03 Dec 2009 13:50:29 +0900 (JST), Yoshiaki Kasahara kasah...@nc.kyushu-u.ac.jp said: I copied some HTML pages with many thumbnails to other PC running 8.0-RC2 (i386), but I couldn't reproduce the problem. The former PC uses vge and latter uses rl, so it might be a NIC driver issue?? I'll try to replace NIC cards when I have time I remembered that there was an onboard NIC (msk0), so I enabled it and moved one IP address to the msk0. Then, the problem was disappeared for that IP address. So, I believe that vge driver of 8.0R is somewhat broken. Is there anyone who can fix the problem? I'm willing to test patches on my PC if available. Anyway I'm considering to purchase two more NIC cards, because I need a quick fix... Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: vge problem
On Thu, 3 Dec 2009 15:08:10 -0800, Pyun YongHyeon pyu...@gmail.com said: I remember there were several instability reports of vge(4). Would you try the following patch? The patch was generated against CURRENT so it may not cleanly apply to 8.0 due to if_timer changes. But I think you can download latest vge(4) code in CURRENT and apply the patch. Note, the patch was not tested at all on real hardware so it even may not work at all.(Long time ago, I ordered the vge(4) hardware was not delivered.) I downloaded vge(4) code in CURRENT, put it in 8.0R source tree, applied the patch, and rebuild GENERIC kernel (actually I shortcut it with NO_CLEAN flag). After I rebooted with the new kernel, the boot sequence stopped just after setting hostname. Setting hostname: elvenbow.cc.kyushu-u.ac.jp msk0: Uncorrectable PCI Express error vge0: link state changed to DOWN msk0: link state changed to DOWN (stop) The system didn't completely freeze. I can push Scroll Lock and Page Up/Down to browse the boot messages, but sometimes it stopped responding to my input for a second. Ctrl-C had no effect and I had to hit the reset button. Now my PC is synchronizing degraded gmirror volume...(ouch) I'm wondering if I need complete kernel rebuild for the code to work... Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
8.0R TCP connection stall with large Send-Q
-16518 - - vge2 1500 Link#3 00:02:2a:dd:00:7d 563715 0 855146 2 0 vge2 1500 133.69.133.96 133.69.133.98 445915 - 3658 - - vge2 1500 fe80:3::202:2 fe80:3::202:2aff:0 - 1875 - - vge2 1500 2001:200:905: 2001:200:905:13140 -65850 - - vge2 1500 2001:200:905: 2001:200:905:13140 -0 - - I believe these Oerrs were due to watchdog timeout like this: Dec 2 13:12:04 elvenbow kernel: vge2: watchdog timeout Dec 2 13:12:04 elvenbow kernel: vge2: link state changed to DOWN Dec 2 13:12:06 elvenbow kernel: vge2: link state changed to UP Dec 3 02:50:27 elvenbow kernel: vge0: watchdog timeout Dec 3 02:50:27 elvenbow kernel: vge0: link state changed to DOWN Dec 3 02:50:30 elvenbow kernel: vge0: link state changed to UP Such timeouts were observed before upgrade, and no noticable effect to the network connection so far. I tried ifconfig vge2 -rxcsum -txcsum but had no effect. I'm using pf, but disabling pf also had no effect. Any ideas to narrow down the cause? Please let me know if you need additional information. I attached dmesg.boot. I'm sorry it is not a verbose output because still I'm compiling all the installed ports Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University kasah...@nc.kyushu-u.ac.jp Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE #0: Thu Nov 26 14:33:01 JST 2009 r...@elvenbow.cc.kyushu-u.ac.jp:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.10-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x649dSSE3,DTES64,MON,DS_CPL,EST,CNXT-ID,CX16,xTPR AMD Features=0x20100800SYSCALL,NX,LM TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2053185536 (1958 MB) ACPI APIC Table: INTEL D925CV2 WARNING: Non-uniform processors. WARNING: Using suboptimal topology. ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: INTEL D925CV2 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 7ff0 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display mem 0xf400-0xf7ff,0xd000-0xd7ff,0xf800-0xf8ff irq 16 at device 0.0 on pci1 hdac0: Intel 82801F High Definition Audio Controller mem 0xf3afc000-0xf3af irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] pcib2: ACPI PCI-PCI bridge at device 28.0 on pci0 pci5: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 28.1 on pci0 pci4: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 28.2 on pci0 pci3: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 28.3 on pci0 pci2: ACPI PCI bus on pcib5 uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0xcc00-0xcc1f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0f30 usbus0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0xd000-0xd01f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0f30 usbus1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B on uhci1 uhci2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C port 0xd400-0xd41f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0f30 usbus2: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-C on uhci2 uhci3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D port 0xd800-0xd81f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0f30 usbus3: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-D on uhci3 ehci0: Intel 82801FB (ICH6) USB 2.0 controller mem 0xf3afb800-0xf3afbbff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: Intel 82801FB (ICH6) USB 2.0 controller on ehci0 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 vge0: VIA Networking Gigabit Ethernet port 0xb800-0xb8ff mem 0xf3b0-0xf3b000ff irq 22 at device 1.0 on pci6 miibus0: MII bus on vge0 ciphy0: Cicada CS8201 10/100/1000TX PHY PHY 1 on miibus0 ciphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto vge0: WARNING: using obsoleted if_watchdog
lost scroll wheel of Intellimouse Explorer 4.0 on 7.0-STABLE
Hello, Today I updated my desktop PC from FreeBSD 7.0R to 7-STABLE. After that, the scroll wheel of my Intellimouse Explorer 4.0 (USB wired) stopped working. I searched relevant information and found kern/123224 [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer 2.0. The symptom is quite similar. ums0: Microsoft Microsoft IntelliMouse Explorer, class 0/0, rev 2.00/4.24, addr 2 on uhub0 ums0: 5 buttons and a TILT dir. Note that there is no Z dir detected. No one care about that? It is hard for me to live without the mouse wheel nowadays I tried another mouse and Z dir was detected properly, so it might be specific to Microsoft products. ums0: Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/11.00, addr 2 on uhub0 ums0: 3 buttons and Z dir. Environment: FreeBSD elvenbow.cc.kyushu-u.ac.jp 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Aug 11 14:04:03 JST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ELVENBOW amd64 Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i386 vs amd64?
On Thu, 7 Aug 2008 11:34:41 +0200, Milan Obuch [EMAIL PROTECTED] said: Funny observation: r is on LEFT keyboard side, l is on RIGHT keyboard side. I for one have problem at times precisely for this reason, but I know this is an important step and one need to act with great care. I use a different mnemonic: r)eplace and l)eave untouched (I read it in this ML a long time ago). Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel panic on 6-STABLE with ipv6?
=0xff0059884980,
uap=0xb75afbc0) at /usr/src/sys/kern/uipc_syscalls.c:920
#15 0x8063fb31 in syscall (frame=
{tf_rdi = 16, tf_rsi = 140737488348864, tf_rdx = 0, tf_rcx = 0, tf_r8 =
0, tf_r9 = 0, tf_rax = 28, tf_rbx = 16, tf_rbp = 140737488348864, tf_r10 = 0,
tf_r11 = 582, tf_r12 = 0, tf_r13 = 5436220, tf_r14 = 1, tf_r15 =
140737488348912, tf_trapno = 12, tf_addr = 5537800, tf_flags = 12, tf_err = 2,
tf_rip = 34374036316, tf_cs = 43, tf_rflags = 518, tf_rsp = 140737488348744,
tf_ss = 35})
at /usr/src/sys/amd64/amd64/trap.c:803
#16 0x80629958 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:270
#17 0x000800da2b5c in ?? ()
Previous frame inner to this frame (corrupt stack?)
--
Please request additional information if needed...
Regards,
--
Yoshiaki Kasahara
Research Institute for Information Technology, Kyushu University
[EMAIL PROTECTED]
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM problems again...
Hi, Sorry this is only a 'me too' message... On Sun, 21 May 2006 11:16:14 +0200, Johan Ström [EMAIL PROTECTED] said: May 21 02:04:58 elfi kernel: ad6: FAILURE - device detached May 21 02:04:58 elfi kernel: subdisk6: detached May 21 02:04:58 elfi kernel: ad6: detached May 21 02:04:58 elfi kernel: GEOM_MIRROR: Device gm0s1: provider ad6s1 disconnected. I have a similar problem on a different M/B (Intel D925XECV2). I'm not sure if it is only a coincidence or somewhat related. May 21 07:43:49 elvenbow kernel: ad4: FAILURE - device detached May 21 07:43:49 elvenbow kernel: subdisk4: detached May 21 07:43:49 elvenbow kernel: ad4: detached May 21 07:43:49 elvenbow kernel: GEOM_MIRROR: Device gm0s1: provider ad4s1 disconnected. excerpts from dmesg: atapci0: Intel ICH6 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 atapci1: Intel ICH6 SATA150 controller port 0xec00-0xec07,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc0f mem 0xf3afbc00-0xf3afbfff irq 19 at device 31.2 on pci0 ata2: ATA channel 0 on atapci1 ata3: ATA channel 1 on atapci1 ata4: ATA channel 2 on atapci1 ata5: ATA channel 3 on atapci1 ad4: 239372MB Maxtor 7V250F0 VA111610 at ata2-master SATA150 ad6: 239372MB Maxtor 7V250F0 VA111610 at ata3-master SATA150 I purchased and started using this new PC last December, and the problem occurred several times by now. Both ad4 and ad6 have been detached (not at a time). 'atacontrol reinit' paused the system for a second, and returned without detecting the detached device. I need a complete power cycle or the device won't recognized by BIOS again. There is no SMART error recorded on these drives. I'm considering to change M/B, but it is difficult right now... dmesg.boot is attached. Ah, the system is running FreeBSD 6.1-STABLE amd64. FreeBSD elvenbow.cc.kyushu-u.ac.jp 6.1-STABLE FreeBSD 6.1-STABLE #0: Mon May 8 16:54:22 JST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ELVENBOW amd64 -- Yoshiaki Kasahara Computing and Communications Center, Kyushu University [EMAIL PROTECTED] Copyright (c) 1992-2006 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 6.1-STABLE #0: Mon May 8 16:54:22 JST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ELVENBOW Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (3000.10-MHz K8-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x649dSSE3,RSVD2,MON,DS_CPL,EST,CNTX-ID,CX16,b14 AMD Features=0x20100800SYSCALL,NX,LM Logical CPUs per core: 2 real memory = 2145579008 (2046 MB) avail memory = 2060705792 (1965 MB) ACPI APIC Table: INTEL D925CV2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: INTEL D925CV2 on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: Please update driver or contact the maintainer. est: cpu_vendor GenuineIntel, msr f2d0f2d, bus_clk, 64 device_attach: est0 attach returned 6 p4tcc0: CPU Frequency Thermal Control on cpu0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci0: multimedia at device 27.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 28.0 on pci0 pci5: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 28.1 on pci0 pci4: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge at device 28.2 on pci0 pci3: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 28.3 on pci0 pci2: ACPI PCI bus on pcib5 uhci0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A port 0xcc00-0xcc1f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B port 0xd000-0xd01f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801FB/FR/FW/FRW (ICH6) USB controller USB-B
Re: 1000baseTX?
Hi, On Sat, 05 Mar 2005 11:31:50 +0100, [EMAIL PROTECTED] said: So I stand by my claim that 1000base-T is clearly more correct than 1000baseTX. It would be nice to get this fixed - however, it is a minor point and I certainly believe that there are other tasks that are more important. Thank you for your additional information about documentation. And I agree with your comment that it is a minor problem. I see frequent (sometimes very minor) rewrites/fixing typos of comments and documents in FreeBSD source tree, so I thought it was worth mentioning... Regards, -- Yoshiaki Kasahara Computing and Communications Center, Kyushu University [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
1000baseTX?
Hello, In man pages, dmesg and ifconfig of FreeBSD5, GbE operation over twisted pair is mostly referred as '1000baseTX'. I guess most of them should be replaced by '1000baseT'. 1000baseTX and 1000baseT are different standard and they are not compatible (TX needs CAT6 cable and uses pairs in different way). Also 1000baseTX support is very rare yet. I'm sorry I'm not sure if some devices really support TX. For example, I have a NIC based on Realtek RTL8169S and its manual says It supports 1000BASE-T/100BASE-TX/10BASE-T. In dmesg: rgephy0: RTL8169S/8110S media interface on miibus1 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto Regards, -- Yoshiaki Kasahara [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_5 IPFW misbehavior
Hello, Could anyone please review kern/71910 and kern/73129 to fix IPFW behavior before 5.4R? I have trouble using ipfw for output interface selection after migrated to 5.x... Thanks in advance, -- Yoshiaki Kasahara [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PHP vulnerability and portupgrade
On Wed, 22 Dec 2004 09:52:01 +0800, Ladislav Bodnar [EMAIL PROTECTED] said: Thanks a lot for your reply. If I understand things correctly, I need to maintain two cvsup files - one that tracks security issues in the base FreeBSD 5.3 system (tag=RELENG_5_3, src-all) and one for the ports collection (tag=. , ports-all). Then every time I receive a FreeBSD security advisory I run cvsup on the former, and every time portaudit tells me about a new security issue in the ports collection, I run cvsup on the latter, then use portupgrade to upgrade vulnerable ports. Is this correct? To do it easier, you can set some variables in /etc/make.conf as follows: SUP_UPDATE= yes SUP=/usr/local/bin/cvsup SUPFLAGS= -g -L 2 SUPHOST=cvsup.jp.FreeBSD.org (- change as you like) SUPFILE=/usr/share/examples/cvsup/stable-supfile PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile Then type 'make update' in /usr/src. Your source tree will be updated using stable-supfile, and your ports tree will be updated using ports-supfile. Maybe you need to edit stable-supfile to retrieve RELENG_5_3. See /usr/share/examples/etc/make.conf and /usr/share/examples/cvsup/README for the detail. Regards, -- Yoshiaki Kasahara Computing and Communications Center, Kyushu University [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
pcn0: watchdog timeout
Hello, Yesterday I updated my 4.10 box into 5.3-STABLE (cvsupped several days ago). After that, I started seeing occasional 'pcn0: watchdog timeout' on my console. Is there any way to fix this? The motherboard is GIGABYTE GA-6VXD7 with dual Pentium III (1GHz). I'm using SMP kernel. I attached 'mptable -verbose -dmesg' output. Actually I suspect my M/B or BIOS, because I couldn't use SMP kernel of 4.x series on this M/B due to sustaining 'microuptime went backwards' issue (and the internal clock ran several times faster). I really want to use SMP kernel (because I have 2 CPU), so if the message is not fatal, I'll live with it. Unfortunately there is no BIOS update for this M/B since 2002/01. Regards, -- Yoshiaki Kasahara [EMAIL PROTECTED] === MPTable, version 2.0.15 looking for EBDA pointer @ 0x040e, found, searching EBDA @ 0x0009fc00 searching CMOS 'top of mem' @ 0x0009f800 (638K) searching default 'top of mem' @ 0x0009fc00 (639K) searching BIOS @ 0x000f MP FPS found in BIOS @ physical addr: 0x000fb120 --- MP Floating Pointer Structure: location: BIOS physical address: 0x000fb120 signature:'_MP_' length: 16 bytes version: 1.1 checksum: 0x5d mode: Virtual Wire --- MP Config Table Header: physical address: 0x000f57e0 signature:'PCMP' base table length:260 version: 1.1 checksum: 0x98 OEM ID: 'VIA ' Product ID: 'VT3075 ' OEM table pointer:0x OEM table size: 0 entry count: 24 local APIC address: 0xfee0 extended table length:0 extended table checksum: 0 --- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model StepFlags 0 0x11BSP, usable 6 8 6 0x387fbff 1 0x11AP, usable 6 8 6 0x387fbff -- Bus:Bus ID Type 0 PCI 1 PCI 2 ISA -- I/O APICs: APIC ID Version State Address 2 0x11usable 0xfec0 -- I/O Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT conformsconforms2 0 20 INT conformsconforms2 1 21 INT conformsconforms2 0 22 INT conformsconforms2 3 23 INT conformsconforms2 4 24 INT conformsconforms2 6 26 INT conformsconforms2 7 27 INT active-hiedge2 8 28 INT conformsconforms212 2 12 INT conformsconforms213 2 13 INT conformsconforms214 2 14 INT conformsconforms215 2 15 INT active-lo level211 2 11 INT active-lo level2 9 29 INT active-lo level2 5 25 INT active-lo level210 2 10 -- Local Ints: TypePolarityTrigger Bus ID IRQAPIC ID PIN# ExtINT conformsconforms0 0:A2550 NMI conformsconforms0 0:A2551 --- dmesg output: Copyright (c) 1992-2004 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.3-STABLE #1: Mon Dec 6 20:11:17 JST 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ELVENBOW Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel Pentium III (1000.04-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 805240832 (767 MB) avail memory = 778215424 (742 MB) ACPI
