Bug 171355
| Summary: | [boot] FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Stefano Marinelli <stefano> |
| Component: | amd64 | Assignee: | freebsd-amd64 (Nobody) <amd64> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Stefano Marinelli
2012-09-05 21:20:03 UTC
On Wednesday, September 05, 2012 4:14:48 pm Stefano Marinelli wrote: > > >Number: 171355 > >Category: amd64 > >Synopsis: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-amd64 > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Wed Sep 05 20:20:03 UTC 2012 > >Closed-Date: > >Last-Modified: > >Originator: Stefano Marinelli > >Release: 9.1-rc1 > >Organization: > >Environment: > impossible to obtain - machine stops at boot > >Description: > Hi, > I tried to install FreeBSD 9.1-rc1 (amd64 and i386, no difference) on the HP Pavilion g6 2147sl. The installation disk's loader runs, the kernel starts to boot then hangs. No strange messages come out (even with verbose output turned on) and the boot process stops there. Everything seems to be recognised in a proper way (usb3, ahci, re0 network card, etc). > I've done some tests (thanks to the suggestions on the ##freebsd irc channel's people) but no success and no further information to add. I can't even go to ddb. But if I remove the cd from the tray, the status change gets detected and the kernel prints something on the screen. > > 9.0 can boot, but it's almost unusable as both the re0 and the wifi interface aren't detected and there isn't any support for power management so fans are running all the time. > > It seems to stop after USB recognition. But I guess it's already finished> with usb... Does 9.1 fail to recognize the on-board disk? I've seen several reports of 9.1 failing to discover certain SSD's but working ok with spinning disks on IBM laptops where 9.0 worked fine. -- John Baldwin >> It seems to stop after USB recognition. But I guess it's already = finished>=20 > with usb... >=20 > Does 9.1 fail to recognize the on-board disk? I've seen several = reports of=20 > 9.1 failing to discover certain SSD's but working ok with spinning = disks on=20 > IBM laptops where 9.0 worked fine. Mmm...actually, seeing the 9.0 boot order, it seems to hang exactly = before detecting the disk. And I've put a hybrid disk (Seagate Momentus = XT) on this machine... Stefano= Stefano, can you please make available somewhere the output of the verbose dmesg with hanging 9.1? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein 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 > Could you try to enable CAM debugging by setting kern.cam.dflags=3D0xff = 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, Stefano= 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 > 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 Hope it helps. Stefano= 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 > 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. >=20 > Looking on messages, I think you have no verbose kernel messages = enabled. Could you enable them (boot_verbose=3D"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 Thank you, Stefano= 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 > Could you try to add such loader tunable:
> kern.eventtimer.timer=3D"i8254"
Bingo! :)
It is booting now!
I will install 9.1rc1 later and send you all the info as soon as I'll =
have a booting system.
Stefano=
> 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. Thank you, Stefano= 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 > 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 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 <cpu count=3D"2" mask=3D"3">0, 1</cpu> <cpu count=3D"2" mask=3D"3">0, 1</cpu> 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=3D\_PR_.C000 dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 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=3D\_PR_.C001 dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 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 More, the machine hangs when performing a shutdown or reboot. Thank you, Stefano= On Sun, Sep 9, 2012 at 8:27 PM, Stefano Marinelli <stefano@dragas.it> wrote= : >> It looks like the problem is in HPET timer operation. There are number o= f known and handled problems with AMD HPETs, but seems like you've found ne= w 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. Defau= lt value is 98304. You may try to double it. The specified value must be mu= ltiple 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 > > 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. O= n Linux, I can see the cpu lowering its frequencies. On FreeBSD, it seems i= t 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 > <cpu count=3D"2" mask=3D"3">0, 1</cpu> > <cpu count=3D"2" mask=3D"3">0, 1</cpu> > 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=3D\_PR_.C000 > dev.cpu.0.%pnpinfo: _HID=3Dnone _UID=3D0 > 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=3D\_PR_.C001 > dev.cpu.1.%pnpinfo: _HID=3Dnone _UID=3D0 > 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 > > More, the machine hangs when performing a shutdown or reboot. Can you please show the reboot/shutdown console output? Also, can you please show the value of sysctl hw.acpi.handle_reboot ? Attilio --=20 Peace can only be achieved by understanding - A. Einstein > Can you please show the reboot/shutdown console output? > Also, can you please show the value of sysctl hw.acpi.handle_reboot ? Sure. The sysctl hw.acpi.handle_reboot value is 1 The reboot (shutdown prints the same output) gives: = http://www.dragas.org/~draga/rps20120909_214157_737.jpg Thank you, Stefano= 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_AMD 0x4353 +#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 = 0x00000000; /* * 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 > <cpu count="2" mask="3">0, 1</cpu> > <cpu count="2" mask="3">0, 1</cpu> > 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 Author: mav Date: Sun Sep 9 20:00:00 2012 New Revision: 240286 URL: http://svn.freebsd.org/changeset/base/240286 Log: At least from A70M FCH chipsets AMD started to use their real vendor ID (1022) in HPET. But according to report they still haven't fixed problem with level-triggered interrupts. Make workaround used for earlier chipsets apply to this new ID also. PR: amd64/171355 MFC after: 3 days Modified: head/sys/dev/acpica/acpi_hpet.c Modified: head/sys/dev/acpica/acpi_hpet.c ============================================================================== --- head/sys/dev/acpica/acpi_hpet.c Sun Sep 9 19:20:23 2012 (r240285) +++ head/sys/dev/acpica/acpi_hpet.c Sun Sep 9 20:00:00 2012 (r240286) @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$"); #endif #define HPET_VENDID_AMD 0x4353 +#define HPET_VENDID_AMD2 0x1022 #define HPET_VENDID_INTEL 0x8086 #define HPET_VENDID_NVIDIA 0x10de #define HPET_VENDID_SW 0x1166 @@ -505,7 +506,7 @@ hpet_attach(device_t dev) * 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 = 0x00000000; /* * NVidia MCP5x chipsets have number of unexplained interrupt _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" > 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=3D"C2" > economy_cx_lowest=3D"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. Thank you, Stefano= 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 > 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. Thank you, Stefano= 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 > 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=3D1 > hint.attimer.0.clock=3D0 > hint.atrtc.0.clock=3D0 After patching the kernel, I can now boot without tunables. Should I try = to set those values on the patched or unpatched kernel? Thanks, Stefano= 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 >>> hint.hpet.0.legacy_route=3D1 >>> hint.attimer.0.clock=3D0 >>> hint.atrtc.0.clock=3D0 I tried on both the patched and the unpatched kernel. The unpatched kernel refuses to boot (hangs as if I didn't write = anything). The patched one boots with this dmesg: = http://www.dragas.org/~draga/dmesg2.txt Thank you, Stefano 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 >> The patched one boots with this dmesg: = http://www.dragas.org/~draga/dmesg2.txt >=20 > 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?=20 Meanwhile, thank you very very much for your help.=20 Stefano= 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 Author: mav Date: Wed Sep 12 09:29:22 2012 New Revision: 240384 URL: http://svn.freebsd.org/changeset/base/240384 Log: MFC r240286: At least from A70M FCH chipsets AMD started to use their real vendor ID (1022) in HPET. But according to report they still haven't fixed problem with level-triggered interrupts. Make workaround used for earlier chipsets apply to this new ID also. PR: amd64/171355 Modified: stable/9/sys/dev/acpica/acpi_hpet.c Directory Properties: stable/9/sys/ (props changed) stable/9/sys/dev/ (props changed) Modified: stable/9/sys/dev/acpica/acpi_hpet.c ============================================================================== --- stable/9/sys/dev/acpica/acpi_hpet.c Wed Sep 12 09:20:37 2012 (r240383) +++ stable/9/sys/dev/acpica/acpi_hpet.c Wed Sep 12 09:29:22 2012 (r240384) @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$"); #endif #define HPET_VENDID_AMD 0x4353 +#define HPET_VENDID_AMD2 0x1022 #define HPET_VENDID_INTEL 0x8086 #define HPET_VENDID_NVIDIA 0x10de #define HPET_VENDID_SW 0x1166 @@ -505,7 +506,7 @@ hpet_attach(device_t dev) * 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 = 0x00000000; /* * NVidia MCP5x chipsets have number of unexplained interrupt _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" Author: mav Date: Wed Sep 12 10:53:08 2012 New Revision: 240390 URL: http://svn.freebsd.org/changeset/base/240390 Log: MFC r240286: At least from A70M FCH chipsets AMD started to use their real vendor ID (1022) in HPET. But according to report they still haven't fixed problem with level-triggered interrupts. Make workaround used for earlier chipsets apply to this new ID also. PR: amd64/171355 Approved by: re (kib) Modified: releng/9.1/sys/dev/acpica/acpi_hpet.c Directory Properties: releng/9.1/sys/ (props changed) releng/9.1/sys/dev/ (props changed) Modified: releng/9.1/sys/dev/acpica/acpi_hpet.c ============================================================================== --- releng/9.1/sys/dev/acpica/acpi_hpet.c Wed Sep 12 10:39:47 2012 (r240389) +++ releng/9.1/sys/dev/acpica/acpi_hpet.c Wed Sep 12 10:53:08 2012 (r240390) @@ -57,6 +57,7 @@ __FBSDID("$FreeBSD$"); #endif #define HPET_VENDID_AMD 0x4353 +#define HPET_VENDID_AMD2 0x1022 #define HPET_VENDID_INTEL 0x8086 #define HPET_VENDID_NVIDIA 0x10de #define HPET_VENDID_SW 0x1166 @@ -505,7 +506,7 @@ hpet_attach(device_t dev) * 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 = 0x00000000; /* * NVidia MCP5x chipsets have number of unexplained interrupt _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" State Changed From-To: open->closed Fix committed and merged down to 9-STABLE and 9.1-RELEASE. |
