From nobody@FreeBSD.org  Wed Sep  5 20:14:48 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id A664A106566C
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  5 Sep 2012 20:14:48 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 923FE8FC0C
	for <freebsd-gnats-submit@FreeBSD.org>; Wed,  5 Sep 2012 20:14:48 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.5/8.14.5) with ESMTP id q85KEmfZ017877
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 5 Sep 2012 20:14:48 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.5/8.14.5/Submit) id q85KEmmB017876;
	Wed, 5 Sep 2012 20:14:48 GMT
	(envelope-from nobody)
Message-Id: <201209052014.q85KEmmB017876@red.freebsd.org>
Date: Wed, 5 Sep 2012 20:14:48 GMT
From: Stefano Marinelli <stefano@dragas.it>
To: freebsd-gnats-submit@FreeBSD.org
Subject: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         171355
>Category:       amd64
>Synopsis:       [boot] FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-amd64
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 05 20:20:03 UTC 2012
>Closed-Date:    Wed Sep 12 10:54:30 UTC 2012
>Last-Modified:  Wed Sep 12 11:00:05 UTC 2012
>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...
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:

From: John Baldwin <jhb@freebsd.org>
To: freebsd-amd64@freebsd.org
Cc: Stefano Marinelli <stefano@dragas.it>,
 freebsd-gnats-submit@freebsd.org,
 Alexander Motin <mav@freebsd.org>,
 re@freebsd.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Thu, 6 Sep 2012 14:10:12 -0400

 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

From: Stefano Marinelli <stefano@dragas.it>
To: John Baldwin <jhb@freebsd.org>
Cc: freebsd-amd64@freebsd.org,
 freebsd-gnats-submit@freebsd.org,
 Alexander Motin <mav@freebsd.org>,
 re@freebsd.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Fri, 7 Sep 2012 19:50:12 +0200

 >> 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=

From: Attilio Rao <attilio@freebsd.org>
To: bug-followup@FreeBSD.org, stefano@dragas.it, 
	John Baldwin <jhb@freebsd.org>
Cc:  
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP
 Pavilion g6 2147sl
Date: Fri, 7 Sep 2012 21:11:11 +0100

 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

From: Alexander Motin <mav@FreeBSD.org>
To: bug-followup@FreeBSD.org, stefano@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
 

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>,
 attilio@freebsd.org
Cc: bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sat, 8 Sep 2012 15:38:37 +0200

 > 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sat, 8 Sep 2012 19:37:44 +0200

 > 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 12:05:26 +0200

 > 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 12:57:39 +0200

 > 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=

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 14:58:28 +0200

 > 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 21:27:28 +0200

 > 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=

From: Attilio Rao <attilio@freebsd.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: Alexander Motin <mav@freebsd.org>, bug-followup@freebsd.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP
 Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 20:30:00 +0100

 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

From: Stefano Marinelli <stefano@dragas.it>
To: attilio@FreeBSD.org
Cc: Alexander Motin <mav@freebsd.org>,
 bug-followup@freebsd.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 21:44:02 +0200

 > 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@FreeBSD.org, 
 John Baldwin <jhb@freebsd.org>,
 re@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_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

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: amd64/171355: commit references a PR
Date: Sun,  9 Sep 2012 20:00:39 +0000 (UTC)

 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"
 

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org,
 John Baldwin <jhb@freebsd.org>,
 re@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 22:03:24 +0200

 > 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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
 
 

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 22:17:20 +0200

 > 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 23:09:47 +0200

 > 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 23:16:21 +0200

 >>> 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
 

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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

From: Stefano Marinelli <stefano@dragas.it>
To: Alexander Motin <mav@FreeBSD.org>
Cc: attilio@freebsd.org,
 bug-followup@FreeBSD.org
Subject: Re: amd64/171355: FreeBSD 9.1rc1 (and 10-HEAD) not booting on HP Pavilion g6 2147sl
Date: Sun, 9 Sep 2012 23:44:20 +0200

 >> 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=

From: Alexander Motin <mav@FreeBSD.org>
To: Stefano Marinelli <stefano@dragas.it>
Cc: attilio@freebsd.org, bug-followup@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

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: amd64/171355: commit references a PR
Date: Wed, 12 Sep 2012 09:29:35 +0000 (UTC)

 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"
 
State-Changed-From-To: open->closed 
State-Changed-By: mav 
State-Changed-When: Wed Sep 12 10:53:40 UTC 2012 
State-Changed-Why:  
Fix committed and merged down to 9-STABLE and 9.1-RELEASE. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=171355 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: amd64/171355: commit references a PR
Date: Wed, 12 Sep 2012 10:53:21 +0000 (UTC)

 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"
 
>Unformatted:
