Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Mon, 10 Sep 2012 00:49:12 +0300 On 10.09.2012 00:44, Stefano Marinelli wrote: >>> The patched one boots with this dmesg: >>> http://www.dragas.org/~draga/dmesg2.txt >> >> Log looks good. If HPET is used as it should be according to priorities I >> see (sysctl kern.eventtimer.timer returns HPET), then legacy_route mode >> probably works as expected. In `systat -vm 1` you should see about 50-70 >> timer interrupts per CPU. > > Yes, it returns HPET. And the sysstat reports more or less those numbers of > interrupts. So this has been sorted out. Now my machine is running PC-BSD > and looks stable (more tests needed). > > About the power consumption issue, I've just rebooted into Linux and tested > with the "vesa" xorg driver. Same power consumption as Free/PCBSD. So > definitely a GPU powersave issue. I just hope that xorg will support my > video card soon. > > Do you think that your patch will be a part of 9.1 final release? Hope so. I will try to manage it. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Mon, 10 Sep 2012 00:29:06 +0300 On 10.09.2012 00:16, Stefano Marinelli wrote: >>>> hint.hpet.0.legacy_route=1 >>>> hint.attimer.0.clock=0 >>>> hint.atrtc.0.clock=0 > > > I tried on both the patched and the unpatched kernel. > The unpatched kernel refuses to boot (hangs as if I didn't write anything). Hmm. Strange. > The patched one boots with this dmesg: > http://www.dragas.org/~draga/dmesg2.txt Log looks good. If HPET is used as it should be according to priorities I see (sysctl kern.eventtimer.timer returns HPET), then legacy_route mode probably works as expected. In `systat -vm 1` you should see about 50-70 timer interrupts per CPU. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Mon, 10 Sep 2012 00:14:29 +0300 On 10.09.2012 00:09, Stefano Marinelli wrote: >> That patch should just block HPET to allow booting without tunables. Thanks >> for testing the patch, but that is not so interesting from practical side. >> What I would try to do after that is switch HPET into legacy_route mode >> that was known to work on previous AMDs: >> hint.hpet.0.legacy_route=1 >> hint.attimer.0.clock=0 >> hint.atrtc.0.clock=0 > > After patching the kernel, I can now boot without tunables. Should I try to > set those values on the patched or unpatched kernel? They should work on both. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sun, 09 Sep 2012 23:22:39 +0300 On 09.09.2012 23:17, Stefano Marinelli wrote: >> There could be other factors except CPU. For example, GPU, screen >> backlight, disks, etc. Without having proper video driver for AMD GPUs it >> is difficult to predict its power consumption. Also you may look on this >> page: http://wiki.freebsd.org/TuningPowerConsumption . It was written some >> time ago and mostly for Intel, but hopefully better then nothing. Unluckily >> I have no experience with AMD laptops. > > Actually I think it's a matter of GPU. On Linux, I can use the proprietary > drivers. On (PC|Free)BSD, I am using the VESA XOrg driver. > The link you gave me allowed me, some time ago, to lower my netbook power > consumption, going even lower than Linux. > > The machine is compiling the patched kernel now. I will try to reboot it as > soon as finished. That patch should just block HPET to allow booting without tunables. Thanks for testing the patch, but that is not so interesting from practical side. What I would try to do after that is switch HPET into legacy_route mode that was known to work on previous AMDs: hint.hpet.0.legacy_route=1 hint.attimer.0.clock=0 hint.atrtc.0.clock=0 AFAIK, that is what Linux uses by default when it uses HPET. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sun, 09 Sep 2012 23:11:31 +0300 On 09.09.2012 23:03, Stefano Marinelli wrote: >> Thanks, that explains a lot. AMD started to use their proper vendor ID for >> HPET, but seems haven't fixed level-triggered interrupts and haven't >> implemented (removed?) message interrupts. All together it broke workaround >> in HPET driver that supposed to block HPET by default in such cases. Such >> patch should restore it: > [...] > > Thank you. I am downloading the sources and will try to patch and recompile > the kernel as soon as it will have finished. Then, I will report back. > >> I can't say about frequency control, never looked inside AMD's PowerNow; >> but C-states are detected as I can see. You should just enable them by >> adding to /etc/rc.conf lines: >> performance_cx_lowest="C2" >> economy_cx_lowest="C2" > > I tried this, and actually I can see the C2 status is now active. Still, the > watt-o-meter I am using shows a 50W power consumption in idle state (wifi is > off as unsupported), compared to 23/24 on GNU/Linux (Arch) with wifi on. There could be other factors except CPU. For example, GPU, screen backlight, disks, etc. Without having proper video driver for AMD GPUs it is difficult to predict its power consumption. Also you may look on this page: http://wiki.freebsd.org/TuningPowerConsumption . It was written some time ago and mostly for Intel, but hopefully better then nothing. Unluckily I have no experience with AMD laptops. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org, John Baldwin , r...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sun, 09 Sep 2012 22:49:10 +0300 On 09.09.2012 22:27, Stefano Marinelli wrote: >> It looks like the problem is in HPET timer operation. There are number of >> known and handled problems with AMD HPETs, but seems like you've found new >> one. Unluckily, the part of the log about HPET timer didn't fit into the >> message buffer. The buffer can be tuned with tunable kern.msgbufsize. >> Default value is 98304. You may try to double it. The specified value must >> be multiple of 4096. > > Ok, I rised it and I think the whole dmesg is now on the file. > The link is: http://www.dragas.org/~draga/dmesg.txt Thanks, that explains a lot. AMD started to use their proper vendor ID for HPET, but seems haven't fixed level-triggered interrupts and haven't implemented (removed?) message interrupts. All together it broke workaround in HPET driver that supposed to block HPET by default in such cases. Such patch should restore it: --- acpi_hpet.c (revision 240235) +++ acpi_hpet.c (working copy) @@ -57,6 +57,7 @@ #endif #define HPET_VENDID_AMD0x4353 +#define HPET_VENDID_AMD2 0x1022 #define HPET_VENDID_INTEL 0x8086 #define HPET_VENDID_NVIDIA 0x10de #define HPET_VENDID_SW 0x1166 @@ -505,7 +506,7 @@ * properly, that makes it very unreliable - it freezes after any * interrupt loss. Avoid legacy IRQs for AMD. */ - if (vendor == HPET_VENDID_AMD) + if (vendor == HPET_VENDID_AMD || vendor == HPET_VENDID_AMD2) sc->allowed_irqs = 0x; /* * NVidia MCP5x chipsets have number of unexplained interrupt > Also, please note there's another problem on this machine: CPU never goes to > low power, keeping fans always on and keeping power consumption high. On > Linux, I can see the cpu lowering its frequencies. On FreeBSD, it seems it > can't detect lower than c1 statuses and other frequencies: > > [root@pcbsd-8515] ~# sysctl -a | grep cpu > cpu HAMMER > device cpufreq > kern.ccpu: 0 > kern.sched.cpusetsize: 8 >0, 1 > 0, 1 > kern.smp.cpus: 2 > kern.smp.maxcpus: 64 > net.inet.tcp.per_cpu_timers: 0 > debug.acpi.cpu_unordered: 0 > debug.cpufreq.verbose: 0 > debug.cpufreq.lowest: 0 > hw.ncpu: 2 > hw.acpi.cpu.cx_lowest: C1 > security.jail.param.cpuset.id: 0 > dev.cpu.0.%desc: ACPI CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: handle=\_PR_.C000 > dev.cpu.0.%pnpinfo: _HID=none _UID=0 > dev.cpu.0.%parent: acpi0 > dev.cpu.0.cx_supported: C1/0 C2/100 > dev.cpu.0.cx_lowest: C1 > dev.cpu.0.cx_usage: 100.00% 0.00% last 305us > dev.cpu.1.%desc: ACPI CPU > dev.cpu.1.%driver: cpu > dev.cpu.1.%location: handle=\_PR_.C001 > dev.cpu.1.%pnpinfo: _HID=none _UID=0 > dev.cpu.1.%parent: acpi0 > dev.cpu.1.cx_supported: C1/0 C2/100 > dev.cpu.1.cx_lowest: C1 > dev.cpu.1.cx_usage: 100.00% 0.00% last 8264us > dev.acpi_perf.0.%parent: cpu0 > dev.acpi_perf.1.%parent: cpu1 I can't say about frequency control, never looked inside AMD's PowerNow; but C-states are detected as I can see. You should just enable them by adding to /etc/rc.conf lines: performance_cx_lowest="C2" economy_cx_lowest="C2" -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sun, 09 Sep 2012 17:16:54 +0300 On 09.09.2012 15:58, Stefano Marinelli wrote: >> If it help, send me output of `sysctl kern.eventtimer` and full verbose >> dmesg. > > Ok. You can find them on: > http://www.dragas.org/~draga/sysctl.txt > http://www.dragas.org/~draga/dmesg.txt > > It's from PC-BSD 9.1rc1, but it's the same. It looks like the problem is in HPET timer operation. There are number of known and handled problems with AMD HPETs, but seems like you've found new one. Unluckily, the part of the log about HPET timer didn't fit into the message buffer. The buffer can be tuned with tunable kern.msgbufsize. Default value is 98304. You may try to double it. The specified value must be multiple of 4096. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sun, 09 Sep 2012 13:50:42 +0300 On 09.09.2012 13:05, Stefano Marinelli wrote: >> Thanks. As I see here, disk probe stopped just on soft-reset stage. I still >> see no problem there, except that soft-reset didn't complete. >> >> Looking on messages, I think you have no verbose kernel messages enabled. >> Could you enable them (boot_verbose="YES") and repeat? > > Sure! > The three pics: > 0x40 - http://www.dragas.org/~draga/IMG_20120909_105237.jpg > 0x08 - http://www.dragas.org/~draga/IMG_20120909_105356.jpg > 0x01 - http://www.dragas.org/~draga/IMG_20120909_105506.jpg Thanks. One more thing I see there is missing one or both "AHCI reset: device ready after Xms" messages. There should always be either such message or "AHCI reset: device not ready after 31ms" for each connected device. "AHCI reset: device ready after 0ms" I see there is a bit special from point that it completes immediately without using callout(9) events. That and also the fact that AHCI reset sequence haven't changed since FreeBSD 9.0 makes me guess that problem may be not in ahci(4) driver, but in timecounters(4), eventtimers(4) or callout(9) subsystems. Could you try to add such loader tunable: kern.eventtimer.timer="i8254" If it help, send me output of `sysctl kern.eventtimer` and full verbose dmesg. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sat, 08 Sep 2012 20:49:54 +0300 On 08.09.2012 20:37, Stefano Marinelli wrote: >> We should somehow try to find out what happened with disk on first AHCI >> channel. Unluckily it is impossible to specify single bus for debugging >> during boot time. So unless your camera can do high-speed series of shots >> to grab previous screens all we can do is to reduce log details to make >> them fit the screen. Please try to set kern.cam.dflags separately to 0x40, >> 0x08 and 0x01, and send me the outputs. > > Thank you for your help. > Here's the pics: > > 0x40: http://www.dragas.org/~draga/IMG_20120908_192301.jpg > 0x08: http://www.dragas.org/~draga/IMG_20120908_192429.jpg > 0x01: http://www.dragas.org/~draga/IMG_20120908_192550.jpg Thanks. As I see here, disk probe stopped just on soft-reset stage. I still see no problem there, except that soft-reset didn't complete. Looking on messages, I think you have no verbose kernel messages enabled. Could you enable them (boot_verbose="YES") and repeat? -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: Stefano Marinelli Cc: atti...@freebsd.org, bug-follo...@freebsd.org Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sat, 08 Sep 2012 19:04:56 +0300 On 08.09.2012 16:38, Stefano Marinelli wrote: > >> Could you try to enable CAM debugging by setting kern.cam.dflags=0xff >> loader tunable either from loader prompt or /boot/loader.conf? It should >> tell us on what stage of device detection hang happens. > > > Tried that. I can't dmesg, but here's a picture of the screen grabbed just > after the hang: http://www.dragas.org/~draga/IMG_20120908_153219.jpg Thank you. Unluckily it doesn't show much. I see two things there: 1) probe of the ATAPI device on second AHCI channel that completed perfectly without any visible problem; 2) probe start for some device on ctl2cam0 virtual bus that didn't completed there, but it is unclear whether it is related to the problem or just was running in unlucky time. I have no experience to tell what behavior to expect from it. We should somehow try to find out what happened with disk on first AHCI channel. Unluckily it is impossible to specify single bus for debugging during boot time. So unless your camera can do high-speed series of shots to grab previous screens all we can do is to reduce log details to make them fit the screen. Please try to set kern.cam.dflags separately to 0x40, 0x08 and 0x01, and send me the outputs. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
The following reply was made to PR amd64/171355; it has been noted by GNATS. From: Alexander Motin To: bug-follo...@freebsd.org, stef...@dragas.it Cc: Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl Date: Sat, 08 Sep 2012 14:39:11 +0300 Could you try to enable CAM debugging by setting kern.cam.dflags=0xff loader tunable either from loader prompt or /boot/loader.conf? It should tell us on what stage of device detection hang happens. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/170487: [boot] Thinkpad X61s cannot boot 9.1-BETA1
The following reply was made to PR amd64/170487; it has been noted by GNATS. From: Alexander Motin To: bug-follo...@freebsd.org, p...@intersonic.se Cc: Subject: Re: amd64/170487: [boot] Thinkpad X61s cannot boot 9.1-BETA1 Date: Sat, 08 Sep 2012 14:38:04 +0300 Could you try to enable CAM debugging by setting kern.cam.dflags=0xff loader tunable either from loader prompt or /boot/loader.conf? It should tell us on what stage of device detection hang happens. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/148526: [ahci] ahci driver does not boot on AMD chip
The following reply was made to PR amd64/148526; it has been noted by GNATS. From: Alexander Motin To: Yury Cc: Andriy Gapon , bug-followup Subject: Re: amd64/148526: [ahci] ahci driver does not boot on AMD chip Date: Fri, 17 Dec 2010 11:32:50 +0200 Yury wrote: > Yes, pciconf is non-empty about MSI (attached). > > And the hint.ahci.0.msi="0" in loader.conf worked for me, with it it can > boot, thank you. > `Good' AHCI verbose messages are attached also. > (The kernel configuration was changed to not only include AHCI, but also > ATA driver, because I have IDE CD-ROM.) As I can see, AHCI is not the only controller in this system using MSI. Does the others (sound, network, ...) work correctly? Linux explicitly disables MSI for SB600 chips, but not for this SB700. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/148526: [ahci] ahci driver does not boot on AMD chip
The following reply was made to PR amd64/148526; it has been noted by GNATS. From: Alexander Motin To: Yury Cc: Andriy Gapon , bug-follo...@freebsd.org Subject: Re: amd64/148526: [ahci] ahci driver does not boot on AMD chip Date: Thu, 16 Dec 2010 19:39:50 +0200 On 16.12.2010 19:11, Andriy Gapon wrote: > on 09/12/2010 19:08 Yury said the following: >> Here they are, message files. >> >> The "bad" file is messages during boot try with the ahci driver, and the >> "good" >> one is the backed up kernel version with ata driver. In the "bad" boot try >> messages last lines could repeat infinitely. And, as I can see there are >> some >> 'time-out' messages in "good" variant, but everything works just fine. BIOS >> was >> updated to 15.06. >> >> Only differences in kernel config files are: >> >> < deviceata >> < deviceatadisk >> --- >> > #deviceata >> > #deviceatadisk >> >> < ##deviceahci >> < deviceatapicd >> --- >> > deviceahci >> > #deviceatapicd >> > > Yury, > will you be able to test ahci with this hardware using stable/8? I can see interrupt status bit set here. Timeout in that case may mean that interrupt was not delivered/handled for some reason. Could you check if this controller supports MSI interrupts with `pciconf -lvbc`? If it does and driver uses it - you may try to disable it by setting loader tunable `hint.ahci.0.msi=0'. It could also be useful to enable verbose kernel messages at boot menu. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/148526: [ahci] ahci driver does not boot on AMD chip
The following reply was made to PR amd64/148526; it has been noted by GNATS. From: Alexander Motin To: Andriy Gapon Cc: bug-follo...@freebsd.org, y...@gorodok.net Subject: Re: amd64/148526: [ahci] ahci driver does not boot on AMD chip Date: Sun, 05 Dec 2010 16:41:17 +0200 On 05.12.2010 16:29, Andriy Gapon wrote: > Can you provide some technical information about the problem? > Screen captures, etc? > > Alexander, > maybe you've got some ideas/suggestions? Not with this info. Verbose dmesg with fresh STABLE would be more useful. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/149713: Kernel crashes on HD timeout
The following reply was made to PR amd64/149713; it has been noted by GNATS. From: Alexander Motin To: bug-follo...@freebsd.org, p...@swarmtv.nl Cc: Subject: Re: amd64/149713: Kernel crashes on HD timeout Date: Tue, 17 Aug 2010 00:11:00 +0300 I think there is two reasons: 1. Too low request timeout value triggers error too early. Increasing timeout should make it less frequent. It was already done in 7-STABLE branch and above. 2. After timeout triggered, panic probably caused by weak locking in ata(4). You may try to upgrade your system, hoping situation was improved. But I would recommend you to upgrade to 8.1 and build kernel with ATA_CAM option, replacing old ata(4) infrastructure with new and probably more reliable one. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/148488: Headphone won't work on NVidia MCP78 High Definition Audio Controller
The following reply was made to PR amd64/148488; it has been noted by GNATS. From: Alexander Motin To: =?ISO-8859-1?Q?St=E9phane_Thibaud?= Cc: bug-follo...@freebsd.org Subject: Re: amd64/148488: Headphone won't work on NVidia MCP78 High Definition Audio Controller Date: Mon, 12 Jul 2010 19:02:37 +0300 Stéphane Thibaud wrote: > Le lundi 12 juillet 2010 07:53:36, Alexander Motin a écrit : >> Difficult to say for sure without seeing verbose dmesg, but may be that >> headphones and microphone input just configured as separate device pcm1. >> You may try to set sysctl hw.snd.default_unit=1 to use that device by >> default. In any way make sure to read snd_hda man page and analyze >> driver's verbose output. > Thanks for your quick response. To be honest I uninstalled PC-BSD already > (in > favor of kubuntu), since I had to have an OS for some basic tasks but I'll > get > back to BSD as soon as 8.1 is released (since you said my SATA would then be > supported in amd64/148489). When the two things I posted actually work in > FreeBSD, then the hardware support for my laptop is practically perfect (and > PC-BSD seems so much more stable than kubuntu, not to mention the terrific > BSD > license!). Can these sound tweaks be tested with the live-boot-thing of > PC-BSD > or is a reboot needed? Default sound device can be set on-the-fly via sysctl. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/127484: [timecounters] Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE
The following reply was made to PR amd64/127484; it has been noted by GNATS. From: Alexander Motin To: bug-follo...@freebsd.org, tg.at.swox@freebsd.org Cc: Subject: Re: amd64/127484: [timecounters] Drift problem with FreeBSD 7.0 and 7.1 PRERELEASE Date: Mon, 12 Jul 2010 10:11:37 +0300 On some AMD chipsets enabling Spread Spectrum makes HPET to run few percents slower then reported by hardware. It is official chipset errata and it should be handled by BIOS SMI code. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/148489: Generic driver is used for Nvidia SATA (nforce? MCP78?)
The following reply was made to PR amd64/148489; it has been noted by GNATS. From: Alexander Motin To: bug-follo...@freebsd.org, snthib...@gmail.com Cc: Subject: Re: amd64/148489: Generic driver is used for Nvidia SATA (nforce? MCP78?) Date: Mon, 12 Jul 2010 08:57:56 +0300 ID for this chipset was added to 8-STABLE after 8.0 release. It should work fine in STABLE and forthcoming 8.1 release. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: amd64/148488: Headphone won't work on NVidia MCP78 High Definition Audio Controller
The following reply was made to PR amd64/148488; it has been noted by GNATS. From: Alexander Motin To: bug-follo...@freebsd.org, snthib...@gmail.com Cc: Subject: Re: amd64/148488: Headphone won't work on NVidia MCP78 High Definition Audio Controller Date: Mon, 12 Jul 2010 08:53:36 +0300 Difficult to say for sure without seeing verbose dmesg, but may be that headphones and microphone input just configured as separate device pcm1. You may try to set sysctl hw.snd.default_unit=1 to use that device by default. In any way make sure to read snd_hda man page and analyze driver's verbose output. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: why does UATA/133 == UATA/100 on amd64?
fbsdm...@dnswatch.com wrote: > On Fri, June 4, 2010 10:58 pm, Alexander Motin wrote: >> Peter Jeremy wrote: >>> On 2010-Jun-04 16:36:08 -0700, fbsdm...@dnswatch.com wrote: >>> >>>> After _finally_ making the correct decisions to install amd64 on an >>>> AMD64 system. I was able to make/build/install world && kernel, I see >>>> a difference in drive recognition. >>> Can you please do a verbose boot and post the resultant dmesg somewhere >>> (preferably with your USB DVD drive connected). >>> >>>> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >>>> kernel: ad6: 476940MB at ata3-master >>>> SATA300 >>>> >>>> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >>>> kernel: ad6: setting UDMA100 >>>> kernel: ad6: 476940MB at ata3-master >>>> UDMA100 >>>> SATA 3Gb/s >>>> >>> The 'UDMA' numbers are meaningless for SATA controllers/drives. >>> >> The 'UDMA' numbers are meaningless for _native_ SATA controllers/drives. >> >> They may be not meaningless for legacy SATA devices, using SATA->PATA >> bridge inside. Some bridges do not support UDMA133 on PATA part, so ata(4) >> prefers not to use it. But in this case it is indeed meaningless. > > If it's not already apparent. The board has an AMD 880G chipset, that > provides RAID support on 6 ports @ 6GBs. Now, from a purely logistical > standpoint. The numbers _can't_ be meaningless. It's clear that the kernel > is making a "judgment call" here: kernel: ad6: setting UDMA100 It is impossible to detect SATA->PATA bridge presence, so kernel has to always follow worst scenario. But as I have said, for this particular device this value affects nothing. > The "judgment call" on both GENERIC/i386, and GENERIC/amd64 was never > made. The capability of both the port && the drive were accepted. Both > cases were booted using "verbose" (5). Please understand, I'm not > attempting to be argumentative here. I just observe this to be true. > In other words; it must have _some_ meaning - no? I have feeling that you have updated your sources while building custom kernel. I can't explain difference you have shown by other reasons. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
Re: why does UATA/133 == UATA/100 on amd64?
Peter Jeremy wrote: > On 2010-Jun-04 16:36:08 -0700, fbsdm...@dnswatch.com wrote: >> After _finally_ making the correct decisions to install amd64 on an >> AMD64 system. I was able to make/build/install world && kernel, I see >> a difference in drive recognition. > > Can you please do a verbose boot and post the resultant dmesg somewhere > (preferably with your USB DVD drive connected). > >> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> kernel: ad6: 476940MB at ata3-master SATA300 > >> kernel: ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire >> kernel: ad6: setting UDMA100 >> kernel: ad6: 476940MB at ata3-master UDMA100 >> SATA 3Gb/s > > The 'UDMA' numbers are meaningless for SATA controllers/drives. The 'UDMA' numbers are meaningless for _native_ SATA controllers/drives. They may be not meaningless for legacy SATA devices, using SATA->PATA bridge inside. Some bridges do not support UDMA133 on PATA part, so ata(4) prefers not to use it. But in this case it is indeed meaningless. -- Alexander Motin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
