Re: possible regression on i386
If your problem is anything like mine was, buildworld is trying to link with /usr/lib/librt.so rather than the new one built during the buildworld build. As per a recent commit, the new librt will have the additional mq_getfd_np() symbol while the original /usr/lib/librt.so will not. That causes those unresolved reference errors for new code trying to use the mq_getfd_np() function. Try building and installing librt manually: cd /usr/src/lib/librt make && make install Then try buildworld again. Reference: https://svnweb.freebsd.org/base?view=revision&revision=306905 Best regards, Nathan Lay On Sun, Oct 9, 2016 at 4:57 PM, Marek Zarychta < zarych...@plan-b.pwste.edu.pl> wrote: > Dear Developers, > > I really appreciate your work for the project so it makes me really > sorry to complain about the code, but probably commit r306905 breaks > builds on i386 machines. > I have been running 11.0-PRERELEASE on i386 machine for a few days. > Upgrade from 9.3-STABLE through 10.3-STABLE went without an issue last > week. Today I have tried to upgrade this system running on old Xeon > without LM feature to latest version, but buildworld fails (see attached > txt file). It is a quite old machine, where FreeBSD was installed 14 > years ago, but regularly upgraded and always running supported branch. > After reversion to r306777 world builds flawlessly. > > Best regards, > -- > Marek Zarychta > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Your buildworld system is pulling userland libraries/headers
Hello FreeBSD-stable, Here's another example: --- begin snip --- ... /usr/src/usr.bin/nfsstat/nfsstat.c:262:22: error: use of undeclared identifier 'NFSSTATS_V1' ext_nfsstats.vers = NFSSTATS_V1; ^ /usr/src/usr.bin/nfsstat/nfsstat.c:272:27: error: incomplete definition of type 'struct nfsstatsv1' (uintmax_t)ext_nfsstats.rpccnt[NFSPROC_GETATTR], ^ /usr/src/usr.bin/nfsstat/nfsstat.c:107:15: note: forward declaration of 'struct nfsstatsv1' static struct nfsstatsv1 ext_nfsstats; ^ /usr/src/usr.bin/nfsstat/nfsstat.c:273:27: error: incomplete definition of type 'struct nfsstatsv1' (uintmax_t)ext_nfsstats.rpccnt[NFSPROC_SETATTR], ^ /usr/src/usr.bin/nfsstat/nfsstat.c:107:15: note: forward declaration of 'struct nfsstatsv1' static struct nfsstatsv1 ext_nfsstats; ^ /usr/src/usr.bin/nfsstat/nfsstat.c:274:27: error: incomplete definition of type 'struct nfsstatsv1' (uintmax_t)ext_nfsstats.rpccnt[NFSPROC_LOOKUP], ... --- end snip --- Now why is this? Your build system is including userland headers. Look it's correct in /usr/src/sys/fs/nfs/nfsport.h root@RADIO:/usr/src/lib/libprocstat # grep -r NFSSTATS_V1 /usr/src/sys/ /usr/src/sys/fs/nfs/nfsport.h: * The vers field will be set to NFSSTATS_V1 by the caller. /usr/src/sys/fs/nfs/nfsport.h:#define NFSSTATS_V1 1 /usr/src/sys/fs/nfs/nfs_commonport.c: if (error == 0 && nfsstatver.vers != NFSSTATS_V1) ^C But nfsstats is including /usr/include/fs/nfs/nfsports.h. This is poisoning the build. root@RADIO:/usr/src/lib/libprocstat # diff /usr/include/fs/nfs/nfsport.h /usr/src/sys/fs/nfs/nfsport.h | less ... > #define NFSSTATS_V1 1 ... So I'll copy this and build nfsstat myself: cp /usr/src/sys/fs/nfs/nfsport.h /usr/include/fs/nfs/nfsport.h root@RADIO:/usr/src/usr.bin/nfsstat # make clang -O2 -pipe -DNFS -march=nocona -g -MD -MF.depend.nfsstat.o -MTnfsstat.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/usr.bin/nfsstat/nfsstat.c -o nfsstat.o clang -O2 -pipe -DNFS -march=nocona -g -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -o nfsstat.full nfsstat.o -ldevstat objcopy --only-keep-debug nfsstat.full nfsstat.debug objcopy --strip-debug --add-gnu-debuglink=nfsstat.debug nfsstat.full nfsstat gzip -cn /usr/src/usr.bin/nfsstat/nfsstat.1 > nfsstat.1.gz This is very very disturbing. A build system that builds a self-contained operating system should not be pulling in the existing userland's headers and libraries. Best regards, Nathan Lay On Sat, Oct 8, 2016 at 12:26 AM, Nathan Lay wrote: > Hello once again FreeBSD-stable, > While upgrading from FreeBSD 10-STABLE and later updating my FreeBSD > 11-STABLE system, I noticed that your build system is pulling headers and > libraries from the userland rather than the /usr/src tree. This can't > possibly be intended. I kind of figured with recent news of delayed > released you might have realized this. After all, _FOR EXAMPLE_ (may not > reflect reality), who wants to accidentally include userland's older > version of OpenSSL headers and link with userland's older version of > OpenSSL? > > I can cope with this by manually copying headers from /usr/src/sys/sys and > /usr/src/include to their appropriate locations and/or installing the newer > library manually and then restarting the build. But others may not be so > familiar with FreeBSD. And I did manage to get FreeBSD 11-STABLE up and > running just fine eventually. > > But just a few days ago, I updated SVN to rebuild world and kernel > following the news of your delayed release and found libprocstat failing to > compile. And it failed to compile because it was including > /usr/include/ufs/ufs/extattr.h instead of /usr/src/sys/sys/ufs/ufs/extattr.h. > This is
Your buildworld system is pulling userland libraries/headers
Hello once again FreeBSD-stable, While upgrading from FreeBSD 10-STABLE and later updating my FreeBSD 11-STABLE system, I noticed that your build system is pulling headers and libraries from the userland rather than the /usr/src tree. This can't possibly be intended. I kind of figured with recent news of delayed released you might have realized this. After all, _FOR EXAMPLE_ (may not reflect reality), who wants to accidentally include userland's older version of OpenSSL headers and link with userland's older version of OpenSSL? I can cope with this by manually copying headers from /usr/src/sys/sys and /usr/src/include to their appropriate locations and/or installing the newer library manually and then restarting the build. But others may not be so familiar with FreeBSD. And I did manage to get FreeBSD 11-STABLE up and running just fine eventually. But just a few days ago, I updated SVN to rebuild world and kernel following the news of your delayed release and found libprocstat failing to compile. And it failed to compile because it was including /usr/include/ufs/ufs/extattr.h instead of /usr/src/sys/sys/ufs/ufs/extattr.h. This is very disturbing to me. During the FreeBSD 10 updating phase, I saw way more examples of this with even unresolved reference errors during linking since the build system was trying to link with userland's FreeBSD 10 libraries! I can think of two recurring examples: devctl and procstat. I also noticed your build system liked to now put modules in /boot/modules. I was hacking if_ath and none of my changes were working. Well, it was because kldload was loading the unchanged one in /boot/kernel rather than the one now being installed in /boot/modules. That's a really nasty surprise. I probably spent a couple hours figuring that out :) Best regards, Nathan Lay P.S. FreeBSD 11 is running great! Great job! ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8-STABLE ahci fails to attach, does not fallback on ataahci
Alexander Motin wrote:
Nathan Lay wrote:
I gave ATA_CAM a try last night and believe I have a similar setup
(crippled hardware) in my laptop as Doug Barton's, although my
controller is ICH6M. Nonetheless, ahci detects my controller and tries
to attach and fails (returns 6). No ada nodes are created and the boot
process halts trying to find a root mount. Verbose booting reveals
nothing special. Anything else I can do to try to reveal the problem?
I tried modular ATA with the following:
device atacore
device atapci
device ataahci
device ataintel
device ahci
From reading the lists more thoroughly, I now have the impression that
either ahci or ataahci are necessary and not both.
They duplicate each other, but should not conflict.
If I remove 'device
ahci' then 8-STABLE boots normally. However, I would think that if ahci
failed to attach then the kernel should fallback on ataahci. If GENERIC
included both ahci and ataahci, then I would never be able to boot
FreeBSD let alone install it.
There is no fallback mechanism on attach failure in newbus. ataahci will
only be used is ahci fail probe, not an attach.
`uname -a`
FreeBSD LIGHTBULB.LOCAL 8.0-STABLE FreeBSD 8.0-STABLE #4: Thu Dec 24
02:40:23 EST 2009
ns...@lightbulb.local:/usr/obj/usr/src/sys/LIGHTBULB i386
Here's what appears in my dmesg:
atapci0: port
0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0
and the result of `pciconf -lv`
atap...@pci0:0:31:2:class=0x010180 card=0x056a1014 chip=0x26538086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82801FBM (ICH6M) SATA Controller'
class = mass storage
subclass = ATA
There is the answer. ICH6 chipsets are using chip ID convention
different from other ICHs. Same ID used for AHCI and legacy modes. It
was false positive probe. This chip now runs in legacy mode.
This patch should fix the issue:
--- ahci.c.prev 2009-12-08 13:27:31.0 +0200
+++ ahci.c 2009-12-25 09:28:32.0 +0200
@@ -115,8 +115,8 @@ static struct {
{0x43931002, "ATI IXP700", 0},
{0x43941002, "ATI IXP800", 0},
{0x43951002, "ATI IXP800", 0},
- {0x26528086, "Intel ICH6", 0},
- {0x26538086, "Intel ICH6M", 0},
+ {0x26528086, "Intel ICH6", AHCI_Q_NOFORCE},
+ {0x26538086, "Intel ICH6M", AHCI_Q_NOFORCE},
{0x26818086, "Intel ESB2", 0},
{0x26828086, "Intel ESB2", 0},
{0x26838086, "Intel ESB2", 0},
Hi Alexander,
I also noticed in dmesg that ataahci never actually attaches (There's no
AHCI messages). I examined ahci.c and ata-ahci.c and noticed that
ata-ahci.c lacks the quirk table and code in ata_ahci_probe that would
normally match this chip in ahci_probe. I think that it's subclass
isn't PCIS_STORAGE_SATA. I tried to hardcode it to see if it would work
but I never successfully persuaded ataahci to attach. I'm not familiar
with kernel debugging or development and grew weary of constantly
recompiling the kernel to try things.
Best Regards,
Nathan Lay
___
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 ahci fails to attach, does not fallback on ataahci
Hi lists, I gave ATA_CAM a try last night and believe I have a similar setup (crippled hardware) in my laptop as Doug Barton's, although my controller is ICH6M. Nonetheless, ahci detects my controller and tries to attach and fails (returns 6). No ada nodes are created and the boot process halts trying to find a root mount. Verbose booting reveals nothing special. Anything else I can do to try to reveal the problem? I tried modular ATA with the following: device atacore device atapci device ataahci device ataintel device ahci From reading the lists more thoroughly, I now have the impression that either ahci or ataahci are necessary and not both. If I remove 'device ahci' then 8-STABLE boots normally. However, I would think that if ahci failed to attach then the kernel should fallback on ataahci. If GENERIC included both ahci and ataahci, then I would never be able to boot FreeBSD let alone install it. `uname -a` FreeBSD LIGHTBULB.LOCAL 8.0-STABLE FreeBSD 8.0-STABLE #4: Thu Dec 24 02:40:23 EST 2009 ns...@lightbulb.local:/usr/obj/usr/src/sys/LIGHTBULB i386 Here's what appears in my dmesg: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x18c0-0x18cf at device 31.2 on pci0 and the result of `pciconf -lv` atap...@pci0:0:31:2:class=0x010180 card=0x056a1014 chip=0x26538086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801FBM (ICH6M) SATA Controller' class = mass storage subclass = ATA the kernel was built from 8-STABLE tree as of last night. Best Regards, Nathan Lay ___ 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: Very serious cooling issues CURRENT/STABLE
Paul B. Mahol wrote: On 12/21/08, Nathan Lay wrote: Paul B. Mahol wrote: On 12/21/08, Nathan Lay wrote: acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 37.0C hw.acpi.thermal.tz0.active: -1 Is this one ever changed? hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 89.5C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 93.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 This one means that coling will never be used, why: my output looks like this: hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 5 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 600 You can play with all thermal values once you enable: hw.acpi.thermal.user_override But acpi may redo such values again after some time. You only real workaround is to use modified acpi ASL: it is explained in handbook. In my case I fixed in that way bogus kernel message "_CRT value is absurd, ignored". hw.acpi never displayed thermal values for some reason. However, after loading acpi_ibm, I can query those values without a problem dev.acpi_ibm.0.thermal: 49 41 33 48 27 -1 22 -1 I'm not sure the critical temperature (99C) is a problem, but what I have observed is you should never be near it. None of these thinkpads got over 80C under load with FreeBSD installed until recently. ACPI's ASL does not appear to be the problem as it has worked correctly in the past. Until recenty when, can you point into svn revision? If the same overheat happens with acpi disabled that I dont see how freebsd acpi can help you. Ok, I ran portupgrade on both systems with ACPI disabled. I do not experience any overheating issues. The thinkpads also do not feel very hot while building large ports like jdk16 and gcc42 as they do when ACPI is enabled. As I said, the laptops only started recently overheating. The T40 started overheating when CURRENT was installed and the T43 started overheating on a more recent STABLE. I'll try to pinpoint exactly which STABLE build experienced this. Best Regards, Nathan Lay ___ 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: Very serious cooling issues CURRENT/STABLE
Paul B. Mahol wrote: On 12/21/08, Nathan Lay wrote: acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 37.0C hw.acpi.thermal.tz0.active: -1 Is this one ever changed? hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 89.5C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 93.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 This one means that coling will never be used, why: my output looks like this: hw.acpi.thermal.tz0._ACx: 85.0C 75.0C 60.0C 50.0C -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 5 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 600 You can play with all thermal values once you enable: hw.acpi.thermal.user_override But acpi may redo such values again after some time. You only real workaround is to use modified acpi ASL: it is explained in handbook. In my case I fixed in that way bogus kernel message "_CRT value is absurd, ignored". hw.acpi never displayed thermal values for some reason. However, after loading acpi_ibm, I can query those values without a problem dev.acpi_ibm.0.thermal: 49 41 33 48 27 -1 22 -1 I'm not sure the critical temperature (99C) is a problem, but what I have observed is you should never be near it. None of these thinkpads got over 80C under load with FreeBSD installed until recently. ACPI's ASL does not appear to be the problem as it has worked correctly in the past. Best Regards, Nathan Lay ___ 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"
Very serious cooling issues CURRENT/STABLE
Hi list(s) Early in the year I noticed CURRENT failed to cool my frankenstein Thinkpad T40 (built from T40/40p parts) under load. The system would shut down from critically high temperatures while building a port. I did nothing special with ACPI. I thought nothing of it since, after all, I rebuilt a broken T40 from T40p parts. Today, however, I noticed that a very recent STABLE build failed to keep my T43 cool while building ports. It reached temperatures of 97, 98, 99C. It used to reach a max temperature of 80C while building a port (idling temperature is ~ 45C). It behaved normally from 5.3 all the way through 7.0. To remedy both issues, I had to underclock the processor (via dev.cpu) and force the fan to its highest (I'm running 533MHz shy of the processor's full potential, with a fan level of 7 to keep the temperature at ~75C). I've always suspected FreeBSD's ACPI didn't work properly on Thinkpad T series laptops (I have T40, T41, T42 and T43) as it could never fully use the fan (Windows XP can rev the fan far higher than acpi_ibm's level 7). Between STABLE and CURRENT...something seems very wrong. These systems never had cooling issues with FreeBSD before. I attached my dmesg and sysctl for hw.acpi, dev.acpi_ibm, and dev.cpu for both machines. I don't think the latter three pieces of information will be useful but I could be wrong. Let me know if there is any other information I can provide. Best Regards, Nathan Lay hw.acpi.supported_sleep_state: S3 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S3 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.disable_on_reboot: 0 hw.acpi.handle_reboot: 0 hw.acpi.reset_video: 0 hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 76.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 94.5C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 99.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 5 hw.acpi.thermal.tz0._TC2: 4 hw.acpi.thermal.tz0._TSP: 600 hw.acpi.battery.life: 99 hw.acpi.battery.time: -1 hw.acpi.battery.state: 0 hw.acpi.battery.units: 1 hw.acpi.battery.info_expire: 5 hw.acpi.acline: 1 hw.acpi.cpu.cx_lowest: C1 dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 415 dev.acpi_ibm.0.lcd_brightness: 7 dev.acpi_ibm.0.volume: 12 dev.acpi_ibm.0.mute: 1 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4684 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 0 dev.acpi_ibm.0.thermal: 76 51 40 61 35 -1 28 -1 Copyright (c) 1992-2008 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-PRERELEASE #0: Wed Dec 10 04:09:36 EST 2008 ns...@lightbulb.local:/usr/obj/usr/src/sys/LIGHTBULB module_register: module g_journal already exists! Module g_journal failed to register: 17 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.86GHz (1862.14-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d8 Stepping = 8 Features=0xafe9fbff Features2=0x180 AMD Features=0x10 real memory = 1609433088 (1534 MB) avail memory = 1567776768 (1495 MB) This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ kbd1 at kbdmux0 netsmb_dev: loaded ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ACPI Warning (tbfadt-0505): Optional field "Gpe1Block" has zero address or length:0102C/0 [20070320] acpi0: on motherboard acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 5ff0 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 11 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x3000-0x30ff mem 0xc000-0xc7ff,0xb010-0xb010 irq 11 at device 0.0 on pci1 drm0: on vgapci0 info: [drm] Initialized radeon 1.25.0 2006
Re: Kernel panic when kldunload acpi_video
n 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered pcib6: at device 30.0 on pci0 pci20: on pcib6 cbb0: mem 0xc000-0xcfff irq 16 at device 0.0 on pci20 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: mem 0xc0001000-0xc00017ff irq 17 at device 0.1 on pci20 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:06:1b:00:20:22:73:c2 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1164000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:06:1b:22:73:c2 fwe0: Ethernet address: 02:06:1b:22:73:c2 fwip0: on firewire0 fwip0: Firewire address: 00:06:1b:00:20:22:73:c2 @ 0xfffe, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode pci20: at device 0.2 (no driver attached) pci20: at device 0.3 (no driver attached) iwi0: mem 0xc0002000-0xc0002fff irq 21 at device 2.0 on pci20 iwi0: Ethernet address: 00:13:ce:cc:a8:7a iwi0: [ITHREAD] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1880-0x188f at device 31.2 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: port 0x2f8-0x2ff irq 3 drq 3 flags 0x10 on acpi0 sio0: type 16550A sio0: [FILTER] battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cryptosoft0: on motherboard pmtimer0 on isa0 orm0: at iomem 0xc-0xc,0xd1800-0xd27ff,0xdc000-0xd,0xe-0xe pnpid ORM on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 ucom0: on uhub0 ums0: on uhub1 ums0: 3 buttons and Z dir. ugen0: on uhub2 Timecounter "TSC" frequency 1995015224 Hz quality 800 Timecounters tick every 1.250 msec Fast IPsec: Initialized Security Association Processing. firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ad0: 95396MB at ata0-master SATA150 acd0: DVDR at ata1-master UDMA33 pcm0: pcm0: acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present Trying to mount root from ufs:/dev/ad0s1a Loading configuration files. kernel dumps on /dev/ad0s1g Entropy harvesting: interrupts ethernet point_to_point kickstart . swapon: adding /dev/ad0s1b as swap device Starting file system checks: /dev/ad0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1a: clean, 333052 free (1716 frags, 41417 blocks, 0.3% fragmentation) /dev/ad0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1e: clean, 113639 free (135 frags, 14188 blocks, 0.0% fragmentation) /dev/ad0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1f: clean, 11008500 free (180964 frags, 1353442 blocks, 0.4% fragmentation) /dev/ad0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad0s1d: clean, 1056584 free (4576 frags, 131501 blocks, 0.3% fragmentation) Setting hostuuid: f1361401-4750-11cb-9867-96e843b1afff. Setting hostid: 0x71df97f3. Mounting local file systems: . Setting hostname: ayiin..com.au. net.inet6.ip6.auto_linklocal: 1 -> 0 kern.ps_arg_cache_limit: 256 -> 1 hw.acpi.reset_video: 0 -> 1 net.link.tap.user_open: 0 -> 1 net.inet.ip.forwarding: 0 -> 1 kern.ipc.shmmax: 33554432 -> 67108864 kern.ipc.shmall: 8192 -> 32768 dev.acpi_ibm.0.events: 0 -> 1 dev.pcm.0.play.vchans: 1 -> 10 dev.pcm.0.rec.vchans: 1 -> 6 dev.pcm.0.polling: 0 -> 1 debug.cpufreq.lowest: 0 -> 932 hw.pci.do_power_nodriver: 0 -> 3 hw.acpi.cpu.cx_lowest: C1 -> C3 hw.acpi.thermal.user_override: 0 -> 1 hw.acpi.thermal.polling_rate: 10 -> 3 lo0: flags=8049 metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff00 Additional routing options: ignore ICMP redirect=YES log ICMP redirect=YES IP gateway=YES . Starting devd. Starting ums0 moused: . ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled Flushed all rules. ... ___________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL
Re: overheating Thinkpad X60s with 7.0-RC1
-1 again ten minutes more. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4675 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 88 59 -1 86 37 -1 32 -1 Yikes! Can you, please, post results of 'sysctl dev.cpu.0' and this some ten/fifteen minutes before overheat. I find it remarkable that it apparently suddenly goes some almost 40 (!) degrees up. So what is left now is a BIOS update, or? Does http://taint.org/2007/04/23/153737a.html sound doable for anyone? Any other ideas? Well, let's cvsup on the close dates (I do it on the regular basis anyway), take my kernel config, build identical kernels, ditch the X completely, remove systems from docks and away from cooling pads, run something CPU-intensive and compare notes. We can do it off-list and post summary in the case of success. For starters, why don't you send me your output of pciconf -lv and /var/run/dmesg.boot along with /boot/loader.conf and /etc/sysctl.conf. You can add you kernel config for the good measure. Thanks, Johannes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" If you can, use DR-DOS (Caldera's DOS). Not to rag on FreeDOS or anything, but I've had bad experiences with FreeDOS and BIOS updates. http://www.drdosprojects.de/ Best Regards, Nathan Lay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: overheating Thinkpad X60s with 7.0-RC1
Alexandre "Sunny" Kovalenko wrote: On Sun, 2008-01-06 at 20:22 -0500, Nathan Lay wrote: Alexandre "Sunny" Kovalenko wrote: On Sun, 2008-01-06 at 23:58 +0100, Johannes Dieterich wrote: On 1/6/08, Henrik Brix Andersen <[EMAIL PROTECTED]> wrote: On Sun, Jan 06, 2008 at 10:26:48PM +0100, Johannes Dieterich wrote: X and T series of the thinkpads are rather different, even the cores are completely different (I have a dualcore low-voltage version, I assume yours is running on a dual Pentium m, or?). FWIW, I haven't seen any temperature related issues on my ThinkPad X60s, which has been tracking -CURRENT for the last year or so. It too has had the IPW3945 replaced by an Atheros wireless card, but it is still using the original HDD. Can the HDD change already cause such a thing? Besides that: I have not configured anything myself concerning ACPI. Anyone any idea what/where/how to check? I DO think that the fan is working. I can hear it (and it does not sound ill) and it also shows in $ sysctl dev.acpi_ibm dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 1443 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 9 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 0 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 4071 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 62 61 -1 58 43 -1 40 -1 Now not being touched at all for an hour and just idling around. Besides it did work under 6.2 without problems, would be a crazy coincident if right with the update the fan broke. Any idea anyone? :S First -- the disclaimer -- mine is X60 (not X60s), but with 1.83GHz 32-bit CPU, so it should be somewhat similar to yours. At the moment it has USB drivers loaded, which tends to bump CPU utilization and temperature. It has UltraBase attached and is sitting on top of the aluminum passive cooler pad. It was bought originally with the Atheros card and 100GB drive and 1GB of memory was added later to the total of 2GB. System is -CURRENT as of January 5th 18:00 EST. This laptop was tracking -CURRENT pretty close since I have acquired it 15 month ago. It does buildwords with -j5 at least weekly. At the moment, I am writing this E-mail and playing some music, using Amarok. It is on the wired network ATM, but I do not recall any thermal problems while using wireless connection. dev.acpi_ibm.0.%desc: IBM ThinkPad ACPI Extras dev.acpi_ibm.0.%driver: acpi_ibm dev.acpi_ibm.0.%location: handle=\_SB_.PCI0.LPC_.EC__.HKEY dev.acpi_ibm.0.%pnpinfo: _HID=IBM0068 _UID=0 dev.acpi_ibm.0.%parent: acpi0 dev.acpi_ibm.0.initialmask: 2060 dev.acpi_ibm.0.availmask: 16777215 dev.acpi_ibm.0.events: 0 dev.acpi_ibm.0.eventmask: 2060 dev.acpi_ibm.0.hotkey: 133 dev.acpi_ibm.0.lcd_brightness: 0 dev.acpi_ibm.0.volume: 7 dev.acpi_ibm.0.mute: 0 dev.acpi_ibm.0.thinklight: 0 dev.acpi_ibm.0.bluetooth: 1 dev.acpi_ibm.0.wlan: 1 dev.acpi_ibm.0.fan_speed: 2874 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.0.thermal: 62 52 -1 61 39 -1 37 -1 RabbitsDen# sysctl -a | grep temperature hw.acpi.thermal.tz0.temperature: 62.0C hw.acpi.thermal.tz1.temperature: 62.0C dev.cpu.0.temperature: 63 // You need coretemp.ko loaded dev.cpu.1.temperature: 63 // to get these values. RabbitsDen# I does look shade cooler then yours, and fan is running at the lower speed. I will try to list things that I do/have done, and you can compare them to your setup: -- BIOS is updated to the latest level (I do keep XP partition for this specific purpose). -- I run powerd: powerd_enable="YES" powerd_flags="-a adaptive -b adaptive -i 75 -r 65" -- I set hw.pci.do_power_nodriver="3" in /boot/loader.conf -- I run GNOME (please, no religious wars here) -- I set low CPU state to C2 in rc.conf performance_cx_lowest="C2"# Online CPU idle state economy_cx_lowest="C2" # Offline CPU idle state I could not think of anything else related to the temperature, ATM. Thanks, Johannes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" 62C looks awfully high for playing music and writing emails. I have a Thank you very much for pointing this out -- turns out that I was missing cpufreq module -- restoring that to its proper place got me down to: dev.acpi_ibm.0.fan_speed: 2866 dev.acpi_ibm.0.fan_level: 0 dev.acpi_ibm.0.fan: 1 dev.acpi_ibm.
Re: overheating Thinkpad X60s with 7.0-RC1
27; when under load. The fan can certainly work faster (even when booting FreeBSD, its audibly faster)...but 7 is the highest level acpi_ibm allows one to set. Here's my dev.acpi_ibm on a T43 dev.acpi_ibm.0.fan_speed: 4677 dev.acpi_ibm.0.fan_level: 7 dev.acpi_ibm.0.fan: 0 dev.acpi_ibm.0.thermal: 44 42 33 47 33 -1 24 -1 Using dev.acpi_ibm.0.fan=1 yields similar results, but the fan runs quieter. Best Regards, Nathan Lay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X11 extremely slow while compiling other things
Yi Wang wrote: Hi, My box is running 7.0-PREREALEASE. When I run more than two building tasks, X11 became extremely slow. The mouse pointer can also hardly move. Running more than two building tasks under 6-stable does not introduce the issues. Does any one know how to solve it? Hi, I had this problem on 7.0 too, but enabling SCHED_ULE seemed to have fixed this problem. I also disabled 'options SMP' since I have a single processor machine - though I'm not sure if this actually contributed to the problem. Best Regards, Nathan Lay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCHED_4BSD in RELENG_7 disturbs workflow
P.U.Kruppa wrote: On Tue, 16 Oct 2007, Kris Kennaway wrote: [LoN]Kamikaze wrote: I know that RELENG_7 is not considered very near-release, but I thought I'd give my 2ยข in the hope that I might have a little influence on the scheduler development to my benefit. The switch from RELENG_6 to RELENG_7 went relatively smooth and apart from ipw causing panics. However there is one thing that's disturbing and this is the scheduler. I only have single core machines, so whatever I say only applies to those. If you think single-core machines are no longer important, feel free to ignore this. In deed, just ignore me however much you like. From my perspective scheduling on RELENG_6 was way better. Even on a full workload like a portupgrade the focused application (both in X and on the console) always received enough cycles to run smoothly and applications that ran in background like audio players also kept on running fine. Quite the contrary on RELENG_7. During a portupgrade or even worse 'pkgdb -L' (recovering lost dependencies) audio players (both graphical and mplayer) scatter, either because they don't get the hard-disk or CPU-cycles (which one, I don't know) and the focused application also often hangs. It just looks like occasionally (under load) everything freezes for a second and then goes on relatively normal. I've got the impression that things compile a little faster (that might be my imagination, though), but I'd rather have a smooth working experience. This is just my view of the situation and I suppose it is only one of many. I bid you be merciful with us single-core people, who cannot afford a slick multi-core machine, because we worry how to pay for our food at the end of the month. Not to say that any problems that might have developed with SCHED_4BSD should not be fixed, but you should give SCHED_ULE a try since it brings benefits even for single CPU systems (e.g. better interactive response). I would like to second that. I have seen the same problems on my single processor system and using SCHED_ULE instead of SCHED_4BSD seems to improve the situation a lot. Uli. Kris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" Peter Ulrich Kruppa Wuppertal Germany ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" I have this problem too...although I always imagined the cause was WITNESS and various other debug options. Best Regards, Nathan Lay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ural as hostap, slow upload rate
Hi Everyone, I have a very odd problem with ural running as hostap. I recently turned one of my machines into a WiFi AP using an old USB Linksys adapter (ural attaches). port 4 addr 2: high speed, power 300 mA, config 1, Wireless-G USB Network Adapter(0x000d), Cisco-Linksys(0x13b1), rev 0.04 Everything works splendidly except there is one small problem. I noticed that while the Linksys adapter can receive at reasonably high speeds, it cannot send over 100KB/s while running as hostap. I originally thought this was a performance problem with NAT on pf but I observe this limit on the wireless network itself. That is, I can send a file at high speed to the AP, but the AP can only send a file to me at 100KB/s tops. Here is ural's configuration ural0: flags=108843 mtu 2290 inet 172.20.0.1 netmask 0x broadcast 172.20.255.255 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated ssid Lamp channel 9 authmode WPA privacy MIXED deftxkey 2 AES-CCM 2:128-bit AES-CCM 3:128-bit txpowmax 100 bmiss 7 pureg protmode CTS dtimperiod 1 bintval 100 My laptop registers speeds of 54mbps. This is the only thing I could find that briefly mentioned a similar problem: http://lists.freebsd.org/pipermail/freebsd-stable/2005-December/020995.html "> It was triggered when I ran the command "ifconfig ath0 pureg" as an > attempt to switch the D-Link G520 running in hostAP mode, into "g > only" mode. I did this because I've been experiencing slow rates with > Airport Express clients (PowerBook) where no matter what the settings > on the AP are, it refuses to go above 1 Mbit/s." I haven't really had much time to look into it further. Comments are appreciated, I'm not sure whats going on or where to look in src ... I'm in the dark on this one. Best Regards, Nathan Lay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
