Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 02:38:11PM -0800, Pyun YongHyeon wrote: > It seems the PHY has no BRGPHY_MII_AUXSTS register as it does not > seem to manufactured by Broadcom. Adding a special case to > brgphy(4) does not look right. Does ukphy(4) work without problem? > If so I think you can live with ukphy(4). Oh yes, it works like a charm, no worry. -- Pierre Beyssac p...@fasterix.frmug.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: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 08:59:32PM +0200, Alexander Motin wrote: > Except ICH6 Intel uses separate IDs for AHCI and non-AHCI SATA > controller modes. So this flag is not completely correct. But probably > it shoudn't be just removed, as it is checked in other place. I know > about this and going to handle it later. It's not a problem now. I was wondering exactly about that given the wording of the Intel document sent by Jeremy... > > http://www.intel.com/Assets/PDF/specupdate/322170.pdf > Thanks. > PS: Check BIOS settings for enabling AHCI mode. Problem is, I can't find any setting to do that, either it's not there or it's well hidden. The BIOS is up-to-date. Could it be possible for Dell to lock the chip in non-AHCI mode? -- Pierre Beyssac p...@fasterix.frmug.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: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 09:46:55AM -0800, Pyun YongHyeon wrote: > This is not related with your interrupt storm issue but something > is wrong here. I think brgphy(4) should be used for bge(4). Have no > idea why the OUI has a different value. > Would you try attached patch and let me know whether brgphy(4) > get attached to the PHY? It sort of works (see attached dmesg) but not quite correctly, the ethernet link takes an awful lot of time to negotiate (> 10s) and it negotiates 10 Mbps instead of 100 Mbps previously. The message "Unrecognized OUI for PHY!" seems to indicate something's amiss, maybe I should regenerate some file(s) after applying your patches? -- Pierre Beyssac p...@fasterix.frmug.org Copyright (c) 1992-2010 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-STABLE #1: Fri Mar 12 19:02:49 CET 2010 r...@inspiron:/usr/src/sys/amd64/compile/INSP580 amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0x80a2b000. Preloaded elf obj module "/boot/kernel/ehci.ko" at 0x80a2b240. Preloaded elf obj module "/boot/kernel/usb.ko" at 0x80a2b868. Preloaded elf obj module "/boot/kernel/ukbd.ko" at 0x80a2bf10. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2659996160 Hz CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2660.00-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x00a5f000 - 0xbd77, 3167883264 bytes (773409 pages) 0x0001 - 0x00022f12, 5084741632 bytes (1241392 pages) avail memory = 8210993152 (7830 MB) ACPI APIC Table: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf9b00 00024 (v2 ACPIAM) ACPI: XSDT 0xbd780100 0006C (v1 DELLFX0920091130 MSFT 0097) ACPI: FACP 0xbd780290 000F4 (v4 DELL FX09 20091130 MSFT 0097) ACPI: DSDT 0xbd780660 05B02 (v2 1 1000 INTL 20051117) ACPI: FACS 0xbd78e000 00040 ACPI: APIC 0xbd780390 0008C (v2 DELL FX09 20091130 MSFT 0097) ACPI: MCFG 0xbd780420 0003C (v1 DELL OEMMCFG 20091130 MSFT 0097) ACPI: SLIC 0xbd780460 00176 (v1 DELLFX0920091130 MSFT 0097) ACPI: OSFR 0xbd7805e0 00080 (v1 DELL FX09 20091130 MSFT 0097) ACPI: OEMB 0xbd78e040 00072 (v1 DELL FX09 20091130 MSFT 0097) ACPI: HPET 0xbd78a660 00038 (v1 DELL OEMHPET 20091130 MSFT 0097) ACPI: ASF! 0xbd78a6a0 00099 (v32 LEGEND I865PASF 0001 INTL 20051117) ACPI: SSDT 0xbd78f6f0 00363 (v1 DpgPmmCpuPm 0012 INTL 20051117) MADT: Found IO APIC ID 7, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 7 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00060015 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x0001000f pcm: 0x00010400 null: random: VESA: information block 56 45 53 41 00 03 f0 01 00 c0 01 00 00 00 44 00 0010 00 01 00 01 0f 0c 29 01 00 c0 bb 00 00 c0 3a 4d 0020 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 00 00 00 00 00 01 01 01 03 01 05 01 07 01 10 01 0050 11 01 13 01 14 01 16 01 17 01 19 01 1a 01 0d 01 0060 0e 01 20 01 93 01 95 01 96 01 b3 01 b5 01 b6 01 0070 c3 01 c5 01 c6 01 33 01 35 01 36 01 53 01 55 01 0080 56 01 63 01 65 01 66 01 21 01 22 01 23 01 24 01 0090 43 01 45 01 46 01 73 01 75 01 76 01 83 01 85 01 00a0 86 01 d3 01 d5 01 d6 01 e3 01 e5 01 e6 01 ff ff 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00f0 00 00 00 00 00 00 00 00 00 00 00
Re: (fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 09:09:36AM -0800, Jeremy Chadwick wrote:
> > + { 0x3b208086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" },
> > + { 0x3b268086, 0, INTEL_AHCI, 0, ATA_SA300, "PCH" },
> Device ID 0x3b20
> - PCH SATA controller
> - Desktop revision, non-AHCI and non-RAID Mode
> - Ports 0,1,2,3
Great, I was just wondering about the values I put in the fields.
So, thanks, non-AHCI. That explains why adding the same ids to
ahci.c didn't yeld anything interesting :-). And the PCH name is
correct OTOH.
> So I'm not sure the setting of the INTEL_AHCI flag there is correct
> for these controllers. mav@ will need to chime in here.
Probably not, I'll remove it. Thanks.
--
Pierre Beyssac p...@fasterix.frmug.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"
(fixed) Re: 8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
On Fri, Mar 12, 2010 at 05:18:32AM -0800, Jeremy Chadwick wrote: > I'm a little confused by the kernel output. It appears as if you're > using the new SATA-to-CAM layer (ahci.ko) for your SATA disks, rather > than the ataahci.ko layer... but I don't see any indication of AHCI > being available/used on your southbridge chipset. ahci.ko is not compiled in or loaded as a module, however in the course of debugging the problem I added option ATA_CAM, which seems to result in /dev/ada0*. Removing the option to get back to /dev/ad4* doesn't fix the problem. BTW ATA_CAM seems to work fine with generic ATA but not with ataintel. > Possibly this is the source of the problem (specifically, it looks like > FreeBSD doesn't have proper device ID knowledge of what this controller > is. I believe that's because this system is *very* new, a Core i3/i5/i7 > system)? I didn't notice that, you're right! The system is brand new, got it delivered on Tuesday. Another odd thing is that the controllers have differents IDs, 0x3b208086 vs 0x3b268086. I added the IDs to ata-intel.c and it fixes the problem. Preparing a patch. Thanks for the hint! -- Pierre Beyssac p...@fasterix.frmug.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"
8-STABLE interrupt storm on atapci(?), Dell Inspiron 580
Hello, I'm having "interrupt storm detected" messages on a Dell Inspiron 580 running up-to-date 8-STABLE (amd64 arch). The interrupts seem to come from one of the atapci controllers, apparently atapci0 (main controller, with a SATA disk and an ATAPI optical drive). ata_interrupt gets called at a variable rate, between 1000-15 times per second, constantly, even when the disk is not used. >From adding debug sysctl code in ata-all.c:ata_interrupt_locked() I have been able to check that: ch->running is NULL (breaks loop in "do we have a running request") ch->state=0 ch->unit=0 ch->devices=1 (ATA_ATA_MASTER) most of the time. Here's attached dmesg output, pciconf -lv output, kernel configuration and vmstat -i output. A -current kernel exhibits the same behaviour. Any hint/idea how to debug this further would be really appreciated... -- Pierre Beyssac p...@fasterix.frmug.org Copyright (c) 1992-2010 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-STABLE #14: Fri Mar 12 01:37:24 CET 2010 r...@inspiron:/usr/src/sys/amd64/compile/INSP580 amd64 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0x80a2a000. Preloaded elf obj module "/boot/kernel/ehci.ko" at 0x80a2a240. Preloaded elf obj module "/boot/kernel/usb.ko" at 0x80a2a868. Preloaded elf obj module "/boot/kernel/ukbd.ko" at 0x80a2af10. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2660007980 Hz CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2660.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106e5 Stepping = 5 Features=0xbfebfbff Features2=0x98e3fd AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x00a5e000 - 0xbd77, 3167887360 bytes (773410 pages) 0x0001 - 0x00022f12, 5084741632 bytes (1241392 pages) avail memory = 8210997248 (7830 MB) ACPI APIC Table: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 4 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf9b00 00024 (v2 ACPIAM) ACPI: XSDT 0xbd780100 0006C (v1 DELLFX0920091130 MSFT 0097) ACPI: FACP 0xbd780290 000F4 (v4 DELL FX09 20091130 MSFT 0097) ACPI: DSDT 0xbd780660 05B02 (v2 1 1000 INTL 20051117) ACPI: FACS 0xbd78e000 00040 ACPI: APIC 0xbd780390 0008C (v2 DELL FX09 20091130 MSFT 0097) ACPI: MCFG 0xbd780420 0003C (v1 DELL OEMMCFG 20091130 MSFT 0097) ACPI: SLIC 0xbd780460 00176 (v1 DELLFX0920091130 MSFT 0097) ACPI: OSFR 0xbd7805e0 00080 (v1 DELL FX09 20091130 MSFT 0097) ACPI: OEMB 0xbd78e040 00072 (v1 DELL FX09 20091130 MSFT 0097) ACPI: HPET 0xbd78a660 00038 (v1 DELL OEMHPET 20091130 MSFT 0097) ACPI: ASF! 0xbd78a6a0 00099 (v32 LEGEND I865PASF 0001 INTL 20051117) ACPI: SSDT 0xbd78f6f0 00363 (v1 DpgPmmCpuPm 0012 INTL 20051117) MADT: Found IO APIC ID 7, Interrupt 0 at 0xfec0 ioapic0: Changing APIC ID to 7 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x VER: 0x00060015 LDR: 0x DFR: 0x lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff timer: 0x000100ef therm: 0x0001 err: 0x0001000f pcm: 0x00010400 null: random: VESA: information block 56 45 53 41 00 03 f0 01 00 c0 01 00 00 00 44 00 0010 00 01 00 01 0f 0c 29 01 00 c0 bb 00 00 c0 3a 4d 0020 00 c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0040 00 00 00 00 00 01 01 01 03 01 05 01 07 01 10 01 0050 11 01 13 01 14 01 16 01 17 01 19 01 1a 01 0d 01 0060 0e 01 20 01 93 01 95 01 96 01 b3 01 b5 01 b6 01 0070 c3 01 c5 01 c6 01 33 01 35 01 36 01 53 01 55 01 0080 56 01 63 01 65 01 66 01 21 01 22 01 23 01 24 01 0090 43 01 45 01 46 01 73 01 75 01 76 01 83 01 85 01 00a0 86 01 d3 01 d5 01 d6 01 e3 01 e5 01 e6 01 ff ff 00b0 00 00 00 00 00 00 00 00 00 00 00 00 00
RELENG_5: panic: ffs_blkfree: freeing free block
RELENG_5 sources from yesterday. This was after attempting a dump -L (snapshot before dump) on a huge (5TB) gconcat filesystem while scp'ing massive amounts of data to it. The snapshot failed with ETOOLARGE; the system became very sluggish after that then paniced a few minutes later. I'm keeping a copy of the crash dump and debug kernel in case someone wants to know more. #13 0xc05524a0 in ffs_blkfree (fs=0xc990f800, devvp=0xc4aa4840, bno=1, size=16384, inum=1) at ../../../ufs/ffs/ffs_alloc.c:1751 #14 0xc0560913 in indir_trunc (freeblks=0xc83c6700, dbn=5677551840, level=0, lbn=268441612, countp=0xe64ffc3c) at ../../../ufs/ffs/ffs_softdep.c:2628 #15 0xc05608ed in indir_trunc (freeblks=0xc83c6700, dbn=5676799200, level=1, lbn=268437516, countp=0xe64ffc3c) at ../../../ufs/ffs/ffs_softdep.c:2624 #16 0xc05608ed in indir_trunc (freeblks=0xc83c6700, dbn=8097653792, level=2, lbn=4196364, countp=0xe64ffc3c) at ../../../ufs/ffs/ffs_softdep.c:2624 #17 0xc0560474 in handle_workitem_freeblocks (freeblks=0xc83c6700, flags=0) at ../../../ufs/ffs/ffs_softdep.c:2483 #18 0xc055dbf4 in process_worklist_item (matchmnt=0x0, flags=0) at ../../../ufs/ffs/ffs_softdep.c:758 #19 0xc055d984 in softdep_process_worklist (matchmnt=0x0) at ../../../ufs/ffs/ffs_softdep.c:624 #20 0xc04f9fd2 in sched_sync () at ../../../kern/vfs_subr.c:1675 #21 0xc049cb04 in fork_exit (callout=0xc04f9bb8 , arg=0x0, frame=0xe64ffd48) at ../../../kern/kern_fork.c:807 #22 0xc05aa3cc in fork_trampoline () at ../../../i386/i386/exception.s:209 -- A: Yes. Pierre Beyssac [EMAIL PROTECTED] >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting annoying in email? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RELENG_5: Giant not owned in ufs/ffs/ffs_vnops.c:371
Backtrace points to device md (accesses to md were during a make release on that machine). Sorry I don't have anything more detailed, panic didn't provide a dump. Excerpt from kernel stack trace: ffs_read() mdstart_vnode() md_ktrhead() Kernel from 2004-12-28. -- A: Yes. Pierre Beyssac [EMAIL PROTECTED] >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting annoying in email? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_4 installworld broken
On Wed, Aug 01, 2001 at 12:43:23PM +0200, Anders Andersson wrote: > Just cvsup'd and built world, > > make installworld... > > ===> sbin/init > install -c -s -o root -g wheel -m 500 -fschg -b -B.bak init /sbin Install the new "install" by hand, that does it. cd /usr/src/usr.bin/xinstall make install mv /usr/bin/install /usr/bin/install.old mv /usr/bin/xinstall /usr/bin/install Then try installworld again. -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Known MMAP() race conditions ... ?
On Thu, Jul 08, 1999 at 08:20:37AM -0300, The Hermit Hacker wrote: > I'm trying to push moving some Solaris boxes at work over to FreeBSD, > with our INN server being the 'safest' example to move over first, but You'd better try to configure INN without mmap(); this doesn't induce much performance penalty and you avoid any problems with FreeBSD's mmap. Now there are other (and IMHO, better) ways to demonstrate FreeBSD stability on a production server: HTTP, POP/SMTP, DNS,... -- Pierre Beyssac [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
