Re: 9.1 and intel graphics
On Fri, Oct 19, 2012 at 9:14 PM, Zoran Kolic zko...@sbb.rs wrote: Yesterday I have gotten lenovo e320 laptop, with core i3 2350 and HD3000 integrated. Gonna wait few days till 9.1 release. I never used anything aside intel on my old laptop. Kostik Belousov made a port of kms and I found patches from june and jule on the net. What should I do after 9.1 install in this case? I assume kms is in xorg. Do I have to find and install some driver from intel? Do I need to change xorg.conf after configure flag, that will make conf file? Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. To use it you need to build X drivers and drm and the kernel with: WITH_NEW_XORG=YES WITH_KMS=YES in /etc/make.conf. Specifically, the kernel and a few ports. graphics/drm and your org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, and xf86-input-keyboard. Then just start X. Don't try loading the kernel module. It will be loaded by the startx. Finally, what happens when I leave x and want to go back to console mode? You don't If you try, your system will lock up. You need to shutdown from a window in X. Hopefully someone will implement switching back to console mode some day, but it has not happened, yet. I tried out live RC2 from usb stick. Few acpi errors, intel 1000 wifi found. After some time sysctl hw.acpi gave me the cpu temperature of 50C. Fan was on. Probably temp gonna go down when I add powerd and cx_lowest to rc.conf on hdd. Is it normal temp for this cpu? Pretty reasonable. Be sure to set both cx_lowest to Cmax. It is new to 9.1 and fixes some serious issues with C-states on many newer platforms. Specifically that some platforms skip some C-states and FreeBSD never used the ones saving more power than hte one skipped. I always remind folks to blow out the heat sink on laptops about one a year. Dust is a great insulator and laptops often collect a lot more dust than office systems, though my office system started dying during buildworld last week and blowing out the CPU heat sink fixed it up, but it had been sitting around for almost three years collecting dust. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: 9.1 and intel graphics
Hi, On Fri, 19 Oct 2012 23:29:28 -0700 Kevin Oberman kob6...@gmail.com wrote: On Fri, Oct 19, 2012 at 9:14 PM, Zoran Kolic zko...@sbb.rs wrote: I always remind folks to blow out the heat sink on laptops about one a year. Dust is a great insulator and laptops often collect a lot more I never did this on a laptop as all of mine where build in a way that dust could not collect. So, it depends very much on the model. dust than office systems, though my office system started dying during buildworld last week and blowing out the CPU heat sink fixed it up, but it had been sitting around for almost three years collecting dust. I do this every year on my desktop. The temperature drops then by 10K. You can use the CPU temperature as an indicator when a cleaning is needed. But blowing does not work on my machine. I really have to take screw driver and tweezers to get the work finally done. Erich ___ 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: 9.1 and intel graphics
Hi, On Sat, 20 Oct 2012 06:14:08 +0200 Zoran Kolic zko...@sbb.rs wrote: Yesterday I have gotten lenovo e320 laptop, with core i3 2350 and HD3000 integrated. Gonna wait few days till 9.1 release. there shouldn't be many changes between RC2 and the final release version. You can always update later. I never used anything aside intel on my old laptop. Kostik Belousov made a port of kms and I found patches from june and jule on the net. What should I do after 9.1 install in this case? I assume kms is in xorg. Do I have to find and install You should not need the patches anymore for 9.x and 10.x. some driver from intel? Do I need to change xorg.conf after configure flag, that will make conf file? I have had to do but this is some time ago. Finally, what happens when I leave x and want to go back to console mode? It might crashes your system. You are not able to go back to X and you only see a black screen. This is not an error but a feature. Fun aside, this function was not implemented yet. I tried out live RC2 from usb stick. Few acpi errors, intel The ACPI errors might depend on your BIOS. I get an endless number of ACPI errors during running X but they do not show any effect on my machine. 1000 wifi found. After some time sysctl hw.acpi gave me the cpu temperature of 50C. Fan was on. Probably temp gonna go down when I add powerd and cx_lowest to rc.conf on hdd. Is it normal temp for this cpu? 50 degrees? Seems pretty low. My i7 goes up to 96 under full load. As the CPU is made for 100 and I am in the tropics, I do not care much. This should be true for your CPU too. Erich ___ 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: Problem reading vitals from Gigabyte H77-DH3H
on 20/10/2012 06:50 Derek Kulinski said the following: Hello Andriy, Friday, October 19, 2012, 6:27:11 AM, you wrote: Here is a (quite large) patch: http://people.freebsd.org/~avg/sensors.diff Please note that if affects both kernel and userland code. Read it(4) manual page after upgrading. Note that you will need to add some entries to /boot/device.hints (unless your upgrade procedure would automatically merge the file). I applied it to RELENG_9 as of today, recompiled the userland and kernel (I did not see any errors). The it device loaded successfully, unfortunately I don't see any effect; the hw.acpi.thermal does not change (though I guess it not supposed to), sysctl hw.sensors and hw._sensors do not return anything (not even a complaint that it does not exist). sensord returns: sensorsd: no sensors found Does your device.hints file has hints for it(4)? What are they? Could you please also fetch sysutils/superiotool port from here https://redports.org/browser/avg/sysutils/superiotool, replace what you have under /usr/ports, install the port and then run 'superiotool -d' command? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 12:37:19 AM, you wrote: Does your device.hints file has hints for it(4)? Yes, I did a full install with mergemaster etc. What are they? hint.it.0.at=isa hint.it.0.port=0x290 hint.it.1.at=isa hint.it.1.port=0xc00 hint.it.2.at=isa hint.it.2.port=0xd00 Could you please also fetch sysutils/superiotool port from here https://redports.org/browser/avg/sysutils/superiotool, replace what you have under /usr/ports, install the port and then run 'superiotool -d' command? No luck: [chinatsu]:/tank/junk/ports/sysutils/superiotool# superiotool -d superiotool r4.0-2827-g1a00cf0 No Super I/O found -- Best regards, Derekmailto:tak...@takeda.tk Hard work pays off in the future. Laziness pays off now. ___ 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: Problem reading vitals from Gigabyte H77-DH3H
on 20/10/2012 11:08 Derek Kulinski said the following: Hello Andriy, Saturday, October 20, 2012, 12:37:19 AM, you wrote: [snip] Could you please also fetch sysutils/superiotool port from here https://redports.org/browser/avg/sysutils/superiotool, replace what you have under /usr/ports, install the port and then run 'superiotool -d' command? No luck: [chinatsu]:/tank/junk/ports/sysutils/superiotool# superiotool -d superiotool r4.0-2827-g1a00cf0 No Super I/O found Hmm, it would be a pity if all of this was a waste of time... I based some of my assumptions on googling, in particular this post http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: Found ITE Super I/O, ID 0x8728 on port 0x2e BTW, I suppose DH3H in the subject line is a typo? Or is it a different model? Oh, hmm, looks like even the latest superiotool may not have support for this newer chip. Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? If this command returns id=0x8728, then you could hack superiotool source code between running 'make patch' and 'make'. You could edit ite.c file, search for 0x8726 and either change it to 0x8728 or duplicate the whole section and make the change there. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem reading vitals from Gigabyte H77-DH3H
It's really late where I live, will do what you mentioned in the morning. I think it is a typo. I believe it is DS3H, but I will confirm that tomorrow. Thank you for helping me with this. -- Sent from my phone. Please excuse my brevity. Andriy Gapon a...@freebsd.org wrote: on 20/10/2012 11:08 Derek Kulinski said the following: Hello Andriy, Saturday, October 20, 2012, 12:37:19 AM, you wrote: [snip] Could you please also fetch sysutils/superiotool port from here https://redports.org/browser/avg/sysutils/superiotool, replace what you have under /usr/ports, install the port and then run 'superiotool -d' command? No luck: [chinatsu]:/tank/junk/ports/sysutils/superiotool# superiotool -d superiotool r4.0-2827-g1a00cf0 No Super I/O found Hmm, it would be a pity if all of this was a waste of time... I based some of my assumptions on googling, in particular this post http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: Found ITE Super I/O, ID 0x8728 on port 0x2e BTW, I suppose DH3H in the subject line is a typo? Or is it a different model? Oh, hmm, looks like even the latest superiotool may not have support for this newer chip. Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? If this command returns id=0x8728, then you could hack superiotool source code between running 'make patch' and 'make'. You could edit ite.c file, search for 0x8726 and either change it to 0x8728 or duplicate the whole section and make the change there. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ 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: 9.1 and intel graphics
Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. To use it you need to build X drivers and drm and the kernel with: WITH_NEW_XORG=YES WITH_KMS=YES in /etc/make.conf. Specifically, the kernel and a few ports. graphics/drm and your org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, and xf86-input-keyboard. Then just start X. Don't try loading the kernel module. It will be loaded by the startx. Finally, what happens when I leave x and want to go back to console mode? You don't If you try, your system will lock up. You need to shutdown from a window in X. Hopefully someone will implement switching back to console mode some day, but it has not happened, yet. How do you shutdown from a window in X if you're nonroot? Can you have both root and nonroot windows simultaneously in X? Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 and intel graphics
Hi, On Sat, 20 Oct 2012 05:12:45 -0400 Thomas Mueller muelle...@insightbb.com wrote: Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. To use it you need to build X drivers and drm and the kernel with: WITH_NEW_XORG=YES WITH_KMS=YES in /etc/make.conf. Specifically, the kernel and a few ports. graphics/drm and your org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, and xf86-input-keyboard. Then just start X. Don't try loading the kernel module. It will be loaded by the startx. Finally, what happens when I leave x and want to go back to console mode? You don't If you try, your system will lock up. You need to shutdown from a window in X. Hopefully someone will implement switching back to console mode some day, but it has not happened, yet. How do you shutdown from a window in X if you're nonroot? Can you have both root and nonroot windows simultaneously in X? I have all the while. You can also open a normal xterm and enter su to become root or start a xterm as root. It booth works. You are also able to start any other program as root. Erich ___ 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: 9.1 and intel graphics
On 2012-10-20 (Saturday) 11:12:45 Thomas Mueller wrote: Full support for the HD3000 is in 9-stable and 9.1-Beta and all RCs. To use it you need to build X drivers and drm and the kernel with: WITH_NEW_XORG=YES WITH_KMS=YES in /etc/make.conf. Specifically, the kernel and a few ports. graphics/drm and your org-drivers: xf86-video-intel, xf86-input-synaptics, xf86-input-mouse, and xf86-input-keyboard. Then just start X. Don't try loading the kernel module. It will be loaded by the startx. Finally, what happens when I leave x and want to go back to console mode? You don't If you try, your system will lock up. You need to shutdown from a window in X. Hopefully someone will implement switching back to console mode some day, but it has not happened, yet. How do you shutdown from a window in X if you're nonroot? Can you have both root and nonroot windows simultaneously in X? Tom ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Hello, While you are not able to see anything on the screen, the system is still operational after X11 shutdown (or tty switch). Therefore you can still type input to the (invisible) command line or connect to that system via telnet/ssh/rlogin ... By default the system shuts down gracefully if you hit it's power button. If you're using GDM/KDM you can also use their shutdown options. Eventually it might crash during shutdown though (at least over here). Alonso ___ 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: 9.1 and intel graphics
On Sat, 20 Oct 2012, Thomas Mueller wrote: How do you shutdown from a window in X if you're nonroot? Users that are a member of the operator group can run shutdown -p or -r. Can you have both root and nonroot windows simultaneously in X? Sure. ___ 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: 9.1-RC2 - could it be that the installer does not write the MBR?
On 2012.10.18 18:44, Rainer Duffner wrote: Thus erasing grub when someone is attempting to install FreeBSD alongside Linux? How many people actually do that, now that there are so many virtualization-options? At least I do. As invaluable and paradigm-shifting as virtualization is, I still like to run different OSen on bare hardware. For example right now I'm working on a prototype FreeBSD NAS, troubleshooting problematic disc controllers, and being able to run a Linux kernel is very useful to compare how both systems see and use the hardware, or access some programs I'm more familiar with. I'm not saying I expect bsdinstaller to hold my hand ; I'm comfortable using gpart, fdisk, grub and dd to get what I want, but it would be nice if things were clear on what is going to happen (through user dialog or even simply in the FreeBSD Handbook). ___ 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: ${CTFCONVERT_CMD} expands to empty string
On Friday, October 19, 2012 09:06:55 PM Andrey Chernov wrote: On recent -stable I got a lots of (see subj) now due to CTF changes in *.mk files. I have WITHOUT_CDDL=yes in my /etc/src.conf and WITHOUT_CDDL have wider scope than WITHOUT_CTF suggested, but WITHOUT_CDDL is not checked in recent CTF changes. Please fix this thing. Which stable? -- John Baldwin ___ 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
[ZFS] Server periodically become unavailable
FreeBSD 9.1-PRERELEASE #0: Wed Jul 25 01:40:56 EEST 2012 I have the server: 8 cores AMD, 16GB RAM, 4x3TB HDD in RAID10 for ZFS. Sometime wheels fall off the server and the network. Can this clean-up memory for ZFS cache? I enclose a picture with the monitoring system at the time lags. http://imageshack.us/a/img341/9643/memoryusage.png http://imageshack.us/a/img22/6935/nginxclientstat.png http://imageshack.us/a/img19/8817/realmemory.png #cat /etc/sysctl.conf kern.ipc.somaxconn=65535 kern.ipc.maxsockets=204800 net.inet.ip.portrange.first=1024 net.inet.ip.portrange.last=65535 kern.ipc.shmmax=67108864 kern.ipc.shmall=67108864 net.inet.tcp.rfc3465=0 net.graph.maxdgram=8388608 net.graph.recvspace=8388608 net.route.netisr_maxqlen=4096 kern.ipc.nmbclusters=40 kern.ipc.maxsockbuf=83886080 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.sendbuf_inc=524288 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=65536 net.inet.tcp.keepidle=30 net.inet.tcp.keepintvl=6 net.inet.ip.fw.dyn_max=65535 net.inet.ip.fw.dyn_buckets=65536 net.inet.ip.fw.dyn_ack_lifetime=120 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.tcp.nolocaltimewait=1 security.bsd.hardlink_check_uid=1 security.bsd.hardlink_check_gid=1 security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 -- Vladislav V. Prodan System Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE ___ 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
stable/9 @r241776 panic: REDZONE: Buffer underflow detected...
This seems ... fairly weird to me. Yesterday, I built booted: FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #274 241726M: Fri Oct 19 05:40:05 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 and used the machine all day; nothing unusual (including various reboots (e.g. when I disembarked the train for the final leg of my commute home, so I powered the laptop off). This morning, I built: FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #275 241776M: Sat Oct 20 04:34:45 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 and on first reboot, I got a panic. After a bit of experimentation, it appears that I get a panic @r241776 if I attempt a normal boot into multi-user mode, but if I first boot to single-user mode, then exit single-user mode, it comes up without a problem. I don't have a serial console, so I started to write down some of the panic information, but my patience ran a bit short. Here's whet I recorded (warning: hand-transcripted -- twice!): ... Starting devd. REDZONE: Buffer underflow detected. 1 byte corrupted before 0xced40080 (4294966796 bytes allocated). Allocation backtrace: #0 0xc0ceac8f at redzone_setup+0xcf #1 0xc0a5d5c9 at malloc+0x1d9 ...[about 20 more such lines I didn't record]... bt Tracing pid 901 tid 100106 td 0xd2b99000 kdb_enter(...) panic(...) free(...) devread(ce8c2d00,f7274c0c,0,c0b1e4f0,d279e380,...) at devread+0x1a6 giant_read(...) at giant_read+0x87 devfs_read(...) at devfs_read+0xc6 dofileread(...) at dofileread+0x99 sys_read(...) at sys_read+0x98 syscall(f7274d08) at syscall+0x387 Within the bounds described above, this appears to be quite reproducible -- on my laptop. My build machine (updated in parallel, at the same GRNs) does not exhibit the panic. I was unable to get a crash dump; I have dumpdev=AUTO in /etc/rc.conf, and the panic was occurring well after swap was enabled. (Yes, I know I have swap over-allocated. I plan to do something about it at some point.) I've attached a copy of dmesg.boot. Anyone else seeing this? Any ideas how to diagnose it? Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. Copyright (c) 1992-2012 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 9.1-PRERELEASE #275 241776M: Sat Oct 20 04:34:45 PDT 2012 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 WARNING: DIAGNOSTIC option enabled, expect reduced performance. MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD map base: 0xc800 MEMGUARD map limit: 0xce681000 MEMGUARD map size: 104964 KBytes CPU: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz (2793.06-MHz 686-class CPU) Origin = GenuineIntel Id = 0x10676 Family = 0x6 Model = 0x17 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x2010NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3643670528 (3474 MB) Event timer LAPIC quality 400 ACPI APIC Table: DELL M09 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: DELL M09 on motherboard hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 Event timer HPET3 frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, df351c00 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 atrtc0: AT realtime clock port 0x70-0x71,0x72-0x77 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 attimer0: AT timer port 0x40-0x43,0x50-0x53 irq 2 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_ec0: Embedded Controller: GPE 0x11 port 0x930,0x934 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible
Re: 9.1-RC2 - could it be that the installer does not write the MBR?
Am Fri, 19 Oct 2012 20:14:01 -0400 schrieb Glen Barber g...@freebsd.org: The grub prompt for (Open)Solaris? Or do you use grub on FreeBSD? I thought it was a linux grub (the Firmware-Update DVD is linux-based and I thought it had gone postal. But I came to realize that it was the Solaris grub. We only use FreeBSD on servers and it's always the only OS on the disks. I _think_ at this point, you've hit the same problem I hit, the only difference is that in my case, 9.1-PRERELEASE was installed twice, because the paritions were not ideal. So, my guess is if you were to boot the install cd and select 'Live CD' or 'Shell' from the first menu option, and wrote the GPT bootcode to da0p1 (assuming da0 is the drive) and reboot, it would have booted fine. I don't think this is what a user is expecting from an OS installation routine It's a bug. Rainer ___ 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: 9.1-RC2 - could it be that the installer does not write the MBR?
On Sat, Oct 20, 2012 at 07:04:02PM +0200, Rainer Duffner wrote: Am Fri, 19 Oct 2012 20:14:01 -0400 schrieb Glen Barber g...@freebsd.org: The grub prompt for (Open)Solaris? Or do you use grub on FreeBSD? I thought it was a linux grub (the Firmware-Update DVD is linux-based and I thought it had gone postal. But I came to realize that it was the Solaris grub. We only use FreeBSD on servers and it's always the only OS on the disks. Ok, thank you. I did not want to assume anything here. I _think_ at this point, you've hit the same problem I hit, the only difference is that in my case, 9.1-PRERELEASE was installed twice, because the paritions were not ideal. So, my guess is if you were to boot the install cd and select 'Live CD' or 'Shell' from the first menu option, and wrote the GPT bootcode to da0p1 (assuming da0 is the drive) and reboot, it would have booted fine. I don't think this is what a user is expecting from an OS installation routine It's a bug. Oh, I agree. For what it is worth, when I ran into this, I just merely thought I did something wrong during the install, so writing the gptboot code to the drive was my quick fix. I originally didn't bother reproducing it, until about an hour later when I saw this thread start. The frustrating part now is I have had zero luck reproducing the problem... Glen pgphxMV76cJHy.pgp Description: PGP signature
Re: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 1:26:40 AM, you wrote: Hmm, it would be a pity if all of this was a waste of time... I based some of my assumptions on googling, in particular this post http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: Found ITE Super I/O, ID 0x8728 on port 0x2e BTW, I suppose DH3H in the subject line is a typo? Or is it a different model? Actually it is a typo, the model is H77-DS3H, sorry for the mistake. Oh, hmm, looks like even the latest superiotool may not have support for this newer chip. Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? # superiotool -V | fgrep Failed | fgrep -v ff Failed. Returned data: id=0x8728, rev=0x1 If this command returns id=0x8728, then you could hack superiotool source code between running 'make patch' and 'make'. You could edit ite.c file, search for 0x8726 and either change it to 0x8728 or duplicate the whole section and make the change there. After the change I run superiotool with -d, here is the output: superiotool r4.0-2827-g1a00cf0 Found ITE IT8726F (id=0x8728, rev=0x1) at 0x2e Register dump: idx 20 21 22 23 24 2b val 87 28 01 00 00 40 def 87 26 01 00 MM 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 val 00 03 f0 06 02 00 00 def 00 03 f0 06 02 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 50 50 def 00 03 f8 04 00 50 00 7f LDN 0x02 (COM2) idx 30 60 61 70 f0 f1 f2 f3 val 00 02 f8 03 00 50 50 50 def 00 02 f8 03 00 50 00 7f LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 03 78 07 78 07 04 0b def 00 03 78 07 78 07 03 03 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 0a 30 0a 20 09 00 40 00 00 20 00 f0 def 00 02 90 02 30 09 00 00 00 00 00 MM MM LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 08 def 01 00 60 00 64 01 02 08 LDN 0x06 (Mouse) idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 f3 10 00 00 00 80 00 00 0a 00 00 00 00 00 20 00 00 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 00 00 00 00 00 00 00 10 42 00 00 00 00 1c 00 00 00 00 00 80 00 def 01 00 00 40 00 00 1f 00 00 00 00 00 00 00 00 MM 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MM 00 LDN 0x08 (MIDI port) idx 30 60 61 70 f0 val 00 00 00 00 00 def 00 03 00 0a 00 LDN 0x09 (Game port) idx 30 60 61 val 00 00 00 def 00 02 01 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 -- Best regards, Derekmailto:tak...@takeda.tk There are two ways to write error-free programs; only the third one works. -- Alan J. Perlis ___ 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: 9.1-RC2 - could it be that the installer does not write the MBR?
On Fri, Oct 19, 2012 at 10:21:54PM -0600, Warren Block wrote: I don't know if this is the problem, but it is worth pointing out that graid(8) is now included in GENERIC. Leftover hardware RAID metadata could make for unexpected results. For example, http://forums.freebsd.org/showthread.php?t=35168 Definitely worth noting. GEOM_MIRROR can do this too, iirc. In my case, however, the target installation disk was not previously part of any RAID configuration, software or otherwise. Glen pgp8wbcOjFYRp.pgp Description: PGP signature
Re: Problem reading vitals from Gigabyte H77-DH3H
on 20/10/2012 20:37 Derek Kulinski said the following: Hello Andriy, Saturday, October 20, 2012, 1:26:40 AM, you wrote: Hmm, it would be a pity if all of this was a waste of time... I based some of my assumptions on googling, in particular this post http://thread.gmane.org/gmane.linux.bios.flashrom/1163 mentioned: Found ITE Super I/O, ID 0x8728 on port 0x2e BTW, I suppose DH3H in the subject line is a typo? Or is it a different model? Actually it is a typo, the model is H77-DS3H, sorry for the mistake. Oh, hmm, looks like even the latest superiotool may not have support for this newer chip. Could you please run superiotool -V | fgrep Failed | fgrep -v ff ? # superiotool -V | fgrep Failed | fgrep -v ff Failed. Returned data: id=0x8728, rev=0x1 If this command returns id=0x8728, then you could hack superiotool source code between running 'make patch' and 'make'. You could edit ite.c file, search for 0x8726 and either change it to 0x8728 or duplicate the whole section and make the change there. After the change I run superiotool with -d, here is the output: superiotool r4.0-2827-g1a00cf0 Found ITE IT8726F (id=0x8728, rev=0x1) at 0x2e Register dump: idx 20 21 22 23 24 2b val 87 28 01 00 00 40 def 87 26 01 00 MM 00 LDN 0x00 (Floppy) idx 30 60 61 70 74 f0 f1 val 00 03 f0 06 02 00 00 def 00 03 f0 06 02 00 00 LDN 0x01 (COM1) idx 30 60 61 70 f0 f1 f2 f3 val 01 03 f8 04 00 50 50 50 def 00 03 f8 04 00 50 00 7f LDN 0x02 (COM2) idx 30 60 61 70 f0 f1 f2 f3 val 00 02 f8 03 00 50 50 50 def 00 02 f8 03 00 50 00 7f LDN 0x03 (Parallel port) idx 30 60 61 62 63 70 74 f0 val 00 03 78 07 78 07 04 0b def 00 03 78 07 78 07 03 03 LDN 0x04 (Environment controller) idx 30 60 61 62 63 70 f0 f1 f2 f3 f4 f5 f6 val 01 0a 30 0a 20 09 00 40 00 00 20 00 f0 def 00 02 90 02 30 09 00 00 00 00 00 MM MM If this information is to be trusted (i.e. 8728 is sufficiently compatible with 8726), then please try to set port number in the hints to 0xa30 (e.g. where you have 0x290 now). LDN 0x05 (Keyboard) idx 30 60 61 62 63 70 71 f0 val 01 00 60 00 64 01 02 08 def 01 00 60 00 64 01 02 08 LDN 0x06 (Mouse) idx 30 70 71 f0 val 01 0c 02 00 def 00 0c 02 00 LDN 0x07 (GPIO) idx 25 26 27 28 29 2a 2c 60 61 62 63 64 65 70 71 72 73 74 b0 b1 b2 b3 b4 b5 b8 b9 ba bb bc bd c0 c1 c2 c3 c4 c8 c9 ca cb cc e0 e1 e2 e3 e4 f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd val 00 f3 10 00 00 00 80 00 00 0a 00 00 00 00 00 20 00 00 00 00 00 00 00 00 20 00 00 00 00 00 01 00 00 40 00 01 00 00 00 00 00 00 00 00 00 10 42 00 00 00 00 1c 00 00 00 00 00 80 00 def 01 00 00 40 00 00 1f 00 00 00 00 00 00 00 00 MM 38 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 40 00 01 00 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 MM 00 LDN 0x08 (MIDI port) idx 30 60 61 70 f0 val 00 00 00 00 00 def 00 03 00 0a 00 LDN 0x09 (Game port) idx 30 60 61 val 00 00 00 def 00 02 01 LDN 0x0a (Consumer IR) idx 30 60 61 70 f0 val 00 03 10 0b 06 def 00 03 10 0b 00 -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 11:34:48 AM, you wrote: If this information is to be trusted (i.e. 8728 is sufficiently compatible with 8726), then please try to set port number in the hints to 0xa30 (e.g. where you have 0x290 now). It appears to work fine: hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1305 RPM hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,23 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: 30,00 degC hw.sensors.it0.temp1: 25,00 degC hw.sensors.it0.temp2: 25,00 degC I have three questions though: 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. Seems like: fan0 - CPU_FAN (did not try to disconnect it to check :) fan1 - SYS_FAN1 fan2 - SYS_FAN2 There is no entry for SYS_FAN3. I disconnected it temporarily but it did not seem to affect the output. Is it possible to get that information from the motherboard? 2. Is there a way for me to figure out which temperature is which? Or at least which one would correspond to H77's temperature? Is it possible that the temperature is not listed? Right now as I check it the component is hot enough to make it hard for me to touch the heat sink. I would think it would be higher than 30C. 3. When will the it module be included with the FreeBSD? Anyway thank you so much for your help so far. At least have meaningful values now that appear to be real (i.e. they change). Can't verify whether the voltages are correct due to my limited knowledge. -- Best regards, Derekmailto:tak...@takeda.tk If brute force doesn't solve your problems, then you aren't using enough. ___ 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: Problem reading vitals from Gigabyte H77-DH3H
on 20/10/2012 22:20 Derek Kulinski said the following: Hello Andriy, Saturday, October 20, 2012, 11:34:48 AM, you wrote: If this information is to be trusted (i.e. 8728 is sufficiently compatible with 8726), then please try to set port number in the hints to 0xa30 (e.g. where you have 0x290 now). It appears to work fine: hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1305 RPM hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,23 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: 30,00 degC hw.sensors.it0.temp1: 25,00 degC hw.sensors.it0.temp2: 25,00 degC Great! I a dreaming about a special Super I/O driver which would provide services for devices on the chip. Super I/O bases addresses are far more stable (hardwired to a few choices) than base addresses of their devices (freely programmable). I have three questions though: 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. Seems like: fan0 - CPU_FAN (did not try to disconnect it to check :) fan1 - SYS_FAN1 fan2 - SYS_FAN2 There is no entry for SYS_FAN3. I disconnected it temporarily but it did not seem to affect the output. Is it possible to get that information from the motherboard? The driver would have to be updated for that. Unfortunately ITE does not provide public datasheets. We could pick up some new bits from the Linux driver though. http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c 2. Is there a way for me to figure out which temperature is which? Or at least which one would correspond to H77's temperature? Is it possible that the temperature is not listed? Right now as I check it the component is hot enough to make it hard for me to touch the heat sink. I would think it would be higher than 30C. Again, this would require more knowledge about the chip. Plus some additional knowledge about the motherboard. BTW, you could try to use some Linux live CD and see what gets reported there. Maybe they've already figured out the correct mapping. 3. When will the it module be included with the FreeBSD? Soon, I hope. I am working towards that, just need some time. Anyway thank you so much for your help so far. At least have meaningful values now that appear to be real (i.e. they change). Can't verify whether the voltages are correct due to my limited knowledge. Voltages are the most tricky ones as for many of them there are resistor dividers. There are some recommendations on what resistors to use, but only a motherboard vendor knows for sure what's there (or maybe some guesses could be made by studying the motherboard with a magnifying glass). Thank you very much for bearing with me and doing all the hard work! BTW, in the driver code there is a place with the following comment: /* XXX perhaps = ? */ Could you please try to use = instead of == there? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem reading vitals from Gigabyte H77-DH3H
on 20/10/2012 22:42 Andriy Gapon said the following: on 20/10/2012 22:20 Derek Kulinski said the following: I have three questions though: 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. Seems like: fan0 - CPU_FAN (did not try to disconnect it to check :) fan1 - SYS_FAN1 fan2 - SYS_FAN2 There is no entry for SYS_FAN3. I disconnected it temporarily but it did not seem to affect the output. Is it possible to get that information from the motherboard? The driver would have to be updated for that. Unfortunately ITE does not provide public datasheets. We could pick up some new bits from the Linux driver though. http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c In fact, here is a completely untested patch: http://people.freebsd.org/~avg/it-fans-0x80.diff P.S. Just to satisfy my curiosity - could you please add a printf in it_attach that would print the value read from ITD_COREID? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 1:09:10 PM, you wrote: on 20/10/2012 22:42 Andriy Gapon said the following: on 20/10/2012 22:20 Derek Kulinski said the following: I have three questions though: 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. Seems like: fan0 - CPU_FAN (did not try to disconnect it to check :) fan1 - SYS_FAN1 fan2 - SYS_FAN2 There is no entry for SYS_FAN3. I disconnected it temporarily but it did not seem to affect the output. Is it possible to get that information from the motherboard? The driver would have to be updated for that. Unfortunately ITE does not provide public datasheets. We could pick up some new bits from the Linux driver though. http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c In fact, here is a completely untested patch: http://people.freebsd.org/~avg/it-fans-0x80.diff hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1352 RPM hw.sensors.it0.fan3: 1222 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 2,70 VDC (VCORE_A) hw.sensors.it0.volt1: 4,60 VDC (VCORE_B) hw.sensors.it0.volt2: 0,06 VDC (+3.3V) hw.sensors.it0.volt3: -5,08 VDC (+5V) hw.sensors.it0.volt4: -6,53 VDC (+12V) hw.sensors.it0.volt5: 3,74 VDC (Unused) hw.sensors.it0.volt6: 2,14 VDC (-12V) hw.sensors.it0.volt7: 301,15 VDC (+5VSB) hw.sensors.it0.volt8: 298,15 VDC (VBAT) hw.sensors.it0.temp0: 22,00 degC hw.sensors.it0.temp1: -273,15 degC hw.sensors.it0.temp2: -273,15 degC Looks like the 3rd fan is visible. BTW: The value invalid shows when it is unplugged, wouldn't value 0 RPM make more sense in that case? At least that's what BIOS reports for unplugged fans. Looks like the the temperatures are messed up. Looks like 2 last voltage values is the temperature. P.S. Just to satisfy my curiosity - could you please add a printf in it_attach that would print the value read from ITD_COREID? Here it is the output (as decimal): Oct 20 14:08:04 chinatsu kernel: it0 at port 0xa30-0xa37 on isa0 Oct 20 14:08:04 chinatsu kernel: it0: ITD_COREID = 18 As for using Linux CD I can't do it immediatelly, the box does not have cdrom, besides I don't have any image lying around. Any recommendation for something that I could boot from USB and would be able to provide everything you need? -- Best regards, Derekmailto:tak...@takeda.tk The meta-Turing test counts a thing as intelligent if it seeks to apply Turing tests to objects of its own creation. ___ 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: ${CTFCONVERT_CMD} expands to empty string
On 20.10.2012 16:38, John Baldwin wrote: On Friday, October 19, 2012 09:06:55 PM Andrey Chernov wrote: On recent -stable I got a lots of (see subj) now due to CTF changes in *.mk files. I have WITHOUT_CDDL=yes in my /etc/src.conf and WITHOUT_CDDL have wider scope than WITHOUT_CTF suggested, but WITHOUT_CDDL is not checked in recent CTF changes. Please fix this thing. Which stable? stable-9 ___ 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
mpt doesn't propagate read errors and dies on a single sector?
Hi, I have a Sun X4540 with LSI C1068E based SAS controllers (FW version: 1.27.02.00-IT). My problem is if one drive starts to fail with read errors, the machine becomes completely unusable (running stable/9 with ZFS), because -it seems- ZFS can't see that there are read errors on a device, the mpt driver (controller, kernel?) wants to re-issue the operation endlessly. Here is a verbose (dev.mpt.0.debug=7 level) dump: mpt0: Address Reply: SCSI IO Request Reply @ 0xff87ffcfdc00 IOC StatusSuccess IOCLogInfo0x MsgLength 0x09 MsgFlags 0x00 MsgContext0x000200eb Bus: 0 TargetID 3 CDBLength 10 SCSI Status: Check Condition SCSI State: (0x0001)AutoSense_Valid TransferCnt 0x2 SenseCnt 0x0012 ResponseInfo 0x (da3:mpt0:0:3:0): READ(10). CDB: 28 0 3a 38 5d e 0 1 0 0 (da3:mpt0:0:3:0): CAM status: SCSI Status Error (da3:mpt0:0:3:0): SCSI status: Check Condition (da3:mpt0:0:3:0): SCSI sense: MEDIUM ERROR asc:11,0 (Unrecovered read error) (da3:mpt0:0:3:0): Info: 0x3a385d1a (da3:mpt0:0:3:0): Error 5, Unretryable error SCSI IO Request @ 0xff80003046f0 Chain Offset 0x00 MsgFlags 0x00 MsgContext0x000200ea Bus:0 TargetID3 SenseBufferLength 32 LUN: 0x0 Control 0x0200 READ SIMPLEQ DataLength 0x0002 SenseBufAddr0x0c65d5e0 CDB[0:10] 28 00 3a 38 5e 0e 00 01 00 00 SE64 0xff87ffd1c430: Addr=0x00010e858000 FlagsLength=0xd302 64_BIT_ADDRESSING LAST_ELEMENT END_OF_BUFFER END_OF_LIST mpt0: Address Reply: SCSI IO Request Reply @ 0xff87ffcfdd00 IOC StatusSuccess IOCLogInfo0x MsgLength 0x09 MsgFlags 0x00 MsgContext0x000200ea Bus: 0 TargetID 3 CDBLength 10 SCSI Status: Check Condition SCSI State: (0x0001)AutoSense_Valid TransferCnt 0x2 SenseCnt 0x0012 ResponseInfo 0x And I get these check condition SCSI errors endlessly. If ZFS is enabled at boot, the machine can't even start because of this (zpool import never finishes), if I boot without ZFS, and try to import, the zpool command stucks in the vdev_g state: 1163 root 1 200 35440K 5200K vdev_g 6 0:01 0.10% zpool procstat -k 1163 PIDTID COMM TDNAME KSTACK 1163 100116 zpool-mi_switch sleepq_timedwait _sleep biowait vdev_geom_read_guid vdev_geom_open vdev_open vdev_open_children vdev_raidz_open vdev_open vdev_open_children vdev_root_open vdev_open spa_load spa_tryimport zfs_ioc_pool_tryimport zfsdev_ioctl devfs_ioctl_f Could it be that GEOM/ZFS doesn't receive this read error and waits indefinitely for the command to complete? ___ 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: Problem reading vitals from Gigabyte H77-DH3H
on 21/10/2012 00:17 Derek Kulinski said the following: Hello Andriy, Saturday, October 20, 2012, 1:09:10 PM, you wrote: on 20/10/2012 22:42 Andriy Gapon said the following: on 20/10/2012 22:20 Derek Kulinski said the following: I have three questions though: 1. The motherboard has 4 fan sockets (as far as I can tell), CPU_FAN, and SYS_FAN[1-3]. SYS_FAN1 currently is not connected. Seems like: fan0 - CPU_FAN (did not try to disconnect it to check :) fan1 - SYS_FAN1 fan2 - SYS_FAN2 There is no entry for SYS_FAN3. I disconnected it temporarily but it did not seem to affect the output. Is it possible to get that information from the motherboard? The driver would have to be updated for that. Unfortunately ITE does not provide public datasheets. We could pick up some new bits from the Linux driver though. http://lxr.linux.no/#linux+v3.6.2/drivers/hwmon/it87.c In fact, here is a completely untested patch: http://people.freebsd.org/~avg/it-fans-0x80.diff hw.sensors.it0.fan0: 997 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1352 RPM hw.sensors.it0.fan3: 1222 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 2,70 VDC (VCORE_A) hw.sensors.it0.volt1: 4,60 VDC (VCORE_B) hw.sensors.it0.volt2: 0,06 VDC (+3.3V) hw.sensors.it0.volt3: -5,08 VDC (+5V) hw.sensors.it0.volt4: -6,53 VDC (+12V) hw.sensors.it0.volt5: 3,74 VDC (Unused) hw.sensors.it0.volt6: 2,14 VDC (-12V) hw.sensors.it0.volt7: 301,15 VDC (+5VSB) hw.sensors.it0.volt8: 298,15 VDC (VBAT) hw.sensors.it0.temp0: 22,00 degC hw.sensors.it0.temp1: -273,15 degC hw.sensors.it0.temp2: -273,15 degC Looks like the 3rd fan is visible. BTW: The value invalid shows when it is unplugged, wouldn't value 0 RPM make more sense in that case? At least that's what BIOS reports for unplugged fans. The sensors code has its own conventions. Looks like the the temperatures are messed up. Looks like 2 last voltage values is the temperature. Oops, right. I've updated the patch at the same URL. P.S. Just to satisfy my curiosity - could you please add a printf in it_attach that would print the value read from ITD_COREID? Here it is the output (as decimal): Oct 20 14:08:04 chinatsu kernel: it0 at port 0xa30-0xa37 on isa0 Oct 20 14:08:04 chinatsu kernel: it0: ITD_COREID = 18 Thank you! As for using Linux CD I can't do it immediatelly, the box does not have cdrom, besides I don't have any image lying around. Any recommendation for something that I could boot from USB and would be able to provide everything you need? Unfortunately, I don't have familiarity with Linux distros either... -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem reading vitals from Gigabyte H77-DH3H
Hello Andriy, Saturday, October 20, 2012, 3:09:22 PM, you wrote: Looks like the the temperatures are messed up. Looks like 2 last voltage values is the temperature. Oops, right. I've updated the patch at the same URL. Seems like it is still wrong: hw.sensors.it0.fan0: 1005 RPM hw.sensors.it0.fan1: invalid hw.sensors.it0.fan2: 1300 RPM hw.sensors.it0.fan3: 1157 RPM hw.sensors.it0.fan4: invalid hw.sensors.it0.volt0: 1,42 VDC (VCORE_A) hw.sensors.it0.volt1: 2,72 VDC (VCORE_B) hw.sensors.it0.volt2: 2,70 VDC (+3.3V) hw.sensors.it0.volt3: 4,60 VDC (+5V) hw.sensors.it0.volt4: 0,06 VDC (+12V) hw.sensors.it0.volt5: -5,08 VDC (Unused) hw.sensors.it0.volt6: -6,53 VDC (-12V) hw.sensors.it0.volt7: 3,74 VDC (+5VSB) hw.sensors.it0.volt8: 2,14 VDC (VBAT) hw.sensors.it0.temp0: -271,73 degC hw.sensors.it0.temp1: -270,43 degC hw.sensors.it0.temp2: -270,45 degC Unfortunately, I don't have familiarity with Linux distros either... Will look try something. -- Best regards, Derekmailto:tak...@takeda.tk -- Backup not found: (A)bort (R)etry (T)hrowup ___ 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
