Problem with CPU freq in 7.1-STABLE -- take 2
Hi, I noticed a problem with CPU freq in 7.1-STABLE. The maximum frequency showed by sysctl is 500Mhz lower than what it should be for my Pentium M 2Ghz. Here is the output from dmesg: 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 7.1-STABLE #7: Tue Jan 6 16:01:20 EST 2009 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 2.00GHz (1995.15-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 AMD Features=0x10 and the output from sysctl: dev.cpu.0.freq_levels: 1500/-1 1312/-1 1200/-1 1050/-1 1000/-1 875/-1 800/-1 700/-1 600/-1 525/-1 450/-1 375/-1 300/-1 225/-1 150/-1 75/-1 dev.est.0.freq_settings: 1500/-1 1200/-1 1000/-1 800/-1 600/-1 This used to work correctly in 7.0... Thanks! Pierre-Luc Drouin ___ 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"
Using FreeBSD Update to deploy system updates from custom builds
Hi, I was wondering if anyone was using freebsd-update to manage deployment of custom FreeBSD builds to there systems. Here is the scenario, I have 2 binary build servers at the moment (one for i386 and one for amd64) and currently we stage the deployments of updates on NFS servers at each site. We use make installworld/kernel to update the servers from read only src and obj NFS mounts. I'm now looking to remove the src trees from the NFS servers and possibly the obj trees and use freebsd-update to deploy and maintain the custom build installation and updates. So I have 2 questions: 1) Does this seem sensible? It seems within scope of what freebsd-update was designed to do. 2) How does one go about building the binary distributions that freebsd-update expects to be on the update server? Thanks Tom ___ 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 7.1 Breaks re and rl Network Interface Drivers
Pyun YongHyeon a écrit : On Tue, Jan 13, 2009 at 10:17:54AM -0500, FreeBSD wrote: > Pyun YongHyeon a ?crit : > >On Mon, Jan 12, 2009 at 05:11:02PM -0500, FreeBSD wrote: > > > Pyun YongHyeon a ?crit : > > > >On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote: > > > > > Walter, > > > > > > > > > > Thursday, January 8, 2009, 2:50:40 AM, you wrote: > > > > > > > > > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely > > alleviates > > all > > > > > WV> problems. I believe this roundly confirms that this is a bug > > in the > > > > > WV> 7.1-RELEASE re kernel drivers. > > > > > > > > > > Does kern/130011 look similar? > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 > > > > > > > >Do you have RTL8168C controller? If not, it's not related with > > > >Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C. > > > > > > > > > > > > > > The re driver was really broken in 7.1-RC2 and the fix didn't get > > to > > 7.1-RELEASE. > > > > > > > >If you have re(4) issues, please provide more details such as > > > >dmesg output, way to reproduce the issue etc. > > > > > > > > > > Hi, > > > > > > I have the exact same card and the exact same problem as the PR you > > > mentionned. > > > > > > r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec rev=0x02 > > > hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > class = network > > > subclass = ethernet > > > > > > > > > re0: > > > Gigabit Ethernet> port 0xd800-0xd8ff mem > > > 0xfeaff000-0xfeaf,0xfdff-0xfdff irq 18 at device 0.0 on pci3 > > > re0: Chip rev. 0x3c00 > > > re0: MAC rev. 0x0040 > > > re0: PHY write failed > > > re0: PHY write failed > > > re0: MII without any phy! > > > device_attach: re0 attach returned 6 > > > > > > I tried to compile a new kernel with the latest version of the 3 files > > > listed in the PR: > > > src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari > > > src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari > > > src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari > > > > > > >You need lastest if_rl.c and if_rlreg.h as well as if_re.c. > > > > That's exactly what I tried. Look at the 3 revision of the specified You've used if_rlreg.h in stable/7. > files. I even tried with a if_rl.c from the 22/12/08 but got the same > problem. > Use if_re.c, if_rl.h and if_rl.c in HEAD. Not all changes were MFCed. Oups... I didn't check the branch. I just concentrated on the "latest revision" not the latest revision in HEAD. Sorry for the noise, it's the first time I have to deal with that kind of kernel modification. I just rebooted and the interface appears in ifconfig. I will let you know if I experience any problem. Thanks again for your good work and the time to took to help me resolve this issue. Martin ___ 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: lenovo t400 does not start 7.1
Ganbold wrote: Harald Servat wrote: Hello, I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). The boot process starts fine, the BTX messages appear, the 7-option menu also appears, but when I hit enter (or when I choose start without ACPI or start in safe mode) the \ symbols starts spinning for a while and then freezes. I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of 8.0-CURRENT dated from December. And the result is the same for all of them. Does anyone have any idea on what can be happening? Or at least, how can I gather more information about this issue? Please try setting "Integrated Graphics" or "Switchable Graphics" mode on Display setting in BIOS. AFAICT it is known issue and FreeBSD doesn't boot when set to Discrete Graphics in BIOS. Or maybe it boots but nothing shows on screen. Ganbold ___ 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: lenovo t400 does not start 7.1
Harald Servat wrote: Hello, I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). The boot process starts fine, the BTX messages appear, the 7-option menu also appears, but when I hit enter (or when I choose start without ACPI or start in safe mode) the \ symbols starts spinning for a while and then freezes. I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of 8.0-CURRENT dated from December. And the result is the same for all of them. Does anyone have any idea on what can be happening? Or at least, how can I gather more information about this issue? Please try setting "Integrated Graphics" or "Switchable Graphics" mode on Display setting in BIOS. AFAICT it is known issue and FreeBSD doesn't boot when set to Discrete Graphics in BIOS. Ganbold Thank you. -- Too often I find that the volume of paper expands to fill the available briefcases. -- Governor Jerry Brown ___ 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: lenovo t400 does not start 7.1
On Tue, Jan 13, 2009 at 1:57 PM, Harald Servat wrote: > Hello, > > I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with > correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). > Could you test the disc on a different machine to verify a good burn? [snip] -- Glen Barber ___ 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: lenovo t400 does not start 7.1
On Tue, Jan 13, 2009 at 5:47 PM, Garrett Cooper wrote: > On Tue, Jan 13, 2009 at 2:04 PM, Harald Servat wrote: > >> On Tue, Jan 13, 2009 at 9:40 PM, Harald Servat wrote: >> >>> >>> >>> On Tue, Jan 13, 2009 at 8:47 PM, Oleksandr Tymoshenko >>> wrote: >>> Harald Servat wrote: > Hello, > > I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with > correct SHA256 checksum), but I'm unable to start the system (Lenovo > T400). > > The boot process starts fine, the BTX messages appear, the 7-option menu > also appears, but when I hit enter (or when I choose start without ACPI > or > start in safe mode) the \ symbols starts spinning for a while and then > freezes. > > I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of > 8.0-CURRENT dated from December. And the result is the same for all of > them. > > Does anyone have any idea on what can be happening? Or at least, how can > I > gather more information about this issue? > Not sure about install CDs but I tried all these systems on my t400. I installed 7.0 then upgraded it to 7.1 and when it turned out that atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup for upgrades). What is your HW configuration? >>> Ok, thanks... I'll give a try to 7.0, and let's see if it works. >>> >>> >> Uhm... FreeBSD 7.0 i386 CD1 behaves in the same manner. It frozes when >> spinning the backslash symbol. >> >> The BIOS reports 4GB of RAM and SATA disk configured in AHCI mode. Should I >> look for something unusual? and how? >> >> Thank you. > >Could you try booting with verbose information (option 5)? Also, > have you tried disabling ACPI, or switching AHCI over to > EIDE/compatible mode? > Thanks, > -Garrett Also, try upgrading your BIOS to the latest version, if at all possible. -Garrett ___ 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: lenovo t400 does not start 7.1
On Tue, Jan 13, 2009 at 2:04 PM, Harald Servat wrote: > On Tue, Jan 13, 2009 at 9:40 PM, Harald Servat wrote: > >> >> >> On Tue, Jan 13, 2009 at 8:47 PM, Oleksandr Tymoshenko >> wrote: >> >>> Harald Servat wrote: >>> Hello, I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). The boot process starts fine, the BTX messages appear, the 7-option menu also appears, but when I hit enter (or when I choose start without ACPI or start in safe mode) the \ symbols starts spinning for a while and then freezes. I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of 8.0-CURRENT dated from December. And the result is the same for all of them. Does anyone have any idea on what can be happening? Or at least, how can I gather more information about this issue? >>>Not sure about install CDs but I tried all these systems on my >>> t400. >>> I installed 7.0 then upgraded it to 7.1 and when it turned out that >>> atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup >>> for upgrades). What is your HW configuration? >>> >>> >> Ok, thanks... I'll give a try to 7.0, and let's see if it works. >> >> > Uhm... FreeBSD 7.0 i386 CD1 behaves in the same manner. It frozes when > spinning the backslash symbol. > > The BIOS reports 4GB of RAM and SATA disk configured in AHCI mode. Should I > look for something unusual? and how? > > Thank you. Could you try booting with verbose information (option 5)? Also, have you tried disabling ACPI, or switching AHCI over to EIDE/compatible mode? Thanks, -Garrett ___ 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"
Reproducible panic (page fault) in poll on 6.3-RELEASE-p4
I have a kernel panic that I can consistently trigger. After a short
while (5 to 30 minutes) with a certain connection pattern of UDP openvpn
connections the server crashes.
I have a crash dump, and stack trace. It seems td->td_selq has been
corrupted (see below).
The only similar panic I've found is:
http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2004-02/0867.html
Does anyone know of a patch or any other pointers in the direction of
solving this problem?
Thanks in advance,
Stef Walter
--- 8< --- 8<
6.3-RELEASE-p4 FreeBSD 6.3-RELEASE-p4 #0: Thu Sep 25 20:16:32 UTC 2008
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xd
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc055d5ec
stack pointer = 0x28:0xeb927b9c
frame pointer = 0x28:0xeb927b9c
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 = 49994 (openvpn)
trap number = 12
panic: page fault
Uptime: 14h58m30s
Dumping 3326 MB (2 chunks)
chunk 0: 1MB (157 pages) ... ok
chunk 1: 3326MB (851312 pages) 3310 3294 3278 3262 3246 3230 3214 3198
3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974
2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750
2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526
2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302
2286 2270 2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078
2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854
1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630
1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406
1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182
1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942
926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654
638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366
350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62
46 30 14
#0 doadump () at pcpu.h:165
165 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc053952e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc05397c4 in panic (fmt=0xc071b0fc "%s")
at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc06f3208 in trap_fatal (frame=0xeb927b5c, eva=13)
at /usr/src/sys/i386/i386/trap.c:838
#4 0xc06f2f6f in trap_pfault (frame=0xeb927b5c, usermode=0, eva=13)
at /usr/src/sys/i386/i386/trap.c:745
#5 0xc06f2bcd in trap (frame=
{tf_fs = -342753272, tf_es = -1068498904, tf_ds = -1065746392,
tf_edi = -929257216, tf_esi = 23531, tf_ebp = -342721636, tf_isp =
-342721656, tf_ebx = 35, tf_edx = -929257216, tf_ecx = -1065693536,
tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip = -1068116500, tf_cs =
32, tf_eflags = 590342, tf_esp = -342721316, tf_ss = -1068117214}) at
/usr/src/sys/i386/i386/trap.c:435
#6 0xc06e096a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc055d5ec in clear_selinfo_list (td=0xc89ca900)
at /usr/src/sys/kern/sys_generic.c:1085
#8 0xc055d322 in poll (td=0xc89ca900, uap=0xeb927d04)
at /usr/src/sys/kern/sys_generic.c:984
#9 0xc06f351f in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = -1077943456, tf_esi
= 134902336, tf_ebp = -1077943512, tf_isp = -342721180, tf_ebx = 0,
tf_edx = 1034, tf_ecx = 1034, tf_eax = 209, tf_trapno = 22, tf_err = 2,
tf_eip = 673704855, tf_cs = ---Type to continue, or q
to quit---
51, tf_eflags = 662, tf_esp = -1077943556, tf_ss = 59})
at /usr/src/sys/i386/i386/trap.c:984
#10 0xc06e09bf in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:200
#11 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) up 7
#7 0xc055d5ec in clear_selinfo_list (td=0xc89ca900)
at /usr/src/sys/kern/sys_generic.c:1085
1085TAILQ_FOREACH(si, &td->td_selq, si_thrlist)
(kgdb) p td
$1 = (struct thread *) 0xc89ca900
(kgdb) p *td
$2 = {td_proc = 0xc89c8c90, td_ksegrp = 0xc82e1540, td_plist = {
tqe_next = 0x0, tqe_prev = 0xc89c8ca0}, td_kglist = {tqe_next = 0x0,
tqe_prev = 0xc82e154c}, td_slpq = {tqe_
interrupt storm
it seems that you hit the same issue with amd sb600 as me :) -- SY, Marat ___ 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"
interrupt storm
Hi, I'm getting this: kernel: interrupt storm detected on "irq22:"; throttling interrupt source on FreeBSD 7.1-STABLE #6: Sat Jan 10 21:45:05 EST 2009 FWIW, I got the same thing on 7.0-stable from back in May (IIRC). Of note, atapci0 and fxp0 are both on irq 22. Ideas? suggestions? 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 7.1-STABLE #6: Sat Jan 10 21:45:05 EST 2009 d...@polo.unixathome.org:/usr/obj/usr/src/sys/PHENOM Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) 9600 Quad-Core Processor (2300.18-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f22 Stepping = 2 Features=0x178bfbff Features2=0x802009> AMD Features=0xee500800 AMD Features2=0x7ff,,,Prefetch,,> Cores per package: 4 usable memory = 4281454592 (4083 MB) avail memory = 4119994368 (3929 MB) ACPI APIC Table: <122107 APIC0947> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: <122107 RSDT0947> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, cff0 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 5.0 on pci0 pci1: on pcib1 re0: Gigabit Ethernet> port 0xc800-0xc8ff mem 0xf9fff000-0xf9ff irq 17 at device 0.0 on pci1 re0: turning off MSI enable bit. re0: Chip rev. 0x3800 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1d:92:63:8b:28 re0: [FILTER] pcib2: at device 11.0 on pci0 pci2: on pcib2 vgapci0: port 0xd800-0xd87f mem 0xfd00-0xfdff,0xd000-0xdfff,0xfa00-0xfbff irq 19 at device 0.0 on pci2 atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xf9eff800-0xf9effbff irq 22 at device 18.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI Version 01.10 controller with 4 ports detected ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xf9efe000-0xf9efefff irq 16 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xf9efd000-0xf9efdfff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xf9efc000-0xf9efcfff irq 18 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: SMM does not respond, resetting usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xf9efb000-0xf9efbfff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: SMM does not respond, resetting usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xf9efa000-0xf9efafff irq 18 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: SMM does not respond, resetting usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xf9eff000-0xf9eff0ff irq 19 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 fwohci0: port 0xe800-0xe87f mem 0xfebff800-0xfebf irq 23 at device 0
interrupt storm and usb issue on ati ixp600 based board
I have two troubles with my freshly upgraded system. There are interrupt storm and usb issues on MSI K9A2 CF motherboard. it made of on amd 790X north-bridge and and SB600 south-bridge. As stated in [1] there is a problem with storms on re or atapci devices, but my experience shows that this storms are not bound to re or ixp600 atapci only. I can say that i have such storms on almost any of my devices. whether it sound-card, ata-device, scsi or network. any device that is used intensively can trigger this storm issue, e.g. playing music via audacious can trigger storm in about random() hours after fresh boot either cold or warm (i tried both built in hda that shares irq with ohci0 and standalone sblive! with its own interrupt), moving large files from one physical drive to another, etc. I've tried to turn off msi and msix setting hw.pci.enable_msix="0" hw.pci.enable_msi="0" in /boot/loader.conf interrupt storm arrived in about 27 hours. and it was on pcm0 (snd_hda) So, can this be hardware or software problem? can it be fixed by some workaround? and finally I've updated to 7.1-S. the same story. temporary workaround for interrupt storm issue is to wait until storm arrive on any device (emu10kx0 in this case, because of its own high interrupt rate) and work pretending to believe that nothing is wrong. second issue is neither 7.0 nor 7.1 refuse to detect in run-time any usb device that plugged into external USB HUB, I have two of them, first is on card-reader, second is in my monitor. devices plugged to these hubs before system boot are detected, but device plugged after boot -- they never appear in system, they silently ignored. so, what should i do? :) [1] http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047010.html [2] fresh boot vmstat: % vmstat -i interrupt total rate irq1: atkbd0 12524 1 irq9: acpi01 0 irq12: psm0 1173440107 irq14: ata0 143 0 irq16: hdac0 ohci0541673 49 irq17: ohci1 ohci3 1 0 irq18: ohci2 ohci+45 0 irq19: ehci0 259 0 irq21: emu10kx0 1137863753 103762 irq22: atapci0210431 19 cpu0: timer 21929877 1999 irq256: re094789 8 cpu1: timer 21927861 1999 Total 1183754797 107947 [3] % uptime 3:15 up 3:03, 2 users, load averages: 0,60 0,47 0,63 [4] dmesg attached -- SY, Marat interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source info: [drm] wait for fifo failed status : 0x9803C100 0x0005 interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source interrupt storm detected on "irq21::irq21: emu10kx0"; throttling interrupt source info: [drm] Num pipes: 1 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...6 3 6 6 0 1 1 0 0 0 done All buffers synced. Uptime: 3d22h21m34s 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 7.1-STABLE #0: Tue Jan 13 23:43:59 MSK 2009 r...@zealot.ksu.ru:/usr/obj/usr/src/sys/ZEALOT Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Dual Core Processor 4850e (2500.19-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 4285845504 (4087 MB) avail memory = 4124442624 (3933 MB) ACPI APIC Table: <061208 APIC1106> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard netsmb_de
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Tue, Jan 13, 2009 at 10:17:54AM -0500, FreeBSD wrote: > Pyun YongHyeon a ?crit : > >On Mon, Jan 12, 2009 at 05:11:02PM -0500, FreeBSD wrote: > > > Pyun YongHyeon a ?crit : > > > >On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote: > > > > > Walter, > > > > > > > > > > Thursday, January 8, 2009, 2:50:40 AM, you wrote: > > > > > > > > > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely > > alleviates > > all > > > > > WV> problems. I believe this roundly confirms that this is a bug > > in the > > > > > WV> 7.1-RELEASE re kernel drivers. > > > > > > > > > > Does kern/130011 look similar? > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 > > > > > > > >Do you have RTL8168C controller? If not, it's not related with > > > >Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C. > > > > > > > > > > > > > > The re driver was really broken in 7.1-RC2 and the fix didn't get > > to > > 7.1-RELEASE. > > > > > > > >If you have re(4) issues, please provide more details such as > > > >dmesg output, way to reproduce the issue etc. > > > > > > > > > > Hi, > > > > > > I have the exact same card and the exact same problem as the PR you > > > mentionned. > > > > > > r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec rev=0x02 > > > hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > class = network > > > subclass = ethernet > > > > > > > > > re0: > > Gigabit Ethernet> port 0xd800-0xd8ff mem > > > 0xfeaff000-0xfeaf,0xfdff-0xfdff irq 18 at device 0.0 on pci3 > > > re0: Chip rev. 0x3c00 > > > re0: MAC rev. 0x0040 > > > re0: PHY write failed > > > re0: PHY write failed > > > re0: MII without any phy! > > > device_attach: re0 attach returned 6 > > > > > > I tried to compile a new kernel with the latest version of the 3 files > > > listed in the PR: > > > src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari > > > src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari > > > src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari > > > > > > >You need lastest if_rl.c and if_rlreg.h as well as if_re.c. > > > > That's exactly what I tried. Look at the 3 revision of the specified You've used if_rlreg.h in stable/7. > files. I even tried with a if_rl.c from the 22/12/08 but got the same > problem. > Use if_re.c, if_rl.h and if_rl.c in HEAD. Not all changes were MFCed. -- Regards, Pyun YongHyeon ___ 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: CFT: ath hal src switchover
On Fri, Jan 9, 2009 at 5:32 AM, Sean C. Farley wrote: > On Thu, 8 Jan 2009, Sam Leffler wrote: > >> I've brought the hal source code back to RELENG_7 but not connected it to >> the build and/or driver. I want folks to test this before I commit those >> changes. To do this you must have an up to date RELENG_7 code base and then >> apply this patch: >> >> http://people.freebsd.org/~sam/ath_hal-releng7.patch > > *snip* > >> Please report any issues to this mailing list. > > No problems for my Netgear WPN511. It works well at home. > > Now, if I just could figure out why the recent Aruba update at work is > preventing me from authenticating with it, I would be happy. This is not > related to the MFC of the code. iPhones and MacOSX 10.4 (but not 10.5) are > also having problems. Windows works. > > Sean > -- > s...@freebsd.org > ___ > 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" > Hi, today I tried to get a (samsung nc10 ath) nic working. The patch failed to edit this three files: sys/modules/ath_rate_onoe/Makefile sys/modules/ath_rate_sample/Makefile sys/modules/ath_rate_amrr/Makefile I emptied them manually and ran a buildworld/kernel/etc on a clean 7.1 stable but i get a error message while booting: ath0: unable to attach hardware; HAL status 13 After that I csuped the latest stable srcs, applied hal-20081015-sanitized.tgz and run the complete buildprocess again. The same error Message occurs. Is there any trick to get the samsungs ath card running? regards, Vincent 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 7.1-STABLE #0: Tue Jan 13 21:21:53 CET 2009 root@:/usr/obj/usr/src/sys/BOOKLI Preloaded elf kernel "/boot/kernel/kernel" at 0xc0a99000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a99250. Calibrating clock(s) ... i8254 clock: 1193244 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1595994372 Hz CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1595.99-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d> AMD Features2=0x1 Logical CPUs per core: 2 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 512 kbytes, 16-way associative, 64 bytes/line real memory = 1064108032 (1014 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x0010 - 0x003f, 3145728 bytes (768 pages) 0x00c25000 - 0x3e4b0fff, 1032372224 bytes (252044 pages) avail memory = 1031852032 (984 MB) Table 'FACP' at 0x3f6e1bd2 Table 'APIC' at 0x3f6e1cc6 MADT: Found table at 0x3f6e1cc6 MP Configuration Table version 1.4 found at 0xc009fc71 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00f7150 bios32: Entry = 0xfd5f0 (c00fd5f0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd5f0+0x275 pnpbios: Found PnP BIOS data at 0xc00f71f0 pnpbios: Entry = f:b8d8 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 ULE: setup cpu group 0 ULE: setup cpu 0 ULE: adding cpu 0 to group 0: cpus 1 mask 0x1 ULE: setup cpu 1 ULE: adding cpu 1 to group 0: cpus 2 mask 0x3 ACPI: RSDP @ 0x0xf71a0/0x0024 (v 2 PTLTD ) ACPI: XSDT @ 0x0x3f6db94a/0x0084 (v 1 SECCSD LH43STAR 0x0604 LTP 0x) ACPI: FACP @ 0x0x3f6e1bd2/0x00F4 (v 3 INTEL CALISTGA 0x0604 ALAN 0x0001) ACPI: DSDT @ 0x0x3f6dd5f2/0x456C (v 1 INTEL CALISTGA 0x0604 INTL 0x20050624) ACPI: FACS @ 0x0x3f6e2fc0/0x0040 ACPI: APIC @ 0x0x3f6e1cc6/0x0068 (v 1 INTEL CALISTGA 0x0604 LOHR 0x005A) ACPI: HPET @ 0x0x3f6e1d2e/0x0038 (v 1 INTEL CALISTGA 0x0604 LOHR 0x005A) ACPI: MCFG @ 0x0x3f6e1d66/0x003C (v 1 INTEL CALISTGA 0x0604 LOHR 0x005A) ACPI: TCPA @ 0x0x3f6e1da2/0x0032 (v 1 PTLTD CALISTGA 0x0604 PTL 0x0001) ACPI: TMOR @ 0x0x3f6e1dd4/0x0026 (v 1 PTLTD 0x0604 PTL 0x0003) ACPI: APIC @ 0x0x3f6e1dfa/0x0068 (v 1 PTLTD APIC 0x0604 LTP 0x) ACPI: BOOT @ 0x0x3f6e1e62/0x0028 (v 1 PTLTD $SBFTBL$ 0x0604 LTP 0x0001) ACPI: SLIC @ 0x0x3f6e1e8a/0x0176 (v 1 SECCSD LH43STAR 0x0604 LTP 0x) ACPI: SSDT @ 0x0x3f6dcfa3/0x064F (v 1 SataRe SataPri 0x1000 INTL 0x20050624) ACPI: SSDT @ 0x0x3f6dc
Re: FreeBSD 7.1 Breaks re and rl Network Interface Drivers
On Tuesday 13 January 2009 10:27 am, Dimitry Andric wrote: > Reverting r180519 seems to solve the problem of not being able to > send any packets. It does not solve the other problem, which is > that the interfaces can take a very long time to come up at boot > time, e.g: > > Setting hostuuid: 3ee65237-8025-11dc-9ab5-003018a6f1a8. > Setting hostid: 0xaaedab9a. > Mounting local file systems:. > Setting hostname: tensor.andric.com. > [... pauses for 10 seconds here ...] > re0: link state changed to DOWN > re1: link state changed to DOWN > lo0: flags=8049 metric 0 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > inet 127.0.0.1 netmask 0xff00 > re0: flags=8843 metric 0 > mtu 1500 > options=389bUCAST,WOL_MCAST,WOL_MAGIC> ether 00:30:18:a6:f1:a8 > inet6 fe80::230:18ff:fea6:f1a8%re0 prefixlen 64 tentative > scopeid 0x1 inet 87.251.56.140 netmask 0xffc0 broadcast > 87.251.56.191 media: Ethernet autoselect (none) > status: no carrier > re1: flags=8843 metric 0 > mtu 1500 > options=389bUCAST,WOL_MCAST,WOL_MAGIC> ether 00:30:18:a6:f1:a9 > inet6 fe80::230:18ff:fea6:f1a9%re1 prefixlen 64 tentative > scopeid 0x2 inet 192.168.0.1 netmask 0xff00 broadcast > 192.168.0.255 media: Ethernet autoselect (none) > status: no carrier > [...] > > (note also the "no carrier" just after upping those interfaces) [...] Can you try one of the following patches? -CURRENT: http://people.freebsd.org/~jkim/re/re.current.diff -STABLE:http://people.freebsd.org/~jkim/re/re.stable.diff These patches contain all patches suggested by me and yongari and an additional patch, which may (or may not) decrease the initial setup time. Jung-uk Kim ___ 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: lenovo t400 does not start 7.1
On Tue, Jan 13, 2009 at 9:40 PM, Harald Servat wrote: > > > On Tue, Jan 13, 2009 at 8:47 PM, Oleksandr Tymoshenko > wrote: > >> Harald Servat wrote: >> >>> Hello, >>> >>> I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with >>> correct SHA256 checksum), but I'm unable to start the system (Lenovo >>> T400). >>> >>> The boot process starts fine, the BTX messages appear, the 7-option menu >>> also appears, but when I hit enter (or when I choose start without ACPI >>> or >>> start in safe mode) the \ symbols starts spinning for a while and then >>> freezes. >>> >>> I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of >>> 8.0-CURRENT dated from December. And the result is the same for all of >>> them. >>> >>> Does anyone have any idea on what can be happening? Or at least, how can >>> I >>> gather more information about this issue? >>> >>Not sure about install CDs but I tried all these systems on my >> t400. >> I installed 7.0 then upgraded it to 7.1 and when it turned out that >> atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup >> for upgrades). What is your HW configuration? >> >> > Ok, thanks... I'll give a try to 7.0, and let's see if it works. > > Uhm... FreeBSD 7.0 i386 CD1 behaves in the same manner. It frozes when spinning the backslash symbol. The BIOS reports 4GB of RAM and SATA disk configured in AHCI mode. Should I look for something unusual? and how? Thank you. ___ 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: lenovo t400 does not start 7.1
On Tue, Jan 13, 2009 at 8:59 PM, Ben Kaduk wrote: > On Tue, Jan 13, 2009 at 1:57 PM, Harald Servat wrote: > > Hello, > > > > I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with > > correct SHA256 checksum), but I'm unable to start the system (Lenovo > T400). > > > > The boot process starts fine, the BTX messages appear, the 7-option menu > > also appears, but when I hit enter (or when I choose start without ACPI > or > > start in safe mode) the \ symbols starts spinning for a while and then > > freezes. > > Have you tried an ISO for FreeBSD-CURRENT? > > I also have a T400, and definitely had FreeBSD running on it for a while, > but I don't remember if it was 7 or current. > > -Ben Kaduk > I tried 8.0-CURRENT snapshot from December with no luck. I'll give 7.0 a try (Oleksandr also suggested the same). Thanks! -- _ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... ___ 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: lenovo t400 does not start 7.1
On Tue, Jan 13, 2009 at 8:47 PM, Oleksandr Tymoshenko wrote: > Harald Servat wrote: > >> Hello, >> >> I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with >> correct SHA256 checksum), but I'm unable to start the system (Lenovo >> T400). >> >> The boot process starts fine, the BTX messages appear, the 7-option menu >> also appears, but when I hit enter (or when I choose start without ACPI or >> start in safe mode) the \ symbols starts spinning for a while and then >> freezes. >> >> I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of >> 8.0-CURRENT dated from December. And the result is the same for all of >> them. >> >> Does anyone have any idea on what can be happening? Or at least, how can >> I >> gather more information about this issue? >> >Not sure about install CDs but I tried all these systems on my t400. > I installed 7.0 then upgraded it to 7.1 and when it turned out that > atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup > for upgrades). What is your HW configuration? > > Ok, thanks... I'll give a try to 7.0, and let's see if it works. -- _ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... ___ 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: lenovo t400 does not start 7.1
Harald Servat wrote: Hello, I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). The boot process starts fine, the BTX messages appear, the 7-option menu also appears, but when I hit enter (or when I choose start without ACPI or start in safe mode) the \ symbols starts spinning for a while and then freezes. I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of 8.0-CURRENT dated from December. And the result is the same for all of them. Does anyone have any idea on what can be happening? Or at least, how can I gather more information about this issue? Not sure about install CDs but I tried all these systems on my t400. I installed 7.0 then upgraded it to 7.1 and when it turned out that atheros is not 100% supported by it I upgraded to CURRENT. (I used cvsup for upgrades). What is your HW configuration? ___ 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: amr driver changes in FreeBSD 7.1-RELEASE
Hello, This seems related to a problem I had with a 7.1-PRERELEASE (I have since upgraded to 7.1-RELEASE, but haven't not tested if the problem is still there). If I compiled the kernel with only the amr driver, it would not see my raid volume. If I enabled a separate scsi driver (I think it was some LSI Logic scsi driver) in addition to amr, the amr driver would work fine. I wish I could give some exact details (like the name of the other scsi driver), but this is on my home machine, and I'm currently at work. While a generic 7.1-PRERELEASE kernel had both of these compiled in (of course), and worked fine for me, I suspect our problems are related. I have an LSI Logic 150-4 SATA raid controller. -Cameron n Tuesday 13 January 2009 11:27:15 am Steve Polyack wrote: > Hello, > > We have a Dell PowerEdge 1850 server. It contains two PERC4 RAID > controllers. One is a PERC4e/Si, and the other is a PERC4/DC. Right > now we are running FreeBSD 6.3-RELEASE, with a 36GB RAID-1 on the > PERC4e/Si (amr0), and both a 1TB RAID5 and a 136GB RAID1 on the > PERC4/DC(amr1). Both adapters are running the latest firmware revision. > > When we boot FreeBSD7.1 install media, the amr driver fails to detect > any volumes (disks) attached to amr0, the PERC4e/Si. However, it picks > up the attached disks on the PERC4/DC just fine. However, if I boot > 7.0-RELEASE install media, it picks up all of the attached volumes, > leading me to believe the issue is due to changes in the amr driver > between 7.0 and 7.1. During the 7.1 boot process, before probing disks, > we see the message "amr0: adapter is busy" show up twice. This also > does not occur on the 6.3, 6.4, or 7.0 releases. > > We also have another PE1850 with a very similar configuration, except > the two PERCs get probed in a different order, and it detects all of the > attached volumes without any issues. > > Any suggestions? These are semi-critical systems, so we aren't always > able to test things like this. But, we can schedule downtime once or > twice a week if necessary. > > -Steve Polyack > ___ > freebsd-hardw...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hardware > To unsubscribe, send any mail to "freebsd-hardware-unsubscr...@freebsd.org" ___ 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: lenovo t400 does not start 7.1
On Tue, Jan 13, 2009 at 1:57 PM, Harald Servat wrote: > Hello, > > I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with > correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). > > The boot process starts fine, the BTX messages appear, the 7-option menu > also appears, but when I hit enter (or when I choose start without ACPI or > start in safe mode) the \ symbols starts spinning for a while and then > freezes. Have you tried an ISO for FreeBSD-CURRENT? I also have a T400, and definitely had FreeBSD running on it for a while, but I don't remember if it was 7 or current. -Ben Kaduk ___ 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"
lenovo t400 does not start 7.1
Hello, I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). The boot process starts fine, the BTX messages appear, the 7-option menu also appears, but when I hit enter (or when I choose start without ACPI or start in safe mode) the \ symbols starts spinning for a while and then freezes. I also tried with the 7.1-amd64-CD1, 7.1-i386-CD1 and a snapshot of 8.0-CURRENT dated from December. And the result is the same for all of them. Does anyone have any idea on what can be happening? Or at least, how can I gather more information about this issue? Thank you. -- _ Empty your memory, with a free()... like a pointer! If you cast a pointer to an integer, it becomes an integer, if you cast a pointer to a struct, it becomes a struct. The pointer can crash..., and can overflow. Be a pointer my friend... ___ 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"
amr driver changes in FreeBSD 7.1-RELEASE
Hello, We have a Dell PowerEdge 1850 server. It contains two PERC4 RAID controllers. One is a PERC4e/Si, and the other is a PERC4/DC. Right now we are running FreeBSD 6.3-RELEASE, with a 36GB RAID-1 on the PERC4e/Si (amr0), and both a 1TB RAID5 and a 136GB RAID1 on the PERC4/DC(amr1). Both adapters are running the latest firmware revision. When we boot FreeBSD7.1 install media, the amr driver fails to detect any volumes (disks) attached to amr0, the PERC4e/Si. However, it picks up the attached disks on the PERC4/DC just fine. However, if I boot 7.0-RELEASE install media, it picks up all of the attached volumes, leading me to believe the issue is due to changes in the amr driver between 7.0 and 7.1. During the 7.1 boot process, before probing disks, we see the message "amr0: adapter is busy" show up twice. This also does not occur on the 6.3, 6.4, or 7.0 releases. We also have another PE1850 with a very similar configuration, except the two PERCs get probed in a different order, and it detects all of the attached volumes without any issues. Any suggestions? These are semi-critical systems, so we aren't always able to test things like this. But, we can schedule downtime once or twice a week if necessary. -Steve Polyack ___ 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: Big problems with 7.1 locking up :-(
On Mon, 2009-01-12 at 21:35 +0100, Tomas Randa wrote: > I have similar problems. The last "good" kernel I have from stable > brach, october the 8. Then in next upgrade, I saw big problems with > performance. > I tried ULE, 4BSD etc, but nothing helps, only downgrading system back. > > Now I am trying 7.1-p1 and problems are here again. Mysql is waiting a > lot of time with status "waiting for opening table" or "waiting for > close tables" > > I have 32bit FreeBSD with PAE, 1x xeon 5420, supermicro motherboard, > areca SATA controller. Could not be problem in "da" device for example? > > Thanks Tomas Randa Could you give r186860 a try? It is an MFC into stable/7 so if the machine in question is something you can experiment with just updating to stable/7 would take care of it. Otherwise if you could just manually apply the patch to a 7.1 source tree and do a test build of the kernel that would also do it. I'm not experiencing lockups but this patch helped a lot on a machine I have with a particular disk I/O pattern that resulted in extremely poor performance with 7.1-RELEASE. This patch brought it back to its normal performance level. Thanks. -- Ken Smith - From there to here, from here to | kensm...@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | signature.asc Description: This is a digitally signed message part
Re: FreeBSD 7.0 kernel panic
On Mon, 2009-01-12 at 21:27 +0300, l1nyx...@googlemail.com wrote:
> Hello, FreeBSD-stable.
>
> Last week I have a lot of kernel panics like:
Firstly: are these new panics on a system that has been reliable until
now, or has something changed on the system recently (hardware change,
different software in use, increased load, etc)? Is there any way you
can reliably reproduce this? And is the panic message and backtrace
always the same?
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 0; apic id = 00
> > fault virtual address = 0x9
> > fault code = supervisor read, page not present
> > instruction pointer = 0x20:0xc079f1af
> > stack pointer = 0x28:0xe5697c80
> > frame pointer = 0x28:0xe5697cbc
> > code segment= base 0x0, limit 0xf, type 0x1b
> > = DPL 0, pres 1, def32 1, gran 1
> > processor eflags= resume, IOPL = 0
> > current process = 14 (swi4: clock)
> > trap number = 12
> > panic: page fault
> > cpuid = 0
> > Uptime: 51m49s
> > Physical memory: 2032 MB
> > Dumping 177 MB: 162 146 130 114 98 82 66 50 34 18 2
> >
> > #0 doadump () at pcpu.h:195
> > 195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
> > (kgdb) bt
> > #0 doadump () at pcpu.h:195
> > #1 0xc078d1b7 in boot (howto=260) at
> > /usr/src/sys/kern/kern_shutdown.c:409
> > #2 0xc078d479 in panic (fmt=Variable "fmt" is not available.
> > ) at /usr/src/sys/kern/kern_shutdown.c:563
> > #3 0xc0a0eaac in trap_fatal (frame=0xe5697c40, eva=9) at
> > /usr/src/sys/i386/i386/trap.c:899
> > #4 0xc0a0f42f in trap (frame=0xe5697c40) at
> > /usr/src/sys/i386/i386/trap.c:280
> > #5 0xc09f565b in calltrap () at
> > /usr/src/sys/i386/i386/exception.s:139
> > #6 0xc079f1af in softclock (dummy=0x0) at
> > /usr/src/sys/kern/kern_timeout.c:202
> > #7 0xc076f31b in ithread_loop (arg=0xc5101250) at
> > /usr/src/sys/kern/kern_intr.c:1036
> > #8 0xc076c119 in fork_exit (callout=0xc076f170 ,
> > arg=0xc5101250, frame=0xe5697d38)
> > at /usr/src/sys/kern/kern_fork.c:781
> > #9 0xc09f56d0 in fork_trampoline () at
> > /usr/src/sys/i386/i386/exception.s:205
> > (kgdb)
>
> What I should do?
In kgdb, enter "frame 6" then "list". The output should show where in
the code this occurred. You can then print any variables that look
interesting by:
p c
p c->ctime
Gavin
___
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: Big problems with 7.1 locking up :-(
On Tue, 13 Jan 2009, Pete French wrote: I can't (fortunately) make it lock up. I have a DL360 G5 which is unused atm. and can test on it if needed. Would it be possible to install that under amd64 and hammer it with DNS requests ? I have been trying to think what the difference might be between my webservers and the machines which are freezing, and the opnly one I an come up with is UDP traffic as the locking machines are serving DNS and also NFS. There are significant changes in UDP locking between 7.0 and 7.1, so it could be that we're looking at a regression there. If you're able to reproduce this reliably, it might well be worth doing a little search-and-replace in udp_usrreq.c along the following lines: INP_RLOCK_ASSERT -> INP_WLOCK_ASSERT INP_RLOCK -> INP_WLOCK INP_RUNLOCK -> INP_WUNLOCK However, before making these changes for debugging purposes, make sure it's 100% reproduceable without them in the configuration so that we don't find ourselves barking up the wrong tree. Normally deadlocks along these lines *do* allow breaking into the debugger from a serial console, but since there are significant changes here in 7.1 it is worth trying to see if this might be related. Robert N M Watson Computer Laboratory University of Cambridge ___ 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: Big problems with 7.1 locking up :-(
I also am experiencing lock-ups on a server recently upgraded from 7.0-RELEASE to 7.1-STABLE. This server is a Supermicro 6022 dual-Xeon box running a GENERIC i386 SMP kernel. Since upgrading to 7.1-STABLE it has started locking up daily. I see similar symptoms that Pete is seeing - no ping response, no keyboard response, no video output on a very lightly loaded server. I have a test machine with duplicate hardware to the one locking up that I just finished installing 7.1-STABLE on but so far it hasn't locked up. Coincidentally my locking machine is also a DNS server but I have not enabled DNS on my test machine yet. Since the locking server is remote to me, I need to downgrade it to 7.0 to get it stable again. Once I finish that process, I can provide remote access to the 7.1-STABLE machine in my office if anyone would like to test with it. ___ 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 7.1 Breaks re and rl Network Interface Drivers
On 2009-01-13 06:02, Pyun YongHyeon wrote: > > I'm also having problems with re's, in my case the interfaces take about > > 10 seconds to come up, if they come up at all. After the interfaces are > > up, half the time no packets go out at all. Usually it helps to bring > > them down via the console, wait about 10 seconds, and then bring them up > > again... > It looks like that RTL8169SC users see regression and I vaguely > remember a couple of issues on RTL8169SC. As Jung-uk said in other > post, would yoy try reverting r180519? Reverting r180519 seems to solve the problem of not being able to send any packets. It does not solve the other problem, which is that the interfaces can take a very long time to come up at boot time, e.g: Setting hostuuid: 3ee65237-8025-11dc-9ab5-003018a6f1a8. Setting hostid: 0xaaedab9a. Mounting local file systems:. Setting hostname: tensor.andric.com. [... pauses for 10 seconds here ...] re0: link state changed to DOWN re1: link state changed to DOWN lo0: flags=8049 metric 0 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 re0: flags=8843 metric 0 mtu 1500 options=389b ether 00:30:18:a6:f1:a8 inet6 fe80::230:18ff:fea6:f1a8%re0 prefixlen 64 tentative scopeid 0x1 inet 87.251.56.140 netmask 0xffc0 broadcast 87.251.56.191 media: Ethernet autoselect (none) status: no carrier re1: flags=8843 metric 0 mtu 1500 options=389b ether 00:30:18:a6:f1:a9 inet6 fe80::230:18ff:fea6:f1a9%re1 prefixlen 64 tentative scopeid 0x2 inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255 media: Ethernet autoselect (none) status: no carrier [...] (note also the "no carrier" just after upping those interfaces) > If that have no effect would > you try attached patch? Apply this patch sometimes speeds up the interfaces going up at boot time, sometimes it doesn't, I'd say about 50/50. It doesn't solve the problem of not being able to send any packets. > > And just FYI, r187080-r187083 that you recently committed (MFCs of > > r184240-184243, r184245, 185575 and r186390), don't seem to change > > anything for this situation. :( > Those MFC are for rl(4), not re(4) so you should see no behavioural > changes in re(4). Sorry about that, I always keep mixing up re(4) and rl(4)... ___ 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: Big problems with 7.1 locking up :-(
> I can't (fortunately) make it lock up. I have a DL360 G5 which is > unused atm. and can test on it if needed. Would it be possible to install that under amd64 and hammer it with DNS requests ? I have been trying to think what the difference might be between my webservers and the machines which are freezing, and the opnly one I an come up with is UDP traffic as the locking machines are serving DNS and also NFS. -pete. ,. ___ 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 7.1 Breaks re and rl Network Interface Drivers
Pyun YongHyeon a écrit : On Mon, Jan 12, 2009 at 05:11:02PM -0500, FreeBSD wrote: > Pyun YongHyeon a ?crit : > >On Sun, Jan 11, 2009 at 07:22:06PM +0300, Eugene Gladchenko wrote: > > > Walter, > > > > > > Thursday, January 8, 2009, 2:50:40 AM, you wrote: > > > > > > WV> Booting kernel.old, which is 7.0-RELEASE-p7 completely alleviates > > all > > > WV> problems. I believe this roundly confirms that this is a bug in the > > > WV> 7.1-RELEASE re kernel drivers. > > > > > > Does kern/130011 look similar? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=130011 > > > >Do you have RTL8168C controller? If not, it's not related with > >Walter's issue as 7.0-RELEASE didn't have a support for RTL8168C. > > > > > > > > The re driver was really broken in 7.1-RC2 and the fix didn't get to > > 7.1-RELEASE. > > > >If you have re(4) issues, please provide more details such as > >dmesg output, way to reproduce the issue etc. > > > > Hi, > > I have the exact same card and the exact same problem as the PR you > mentionned. > > r...@pci0:3:0:0: class=0x02 card=0x02831028 chip=0x816810ec rev=0x02 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > > re0: > Gigabit Ethernet> port 0xd800-0xd8ff mem > 0xfeaff000-0xfeaf,0xfdff-0xfdff irq 18 at device 0.0 on pci3 > re0: Chip rev. 0x3c00 > re0: MAC rev. 0x0040 > re0: PHY write failed > re0: PHY write failed > re0: MII without any phy! > device_attach: re0 attach returned 6 > > I tried to compile a new kernel with the latest version of the 3 files > listed in the PR: > src/sys/dev/re/if_re.c,v 1.147 2008/12/22 00:46:22 yongari > src/sys/pci/if_rl.c,v 1.170.2.10 2009/01/12 04:10:40 yongari > src/sys/pci/if_rlreg.h,v 1.67.2.16 2009/01/12 03:48:25 yongari > You need lastest if_rl.c and if_rlreg.h as well as if_re.c. That's exactly what I tried. Look at the 3 revision of the specified files. I even tried with a if_rl.c from the 22/12/08 but got the same problem. Thanks for your quick reply. > but I get the following error in buildworld: [...] ___ 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 7.1 Breaks re and rl Network Interface Drivers
Jung-uk Kim wrote: On Monday 12 January 2009 12:21 pm, Sascha Holzleiter wrote: Hi, i see similar problems with a re card: r...@pci0:4:7:0:class=0x02 card=0x816710ec chip=0x816710ec rev=0x10 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8169/8110 Family Gigabit Ethernet NIC' class = network subclass = ethernet After upgrading to 7.1-RELEASE (and also STABLE) the NIC doesn't seem to receive any frames. I can see the DHCP Requests on the DHCP Server but the DHCPOFFERS are never seen by the client with the re0 device. After setting promiscious mode on the interface (i.e. by tcpdump -ni re0) the interface begins to work fine. I've attached a complete dmesg output, but i think the detection works fine, here the short version: re0: port 0x9c00-0x9cff mem 0xdfdff000-0xdfdff0ff irq 20 at device 7.0 on pci4 re0: Chip rev. 0x1800 re0: MAC rev. 0x miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:1a:92:35:29:fa re0: [FILTER] Please revert SVN r180519 (or CVS r1.95.2.22) and try again: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/re/if_re.c.diff?r1=1.95.2.21;r2=1.95.2.22 Thanks! This fixed my problem. I now have DHCP and a running network interface again with a 7.1-STABLE and the reverted r180519 changes. If you need to test another version for the changes in r180519 let me know and i'll test them on this machine. Cheers, Sascha ___ 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: Big problems with 7.1 locking up :-(
> Silly question but do you have powerd enabled on that server? If so, > does disabling it help? Also do you have any of these in /etc/rc.conf > (i.e., they are not the same as the default values in > /etc/defaults/rc.conf): > performance_cx_lowest="HIGH"# Online CPU idle state > performance_cpu_freq="NONE" # Online CPU frequency > economy_cx_lowest="HIGH"# Offline CPU idle state > economy_cpu_freq="NONE" # Offline CPU frequency No, none of those. My rc.conf is below. The only slightly unusual thing I am doing is using lagg rather than the interfaces directly I guess, but that has worked fine for ages. -pete. hostname="florentine.rattatosk" cloned_interfaces="lagg0" network_interfaces="lo0 bce0 bce1 lagg0" ifconfig_bce0="up" ifconfig_bce1="up" ifconfig_lagg0="laggproto lacp laggport bce0 laggport bce1" ipv4_addrs_lagg0="10.48.19.0/16 10.48.19.229/16 10.48.19.223/16 10.48.19.243/16 10.48.19.226/16 10 .48.19.224/16 10.48.19.227/16 10.48.19.239/16 10.48.19.225/16 10.48.19.230/16 10.48.19.232/16 10.4 8.19.228/16 10.48.19.235/16 10.48.19.244/16 10.48.19.245/16" defaultrouter="10.48.0.9" inetd_enable="YES" sshd_enable="YES" dhcpd_enable="YES" dhcpd_ifaces="lagg0" dhcpd_flags="-q" dhcpd_conf="/usr/local/etc/dhcpd.conf" dhcpd_withumask="022" nfs_client_enable="YES" nfs_server_enable="YES" portmap_enable="YES" rpcbind_enable="YES" named_enable="YES" pdns_enable="YES" pdns_recursor_enable="NO" mysql_enable="YES" apache22_http_accept_enable="YES" apache22_enable="YES" ntpd_enable="YES" ntpd_sync_on_start="YES" exim_enable="YES" exim_flags="-bd -q10m" sendmail_enable="NONE" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" ___ 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: Big problems with 7.1 locking up :-(
> Can you break into the debugger with Ctrl-Alt-Esc, or by sending a break > over the serial line? No, ctrl-alt-esc doesnt work, and there is no serial line on the machine (not that I can access anyway) -pete. ___ 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: Big problems with 7.1 locking up :-(
On Tue, 13 Jan 2009, Pete French wrote: Features like WITNESS and INVARIANTS may change the timing of the kernel making certain race conditions less likely; I'd run with them for a bit and see if you can reproduce the hang with them present, as they will make debugging the problem a lot easier, if it's possible. Uh, the above *was* me reproducing the hang with them present ;-)) It quite happily hangs with thoise things in the kernel - indeed the next hang was immediately after I rebooted the machine. But even with WITNESS and INVARIANTS and all the rest it does not drop to a debugger, it simply locks up. That machine is currently turned off, but still has 7.1 installed. What would you like me to try now ? I have a lockup I can reproduce pretty reliably now (just wait and it will always lock up). I also found that my other 7.1 box locks up fairly reliably when doing a buildworld. The only similarily between these two machines and the ones which dont lock up is that these are serving DNS. The others don't. Note that all the hardware is identical, as is the installed software and the configuration. If you have BREAK_TO_DEBUGGER compiled into the kernel, then try pressing ctrl-alt-break on the console to see if you can drop into the debugger, or issue a serial break on a serial console. For somewhat complicated reasons to explain, serial breaks are more effective at getting into the debugger, so are preferable -- also because you can more easily log output from the debugger. If you are able to get into the debugger, the normal commands would be most helpful, especially if you can log the results: ps show lockedvnods show alllocks Robert N M Watson Computer Laboratory University of Cambridge ___ 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: fsck_y_enable: suboptimal/odd?
on 13/01/2009 02:34 Andrew Snow said the following: > Andriy Gapon wrote: > >> To me it seems like fsck_y passes suboptimal flags to fsck, it doesn't >> have to examine each and every filesystem in fstab. > > I think think this is because it does a quick check first to see if it > can run the fsck in background after boot into multi-user mode. > > If it cannot, then fsck exits and is re-run with fsck -y and runs in > foreground mode. True, I do not have softupdates enabled and I also have bg fsck explicietely prohibited. Still I do not understand why clean filesystems have to be checked. -- Andriy Gapon ___ 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: Big problems with 7.1 locking up :-(
> It was mentioned previous in this thread that CPUTYPE could be an > issue. Did you change this if you customized your kernel? Actually, I think thats been ruled out as a possible cause, along with the scheduler. Certainly I have tried it both ways and there is no difference, and I think i saw that the others had too. -pete. ___ 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: Big problems with 7.1 locking up :-(
> Lock order reversals are warnings of potential deadlock due to a lock cycle, > but deadlocks may not actually result, either because it's a false positive > (some locking construct that is deadlock free but involves lock cycles), or > because a cycle didn't actually form. The message is suggestive, but if you > have significant system activity after the message, then it may be unrelated. Its hard to tell in this case as there are no timestamps, so I cant see if there is any activity after the lockup. > Features like WITNESS and INVARIANTS may change the timing of the kernel > making certain race conditions less likely; I'd run with them for a bit and > see if you can reproduce the hang with them present, as they will make > debugging the problem a lot easier, if it's possible. Uh, the above *was* me reproducing the hang with them present ;-)) It quite happily hangs with thoise things in the kernel - indeed the next hang was immediately after I rebooted the machine. But even with WITNESS and INVARIANTS and all the rest it does not drop to a debugger, it simply locks up. That machine is currently turned off, but still has 7.1 installed. What would you like me to try now ? I have a lockup I can reproduce pretty reliably now (just wait and it will always lock up). I also found that my other 7.1 box locks up fairly reliably when doing a buildworld. The only similarily between these two machines and the ones which dont lock up is that these are serving DNS. The others don't. Note that all the hardware is identical, as is the installed software and the configuration. I am at a total loss... -pete. ___ 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: Big problems with 7.1 locking up :-(
On Mon, 2009-01-12 at 19:00 +, Pete French wrote: > > I'm not sure if you've done this already, but the normal suggestions apply: > > have you compiled with INVARIANTS/WITNESS/DDB/KDB/BREAK_TO_DEBUGGER, and do > > any results / panics / etc result? Sometimes these debugging tools are > > able > > to convert hangs into panics, which gives us much more ability to debug > > them. > > OK, I have now had a machine hand again, with the correct debug options in > the kernel. The screen looked like this when I went to restart it: > > http://toybox.twisted.org.uk/~pete/71_lor2.png > > It had not, however, dropped into any kind of debugger. Also there appear > to me console messages after the lock order reversal - is that normal ? > > The machine did stay up for a signifanct amount of time before doing this. I > notice that it is more or less identical to the one I posted whenI > had WITNESS_KDB in the kernel too, so maybe those results arent > entirely suprious after all ? > > Given it hasnt dropped to a debugger, is there anything else I can try ? Can you break into the debugger with Ctrl-Alt-Esc, or by sending a break over the serial line? Gavin ___ 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 7.1 Breaks re and rl Network Interface Drivers
On Tue, Jan 13, 2009 at 08:59:41AM +, Oliver Peter wrote: > I'm on 7.1-RELEASE/amd64 with the following card: > > r...@pci0:2:0:0: class=0x02 card=0x368c1462 chip=0x816810ec rev=0x01 > hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > > And luckey me does not experience any network problems at all. > > But I have to say that I was suffering an interrupt storm, and some > smart people told me just to remove USB and Firewire support from the > kernel which has fixed the problem. > Read the following thread and enable MSI feature of re(4). http://lists.freebsd.org/pipermail/freebsd-stable/2008-December/047010.html > Dunno if this helps you. -- Regards, Pyun YongHyeon ___ 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: Big problems with 7.1 locking up :-(
>> Mine never lock up doing buildworlds either. They only lock up when they are
>> sitting there more of less idle! The machines which have never locked up
>> are the webservers, which are fairly heavlt loaded. The machine which locks
>> up the most frequently is a box sitting there doing nothing but DNS, which is
>> the most lightly loaded of the lot.
The server has been idle for a day now and is up and running. I have
then copied a file to generate some i/o and it copies without
problems.
for ((a=0;a<10;a++))
do
cp netbeans-6.5-ml-macosx.dmg ${a}.dmg &
done
I can't (fortunately) make it lock up. I have a DL360 G5 which is
unused atm. and can test on it if needed.
--
regards
Claus
When lenity and cruelty play for a kingdom,
the gentler gamester is the soonest winner.
Shakespeare
___
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 7.1 Breaks re and rl Network Interface Drivers
I'm on 7.1-RELEASE/amd64 with the following card: r...@pci0:2:0:0: class=0x02 card=0x368c1462 chip=0x816810ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet And luckey me does not experience any network problems at all. But I have to say that I was suffering an interrupt storm, and some smart people told me just to remove USB and Firewire support from the kernel which has fixed the problem. Dunno if this helps you. -- Oliver PETER, email: oli...@peter.de.com, ICQ# 113969174 "If it feels good, you're doing something wrong." -- Coach McTavish ___ 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: Big problems with 7.1 locking up :-(
Pete French wrote: > Mine never lock up doing buildworlds either. They only lock up when they are > sitting there more of less idle! The machines which have never locked up > are the webservers, which are fairly heavlt loaded. The machine which locks > up the most frequently is a box sitting there doing nothing but DNS, which is > the most lightly loaded of the lot. Silly question but do you have powerd enabled on that server? If so, does disabling it help? Also do you have any of these in /etc/rc.conf (i.e., they are not the same as the default values in /etc/defaults/rc.conf): performance_cx_lowest="HIGH"# Online CPU idle state performance_cpu_freq="NONE" # Online CPU frequency economy_cx_lowest="HIGH"# Offline CPU idle state economy_cpu_freq="NONE" # Offline CPU frequency Doug -- This .signature sanitized for your protection ___ 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"
