lost scroll wheel of Intellimouse Explorer 4.0 on 7.0-STABLE
Hello, Today I updated my desktop PC from FreeBSD 7.0R to 7-STABLE. After that, the scroll wheel of my Intellimouse Explorer 4.0 (USB wired) stopped working. I searched relevant information and found kern/123224 [ums] Scroll wheel breakage w/ USB MS Wireless Intellimouse Explorer 2.0. The symptom is quite similar. ums0: Microsoft Microsoft IntelliMouse Explorer, class 0/0, rev 2.00/4.24, addr 2 on uhub0 ums0: 5 buttons and a TILT dir. Note that there is no Z dir detected. No one care about that? It is hard for me to live without the mouse wheel nowadays I tried another mouse and Z dir was detected properly, so it might be specific to Microsoft products. ums0: Logitech USB-PS/2 Optical Mouse, class 0/0, rev 2.00/11.00, addr 2 on uhub0 ums0: 3 buttons and Z dir. Environment: FreeBSD elvenbow.cc.kyushu-u.ac.jp 7.0-STABLE FreeBSD 7.0-STABLE #0: Mon Aug 11 14:04:03 JST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ELVENBOW amd64 Regards, -- Yoshiaki Kasahara Research Institute for Information Technology, Kyushu University [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ICRC's
* Larry Rosenman ([EMAIL PROTECTED]) wrote: I'm getting the following on a zpool scrub: ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187521229 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187522189 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=109095258 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=101327859 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172911744 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=65393370 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64741875 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=262496999 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 NAMESTATE READ WRITE CKSUM ad8 ONLINE 0 017 Having just experienced NTFS corruption in Windows thanks to a slightly kinked SATA cable (hint: *never* chkdsk/fsck/etc until you're sure the cables are fine), I would *love* to know why this causes a checksum error at ZFS level rather than a read error that any filesystem (or indeed RAID layer) will notice. What's the point in having the connection protected by a CRC if it's just going to let bogus data through anyway? -- Thomas 'Freaky' Hurst http://hur.st/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wireless net Card
Date: Sun, 10 Aug 2008 14:33:54 +1000 From: Warren Liddell [EMAIL PROTECTED] I downloaded the drivers for the chipset my belkin wireless card has, used ndisgen to create the kernel module, which all went aok .. however when trying to load the module it hard hangs the machine to the point of it restarting itself .. is there something i perhaps mybe missing or am i out in the cold in not being able to use this wireless card untill some time a freebsd driver is done ? Which Belkin wireless card do you have? Which arch are you running (i386/amd64)? I had horrific trouble with a Belkin on the Realtek chipset, played up with Ubuntu, FreeBSD, Fedora, even Windows! Trouble with Belkin is, you never know what you're getting. You need the revision number of the card, and then find out which chipset it is. Make sure the drivers you downloaded are for that exact revision. Hope you have more luck than I did, I tossed mine and bought a Ralink. Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wireless net Card
Which Belkin wireless card do you have? Which arch are you running (i386/amd64)? I had horrific trouble with a Belkin on the Realtek chipset, played up with Ubuntu, FreeBSD, Fedora, even Windows! Trouble with Belkin is, you never know what you're getting. You need the revision number of the card, and then find out which chipset it is. Make sure the drivers you downloaded are for that exact revision. Hope you have more luck than I did, I tossed mine and bought a Ralink. Chris AMD64 Arch ironically it worked beautifully for ages in windows, but i got sick of windows having been used to FreeBSD, so i re-installed FreeBSD an using the onboard LAN card atm, but am wanting to goto wireless. [EMAIL PROTECTED]:3:5:0: class=0x02 card=0x700f1799 chip=0x700f1799 rev=0x20 hdr=0x00 vendor = 'Belkin Research and Development Labs' class = network subclass = ethernet Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just over 572kb in size. ironically the 8180 works fine, but naturally wont do my wireless card. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
umtxn and Apache 2.2
Hello, I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 with mpm/worker and threads support, and PHP 5.2.6. Everything works like a charm, but I see that Apache is leaking processes that get stuck in umtxn state. This graph shows it pretty well (I upgraded the system last Friday). Attaching gdb to one of the stray processes and doing a backtrace of the active thread, I see this: [Switching to Thread 0x8705900 (LWP 100647)] 0x382a8789 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382a8789 in _umtx_op () from /lib/libc.so.7 #1 0x3825fe0d in __error () from /lib/libthr.so.3 #2 0x084b2b80 in ?? () #3 0x0005 in ?? () #4 0x in ?? () #5 0x in ?? () #6 0x in ?? () #7 0x38261914 in ?? () from /lib/libthr.so.3 #8 0xbe0e5ca8 in ?? () #9 0x3825b818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) and it seems all the threads in the process are stuck here. Any ideas? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPMI Console: No luck once OS is booted
Daryl Richards [EMAIL PROTECTED] writes: I have a Sun Fire X2200. I can access the LOM no problem once Linux or Solaris is booted. But, once FreeBSD boots, it's no longer accessible from the NIC. Serial still works fine, it's just access via web or ssh. Try setting hw.bge.allow_asf=1 in /boot/loader.conf /Kenneth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtxn and Apache 2.2
Borja Marcos wrote: Hello, I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 with mpm/worker and threads support, and PHP 5.2.6. Everything works like a charm, but I see that Apache is leaking processes that get stuck in umtxn state. This graph shows it pretty well (I upgraded the system last Friday). Attaching gdb to one of the stray processes and doing a backtrace of the active thread, I see this: [Switching to Thread 0x8705900 (LWP 100647)] 0x382a8789 in _umtx_op () from /lib/libc.so.7 (gdb) bt #0 0x382a8789 in _umtx_op () from /lib/libc.so.7 #1 0x3825fe0d in __error () from /lib/libthr.so.3 #2 0x084b2b80 in ?? () #3 0x0005 in ?? () #4 0x in ?? () #5 0x in ?? () #6 0x in ?? () #7 0x38261914 in ?? () from /lib/libthr.so.3 #8 0xbe0e5ca8 in ?? () #9 0x3825b818 in pthread_mutex_getprioceiling () from /lib/libthr.so.3 Previous frame identical to this frame (corrupt stack?) (gdb) and it seems all the threads in the process are stuck here. Any ideas? This trace doesn't show anything really. You need to recompile the binaries with debugging symbols as well. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umtxn and Apache 2.2
On Aug 11, 2008, at 12:31 PM, Kris Kennaway wrote: Borja Marcos wrote: Hello, I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 with mpm/worker and threads support, and PHP 5.2.6. This trace doesn't show anything really. You need to recompile the binaries with debugging symbols as well. Thanks, sorry. I was just wondering if someone heard of a bug on libthr, that's why first I emailed to this list, perhaps the umtxn ringed a bell. I'll recompile and keep investigating. And yes, I'm using 7-STABLE because I prefer to give a try to SCHED_ULE. It's working like a charm with MySQL and Apache, except for this problem. :) Borja. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wireless net Card
On 8/11/08, Warren Liddell [EMAIL PROTECTED] wrote: [EMAIL PROTECTED]:3:5:0: class=0x02 card=0x700f1799 chip=0x700f1799 rev=0x20 hdr=0x00 vendor = 'Belkin Research and Development Labs' class = network subclass = ethernet Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just over 572kb in size. Which Belkin Wireless card is this? (Name/Model) Could you provide a link to the driver you downloaded. When you ran ndisgen to create the kernel module, did you specify the 32bit driver or the 64bit driver? You should be using the 64bit driver on FreeBSD/amd64. When you kldloaded the kernel module, did it indicate any required NDIS functions were missing? Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wireless net Card
Please provide more detailed informatio. Card model, at least, or the output of pciconf -lv supposing that you have a real card, either internal or PCMCIA. If it is a USB model, then use usbdevs -v [EMAIL PROTECTED]:3:5:0: class=0x02 card=0x700f1799 chip=0x700f1799 rev=0x20 hdr=0x00 vendor = 'Belkin Research and Development Labs' class = network subclass = ethernet Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just over 572kb in size. ironically the 8180 works fine, but naturally wont do my wireless card. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wireless net Card
Chipset is RT8185L an i used the ndisgen to create the .ko file, which is just over 572kb in size. Which Belkin Wireless card is this? (Name/Model) No idea what name//Model .. all i know is its Belkin and on the card itself it has RT8185L on the sticker. I dont have any of the original box etc as it was tossed quite some time ago ironically. Could you provide a link to the driver you downloaded. The driver i downloaded was directly from the realtek website and it was the 64bit version. below is the link to the site that has the file i d/l http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=1PFid=1Level=6Conn=5DownTypeID=3GetDown=falseDownloads=true#RTL8185L When you ran ndisgen to create the kernel module, did you specify the 32bit driver or the 64bit driver? You should be using the 64bit driver on FreeBSD/amd64. Only downloaded the 64bit version When you kldloaded the kernel module, did it indicate any required NDIS functions were missing? When i did the kldload i instantly lost all functionality of the computer system untill it rebooted itself. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: should looking at an interface with 'ifconfig' trigger a change ?
Pyun YongHyeon [EMAIL PROTECTED] wrote: Try attached patch and check whether bce(4) correctly reports link state changes. After seeing 'link state changed to UP' message, unplug the cable and see whether it reports link DOWN. The message should be printed in a second. Also try replugging cable and you should see link UP message within several seconds. Since auto-negotation takes more time you may have to wait for a while. I do not have phsyical access to the machine, so I did this using a sutdown of the interface on the sitch - but yes, it works! This fixes the progem with lagg as well - it now fails over to the other interface properly. Such a simple patch - if this has no ill effects then I will deploy it on al our servers,m and hope for it to be committed soon. All new HP servers appear to come with bce interfaces, so this is an importnat fix for us, and probably a lot of other people too. Thanks. -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ICRC's
On Mon, Aug 11, 2008 at 07:58:22AM +0100, Thomas Hurst wrote: * Larry Rosenman ([EMAIL PROTECTED]) wrote: I'm getting the following on a zpool scrub: ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=54817587 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187521229 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=187522189 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=109095258 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=101327859 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=172911744 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=65393370 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=64741875 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=262496999 ad8: WARNING - READ_DMA UDMA ICRC error (retrying request) LBA=154593293 NAMESTATE READ WRITE CKSUM ad8 ONLINE 0 017 Having just experienced NTFS corruption in Windows thanks to a slightly kinked SATA cable (hint: *never* chkdsk/fsck/etc until you're sure the cables are fine), I would *love* to know why this causes a checksum error at ZFS level rather than a read error that any filesystem (or indeed RAID layer) will notice. The ad8 errors you're quoting come from the ATA subsystem in FreeBSD. That is lower-level (e.g. closer to the hardware) than ZFS's checksum method is. If Larry was using UFS, he'd also see the above errors from the kernel. FreeBSD reports the CRC errors reported by the ATA device, ZFS reports the said data as corrupted during scrubbing or standard usage (hence the CKSUM field in 'zpool status'), and ZFS also *repairs* the corrupted data. I can't explain how the repair works, but it's one of the many features of the filesystem. I believe journalling filesystems (e.g. ext3fs and gjournal) have this ability, while Standard UFS, UFS2, NTFS, FAT, and many others do not. What's the point in having the connection protected by a CRC if it's just going to let bogus data through anyway? A CRC (or checksum) acts as a method of differential detection, e.g. detect corruption between X and Y. CRCs are not the same thing as error correction or retransmittal; they only result in reporting data corruption, and cannot repair it. http://en.wikipedia.org/wiki/Cyclic_redundancy_check -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: OK, I just got access to a machine, am going to install and see if I can repro this this afternoon. Jack For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 and neither install has this problem. I can cold boot it with the NIC unplugged, plug in a cable, I get a link light and ifconfig em0 goes to active, dhclient em0 gets an IP successfully. -- Thanks, Josh Paetzel PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB signature.asc Description: This is a digitally signed message part.
Re: em(4) on FreeBSD is sometimes annoying
On Mon, Aug 11, 2008 at 08:19:46AM +, Josh Paetzel wrote: On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: OK, I just got access to a machine, am going to install and see if I can repro this this afternoon. Jack For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 and neither install has this problem. I can cold boot it with the NIC unplugged, plug in a cable, I get a link light and ifconfig em0 goes to active, dhclient em0 gets an IP successfully. As promised, I tested said issue out on my T60p (widescreen) tonight, using both FreeBSD 7.0-STABLE and 7.0-RELEASE. I wasn't able to reproduce the issue; so my experience was the same as Josh. I can also boot it with the CAT5 inserted, dhclient fetch an IP, no LED oddities -- then yank the cable (LED and link light go off), re-insert the cable, and within a moment or so dhclient again gets an IP. I'm left wondering if maybe there's an EEPROM setting that's doing this (purely speculative on my part), or possibly some odd BIOS quirk. My T60p (widescreen) is running BIOS 1.14. It's worth noting that the non-widescreen T60p uses a different BIOS. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with /boot/loader [A new patch]
On Sunday 10 August 2008 02:27:26 am Eugene Grosbein wrote: On Sat, Aug 09, 2008 at 05:17:31PM -0400, John Baldwin wrote: In addition to my earlier message, it would probably be good to narrow down what breaks the loader for you. For example, does it work ok over serial and only break on vidconsole? Also, if you just backout sys/boot/i386/btx to 7.0-release and leave the rest of the sys/boot tree at 7.0-stable, do you get a working loader? I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got working loader! Err, my patch should have failed (well, the btx.S part) if you had a 7.0-RELEASE sys/boot/i386/btx. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.)
2008/8/11 John Baldwin [EMAIL PROTECTED]:
On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote:
Hi John,
I now figured out the who, the why still eludes me.
So, after your MFC of ichss.c on June 27th the device now attaches at my
laptop. It didn't before, so it could cause no trouble.
With ichss loaded, the kernel will panic 1-3 minutes after powerd has
been started (if I kill powerd early enough, it seems pretty stable).
I'm now running a kernel from 2008-08-08 with
hint.ichss.0.disabled=1
Ok. Can you get a crashdump from a crash?
ehm,. I am not Ulrich Spoerlein, but I can help with this issue.
my crashdump from kgdb and some debug info.
(ouch, I forgot to include it in my prev. mail
http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html )
wbr,
pluknet
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc056cf46
stack pointer = 0x28:0xe6592ac8
frame pointer = 0x28:0xe6592ac8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2507 (powerd)
Physical memory: 1014 MB
Dumping 120 MB: 105 89 73 57 41 25 9
#0 doadump () at pcpu.h:195
195 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0,
dummy4=0xe6592860 0╛йц) at /media/src-7/sys/ddb/db_command.c:516
#2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0, dopager=1)
at /media/src-7/sys/ddb/db_command.c:413
#3 0xc0459655 in db_command_loop () at /media/src-7/sys/ddb/db_command.c:466
#4 0xc045b17c in db_trap (type=12, code=0)
at /media/src-7/sys/ddb/db_main.c:228
#5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88)
at /media/src-7/sys/kern/subr_kdb.c:524
#6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56)
at /media/src-7/sys/i386/i386/trap.c:890
#7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56)
at /media/src-7/sys/i386/i386/trap.c:812
#8 0xc0746d36 in trap (frame=0xe6592a88)
at /media/src-7/sys/i386/i386/trap.c:490
#9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:139
#10 0xc056cf46 in device_is_attached (dev=0x0)
at /media/src-7/sys/kern/subr_bus.c:2228
#11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4,
priority=100) at /media/src-7/sys/kern/kern_cpu.c:332
#12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00,
arg2=0, req=0xe6592ba4) at cpufreq_if.h:32
---Type return to continue, or q return to quit---
#13 0xc0554b67 in sysctl_root (oidp=Variable oidp is not available.
)
at /media/src-7/sys/kern/kern_sysctl.c:1306
#14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14, namelen=4,
old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4,
retval=0xe6592c10, flags=0) at /media/src-7/sys/kern/kern_sysctl.c:1401
#15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc)
at /media/src-7/sys/kern/kern_sysctl.c:1336
#16 0xc07466d5 in syscall (frame=0xe6592d38)
at /media/src-7/sys/i386/i386/trap.c:1035
#17 0xc072fdb0 in Xint0x80_syscall ()
at /media/src-7/sys/i386/i386/exception.s:196
#18 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) f 11
#11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4,
priority=100) at /media/src-7/sys/kern/kern_cpu.c:332
332 if (!device_is_attached(set-dev)) {
(kgdb) list
327 }
328
329 /* Next, set any/all relative frequencies via their drivers. */
330 for (i = 0; i level-rel_count; i++) {
331 set = level-rel_set[i];
332 if (!device_is_attached(set-dev)) {
333 error = ENXIO;
334 goto out;
335 }
336
(kgdb) p level.rel_count
$1 = 1986356271
(kgdb) p i
$2 = 0
(kgdb) p level.rel_set
$3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0,
0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0,
0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0,
0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {
0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0,
spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0,
dev = 0x656e7552, spec = {828858701, 1162760014, 0, 134632492}}, {
freq = 0, volts = 53, power = -1024, lat = -1, dev = 0x7fff, spec = {
- and so on-
Also there are very unusual (and high) numbers in sysctl dev.cpu.0.freq_levels.
___
freebsd-stable@freebsd.org mailing list
Re: em(4) on FreeBSD is sometimes annoying
On Mon, Aug 11, 2008 at 7:02 AM, Jeremy Chadwick [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 08:19:46AM +, Josh Paetzel wrote: On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: OK, I just got access to a machine, am going to install and see if I can repro this this afternoon. Jack For what it's worth, I have a T60 that dual boots 6.3-R/amd64 and 7.0-R/i386 and neither install has this problem. I can cold boot it with the NIC unplugged, plug in a cable, I get a link light and ifconfig em0 goes to active, dhclient em0 gets an IP successfully. As promised, I tested said issue out on my T60p (widescreen) tonight, using both FreeBSD 7.0-STABLE and 7.0-RELEASE. I wasn't able to reproduce the issue; so my experience was the same as Josh. I can also boot it with the CAT5 inserted, dhclient fetch an IP, no LED oddities -- then yank the cable (LED and link light go off), re-insert the cable, and within a moment or so dhclient again gets an IP. I'm left wondering if maybe there's an EEPROM setting that's doing this (purely speculative on my part), or possibly some odd BIOS quirk. My T60p (widescreen) is running BIOS 1.14. It's worth noting that the non-widescreen T60p uses a different BIOS. Cool, it turned out that the laptop I was told I could use was an X61 and it had an ICH8 NIC rather than 82573 anyway, they were supposed to get me one today but given the two of you have already gone thru this verification I see little point in doing the same. Seems possibly a BIOS thing, if not that bad cable, bad link partner maybe?? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with /boot/loader [A new patch]
On Mon, Aug 11, 2008 at 11:31:33AM -0400, John Baldwin wrote: I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got working loader! Err, my patch should have failed (well, the btx.S part) if you had a 7.0-RELEASE sys/boot/i386/btx. I've applied patch first, then replaced sys/boot/i386/btx with 7.0-RELEASE version. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.)
On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote: Hi John, I now figured out the who, the why still eludes me. So, after your MFC of ichss.c on June 27th the device now attaches at my laptop. It didn't before, so it could cause no trouble. With ichss loaded, the kernel will panic 1-3 minutes after powerd has been started (if I kill powerd early enough, it seems pretty stable). I'm now running a kernel from 2008-08-08 with hint.ichss.0.disabled=1 Ok. Can you get a crashdump from a crash? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
-stable tar complie broken?
On a box cvsupped today, I get: [EMAIL PROTECTED]:/usr/src/usr.bin/tar sudo make clean depend all rm -f bsdtar bsdtar.o getdate.o matching.o read.o siginfo.o subst.o tree.o util.o write.o bsdtar.1.gz bsdtar.1.cat.gz getdate.c getdate.h yacc -d -o getdate.c /usr/src/usr.bin/tar/getdate.y yacc: 8 shift/reduce conflicts rm -f .depend mkdep -f .depend -a-DBSDTAR_VERSION_STRING=\2.5.5\ -DPLATFORM_CONFIG_H=\config_freebsd.h\ -I/usr/src/usr.bin/tar /usr/src/usr.bin/tar/bsdtar.c getdate.c /usr/src/usr.bin/tar/matching.c /usr/src/usr.bin/tar/read.c /usr/src/usr.bin/tar/siginfo.c /usr/src/usr.bin/tar/subst.c /usr/src/usr.bin/tar/tree.c /usr/src/usr.bin/tar/util.c /usr/src/usr.bin/tar/write.c echo bsdtar: /usr/lib/libc.a /usr/lib/libarchive.a /usr/lib/libbz2.a /usr/lib/libz.a .depend cc -O2 -fno-strict-aliasing -pipe -march=pentium3 -DBSDTAR_VERSION_STRING=\2.5.5\ -DPLATFORM_CONFIG_H=\config_freebsd.h\ -I/usr/src/usr.bin/tar -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-pointer-sign -c /usr/src/usr.bin/tar/bsdtar.c /usr/src/usr.bin/tar/bsdtar.c: In function 'main': /usr/src/usr.bin/tar/bsdtar.c:508: error: 'ARCHIVE_EXTRACT_SPARSE' undeclared (first use in this function) /usr/src/usr.bin/tar/bsdtar.c:508: error: (Each undeclared identifier is reported only once /usr/src/usr.bin/tar/bsdtar.c:508: error: for each function it appears in.) *** Error code 1 Michael ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
Jack Vogel wrote: Seems possibly a BIOS thing, if not that bad cable, bad link partner maybe?? I had the problem with all sorts of switches / cables. How can I dump my EEPROM settings if that helps? -- Markus ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em(4) on FreeBSD is sometimes annoying
On Mon, Aug 11, 2008 at 1:32 PM, Markus Vervier [EMAIL PROTECTED] wrote: Jack Vogel wrote: Seems possibly a BIOS thing, if not that bad cable, bad link partner maybe?? I had the problem with all sorts of switches / cables. How can I dump my EEPROM settings if that helps? I didn't mean the NIC EEPROM, but the system BIOS, make sure you are running the version that Jeremy said he was, if that matches you might go look at settings in the BIOS that are about management. I thought you told us that when you had a back to back connection that it worked, no?? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cpufreq(4) panic on RELENG_7 (was: Re: Call for bfe(4) testers.)
On Monday 11 August 2008 12:35:17 pm pluknet wrote:
2008/8/11 John Baldwin [EMAIL PROTECTED]:
On Saturday 09 August 2008 07:16:37 am Ulrich Spoerlein wrote:
Hi John,
I now figured out the who, the why still eludes me.
So, after your MFC of ichss.c on June 27th the device now attaches at my
laptop. It didn't before, so it could cause no trouble.
With ichss loaded, the kernel will panic 1-3 minutes after powerd has
been started (if I kill powerd early enough, it seems pretty stable).
I'm now running a kernel from 2008-08-08 with
hint.ichss.0.disabled=1
Ok. Can you get a crashdump from a crash?
ehm,. I am not Ulrich Spoerlein, but I can help with this issue.
my crashdump from kgdb and some debug info.
(ouch, I forgot to include it in my prev. mail
http://lists.freebsd.org/pipermail/freebsd-stable/2008-August/044182.html )
wbr,
pluknet
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc056cf46
stack pointer = 0x28:0xe6592ac8
frame pointer = 0x28:0xe6592ac8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2507 (powerd)
Physical memory: 1014 MB
Dumping 120 MB: 105 89 73 57 41 25 9
#0 doadump () at pcpu.h:195
195 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc0458f89 in db_fncall (dummy1=-1010027648, dummy2=0, dummy3=0,
dummy4=0xe6592860 0╛йц) at /media/src-7/sys/ddb/db_command.c:516
#2 0xc045953a in db_command (last_cmdp=0xc07dcf14, cmd_table=0x0,
dopager=1)
at /media/src-7/sys/ddb/db_command.c:413
#3 0xc0459655 in db_command_loop ()
at /media/src-7/sys/ddb/db_command.c:466
#4 0xc045b17c in db_trap (type=12, code=0)
at /media/src-7/sys/ddb/db_main.c:228
#5 0xc0575023 in kdb_trap (type=12, code=0, tf=0xe6592a88)
at /media/src-7/sys/kern/subr_kdb.c:524
#6 0xc07460bf in trap_fatal (frame=0xe6592a88, eva=56)
at /media/src-7/sys/i386/i386/trap.c:890
#7 0xc074636b in trap_pfault (frame=0xe6592a88, usermode=0, eva=56)
at /media/src-7/sys/i386/i386/trap.c:812
#8 0xc0746d36 in trap (frame=0xe6592a88)
at /media/src-7/sys/i386/i386/trap.c:490
#9 0xc072fd4b in calltrap () at /media/src-7/sys/i386/i386/exception.s:139
#10 0xc056cf46 in device_is_attached (dev=0x0)
at /media/src-7/sys/kern/subr_bus.c:2228
#11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4,
priority=100) at /media/src-7/sys/kern/kern_cpu.c:332
#12 0xc0511452 in cpufreq_curr_sysctl (oidp=0xc3c8bac0, arg1=0xc3bc7c00,
arg2=0, req=0xe6592ba4) at cpufreq_if.h:32
---Type return to continue, or q return to quit---
#13 0xc0554b67 in sysctl_root (oidp=Variable oidp is not available.
)
at /media/src-7/sys/kern/kern_sysctl.c:1306
#14 0xc0554cd1 in userland_sysctl (td=0xc4245440, name=0xe6592c14,
namelen=4,
old=0x0, oldlenp=0x0, inkernel=0, new=0xbfbfe7c4, newlen=4,
retval=0xe6592c10, flags=0) at /media/src-7/sys/kern/kern_sysctl.c:1401
#15 0xc0555a7c in __sysctl (td=0xc4245440, uap=0xe6592cfc)
at /media/src-7/sys/kern/kern_sysctl.c:1336
#16 0xc07466d5 in syscall (frame=0xe6592d38)
at /media/src-7/sys/i386/i386/trap.c:1035
#17 0xc072fdb0 in Xint0x80_syscall ()
at /media/src-7/sys/i386/i386/exception.s:196
#18 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) f 11
#11 0xc0512de7 in cf_set_method (dev=0xc3c9c880, level=0xc4525ef4,
priority=100) at /media/src-7/sys/kern/kern_cpu.c:332
332 if (!device_is_attached(set-dev)) {
(kgdb) list
327 }
328
329 /* Next, set any/all relative frequencies via their drivers.
*/
330 for (i = 0; i level-rel_count; i++) {
331 set = level-rel_set[i];
332 if (!device_is_attached(set-dev)) {
333 error = ENXIO;
334 goto out;
335 }
336
(kgdb) p level.rel_count
$1 = 1986356271
(kgdb) p i
$2 = 0
(kgdb) p level.rel_set
$3 = {{freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0, 0, 0,
0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec = {0,
0,
0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec =
{0,
0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0, spec =
{
0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0, dev = 0x0,
spec = {0, 0, 0, 0}}, {freq = 0, volts = 0, power = 0, lat = 0,
dev = 0x656e7552, spec = {828858701, 1162760014, 0, 134632492}}, {
freq = 0, volts = 53, power = -1024, lat = -1, dev = 0x7fff, spec =
{
- and so
Re: Problem with /boot/loader [A new patch]
On Monday 11 August 2008 01:06:23 pm Eugene Grosbein wrote: On Mon, Aug 11, 2008 at 11:31:33AM -0400, John Baldwin wrote: I've just rolled sys/boot/i386/btx back to RELENG_7_0_0_RELEASE leaving rest of src at 7.0-STABLE (plus your patch) and yes, I've got working loader! Err, my patch should have failed (well, the btx.S part) if you had a 7.0-RELEASE sys/boot/i386/btx. I've applied patch first, then replaced sys/boot/i386/btx with 7.0-RELEASE version. Ok, I'm at a loss for why the new BTX doesn't work for you. Unfortunately, this sort of thing isn't easy to debug. If you have firewire (and another machine with firewire) then I have some debugging code I used with qemu to save a summary of the last request made by the loader to BTX. That can at least indicate which BIOS call is hanging. From there you can dissassemble your BIOS to try to determine if there are any spin loops and see what it is waiting on. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic
On Sunday 10 August 2008 10:01:49 pm Johan Kuuse wrote:
Hi,
I am a kgdb newbie, so please be patient.
I suspect (just based on the fact that this is the 4th time I edit text
files on my NTFS partition through ntfs-3g, using Emacs, and getting frequent
I/O error messages inside Emacs, and then a kernel panic) that this is a
ntfs-3g related problem.
If you ask me exactly how to reproduce it, I sorry, I can tell you exactly
(but see the kgdb output below).
Anyway, the kernel seems to panic at /usr/src/sys/kern/vfs_bio.c:1530
Just a suggestion for a patch (without knowing the functionality
of /usr/src/sys/kern/vfs_bio.c):
The line where the kernel panics:
/usr/src/sys/kern/vfs_bio.c:
--
VM_OBJECT_LOCK(bp-b_bufobj-bo_object);
...
--
Comparing to another file, which does error checking before calling
VM_OBJECT_LOCK:
/usr/src/sys/kern/vfs_aio.c:
--
if (vp-v_object != NULL) {
VM_OBJECT_LOCK(vp-v_object);
...
--
Perhaps the kernel panic could be avoided with the following patch?
/usr/src/sys/kern/vfs_bio.c (suggested patch):
--
if ((bp-b_bufobj != NULL) (bp-b_bufobj-bo_object != NULL)) {
VM_OBJECT_LOCK(bp-b_bufobj-bo_object);
...
--
Please let me know if you need more information.
Regards,
Johan Kuuse
---
kgdb kernel.debug /var/crash/vmcore.1
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x34
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc07b6de4
stack pointer = 0x28:0xe79de7c8
frame pointer = 0x28:0xe79de7e8
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1214 (opera)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 5h20m30s
Physical memory: 2035 MB
Dumping 218 MB: 203 187 171 155 139 123 107 91 75 59 43 27 11
#0 doadump () at pcpu.h:195
195 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) list *0xc07b6de4
0xc07b6de4 is in vfs_vmio_release (/usr/src/sys/kern/vfs_bio.c:1530).
1525vfs_vmio_release(struct buf *bp)
1526{
1527int i;
1528vm_page_t m;
1529
1530VM_OBJECT_LOCK(bp-b_bufobj-bo_object);
1531vm_page_lock_queues();
1532for (i = 0; i bp-b_npages; i++) {
1533m = bp-b_pages[i];
1534bp-b_pages[i] = NULL;
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0xc0754457 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc0754719 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc0a4905c in trap_fatal (frame=0xe79de788, eva=52)
at /usr/src/sys/i386/i386/trap.c:899
#4 0xc0a492e0 in trap_pfault (frame=0xe79de788, usermode=0, eva=52)
at /usr/src/sys/i386/i386/trap.c:812
#5 0xc0a49c8c in trap (frame=0xe79de788)
at /usr/src/sys/i386/i386/trap.c:490
#6 0xc0a2fc0b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc07b6de4 in vfs_vmio_release (bp=0xd927e33c)
at /usr/src/sys/kern/vfs_bio.c:1530
#8 0xc07b8a81 in getnewbuf (slpflag=0, slptimeo=0, size=Variable size is
not available.
) at /usr/src/sys/kern/vfs_bio.c:1847
#9 0xc07ba118 in getblk (vp=0xc8891bb0, blkno=0, size=2048, slpflag=0,
slptimeo=0, flags=Variable flags is not available.
) at /usr/src/sys/kern/vfs_bio.c:2602
#10 0xc0932815 in ffs_balloc_ufs2 (vp=0xc8891bb0,
startoffset=Variable startoffset is not available.
) at /usr/src/sys/ufs/ffs/ffs_balloc.c:699
#11 0xc0952a85 in ffs_write (ap=0xe79debc4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:720
#12 0xc0a5efc6 in VOP_WRITE_APV (vop=0xc0b93c60, a=0xe79debc4) at
vnode_if.c:691
#13 0xc07dbf37 in vn_write (fp=0xc85f3168, uio=0xe79dec60,
active_cred=0xc61c6300, flags=0, td=0xc583fc60) at vnode_if.h:373
#14 0xc07875e7 in dofilewrite (td=0xc583fc60, fd=17, fp=0xc85f3168,
auio=0xe79dec60, offset=-1, flags=0) at file.h:254
#15 0xc07878c8 in kern_writev (td=0xc583fc60, fd=17,
Re: umtxn and Apache 2.2
Borja Marcos wrote: Hello, I'm running a server with FreeBSD 7-STABLE as of August 8, Apache 2.2 with mpm/worker and threads support, and PHP 5.2.6. Everything works like a charm, but I see that Apache is leaking processes that get stuck in umtxn state. I run Apache 2.2 with worker MPM but without mod_php (I use PHP as FastCGI) on many servers and I don't have such problems. Maybe it's PHP's fault? (I agree you need a trace with debugging symbols). signature.asc Description: OpenPGP digital signature
Hardware monitoring for Intel Atom D945GCLF.
Hi, Is there a way to make use of hardware monitoring on Intel 945GCLF (with Atom 230 cpu)? It is relatively new child of Intel, but maybe someone figured it out yet. pciconf -lv shows this: [EMAIL PROTECTED]:0:31:3:class=0x0c0500 card=0x464c8086 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus Modules ichsmb and smb are loaded, /dev/smb0 is present, but mbon and lmmon don't give any results. lmmon says: IOCTL: Device not configured mbmon prints this: No SMBus HWM available!! InitMBInfo: Unknown error: 0 Best regards, -- _/_/ .. Eugene Butusov _/_/ ... www.devilka.info _/_/ ebutusov(at)gmail(dot)com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware monitoring for Intel Atom D945GCLF.
On Tue, Aug 12, 2008 at 12:37:52AM +0200, Eugene Butusov wrote: Hi, Is there a way to make use of hardware monitoring on Intel 945GCLF (with Atom 230 cpu)? It is relatively new child of Intel, but maybe someone figured it out yet. pciconf -lv shows this: [EMAIL PROTECTED]:0:31:3:class=0x0c0500 card=0x464c8086 chip=0x27da8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus Modules ichsmb and smb are loaded, /dev/smb0 is present, but mbon and lmmon don't give any results. The board in question is here: http://www.intel.com/products/desktop/motherboards/D945GCLF/D945GCLF-overview.htm The Technical Product Specification also does not mention any H/W monitoring IC in the Block Diagram (see section 1.1.3): http://download.intel.com/support/motherboards/desktop/d945gclf/sb/e35968001us.pdf Section 1.11 mentions support for Hardware Monitoring via WfM, and Section 1.11.1 states that such statistics are available via SMBus (which is the more important part). More on that in a moment. Secondly, re: lmmon: no surprise. It's very, very unlikely your Intel board will contain an LMxx IC; lmmon is specifically for older motherboards (read: mid-to-late 90s) which use LMxx series ICs. There are some present-day AMD boards which use dual LMxx ICs, but it's not a common thing. Thirdly, mbmon doesn't particularly use SMBus in the way you think it would, and I'm betting use of -I will either fail, report fake values, or crash your system, since I don't think any of the features are available on the ISA bus (good riddance). See my H/W monitoring project for FreeBSD: http://bsdhwmon.parodius.com/ I'm presently focusing on Supermicro boards. Regarding your board, I found this on Intel's site: http://www.intel.com/support/motherboards/desktop/sb/CS-012552.htm#sdk * Developing Applications to Read Thermal Information Intel does not offer any development kit or API for application development that will allow you to read a board.s thermal values. However, there are 3rd party tools that you may find helpful. I don't need an API, but this kind of statement makes Intel sound like they're not willing to disclose the SMBus offsets for monitoring. I might have to look at lm-sensors from Linux, but that code is very difficult to follow. I'm not sure if Intel gives this sort of information out publicly, but I sure hope so. You might be able to get CPU thermal statistics by looking at sysctl, but I know absolutely nothing about the Atom CPU (if it behaves like a Core2Duo, then the coretemp(4) driver might work with it, or might need to be modified to work with it). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware monitoring for Intel Atom D945GCLF.
On Mon, Aug 11, 2008 at 04:45:47PM -0700, Jeremy Chadwick wrote: I don't need an API, but this kind of statement makes Intel sound like they're not willing to disclose the SMBus offsets for monitoring. I might have to look at lm-sensors from Linux, but that code is very difficult to follow. I'm not sure if Intel gives this sort of information out publicly, but I sure hope so. There's a web page mentioning this board (note: entirely Japanese) -- http://iktaka.dyndns.org/node/11 The bottom part of the page states that Linux's lm_sensors 3.0.2 can successfully monitor temperatures, voltages, and fan RPMs on that board, very likely via SMBus. Ideally I should be able to track down technical details by looking at that code. I'd feel much more comfortable asking Intel and having them provide necessary registers and offsets, though; I prefer to avoid reverse-engineering things if possible (less mistakes). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: should looking at an interface with 'ifconfig' trigger a change ?
On Mon, Aug 11, 2008 at 02:03:31PM +0100, Pete French wrote: Pyun YongHyeon [EMAIL PROTECTED] wrote: Try attached patch and check whether bce(4) correctly reports link state changes. After seeing 'link state changed to UP' message, unplug the cable and see whether it reports link DOWN. The message should be printed in a second. Also try replugging cable and you should see link UP message within several seconds. Since auto-negotation takes more time you may have to wait for a while. I do not have phsyical access to the machine, so I did this using a sutdown of the interface on the sitch - but yes, it works! This fixes the progem with lagg as well - it now fails over to the other interface properly. Such a simple patch - if this has no ill effects then I will deploy it on al our servers,m and hope for it to be committed soon. All new HP servers appear to come with bce interfaces, so this is an importnat fix for us, and probably a lot of other people too. Thanks. Thanks for testing! Patch committed to HEAD with svn r181619. -pete. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: inpcb/inpcbinfo rwlocking: coming to a 7-STABLE branch near you
At 05:21 PM 8/8/2008, Robert Watson wrote: http://www.watson.org/~robert/freebsd/netperf/20080808-7stable-rwlock-inpcb.diff These incude the inpcb/inpcbinfo read/write locking changes (although not yet for raw/divert sockets). Any testing, especially with heavy UDP loads, would be much appreciated -- this are fairly complex changes, and also quite a complex MFC. Hi Robert, So far so good with the patches. I am running them on a busy sendmail server that also does a lot of DNS locally for itself and a number of other boxes. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with /boot/loader [A new patch]
John Baldwin wrote: Ok, I'm at a loss for why the new BTX doesn't work for you. Unfortunately, this sort of thing isn't easy to debug. If you have firewire (and another machine with firewire) then I have some debugging code I used with qemu to save a summary of the last request made by the loader to BTX. That can at least indicate which BIOS call is hanging. From there you can dissassemble your BIOS to try to determine if there are any spin loops and see what it is waiting on. Thank you very much for the effort. I have firewire here but not another machine with it, but I'll try to find one. I'll contact you again when I'll find it. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ICRC's
Jeremy Chadwick [EMAIL PROTECTED] writes: If Larry was using UFS, he'd also see the above errors from the kernel. FreeBSD reports the CRC errors reported by the ATA device, ZFS reports the said data as corrupted during scrubbing or standard usage (hence the CKSUM field in 'zpool status'), and ZFS also *repairs* the corrupted data. I can't explain how the repair works, but it's one of the many features of the filesystem. I believe journalling filesystems (e.g. Um, not exactly. It's one of the features of the filesystem when you're running on a ZFS pool which is mirrored or raidz. If your ZFS pool is not mirrored or raidz-ed, checksum errors *will* be unrepairable and should show up as read errors to the application. AFAIK, the repair is just ZFS either finding a good copy of the block from the other half of the mirror (if mirrored) or reconstructing the missing block thru parity (if raidz-ed) and rewriting it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
