Re: Updating the tuning man page
Kevin Oberman gmail.com> writes: > > On Mon, Mar 26, 2012 at 8:55 PM, Eitan Adler eitanadler.com> > wrote: > > As some of you may know there is/was an effort to rewrite the tuning > > man page at http://wiki.freebsd.org/SystemTuning . > > Feel free to email me with any questions. > ... > Should tuning include discussion of tuning for power management? Even > server operators are becoming aware of the need for power management > and the only really good information on it is mav's excellent wiki > page. From queries about the subject, most people really don't > understand the concepts and do the wrong thing. Frankly, FreeBSD does > the wrong thing by default, as mav pointed out. I agree. The wiki page at http://wiki.freebsd.org/TuningPowerConsumption could be improved as well. These are my notes - feel free to include them in tuning(7) and wiki. http://wiki.freebsd.org/TuningPowerConsumption POWERD(8), TUNING(7) A processor frequency (ticks per second) determines how much work (instructions processed per second) can be done. CPU-bound (intensive) tasks can run faster with higher CPU frequency. More work done (more tasks per second) causes more switchings in integrated circuits, which consumes more current, which causes more power consumption. Even when no CPU tasks are performed (idle state), higher CPU frequency causes some power consumption. >From the source of power point of view (AC or battery), higher voltage enables higher power supply, but in turn also possible power consumption. In order to reduce power consumption, it is advantageous to modulate CPU frequency and its voltage when: - CPU is idle - when CPU performs tasks (by optimizing based on curve of power consumption) - power supply comes from a battery - increased work load causes increased thermal load and dissipation and loss of energy (increased power consumption) The power management works by modulating CPU frequency and voltage by means of: - CPU states control - P-states (CPU performance states) They are defined by ACPI specs. They determine the ability of a working CPU (under load) to save power consumption and reduce the peak thermal load. To operate at any P-state, the CPU must be in the C0 operational state where the processor is working (under load) and not idling. The number of P-states is processor specific. Both frequency and voltage are scaled as the P-state changes. Higher P-state numbers represent lower frequencies (slower processor speeds). Power consumption is lower at higher P-states. - C-states (operating states) They are defined by ACPI specs. They determine an ability of an idle CPU to turn off unused components to save power. They are idle CPU states, except C0 in which the CPU is active (under load). Higher C-state numbers represent deeper CPU sleep states, at which correspondingly more components shut down to save power. Some components that are shut down include stopping the CPU clock and stopping interrupts. A disadvantage is that deeper sleep states have slower wakeup times. C1 is the default state. NOTE: P-states and C-states are orthogonal (each can vary independently of the other). - thermal control The CPU Frequency Thermal Control, also called throttling, can be implemented via an older external mechanism or via TCC (also called P4TCC). $ sysctl -e dev.cpu dev.cpu.0.%desc=ACPI CPU dev.cpu.0.%driver=cpu dev.cpu.0.%location=handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo=_HID=none _UID=0 dev.cpu.0.%parent=acpi0 dev.cpu.0.freq=300 dev.cpu.0.freq_levels=1867/35000 1633/30625 1600/3 1400/26250 1333/25000 1166/21875 1067/2 933/17500 800/16000 700/14000 600/12000 500/1 400/8000 300/6000 200/4000 100/2000 dev.cpu.0.cx_supported=C1/1 C2/1 C3/17 dev.cpu.0.cx_lowest=C1 dev.cpu.0.cx_usage=100.00% 0.00% 0.00% last 3302us dev.cpu.1.%desc=ACPI CPU dev.cpu.1.%driver=cpu dev.cpu.1.%location=handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo=_HID=none _UID=0 dev.cpu.1.%parent=acpi0 dev.cpu.1.cx_supported=C1/1 C2/1 C3/17 dev.cpu.1.cx_lowest=C1 dev.cpu.1.cx_usage=100.00% 0.00% 0.00% last 2062us $ sysctl -e dev.p4tcc dev.p4tcc.0.%desc=CPU Frequency Thermal Control dev.p4tcc.0.%driver=p4tcc dev.p4tcc.0.%parent=cpu0 dev.p4tcc.0.freq_settings=1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 dev.p4tcc.1.%desc=CPU Frequency Thermal Control dev.p4tcc.1.%driver=p4tcc dev.p4tcc.1.%parent=cpu1 dev.p4tcc.1.freq_settings=1/-1 8750/-1 7500/-1 6250/-1 5000/-1 3750/-1 2500/-1 1250/-1 $ sysctl -a |grep acpi ... Power management with powerd daemon (P-states and C-states): The default mode is adaptive for battery and hiadaptive for other (AC power). $ ps auxww | grep -i powerd root1799 0.0 0.0 9612852 ?? Ss Sat06AM 8:12.95 /usr/sbin/powerd An example of user configuration (not that I need it; be careful of using non-default values as they may b
PostgreSQL server 9.1.3 rejects connections after update: Error connection to the server: FATAL: frontend-protocol 1234.5887 not supported: server supports 1.0 through 3.0
Since the last PostgreSQL port update, server and client are version 9.1.3 and a newly build of the FreeBSD OS (both 9.0-STABLE and 10.0-CURRENT, amd64), clients like pgadmin3 or webinterfaces like those from refdb reject connection to the PostgreSQL server with the error message: Error connection to the server: FATAL: frontend-protocol 1234.5887 not supported: server supports 1.0 through 3.0 All users, execept a local admin and the psql user, are kept in OpenLDAP. It seems, that the LDAP connection got messed up somehow. I tried to recompile everything required by OpenLDAP, PostgreSQL via portmaster -f, since I realized changes in Heimdal on FreeBSD 10.0-CUR and I deleted the old libs via delete-old-libs/files. Does anyone see this problem, too? Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: Updating the tuning man page
On Tue, Mar 27, 2012 at 1:37 AM, Kevin Oberman wrote: > Should tuning include discussion of tuning for power management? Even > server operators are becoming aware of the need for power management > and the only really good information on it is mav's excellent wiki > page. From queries about the subject, most people really don't > understand the concepts and do the wrong thing. Frankly, FreeBSD does > the wrong thing by default, as mav pointed out. Sure - the page could include anything relevant. Please just edit it. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Updating the tuning man page
On Tue, Mar 27, 2012 at 4:57 AM, jb wrote: > Kevin Oberman gmail.com> writes: > >> >> On Mon, Mar 26, 2012 at 8:55 PM, Eitan Adler eitanadler.com> >> wrote: >> > As some of you may know there is/was an effort to rewrite the tuning >> > man page at http://wiki.freebsd.org/SystemTuning . >> > Feel free to email me with any questions. >> ... >> Should tuning include discussion of tuning for power management? Even >> server operators are becoming aware of the need for power management >> and the only really good information on it is mav's excellent wiki >> page. From queries about the subject, most people really don't >> understand the concepts and do the wrong thing. Frankly, FreeBSD does >> the wrong thing by default, as mav pointed out. > > I agree. > The wiki page at > http://wiki.freebsd.org/TuningPowerConsumption > could be improved as well. > > These are my notes - feel free to include them in tuning(7) and wiki. They *will* get lost in this email. The wiki page is set up so that anyone - even anonymous users can edit it. Please add your notes to the page. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On 26 March 2012 23:55, Gary Palmer wrote: > On Mon, Mar 26, 2012 at 08:05:59PM +1030, Matt Thyer wrote: > > On Mar 26, 2012 3:43 AM, "Garrett Cooper" wrote: > > > > > > On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer > wrote: > > > > Has this driver been MFC to 8-STABLE yet ? > > > > > > > > I'm asking because I updated my NAS on the 4th of March from 8-STABLE > > > > r225723 to r232477 and am now seeing 157,000 interrupts per second on > > irq > > > > 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the LSI > > > > SAS2008 chip). > [snip] > > After encountering this problem I updated my firmware from phase 7 to > phase > > 11 but this did not fix things. > > > > My question is: "Is the LSI driver even in 8-STABLE yet?". > > > > If not I'll upgrade to 9-STABLE to get the new driver. > > > > If it is, then I want to downgrade to just before it came in to see if > this > > high interrupt rate problem is fixed. > > I'm no export in svn, however: > > http://svnweb.freebsd.org/base?view=revision&revision=230922 > > would appear to suggest that the new driver is in 8-Stable > > Gary > It's painful to take this system back to r230921 due to intolerance for downtime from it's users so I'd like to investigate the cause of the problem and try patches/sysctls/whatever first. The drives I'm using are 7 x WDC WD20EARS-00M (3 are AB50, 4 are AB51) and 1 x WD20EARX-00P AB51. The WD20EARX-00P AB51 is a SATA 3 (6 Gbps) drive but the others are all SATA 2 (3 Gbps). I know the driver doesn't like mixed speeds in IR mode but I'm flashed with IT firmware as ZFS is doing my RAID (raidz2). I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS until I updated the firmware to 11 and now ZFS is happy (I've also done a full extended drive SMART test and the drive is fine). So what do people suggest (before reversion to r230921) ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PostgreSQL server 9.1.3 rejects connections after update: Error connection to the server: FATAL: frontend-protocol 1234.5887 not supported: server supports 1.0 through 3.0
At 10:54 27/03/2012, you wrote: Since the last PostgreSQL port update, server and client are version 9.1.3 and a newly build of the FreeBSD OS (both 9.0-STABLE and 10.0-CURRENT, amd64), clients like pgadmin3 or webinterfaces like those from refdb reject connection to the PostgreSQL server with the error message: Error connection to the server: FATAL: frontend-protocol 1234.5887 not supported: server supports 1.0 through 3.0 All users, execept a local admin and the psql user, are kept in OpenLDAP. It seems, that the LDAP connection got messed up somehow. I tried to recompile everything required by OpenLDAP, PostgreSQL via portmaster -f, since I realized changes in Heimdal on FreeBSD 10.0-CUR and I deleted the old libs via delete-old-libs/files. Does anyone see this problem, too? No sorry, i use 8.2 for Postgresql server. Have you touched the pg_hba.conf file? Perhaps it has been reinstalled and setted with default values, so pg don't know what a ldap server is. Regards, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2012-03-27 13:03:39 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-27 13:03:39 - starting HEAD tinderbox run for mips/mips TB --- 2012-03-27 13:03:39 - mkdir /tinderbox/HEAD/mips TB --- 2012-03-27 13:03:39 - mkdir /tinderbox/HEAD/mips/mips TB --- 2012-03-27 13:03:39 - cleaning the object tree TB --- 2012-03-27 13:03:39 - cvsupping the source tree TB --- 2012-03-27 13:03:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-03-27 13:09:09 - building world TB --- 2012-03-27 13:09:09 - CROSS_BUILD_TESTING=YES TB --- 2012-03-27 13:09:09 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-27 13:09:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-27 13:09:09 - SRCCONF=/dev/null TB --- 2012-03-27 13:09:09 - TARGET=mips TB --- 2012-03-27 13:09:09 - TARGET_ARCH=mips TB --- 2012-03-27 13:09:09 - TZ=UTC TB --- 2012-03-27 13:09:09 - __MAKE_CONF=/dev/null TB --- 2012-03-27 13:09:09 - cd /src TB --- 2012-03-27 13:09:09 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 27 13:09:10 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 > kfd.8.gz ===> kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mipsel/src/tmp/usr/bin/ld: /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-27 13:54:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-27 13:54:38 - ERROR: failed to build world TB --- 2012-03-27 13:54:38 - 2075.04 user 398.60 system 3058.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Double free() in libc or gdb ?
On Tue, Mar 13, 2012 at 01:40:12PM +0100, Alexandre Martins wrote: > Two other thing > - The process consume memory, but there is no allocation in my code. Maybe a > leak in the libc ? No, this is a leak in rtld. I fixed it in r233546. > - My kernel have crashed after some minute of leak (i have removed printf > for > better perf on the loop). Maybe unrelated, but ... > pgpurZXqIh4Xf.pgp Description: PGP signature
Re: general protection fault panic
On Monday, March 26, 2012 4:45:30 pm Steve Kargl wrote:
> On Mon, Mar 26, 2012 at 04:17:50PM -0400, John Baldwin wrote:
> > On Monday, March 26, 2012 1:59:18 pm Steve Kargl wrote:
> > > On Mon, Mar 26, 2012 at 01:53:25PM -0400, John Baldwin wrote:
> > > > On Monday, March 26, 2012 1:41:55 pm Steve Kargl wrote:
> > > > > On Mon, Mar 26, 2012 at 01:18:37PM -0400, John Baldwin wrote:
> > > > > > On Monday, March 26, 2012 12:21:29 pm Steve Kargl wrote:
> > > > > >
> > > > > > You know your APIC ID is 0, so you should be able to find the IRQ
for vector
> > > > > > 51 from here in apic_idt_to_irq():
> > > > > >
> > > > > > irq = lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS];
> > > > > >
> > > > > > Your apic_id is 0, and APIC_IO_INTS is 48, so you should be able
to do this
> > > > > > in kgdb:
> > > > > >
> > > > > > p lapics[0].la_ioint_irqs[3]
> > > > > >
> > > > > > That should give you an index, and intr_lookup_source() just does
an array
> > > > > > lookup. However, I'd be curious to see what the assembly looks
like
> > > > > > (x/10i $rip at this frame).
> > > > > >
> > > > >
> > > > >
> > > > > (kgdb) p lapics[0].la_ioint_irqs[3]
> > > > > $1 = 16
> > > > > (kgdb) frame 27
> > > > > #27 0x806dc186 in acpi_cpu_c1 ()
> > > > > at /usr/src/sys/amd64/acpica/acpi_machdep.c:97
> > > >
> > > > Sorry, I meant down at the frame that faulted (frame 7 in this case).
> > > >
> > >
> > > (kgdb) frame 7
> > > #7 0x80751232 in lapic_handle_intr (vector=51,
> > > frame=0xff8000229a70) at /usr/src/sys/x86/x86/local_apic.c:777
> > > 777 {
> > > (kgdb) x/10i $rip
> > > 0x80751232 : stos %eax,%es:(%rdi)
> > > 0x80751233 : (bad)
> > > 0x80751234 : pop%rbp
> > > 0x80751235 : pop%rsi
> > > 0x80751236 : fsubr %st(3),%st
> > > 0x80751238 : (bad)
> > > 0x80751239 : or $0xac1ae6b3,%eax
> > > 0x8075123e : out%eax,$0x19
> > > 0x80751240 :
> > > jl 0x8075125e
> > > 0x80751242 : adc
%r12d,0xc6aa671(%rdi)
> >
> > Looks like the instruction pointer is busted. Try doing 'x/10i
lapic_handle_intr'.
> > I suspect you will not see 'lapic_handle_intr+2' as a valid instruction
offset. :(
> >
>
> I'm assuming you want this in frame 7
>
> (kgdb) frame 7
> #7 0x80751232 in lapic_handle_intr (vector=51,
> frame=0xff8000229a70) at /usr/src/sys/x86/x86/local_apic.c:777
> (kgdb) x/10i lapic_handle_intr
> 0x80751230 : sbb$0xa7,%al
> 0x80751232 : stos %eax,%es:(%rdi)
> 0x80751233 : (bad)
> 0x80751234 : pop%rbp
> 0x80751235 : pop%rsi
> 0x80751236 : fsubr %st(3),%st
> 0x80751238 : (bad)
> 0x80751239 : or $0xac1ae6b3,%eax
> 0x8075123e : out%eax,$0x19
> 0x80751240 :
> jl 0x8075125e
Hmmm, odd. In this case the frame doesn't matter (global symbol).
Are you sure you are using the correct kernel.debug file?
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ACPI refcount increasing
On Monday 26 March 2012 12:50 pm, Jung-uk Kim wrote: > On Monday 26 March 2012 01:42 am, Poul-Henning Kamp wrote: > > I tried -current as of approx one day ago and was greeted with a > > kernel printf flooding the screen with something about a ACPI(?) > > mutex(?) refcount increasing. > > > > I were unable to divine any identifying info from the messages > > because the screen scrolled too fast and the message was longer > > than the width of the screen. > > > > I were unable to get a core-dump and had to reset the laptop > > (Lenovo T400s) > > I am well aware of the issue and identified the regression was > introduced in these changes: > > http://svnweb.freebsd.org/base/head/sys/contrib/dev/acpica/componen >ts/namespace/nspredef.c?r1=231844&r2=233250&view=patch > http://svnweb.freebsd.org/base/head/sys/contrib/dev/acpica/componen >ts/namespace/nsrepair.c?r1=231844&r2=233250&view=patch > http://svnweb.freebsd.org/base/head/sys/contrib/dev/acpica/include/ >aclocal.h?r1=229989&r2=233250&view=patch > http://svnweb.freebsd.org/base/head/sys/contrib/dev/acpica/include/ >acnamesp.h?r1=229989&r2=233250&view=patch > > I notified the upstream maintainers and they are working very hard > to correct the issue ATM. I'll update ACPICA as soon as they find > a fix but please revert the changes for now if you are in hurry. FYI, it seems it will take more time than I originally thought. So, I had no choice but to locally revert these changes for now. It is committed as r233555. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Awkward booting issue
Hi, I have been trying to get FreeBSD 9 amd64 to boot on my 1U server but am unsuccesful and am out of ideas. I tried to boot the iso from CD-ROM, I tried multiple USB memory sticks and I even tried to boot from hard discs, I'll explain this further below. Oddly enough every boot attempt fails. Right after the hard discs are recognised the system just sits there, silent, with no errors. The last messages I see tell me that three hard discs are found and the very last message is something like "ada2: previously was known as ad14" and then... nothing happens. Verbose mode tells me nothing extra. So I tried to boot with ACPI disabled but this crashes the kernel and forces a reboot. I tried to disable the USB controller from the bios. I tried to boot from the hard discs in AHCI or IDE mode. I even unplugged everything from the motherboard except the essentials and 2G RAM. And I toggled and changed all BIOS options to no avail. The motherboard is an MSI MS-9656, the variant without IPMI. It has an Intel Q9600 processor. As a workaround I installed a third hard disc, installed Xen onto that with ArchLinux as dom0. Fortunately this does boot. So then I assigned the original two hard discs to the FreeBSD 9 VM. I gave the VM all available memory and three cores, and eth0 is bridged with the FreeBSD VM. After FreeBSD was installed I updated it to 9-STABLE, compiled the kernel (an unmodified GENERIC) and world. It still only boots when it's a virtual machine. If I try to boot the two hard discs (a mirrored zfs root) directly i.e. without Xen I still have exactly the same issues so I do see the bootloader and the first part of the boot process. It just gets stuck after the ada2 message. Here is the lspci output from Linux: # lspci 00:00.0 Host bridge: Intel Corporation 3200/3210 Chipset DRAM Controller (rev 01) 00:01.0 PCI bridge: Intel Corporation 3200/3210 Chipset Host-Primary PCI Express Bridge (rev 01) 00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02) 00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02) 00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02) 00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02) 00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) 00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02) 03:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller 04:02.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics Innovation) Z7/Z9 (XG20 core) 04:03.0 IDE interface: Integrated Technology Express, Inc. IT8213 IDE Controller I hope we can solve this problem so I can use FreeBSD natively. Thanks up front for helping me with this issue. Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Awkward booting issue
On 03/27/12 09:22, Mark wrote: > 03:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet > Controller > 04:02.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics > Innovation) Z7/Z9 (XG20 core) > 04:03.0 IDE interface: Integrated Technology Express, Inc. IT8213 IDE > Controller Can you disable any of these in BIOS? Sometimes last message isn't the cause of the hang, I was having igb issues a while ago that "ended" with ada, but were caused by igb hanging shortly after attach. Disable everything you can to reduce the attachable devices and see if it will still boot. This will help identify which device if any is causing the hang Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On Tue, Mar 27, 2012 at 23:50:31 +1030, Matt Thyer wrote: > On 26 March 2012 23:55, Gary Palmer wrote: > > > On Mon, Mar 26, 2012 at 08:05:59PM +1030, Matt Thyer wrote: > > > On Mar 26, 2012 3:43 AM, "Garrett Cooper" wrote: > > > > > > > > On Sun, Mar 25, 2012 at 5:16 AM, Matt Thyer > > wrote: > > > > > Has this driver been MFC to 8-STABLE yet ? > > > > > > > > > > I'm asking because I updated my NAS on the 4th of March from 8-STABLE > > > > > r225723 to r232477 and am now seeing 157,000 interrupts per second on > > > irq > > > > > 16 where my SuperMicro AOC-USAS2-L8i resides (this card uses the LSI > > > > > SAS2008 chip). > > > > [snip] > > > > > After encountering this problem I updated my firmware from phase 7 to > > phase > > > 11 but this did not fix things. > > > > > > My question is: "Is the LSI driver even in 8-STABLE yet?". > > > > > > If not I'll upgrade to 9-STABLE to get the new driver. > > > > > > If it is, then I want to downgrade to just before it came in to see if > > this > > > high interrupt rate problem is fixed. > > > > I'm no export in svn, however: > > > > http://svnweb.freebsd.org/base?view=revision&revision=230922 > > > > would appear to suggest that the new driver is in 8-Stable > > > > Gary > > > > It's painful to take this system back to r230921 due to intolerance for > downtime from it's users so I'd like to investigate the cause of the > problem and try patches/sysctls/whatever first. > > The drives I'm using are 7 x WDC WD20EARS-00M (3 are AB50, 4 are AB51) and > 1 x WD20EARX-00P AB51. > The WD20EARX-00P AB51 is a SATA 3 (6 Gbps) drive but the others are all > SATA 2 (3 Gbps). > > I know the driver doesn't like mixed speeds in IR mode but I'm flashed with > IT firmware as ZFS is doing my RAID (raidz2). > > I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS > until I updated the firmware to 11 and now ZFS is happy (I've also done a > full extended drive SMART test and the drive is fine). > > So what do people suggest (before reversion to r230921) ? If you're going to prove that it's the new LSI driver, you will probably have to go back to the old driver. You don't have to back out your entire tree, you can just back out the driver itself if you have an SVN tree. You can go into sys/dev/mps and do: svn update -r 230714 And then edit sys/conf/files and comment out these three lines: dev/mps/mps_config.coptional mps dev/mps/mps_mapping.c optional mps dev/mps/mps_sas_lsi.c optional mps Then you should be able to rebuild your kernel with the old driver and see if the problem occurs again. Ken -- Kenneth Merry k...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Awkward booting issue
On Tue, 27 Mar 2012 09:30:30 -0700 matt wrote: > On 03/27/12 09:22, Mark wrote: > > 03:00.0 Ethernet controller: Intel Corporation 82573L Gigabit > > Ethernet Controller 04:02.0 VGA compatible controller: XGI > > Technology Inc. (eXtreme Graphics Innovation) Z7/Z9 (XG20 core) > > 04:03.0 IDE interface: Integrated Technology Express, Inc. IT8213 > > IDE Controller > Can you disable any of these in BIOS? I can disable VGA with a jumper. It was disabled when I tried to boot. I'm not sure if this also disables the device's visibility but jumpering didn't help my problem. I can't disable the IDE interface. There seems to be no such option. > > Sometimes last message isn't the cause of the hang, I was having igb > issues a while ago that "ended" with ada, but were caused by igb > hanging shortly after attach. > > Disable everything you can to reduce the attachable devices and see if > it will still boot. This will help identify which device if any is > causing the hang Yes, I considered this. But even after having disabled everything that's possible in the bios, the boot issue persists... Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On Tue, Mar 27, 2012 at 10:21 AM, Kenneth D. Merry wrote: > On Tue, Mar 27, 2012 at 23:50:31 +1030, Matt Thyer wrote: >> On 26 March 2012 23:55, Gary Palmer wrote: >> >> It's painful to take this system back to r230921 due to intolerance for >> downtime from it's users so I'd like to investigate the cause of the >> problem and try patches/sysctls/whatever first. >> >> The drives I'm using are 7 x WDC WD20EARS-00M (3 are AB50, 4 are AB51) and >> 1 x WD20EARX-00P AB51. >> The WD20EARX-00P AB51 is a SATA 3 (6 Gbps) drive but the others are all >> SATA 2 (3 Gbps). >> >> I know the driver doesn't like mixed speeds in IR mode but I'm flashed with >> IT firmware as ZFS is doing my RAID (raidz2). >> >> I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS >> until I updated the firmware to 11 and now ZFS is happy (I've also done a >> full extended drive SMART test and the drive is fine). >> >> So what do people suggest (before reversion to r230921) ? > > If you're going to prove that it's the new LSI driver, you will probably > have to go back to the old driver. > > You don't have to back out your entire tree, you can just back out the > driver itself if you have an SVN tree. You can go into sys/dev/mps and do: > > svn update -r 230714 > > And then edit sys/conf/files and comment out these three lines: > > dev/mps/mps_config.c optional mps > dev/mps/mps_mapping.c optional mps > dev/mps/mps_sas_lsi.c optional mps > > Then you should be able to rebuild your kernel with the old driver and see > if the problem occurs again. > > Ken > -- > Kenneth Merry > k...@freebsd.org I'm having an issue with the new mps driver myself http://lists.freebsd.org/pipermail/freebsd-scsi/2012-February/005243.html , so I have a patch handy for downgrading also if it helps anyone. It includes the sys/conf/files removals also. http://nitrology.com/mps_downgrade-fbsd8.diff Jason ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: LSI supported mps(4) driver available
On Tue, Mar 27, 2012 at 11:27 AM, Jason Wolfe wrote: > On Tue, Mar 27, 2012 at 10:21 AM, Kenneth D. Merry wrote: >> On Tue, Mar 27, 2012 at 23:50:31 +1030, Matt Thyer wrote: >>> On 26 March 2012 23:55, Gary Palmer wrote: >>> >>> It's painful to take this system back to r230921 due to intolerance for >>> downtime from it's users so I'd like to investigate the cause of the >>> problem and try patches/sysctls/whatever first. >>> >>> The drives I'm using are 7 x WDC WD20EARS-00M (3 are AB50, 4 are AB51) and >>> 1 x WD20EARX-00P AB51. >>> The WD20EARX-00P AB51 is a SATA 3 (6 Gbps) drive but the others are all >>> SATA 2 (3 Gbps). >>> >>> I know the driver doesn't like mixed speeds in IR mode but I'm flashed with >>> IT firmware as ZFS is doing my RAID (raidz2). >>> >>> I was having problems with the WD20EARX-00P AB51 drive being faulted by ZFS >>> until I updated the firmware to 11 and now ZFS is happy (I've also done a >>> full extended drive SMART test and the drive is fine). >>> >>> So what do people suggest (before reversion to r230921) ? >> >> If you're going to prove that it's the new LSI driver, you will probably >> have to go back to the old driver. >> >> You don't have to back out your entire tree, you can just back out the >> driver itself if you have an SVN tree. You can go into sys/dev/mps and do: >> >> svn update -r 230714 >> >> And then edit sys/conf/files and comment out these three lines: >> >> dev/mps/mps_config.c optional mps >> dev/mps/mps_mapping.c optional mps >> dev/mps/mps_sas_lsi.c optional mps >> >> Then you should be able to rebuild your kernel with the old driver and see >> if the problem occurs again. >> >> Ken >> -- >> Kenneth Merry >> k...@freebsd.org > > I'm having an issue with the new mps driver myself > http://lists.freebsd.org/pipermail/freebsd-scsi/2012-February/005243.html > , so I have a patch handy for downgrading also if it helps anyone. It > includes the sys/conf/files removals also. Have you tried upgrading your firmware to phase11 or newer? We saw this issue at iXsystems, but after upgrading to phase11 the first drive "disappearing" issue went away. I have noticed that the driver is noticeably slower at boot on 8.2 and I needed to increase kern.geom.boot_delay to 20 seconds to get booting off FreeNAS-like hardware (uses USB) to work. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on mips/mips
On Tuesday, March 27, 2012 9:54:38 am FreeBSD Tinderbox wrote: > TB --- 2012-03-27 13:03:39 - tinderbox 2.9 running on freebsd- current.sentex.ca > TB --- 2012-03-27 13:03:39 - starting HEAD tinderbox run for mips/mips > TB --- 2012-03-27 13:03:39 - mkdir /tinderbox/HEAD/mips > TB --- 2012-03-27 13:03:39 - mkdir /tinderbox/HEAD/mips/mips > TB --- 2012-03-27 13:03:39 - cleaning the object tree > TB --- 2012-03-27 13:03:39 - cvsupping the source tree > TB --- 2012-03-27 13:03:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile > TB --- 2012-03-27 13:09:09 - building world > TB --- 2012-03-27 13:09:09 - CROSS_BUILD_TESTING=YES > TB --- 2012-03-27 13:09:09 - MAKEOBJDIRPREFIX=/obj > TB --- 2012-03-27 13:09:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2012-03-27 13:09:09 - SRCCONF=/dev/null > TB --- 2012-03-27 13:09:09 - TARGET=mips > TB --- 2012-03-27 13:09:09 - TARGET_ARCH=mips > TB --- 2012-03-27 13:09:09 - TZ=UTC > TB --- 2012-03-27 13:09:09 - __MAKE_CONF=/dev/null > TB --- 2012-03-27 13:09:09 - cd /src > TB --- 2012-03-27 13:09:09 - /usr/bin/make -B buildworld > >>> World build started on Tue Mar 27 13:09:10 UTC 2012 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > [...] > cc -O -pipe -G0 - I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 - I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c > cc -O -pipe -G0 - I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 - I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 - lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a > gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 > kfd.8.gz > ===> kerberos5/libexec/kimpersonate (all) > cc -O -pipe -G0 - I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 - I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 - I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken - I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. - DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c > cc -O -pipe -G0 - I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 - I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 - I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken - I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. - DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 - lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a > /obj/mips.mipsel/src/tmp/usr/bin/ld: /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section > /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized > *** Error code 1 I got this exact error for my own 'make tinderbox' for both mipsel and mipseb worlds yesterday. Anyone have any ideas? Is this some sort of binutils bug? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2012-03-27 21:07:23 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-27 21:07:23 - starting HEAD tinderbox run for mips/mips TB --- 2012-03-27 21:07:23 - cleaning the object tree TB --- 2012-03-27 21:07:58 - cvsupping the source tree TB --- 2012-03-27 21:07:58 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-03-27 21:08:32 - building world TB --- 2012-03-27 21:08:32 - CROSS_BUILD_TESTING=YES TB --- 2012-03-27 21:08:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-27 21:08:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-27 21:08:32 - SRCCONF=/dev/null TB --- 2012-03-27 21:08:32 - TARGET=mips TB --- 2012-03-27 21:08:32 - TARGET_ARCH=mips TB --- 2012-03-27 21:08:32 - TZ=UTC TB --- 2012-03-27 21:08:32 - __MAKE_CONF=/dev/null TB --- 2012-03-27 21:08:32 - cd /src TB --- 2012-03-27 21:08:32 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 27 21:08:33 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 > kfd.8.gz ===> kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mipsel/src/tmp/usr/bin/ld: /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-27 21:56:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-27 21:56:05 - ERROR: failed to build world TB --- 2012-03-27 21:56:05 - 2068.72 user 418.44 system 2921.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[PATCH] ACPI object refcount fix
The upstream maintainer just e-mailed me a possible fix for the
problem and it looks very promising. Please try the attached patch.
Note the patch reverts r233555 and applies the fix. This patch is
also available from here:
http://people.freebsd.org/~jkim/acpi_refcnt.diff
Thanks!
Jung-uk Kim
Index: sys/contrib/dev/acpica/include/aclocal.h
===
--- sys/contrib/dev/acpica/include/aclocal.h(revision 233578)
+++ sys/contrib/dev/acpica/include/aclocal.h(working copy)
@@ -424,6 +424,7 @@ typedef struct acpi_predefined_data
/* Defines for Flags field above */
#define ACPI_OBJECT_REPAIRED1
+#define ACPI_OBJECT_WRAPPED 2
/*
Index: sys/contrib/dev/acpica/include/acnamesp.h
===
--- sys/contrib/dev/acpica/include/acnamesp.h (revision 233578)
+++ sys/contrib/dev/acpica/include/acnamesp.h (working copy)
@@ -368,8 +368,9 @@ AcpiNsRepairObject (
ACPI_OPERAND_OBJECT **ReturnObjectPtr);
ACPI_STATUS
-AcpiNsRepairPackageList (
+AcpiNsWrapWithPackage (
ACPI_PREDEFINED_DATA*Data,
+ACPI_OPERAND_OBJECT *OriginalObject,
ACPI_OPERAND_OBJECT **ObjDescPtr);
ACPI_STATUS
Index: sys/contrib/dev/acpica/components/namespace/nsrepair.c
===
--- sys/contrib/dev/acpica/components/namespace/nsrepair.c (revision
233578)
+++ sys/contrib/dev/acpica/components/namespace/nsrepair.c (working copy)
@@ -74,11 +74,10 @@
* Buffer -> String
* Buffer -> Package of Integers
* Package -> Package of one Package
+ * An incorrect standalone object is wrapped with required outer package
*
* Additional possible repairs:
- *
* Required package elements that are NULL replaced by Integer/String/Buffer
- * Incorrect standalone package wrapped with required outer package
*
**/
@@ -100,12 +99,7 @@ AcpiNsConvertToBuffer (
ACPI_OPERAND_OBJECT *OriginalObject,
ACPI_OPERAND_OBJECT **ReturnObject);
-static ACPI_STATUS
-AcpiNsConvertToPackage (
-ACPI_OPERAND_OBJECT *OriginalObject,
-ACPI_OPERAND_OBJECT **ReturnObject);
-
/***
*
* FUNCTION:AcpiNsRepairObject
@@ -172,10 +166,24 @@ AcpiNsRepairObject (
}
if (ExpectedBtypes & ACPI_RTYPE_PACKAGE)
{
-Status = AcpiNsConvertToPackage (ReturnObject, &NewObject);
+/*
+ * A package is expected. We will wrap the existing object with a
+ * new package object. It is often the case that if a variable-length
+ * package is required, but there is only a single object needed, the
+ * BIOS will return that object instead of wrapping it with a Package
+ * object. Note: after the wrapping, the package will be validated
+ * for correct contents (expected object type or types).
+ */
+Status = AcpiNsWrapWithPackage (Data, ReturnObject, &NewObject);
if (ACPI_SUCCESS (Status))
{
-goto ObjectRepaired;
+/*
+ * The original object just had its reference count
+ * incremented for being inserted into the new package.
+ */
+*ReturnObjectPtr = NewObject; /* New Package object */
+Data->Flags |= ACPI_OBJECT_REPAIRED;
+return (AE_OK);
}
}
@@ -188,24 +196,30 @@ ObjectRepaired:
/* Object was successfully repaired */
-/*
- * If the original object is a package element, we need to:
- * 1. Set the reference count of the new object to match the
- *reference count of the old object.
- * 2. Decrement the reference count of the original object.
- */
if (PackageIndex != ACPI_NOT_PACKAGE_ELEMENT)
{
-NewObject->Common.ReferenceCount =
-ReturnObject->Common.ReferenceCount;
+/*
+ * The original object is a package element. We need to
+ * decrement the reference count of the original object,
+ * for removing it from the package.
+ *
+ * However, if the original object was just wrapped with a
+ * package object as part of the repair, we don't need to
+ * change the reference count.
+ */
+if (!(Data->Flags & ACPI_OBJECT_WRAPPED))
+{
+NewObject->Common.ReferenceCount =
+ReturnObject->Common.ReferenceCount;
-if (ReturnObject->Common.ReferenceCount > 1)
-{
-ReturnObject->Common.ReferenceCount--;
+if (ReturnObject->Common.ReferenceCount > 1)
+{
+ReturnObject->Common.ReferenceCount--;
+}
}
ACPI_DEBUG_PRINT ((ACPI_DB_REPAIR,
-"%s: Converted %s to expected %s at index %u\
Re: [PATCH] ACPI object refcount fix
On 03/27/12 17:13, Jung-uk Kim wrote: The upstream maintainer just e-mailed me a possible fix for the problem and it looks very promising. Please try the attached patch. Note the patch reverts r233555 and applies the fix. This patch is also available from here: http://people.freebsd.org/~jkim/acpi_refcnt.diff Seems to have fixed things nicely on my Thinkpad T61. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] ACPI object refcount fix
On 28.03.12 00:13, Jung-uk Kim wrote: The upstream maintainer just e-mailed me a possible fix for the problem and it looks very promising. Please try the attached patch. Note the patch reverts r233555 and applies the fix. This patch is also available from here: http://people.freebsd.org/~jkim/acpi_refcnt.diff Thanks! Thank you very much, T60 is up and running! Gruss, Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on mips/mips
On 2012-03-27, at 11:14 AM, John Baldwin wrote: > /obj/mips.mipsel/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a >> /obj/mips.mipsel/src/tmp/usr/bin/ld: > /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so symbol number 13 references > nonexistent SHT_SYMTAB_SHNDX section >> /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so: could not read symbols: File > format not recognized >> *** Error code 1 > > I got this exact error for my own 'make tinderbox' for both mipsel and mipseb > worlds yesterday. Anyone have any ideas? Is this some sort of binutils bug? > Yes. It's binutils bug. More details in this thread: http://lists.freebsd.org/pipermail/freebsd-tinderbox/2012-March/009482.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [head tinderbox] failure on mips/mips
On Mar 27, 2012, at 11:14 AM, John Baldwin wrote: > I got this exact error for my own 'make tinderbox' for both mipsel and mipseb > worlds yesterday. Anyone have any ideas? Is this some sort of binutils bug? Hmm, this shouldn't happen on mipsel/mipseb as I've put a workaround in the libkafs5 Makefile. Can you, please, upload the full build log somewhere, or post the part where it links libkafs5? The problem there is that when linking libkafs5 if we link agains libkrb5 we trigger the binutils bug which create the bad symbol. -- ST4096-RIPE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2012-03-28 05:04:34 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-28 05:04:34 - starting HEAD tinderbox run for mips/mips TB --- 2012-03-28 05:04:34 - cleaning the object tree TB --- 2012-03-28 05:05:13 - cvsupping the source tree TB --- 2012-03-28 05:05:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-03-28 05:05:49 - building world TB --- 2012-03-28 05:05:49 - CROSS_BUILD_TESTING=YES TB --- 2012-03-28 05:05:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-28 05:05:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-28 05:05:49 - SRCCONF=/dev/null TB --- 2012-03-28 05:05:49 - TARGET=mips TB --- 2012-03-28 05:05:49 - TARGET_ARCH=mips TB --- 2012-03-28 05:05:49 - TZ=UTC TB --- 2012-03-28 05:05:49 - __MAKE_CONF=/dev/null TB --- 2012-03-28 05:05:49 - cd /src TB --- 2012-03-28 05:05:49 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 28 05:05:50 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -c /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kfd/../../../crypto/heimdal/lib/roken -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kfd/../../include -std=gnu99 -o kfd kfd.o -lkrb5 -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kfd/../../lib/libvers/libvers.a gzip -cn /src/kerberos5/libexec/kfd/../../../crypto/heimdal/appl/kf/kfd.8 > kfd.8.gz ===> kerberos5/libexec/kimpersonate (all) cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -c /src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/kuser/kimpersonate.c cc -O -pipe -G0 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/hx509 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/asn1 -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/roken -I/src/kerberos5/libexec/kimpersonate/../../../crypto/heimdal/lib/sl -I. -DHAVE_CONFIG_H -I/src/kerberos5/libexec/kimpersonate/../../include -std=gnu99 -o kimpersonate kimpersonate.o -lkafs5 -lkrb5 -lheimntlm -lroken -lasn1 -lcrypto -lcrypt /obj/mips.mipsel/src/kerberos5/libexec/kimpersonate/../../lib/libvers/libvers.a /obj/mips.mipsel/src/tmp/usr/bin/ld: /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so symbol number 13 references nonexistent SHT_SYMTAB_SHNDX section /obj/mips.mipsel/src/tmp/usr/lib/libkafs5.so: could not read symbols: File format not recognized *** Error code 1 Stop in /src/kerberos5/libexec/kimpersonate. *** Error code 1 Stop in /src/kerberos5/libexec. *** Error code 1 Stop in /src/kerberos5. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-03-28 05:54:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-03-28 05:54:37 - ERROR: failed to build world TB --- 2012-03-28 05:54:37 - 2107.59 user 427.66 system 3002.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
