Re: [RFC, RFT] LDM support (aka Windows Dynamic Volumes)
2012/3/11 Andrey V. Elsukov : > On 11.03.2012 23:31, Adrian Chadd wrote: >> This is awesome! >> >> Is it just read-only, or does it allow creation/destruction of LDM volumes? > > It is read-only, but you can partially destroy LDM metadata on given disk. > LDM keeps information about all volumes on each disk, and i guess windows > can recover destroyed metadata. It is targeted to get access to some windows > partitions. Actually, it is possible make better LDM support in conjunction > with GEOM_RAID, but i think we don't need it :) Hah, I wouldn't say no to being able to modify (correctly) LDM metadat.a i'd also love to see say, read/write Linux LVM support, but that's just me. GEOM people: any chance of getting a review of this? Adrian > > -- > WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC, RFT] LDM support (aka Windows Dynamic Volumes)
On 12.03.2012 11:49, Adrian Chadd wrote: >> partitions. Actually, it is possible make better LDM support in conjunction >> with GEOM_RAID, but i think we don't need it :) > > Hah, I wouldn't say no to being able to modify (correctly) LDM metadat.a > > i'd also love to see say, read/write Linux LVM support, but that's just me. We have geom_linux_lvm, doesn't it work for you? -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC, RFT] LDM support (aka Windows Dynamic Volumes)
On 3/12/12, Adrian Chadd wrote: > 2012/3/11 Andrey V. Elsukov : >> On 11.03.2012 23:31, Adrian Chadd wrote: >>> This is awesome! >>> >>> Is it just read-only, or does it allow creation/destruction of LDM >>> volumes? >> >> It is read-only, but you can partially destroy LDM metadata on given disk. >> LDM keeps information about all volumes on each disk, and i guess windows >> can recover destroyed metadata. It is targeted to get access to some >> windows >> partitions. Actually, it is possible make better LDM support in >> conjunction >> with GEOM_RAID, but i think we don't need it :) > > Hah, I wouldn't say no to being able to modify (correctly) LDM metadat.a > > i'd also love to see say, read/write Linux LVM support, but that's just me. > > GEOM people: any chance of getting a review of this? In NetBSD this feature already exists: http://www.netbsd.org/docs/guide/en/chap-lvm.html > > > Adrian > >> >> -- >> WBR, Andrey V. Elsukov > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sudo through ssh broken on -current?
On 11. Mar 2012, at 23:55 , Michael Butler wrote: > I noted some thing odd when executing the following .. > > /home/imb> ssh imb@ "sudo /sbin/ipfw list" > > sudo: (malloc) /usr/src/lib/libc/stdlib/malloc.c:2644: Failed assertion: > "(run->regs_mask[elm] & (1U << bit)) == 0" > Abort > > Adding '-t' as a parameter to ssh runs without the assert, yeah latest sudo seems to be rather *argh* I have heard about this twice already but it always ended with abandoning sudo I think. ssh has nothing to do with it; same happens for local users as much as I am aware. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC, RFT] LDM support (aka Windows Dynamic Volumes)
On 11/03/2012 10:35, Andrey V. Elsukov wrote: > Hi, All > > i wrote GEOM_PART_LDM class. It provides basic support of Logical Disk Manager > partitioning scheme [1]. Since LDM metadata is not documented i used several > articles found in the web and linux implementation as reference [2]. Seems ok, but there are a lot of "magic numbers" sprinkled around, which could possibly be better expressed as named constants / macros. E.g. in ldm_privhdr_parse(), ldm_tochdr_check(), as the array size in line 434, in the switch block in lines 635, etc. I don't think it's a big problem, though. You could use SLIST_FOREACH_SAFE in ldm_vmdb_free(), but that's also not a problem. You have a lot of deeply nested loops in ldm_vmdb_parse() and others, which may be "flattened" by removing the inner loops into separate functions (so you don't run into the 80 column limit so often), but again, not a problem. Looks ok. signature.asc Description: OpenPGP digital signature
Re: sudo through ssh broken on -current?
On 2012-03-12 00:55, Michael Butler wrote: > I noted some thing odd when executing the following .. > > /home/imb> ssh imb@ "sudo /sbin/ipfw list" > > sudo: (malloc) /usr/src/lib/libc/stdlib/malloc.c:2644: Failed assertion: > "(run->regs_mask[elm] & (1U << bit)) == 0" > Abort > > Adding '-t' as a parameter to ssh runs without the assert, This is a double free bug in sudo: http://www.sudo.ws/bugs/show_bug.cgi?id=544 Alternative fix: http://www.andric.com/freebsd/security-sudo-fix-double-free-1.diff ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Double free() in libc or gdb ?
Dear all, I'm currently having some trouble with the dynamic loader. I have the libc compilled with "MALLOC_DEBUG" flag to detect double free. When i run this piece of code (attached file) thought GDB, i have this assertion : Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0), function arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 2543. But when i run the same binary without GDB, no assert. I'm very confused. Can you help me to debug that ? Best regards -- Alexandre Martins NETASQ -- We secure IT
Re: Double free() in libc or gdb ?
On Mon, Mar 12, 2012 at 05:50:33PM +0100, Alexandre Martins wrote: > Dear all, > > I'm currently having some trouble with the dynamic loader. > > I have the libc compilled with "MALLOC_DEBUG" flag to detect double free. > When i run this piece of code (attached file) thought GDB, i have this > assertion : > > Assertion failed: ((run->regs_mask[elm] & (1U << bit)) == 0), function > arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 2543. > > But when i run the same binary without GDB, no assert. > > I'm very confused. Can you help me to debug that ? There is no attachment. Put the source somewhere on web. pgprMtcFQlRgB.pgp Description: PGP signature
Improved Intel Turbo Boost status/control
Hi. I'd like to note that recent r232793 change to cpufreq(4) in HEAD opened simple access to the Intel Turbo Boost status/control. I've found that at least two of my desktop systems (based Nehalem and SandyBridge Core i7s) with enabled Intel Turbo Boost in BIOS it is not use it by default, unless powerd is enabled. And before this change it was difficult to detect/fix. ACPI reports extra performance level with frequency 1MHz above the nominal to control Intel Turbo Boost operation. It is not a bug, but feature: dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. After boot with default settings I see: dev.cpu.0.freq: 2933 , that means Turbo Boost is disabled. Enabling powerd or just adding to rc.conf performance_cpu_freq="HIGH" enables Turbo Boost and adds extra 10-20% to the system performance. Turbo Boost operation can be monitored in run-time via the PMC with command that prints number or really executed cycles per CPU core: pmcstat -s unhalted-core-cycles -w 1 -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
В Mon, 12 Mar 2012 21:15:35 +0200 Alexander Motin пишет: > Hi. > > I'd like to note that recent r232793 change to cpufreq(4) in HEAD > opened simple access to the Intel Turbo Boost status/control. I've > found that at least two of my desktop systems (based Nehalem and > SandyBridge Core i7s) with enabled Intel Turbo Boost in BIOS it is > not use it by default, unless powerd is enabled. And before this > change it was difficult to detect/fix. > > ACPI reports extra performance level with frequency 1MHz above the > nominal to control Intel Turbo Boost operation. It is not a bug, but > feature: > dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... > In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. > > After boot with default settings I see: > dev.cpu.0.freq: 2933 > , that means Turbo Boost is disabled. > > Enabling powerd or just adding to rc.conf > performance_cpu_freq="HIGH" > enables Turbo Boost and adds extra 10-20% to the system performance. > > Turbo Boost operation can be monitored in run-time via the PMC with > command that prints number or really executed cycles per CPU core: > pmcstat -s unhalted-core-cycles -w 1 > Thank you very much! performance_cpu_freq="HIGH" and as this option must be combined with state of the processor C1 C2 C3? performance_cx_lowest="XX" economy_cx_lowest="XX" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
On 03/12/12 21:33, Ivan Klymenko wrote: В Mon, 12 Mar 2012 21:15:35 +0200 Alexander Motin пишет: I'd like to note that recent r232793 change to cpufreq(4) in HEAD opened simple access to the Intel Turbo Boost status/control. I've found that at least two of my desktop systems (based Nehalem and SandyBridge Core i7s) with enabled Intel Turbo Boost in BIOS it is not use it by default, unless powerd is enabled. And before this change it was difficult to detect/fix. ACPI reports extra performance level with frequency 1MHz above the nominal to control Intel Turbo Boost operation. It is not a bug, but feature: dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. After boot with default settings I see: dev.cpu.0.freq: 2933 , that means Turbo Boost is disabled. Enabling powerd or just adding to rc.conf performance_cpu_freq="HIGH" enables Turbo Boost and adds extra 10-20% to the system performance. Turbo Boost operation can be monitored in run-time via the PMC with command that prints number or really executed cycles per CPU core: pmcstat -s unhalted-core-cycles -w 1 Thank you very much! performance_cpu_freq="HIGH" and as this option must be combined with state of the processor C1 C2 C3? performance_cx_lowest="XX" economy_cx_lowest="XX" The more CPU cores on package are sleeping and the deeper they are sleeping, the bigger will be boost for remaining active cores. Without using deeper C-states boost is usually quite small (about 100-200MHz for desktop chips). Enabling C-states increases it in few times. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
В Mon, 12 Mar 2012 21:55:21 +0200 Alexander Motin пишет: > On 03/12/12 21:33, Ivan Klymenko wrote: > > В Mon, 12 Mar 2012 21:15:35 +0200 > > Alexander Motin пишет: > >> I'd like to note that recent r232793 change to cpufreq(4) in HEAD > >> opened simple access to the Intel Turbo Boost status/control. I've > >> found that at least two of my desktop systems (based Nehalem and > >> SandyBridge Core i7s) with enabled Intel Turbo Boost in BIOS it is > >> not use it by default, unless powerd is enabled. And before this > >> change it was difficult to detect/fix. > >> > >> ACPI reports extra performance level with frequency 1MHz above the > >> nominal to control Intel Turbo Boost operation. It is not a bug, > >> but feature: > >> dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... > >> In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. > >> > >> After boot with default settings I see: > >> dev.cpu.0.freq: 2933 > >> , that means Turbo Boost is disabled. > >> > >> Enabling powerd or just adding to rc.conf > >> performance_cpu_freq="HIGH" > >> enables Turbo Boost and adds extra 10-20% to the system > >> performance. > >> > >> Turbo Boost operation can be monitored in run-time via the PMC with > >> command that prints number or really executed cycles per CPU core: > >> pmcstat -s unhalted-core-cycles -w 1 > >> > > > > Thank you very much! > > performance_cpu_freq="HIGH" > > and as this option must be combined with state of the processor C1 > > C2 C3? > > performance_cx_lowest="XX" > > economy_cx_lowest="XX" > > The more CPU cores on package are sleeping and the deeper they are > sleeping, the bigger will be boost for remaining active cores. > Without using deeper C-states boost is usually quite small (about > 100-200MHz for desktop chips). Enabling C-states increases it in few > times. > I have a Core i5 c Turbo Boost technology (enabled in BIOS) After the following: sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 200/2489 100/1244 performance_cpu_freq="HIGH" >> /etc/rc.conf /etc/rc.d/powerd restart sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 200/2489 100/1244 CPU frequency does not rise above 2300 Mhz What am I doing wrong? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
On 03/12/12 22:05, Ivan Klymenko wrote: В Mon, 12 Mar 2012 21:55:21 +0200 Alexander Motin пишет: On 03/12/12 21:33, Ivan Klymenko wrote: В Mon, 12 Mar 2012 21:15:35 +0200 Alexander Motin пишет: I'd like to note that recent r232793 change to cpufreq(4) in HEAD opened simple access to the Intel Turbo Boost status/control. I've found that at least two of my desktop systems (based Nehalem and SandyBridge Core i7s) with enabled Intel Turbo Boost in BIOS it is not use it by default, unless powerd is enabled. And before this change it was difficult to detect/fix. ACPI reports extra performance level with frequency 1MHz above the nominal to control Intel Turbo Boost operation. It is not a bug, but feature: dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. After boot with default settings I see: dev.cpu.0.freq: 2933 , that means Turbo Boost is disabled. Enabling powerd or just adding to rc.conf performance_cpu_freq="HIGH" enables Turbo Boost and adds extra 10-20% to the system performance. Turbo Boost operation can be monitored in run-time via the PMC with command that prints number or really executed cycles per CPU core: pmcstat -s unhalted-core-cycles -w 1 Thank you very much! performance_cpu_freq="HIGH" and as this option must be combined with state of the processor C1 C2 C3? performance_cx_lowest="XX" economy_cx_lowest="XX" The more CPU cores on package are sleeping and the deeper they are sleeping, the bigger will be boost for remaining active cores. Without using deeper C-states boost is usually quite small (about 100-200MHz for desktop chips). Enabling C-states increases it in few times. I have a Core i5 c Turbo Boost technology (enabled in BIOS) After the following: sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 200/2489 100/1244 performance_cpu_freq="HIGH">> /etc/rc.conf /etc/rc.d/powerd restart sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 200/2489 100/1244 CPU frequency does not rise above 2300 Mhz What am I doing wrong? performance_cpu_freq variable handled not by /etc/rc.d/powerd, but /etc/rc.d/power_profile. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
В Mon, 12 Mar 2012 22:11:28 +0200 Alexander Motin пишет: > On 03/12/12 22:05, Ivan Klymenko wrote: > > В Mon, 12 Mar 2012 21:55:21 +0200 > > Alexander Motin пишет: > > > >> On 03/12/12 21:33, Ivan Klymenko wrote: > >>> В Mon, 12 Mar 2012 21:15:35 +0200 > >>> Alexander Motin пишет: > I'd like to note that recent r232793 change to cpufreq(4) in HEAD > opened simple access to the Intel Turbo Boost status/control. > I've found that at least two of my desktop systems (based > Nehalem and SandyBridge Core i7s) with enabled Intel Turbo Boost > in BIOS it is not use it by default, unless powerd is enabled. > And before this change it was difficult to detect/fix. > > ACPI reports extra performance level with frequency 1MHz above > the nominal to control Intel Turbo Boost operation. It is not a > bug, but feature: > dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... > In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. > > After boot with default settings I see: > dev.cpu.0.freq: 2933 > , that means Turbo Boost is disabled. > > Enabling powerd or just adding to rc.conf > performance_cpu_freq="HIGH" > enables Turbo Boost and adds extra 10-20% to the system > performance. > > Turbo Boost operation can be monitored in run-time via the PMC > with command that prints number or really executed cycles per > CPU core: pmcstat -s unhalted-core-cycles -w 1 > > >>> > >>> Thank you very much! > >>> performance_cpu_freq="HIGH" > >>> and as this option must be combined with state of the processor C1 > >>> C2 C3? > >>> performance_cx_lowest="XX" > >>> economy_cx_lowest="XX" > >> > >> The more CPU cores on package are sleeping and the deeper they are > >> sleeping, the bigger will be boost for remaining active cores. > >> Without using deeper C-states boost is usually quite small (about > >> 100-200MHz for desktop chips). Enabling C-states increases it in > >> few times. > >> > > > > I have a Core i5 c Turbo Boost technology (enabled in BIOS) > > After the following: > > sysctl dev.cpu.0.freq_levels > > dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 > > 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 > > 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 > > 200/2489 100/1244 > > > > performance_cpu_freq="HIGH">> /etc/rc.conf > > > > /etc/rc.d/powerd restart > > > > sysctl dev.cpu.0.freq_levels > > dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 > > 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 > > 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 > > 200/2489 100/1244 > > > > CPU frequency does not rise above 2300 Mhz > > > > What am I doing wrong? > > performance_cpu_freq variable handled not by /etc/rc.d/powerd, but > /etc/rc.d/power_profile. > ok I remove and insert power supply unit connector - nothing has changed... sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 200/2489 100/1244 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
В Mon, 12 Mar 2012 22:11:28 +0200 Alexander Motin пишет: > On 03/12/12 22:05, Ivan Klymenko wrote: > > В Mon, 12 Mar 2012 21:55:21 +0200 > > Alexander Motin пишет: > > > >> On 03/12/12 21:33, Ivan Klymenko wrote: > >>> В Mon, 12 Mar 2012 21:15:35 +0200 > >>> Alexander Motin пишет: > I'd like to note that recent r232793 change to cpufreq(4) in HEAD > opened simple access to the Intel Turbo Boost status/control. > I've found that at least two of my desktop systems (based > Nehalem and SandyBridge Core i7s) with enabled Intel Turbo Boost > in BIOS it is not use it by default, unless powerd is enabled. > And before this change it was difficult to detect/fix. > > ACPI reports extra performance level with frequency 1MHz above > the nominal to control Intel Turbo Boost operation. It is not a > bug, but feature: > dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... > In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. > > After boot with default settings I see: > dev.cpu.0.freq: 2933 > , that means Turbo Boost is disabled. > > Enabling powerd or just adding to rc.conf > performance_cpu_freq="HIGH" > enables Turbo Boost and adds extra 10-20% to the system > performance. > > Turbo Boost operation can be monitored in run-time via the PMC > with command that prints number or really executed cycles per > CPU core: pmcstat -s unhalted-core-cycles -w 1 > > >>> > >>> Thank you very much! > >>> performance_cpu_freq="HIGH" > >>> and as this option must be combined with state of the processor C1 > >>> C2 C3? > >>> performance_cx_lowest="XX" > >>> economy_cx_lowest="XX" > >> > >> The more CPU cores on package are sleeping and the deeper they are > >> sleeping, the bigger will be boost for remaining active cores. > >> Without using deeper C-states boost is usually quite small (about > >> 100-200MHz for desktop chips). Enabling C-states increases it in > >> few times. > >> > > > > I have a Core i5 c Turbo Boost technology (enabled in BIOS) > > After the following: > > sysctl dev.cpu.0.freq_levels > > dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 > > 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 > > 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 > > 200/2489 100/1244 > > > > performance_cpu_freq="HIGH">> /etc/rc.conf > > > > /etc/rc.d/powerd restart > > > > sysctl dev.cpu.0.freq_levels > > dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 > > 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 > > 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 > > 200/2489 100/1244 > > > > CPU frequency does not rise above 2300 Mhz > > > > What am I doing wrong? > > performance_cpu_freq variable handled not by /etc/rc.d/powerd, but > /etc/rc.d/power_profile. > hm :( hw.acpi.acline: 1 no change status :( apparently something is broken with ACPI ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
On 03/12/12 22:22, Ivan Klymenko wrote: В Mon, 12 Mar 2012 22:11:28 +0200 Alexander Motin пишет: On 03/12/12 22:05, Ivan Klymenko wrote: В Mon, 12 Mar 2012 21:55:21 +0200 Alexander Motin пишет: On 03/12/12 21:33, Ivan Klymenko wrote: В Mon, 12 Mar 2012 21:15:35 +0200 Alexander Motinпишет: I'd like to note that recent r232793 change to cpufreq(4) in HEAD opened simple access to the Intel Turbo Boost status/control. I've found that at least two of my desktop systems (based Nehalem and SandyBridge Core i7s) with enabled Intel Turbo Boost in BIOS it is not use it by default, unless powerd is enabled. And before this change it was difficult to detect/fix. ACPI reports extra performance level with frequency 1MHz above the nominal to control Intel Turbo Boost operation. It is not a bug, but feature: dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. After boot with default settings I see: dev.cpu.0.freq: 2933 , that means Turbo Boost is disabled. Enabling powerd or just adding to rc.conf performance_cpu_freq="HIGH" enables Turbo Boost and adds extra 10-20% to the system performance. Turbo Boost operation can be monitored in run-time via the PMC with command that prints number or really executed cycles per CPU core: pmcstat -s unhalted-core-cycles -w 1 Thank you very much! performance_cpu_freq="HIGH" and as this option must be combined with state of the processor C1 C2 C3? performance_cx_lowest="XX" economy_cx_lowest="XX" The more CPU cores on package are sleeping and the deeper they are sleeping, the bigger will be boost for remaining active cores. Without using deeper C-states boost is usually quite small (about 100-200MHz for desktop chips). Enabling C-states increases it in few times. I have a Core i5 c Turbo Boost technology (enabled in BIOS) After the following: sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 200/2489 100/1244 performance_cpu_freq="HIGH">> /etc/rc.conf /etc/rc.d/powerd restart sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 200/2489 100/1244 CPU frequency does not rise above 2300 Mhz What am I doing wrong? performance_cpu_freq variable handled not by /etc/rc.d/powerd, but /etc/rc.d/power_profile. ok I remove and insert power supply unit connector - nothing has changed... sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 200/2489 100/1244 What changes do you expect to see in dev.cpu.0.freq_levels? This list is static. It is dev.cpu.0.freq that may change and that is where difference between 2301 and 2300 should now have effect. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
On Mon, 2012-03-12 at 21:15 +0200, Alexander Motin wrote: > Hi. > > I'd like to note that recent r232793 change to cpufreq(4) in HEAD opened > simple access to the Intel Turbo Boost status/control. I've found that > at least two of my desktop systems (based Nehalem and SandyBridge Core > i7s) with enabled Intel Turbo Boost in BIOS it is not use it by default, > unless powerd is enabled. And before this change it was difficult to > detect/fix. > > ACPI reports extra performance level with frequency 1MHz above the > nominal to control Intel Turbo Boost operation. It is not a bug, but > feature: > dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... > In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. > > After boot with default settings I see: > dev.cpu.0.freq: 2933 > , that means Turbo Boost is disabled. > > Enabling powerd or just adding to rc.conf > performance_cpu_freq="HIGH" > enables Turbo Boost and adds extra 10-20% to the system performance. > > Turbo Boost operation can be monitored in run-time via the PMC with > command that prints number or really executed cycles per CPU core: > pmcstat -s unhalted-core-cycles -w 1 > The r232793 patch applies cleanly to 8-stable and builds just fine, but after install/reboot I don't see a change in the freq_levels revolution > sysctl dev.cpu.0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.coretemp.delta: 70 dev.cpu.0.coretemp.resolution: 1 dev.cpu.0.coretemp.tjmax: 101.0C dev.cpu.0.coretemp.throttle_log: 0 dev.cpu.0.temperature: 31.0C dev.cpu.0.freq: dev.cpu.0.freq_levels: /13 3200/117000 3067/105000 2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 1733/35000 1600/32000 1400/28000 1200/24000 1000/2 800/16000 600/12000 400/8000 200/4000 dev.cpu.0.cx_supported: C1/32 C2/96 C3/128 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 657us revolution > I would have expected a 3334 entry to appear after the reboot. Is this expected (like are there other required changes missing in 8-stable), or do I have something misconfigured? (I can post more info, but don't want to spam the list if the answer is going to be "this shouldn't work in 8.x). -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
В Mon, 12 Mar 2012 22:38:16 +0200 Alexander Motin пишет: > On 03/12/12 22:22, Ivan Klymenko wrote: > > В Mon, 12 Mar 2012 22:11:28 +0200 > > Alexander Motin пишет: > > > >> On 03/12/12 22:05, Ivan Klymenko wrote: > >>> В Mon, 12 Mar 2012 21:55:21 +0200 > >>> Alexander Motin пишет: > >>> > On 03/12/12 21:33, Ivan Klymenko wrote: > > В Mon, 12 Mar 2012 21:15:35 +0200 > > Alexander Motinпишет: > >> I'd like to note that recent r232793 change to cpufreq(4) in > >> HEAD opened simple access to the Intel Turbo Boost > >> status/control. I've found that at least two of my desktop > >> systems (based Nehalem and SandyBridge Core i7s) with enabled > >> Intel Turbo Boost in BIOS it is not use it by default, unless > >> powerd is enabled. And before this change it was difficult to > >> detect/fix. > >> > >> ACPI reports extra performance level with frequency 1MHz above > >> the nominal to control Intel Turbo Boost operation. It is not a > >> bug, but feature: > >> dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... > >> In this case value 2933 means 2.93GHz, but 2934 means > >> 3.2-3.6GHz. > >> > >> After boot with default settings I see: > >> dev.cpu.0.freq: 2933 > >> , that means Turbo Boost is disabled. > >> > >> Enabling powerd or just adding to rc.conf > >> performance_cpu_freq="HIGH" > >> enables Turbo Boost and adds extra 10-20% to the system > >> performance. > >> > >> Turbo Boost operation can be monitored in run-time via the PMC > >> with command that prints number or really executed cycles per > >> CPU core: pmcstat -s unhalted-core-cycles -w 1 > >> > > > > Thank you very much! > > performance_cpu_freq="HIGH" > > and as this option must be combined with state of the processor > > C1 C2 C3? > > performance_cx_lowest="XX" > > economy_cx_lowest="XX" > > The more CPU cores on package are sleeping and the deeper they > are sleeping, the bigger will be boost for remaining active > cores. Without using deeper C-states boost is usually quite > small (about 100-200MHz for desktop chips). Enabling C-states > increases it in few times. > > >>> > >>> I have a Core i5 c Turbo Boost technology (enabled in BIOS) > >>> After the following: > >>> sysctl dev.cpu.0.freq_levels > >>> dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 > >>> 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 > >>> 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 > >>> 200/2489 100/1244 > >>> > >>> performance_cpu_freq="HIGH">> /etc/rc.conf > >>> > >>> /etc/rc.d/powerd restart > >>> > >>> sysctl dev.cpu.0.freq_levels > >>> dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 > >>> 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 > >>> 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 > >>> 200/2489 100/1244 > >>> > >>> CPU frequency does not rise above 2300 Mhz > >>> > >>> What am I doing wrong? > >> > >> performance_cpu_freq variable handled not by /etc/rc.d/powerd, but > >> /etc/rc.d/power_profile. > >> > > > > ok > > > > I remove and insert power supply unit connector - nothing has > > changed... > > > > sysctl dev.cpu.0.freq_levels > > dev.cpu.0.freq_levels: 2301/35000 2300/35000 2000/29079 1800/25766 > > 1600/22265 1400/18904 1225/16541 1200/15996 1050/13996 1000/12907 > > 875/11293 800/9956 700/8711 600/7467 500/6222 400/4978 300/3733 > > 200/2489 100/1244 > > What changes do you expect to see in dev.cpu.0.freq_levels? This list > is static. It is dev.cpu.0.freq that may change and that is where > difference between 2301 and 2300 should now have effect. > I expected that I should be a value greater than 35000 when 2301... it is the same as the next 2300... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Improved Intel Turbo Boost status/control
On 03/12/12 22:45, Ian Lepore wrote: On Mon, 2012-03-12 at 21:15 +0200, Alexander Motin wrote: I'd like to note that recent r232793 change to cpufreq(4) in HEAD opened simple access to the Intel Turbo Boost status/control. I've found that at least two of my desktop systems (based Nehalem and SandyBridge Core i7s) with enabled Intel Turbo Boost in BIOS it is not use it by default, unless powerd is enabled. And before this change it was difficult to detect/fix. ACPI reports extra performance level with frequency 1MHz above the nominal to control Intel Turbo Boost operation. It is not a bug, but feature: dev.cpu.0.freq_levels: 2934/106000 2933/95000 2800/82000 ... In this case value 2933 means 2.93GHz, but 2934 means 3.2-3.6GHz. After boot with default settings I see: dev.cpu.0.freq: 2933 , that means Turbo Boost is disabled. Enabling powerd or just adding to rc.conf performance_cpu_freq="HIGH" enables Turbo Boost and adds extra 10-20% to the system performance. Turbo Boost operation can be monitored in run-time via the PMC with command that prints number or really executed cycles per CPU core: pmcstat -s unhalted-core-cycles -w 1 The r232793 patch applies cleanly to 8-stable and builds just fine, but after install/reboot I don't see a change in the freq_levels revolution> sysctl dev.cpu.0 dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.P001 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.coretemp.delta: 70 dev.cpu.0.coretemp.resolution: 1 dev.cpu.0.coretemp.tjmax: 101.0C dev.cpu.0.coretemp.throttle_log: 0 dev.cpu.0.temperature: 31.0C dev.cpu.0.freq: dev.cpu.0.freq_levels: /13 3200/117000 3067/105000 2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000 2133/48000 2000/43000 1867/39000 1733/35000 1600/32000 1400/28000 1200/24000 1000/2 800/16000 600/12000 400/8000 200/4000 dev.cpu.0.cx_supported: C1/32 C2/96 C3/128 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 657us revolution> I would have expected a 3334 entry to appear after the reboot. Is this expected (like are there other required changes missing in 8-stable), or do I have something misconfigured? (I can post more info, but don't want to spam the list if the answer is going to be "this shouldn't work in 8.x). I don't know any reason why it should not work on 8.x. It is ACPI BIOS duty to report set of frequencies. This patch just makes system to follow it more close. Make sure your CPU supports Turbo Boost and it is enabled in BIOS. On my system disabling Turbo Boost in BIOS removes the frequency from the list. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on amd64/amd64
TB --- 2012-03-12 16:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-12 16:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-03-12 16:20:00 - cleaning the object tree TB --- 2012-03-12 16:20:00 - cvsupping the source tree TB --- 2012-03-12 16:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2012-03-12 16:20:15 - building world TB --- 2012-03-12 16:20:15 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 16:20:15 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 16:20:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-12 16:20:15 - SRCCONF=/dev/null TB --- 2012-03-12 16:20:15 - TARGET=amd64 TB --- 2012-03-12 16:20:15 - TARGET_ARCH=amd64 TB --- 2012-03-12 16:20:15 - TZ=UTC TB --- 2012-03-12 16:20:15 - __MAKE_CONF=/dev/null TB --- 2012-03-12 16:20:15 - cd /src TB --- 2012-03-12 16:20:15 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 12 16:20:16 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Mon Mar 12 18:51:54 UTC 2012 TB --- 2012-03-12 18:51:54 - generating LINT kernel config TB --- 2012-03-12 18:51:54 - cd /src/sys/amd64/conf TB --- 2012-03-12 18:51:54 - /usr/bin/make -B LINT TB --- 2012-03-12 18:51:54 - cd /src/sys/amd64/conf TB --- 2012-03-12 18:51:54 - /usr/sbin/config -m LINT TB --- 2012-03-12 18:51:54 - building LINT kernel TB --- 2012-03-12 18:51:54 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 18:51:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 18:51:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-12 18:51:54 - SRCCONF=/dev/null TB --- 2012-03-12 18:51:54 - TARGET=amd64 TB --- 2012-03-12 18:51:54 - TARGET_ARCH=amd64 TB --- 2012-03-12 18:51:54 - TZ=UTC TB --- 2012-03-12 18:51:54 - __MAKE_CONF=/dev/null TB --- 2012-03-12 18:51:54 - cd /src TB --- 2012-03-12 18:51:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 12 18:51:54 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Mar 12 19:20:52 UTC 2012 TB --- 2012-03-12 19:20:52 - cd /src/sys/amd64/conf TB --- 2012-03-12 19:20:52 - /usr/sbin/config -m LINT-NOINET TB --- 2012-03-12 19:20:52 - building LINT-NOINET kernel TB --- 2012-03-12 19:20:52 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 19:20:52 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 19:20:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-12 19:20:52 - SRCCONF=/dev/null TB --- 2012-03-12 19:20:52 - TARGET=amd64 TB --- 2012-03-12 19:20:52 - TARGET_ARCH=amd64 TB --- 2012-03-12 19:20:52 - TZ=UTC TB --- 2012-03-12 19:20:52 - __MAKE_CONF=/dev/null TB --- 2012-03-12 19:20:52 - cd /src TB --- 2012-03-12 19:20:52 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Mar 12 19:20:53 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Mon Mar 12 19:48:50 UTC 2012 TB --- 2012-03-12 19:48:50 - cd /src/sys/amd64/conf TB --- 2012-03-12 19:48:50 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-03-12 19:48:50 - building LINT-NOINET6 kernel TB --- 2012-03-12 19:48:50 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 19:48:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 19:48:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-12 19:48:50 - SRCCONF=/dev/null TB --- 2012-03-12 19:48:50 - TARGET=amd64 TB --- 2012-03-12 19:48:50 - TARGET_ARCH=amd64 TB --- 2012-03-12 19:48:50 - TZ=UTC TB --- 2012-03-12 19:48:50 - __MAKE_CONF=/dev/null TB --- 2012-03-12 19:48:50 - cd /src TB --- 2012-03-12 19:48:50 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Mar 12 19:48:50 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Mon Mar 12 20:16:46 UTC 2012 TB --- 2012-03-12 20:16:46 - cd /src/sys/amd64/conf TB --- 2012-03-12 20:16:46 - /usr/sbin/config -m LINT-NOIP TB --- 2012-03-12 20:16:46 - building LINT-NOIP kernel TB --- 2012-03-12 20:16:46 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 20:16:46 - MAKEOBJDIRPREFIX=/obj TB --- 20
[head tinderbox] failure on i386/i386
TB --- 2012-03-12 16:20:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-03-12 16:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-03-12 16:20:00 - cleaning the object tree TB --- 2012-03-12 16:20:00 - cvsupping the source tree TB --- 2012-03-12 16:20:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-03-12 16:25:24 - building world TB --- 2012-03-12 16:25:24 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 16:25:24 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 16:25:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-12 16:25:24 - SRCCONF=/dev/null TB --- 2012-03-12 16:25:24 - TARGET=i386 TB --- 2012-03-12 16:25:24 - TARGET_ARCH=i386 TB --- 2012-03-12 16:25:24 - TZ=UTC TB --- 2012-03-12 16:25:24 - __MAKE_CONF=/dev/null TB --- 2012-03-12 16:25:24 - cd /src TB --- 2012-03-12 16:25:24 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 12 16:25:24 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Mar 12 18:28:01 UTC 2012 TB --- 2012-03-12 18:28:01 - generating LINT kernel config TB --- 2012-03-12 18:28:01 - cd /src/sys/i386/conf TB --- 2012-03-12 18:28:01 - /usr/bin/make -B LINT TB --- 2012-03-12 18:28:02 - cd /src/sys/i386/conf TB --- 2012-03-12 18:28:02 - /usr/sbin/config -m LINT TB --- 2012-03-12 18:28:02 - building LINT kernel TB --- 2012-03-12 18:28:02 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 18:28:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 18:28:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-12 18:28:02 - SRCCONF=/dev/null TB --- 2012-03-12 18:28:02 - TARGET=i386 TB --- 2012-03-12 18:28:02 - TARGET_ARCH=i386 TB --- 2012-03-12 18:28:02 - TZ=UTC TB --- 2012-03-12 18:28:02 - __MAKE_CONF=/dev/null TB --- 2012-03-12 18:28:02 - cd /src TB --- 2012-03-12 18:28:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Mar 12 18:28:02 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Mar 12 18:59:05 UTC 2012 TB --- 2012-03-12 18:59:05 - cd /src/sys/i386/conf TB --- 2012-03-12 18:59:05 - /usr/sbin/config -m LINT-NOINET TB --- 2012-03-12 18:59:05 - building LINT-NOINET kernel TB --- 2012-03-12 18:59:05 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 18:59:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 18:59:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-12 18:59:05 - SRCCONF=/dev/null TB --- 2012-03-12 18:59:05 - TARGET=i386 TB --- 2012-03-12 18:59:05 - TARGET_ARCH=i386 TB --- 2012-03-12 18:59:05 - TZ=UTC TB --- 2012-03-12 18:59:05 - __MAKE_CONF=/dev/null TB --- 2012-03-12 18:59:05 - cd /src TB --- 2012-03-12 18:59:05 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Mon Mar 12 18:59:05 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Mon Mar 12 19:28:27 UTC 2012 TB --- 2012-03-12 19:28:27 - cd /src/sys/i386/conf TB --- 2012-03-12 19:28:27 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-03-12 19:28:27 - building LINT-NOINET6 kernel TB --- 2012-03-12 19:28:27 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 19:28:27 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 19:28:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-03-12 19:28:27 - SRCCONF=/dev/null TB --- 2012-03-12 19:28:27 - TARGET=i386 TB --- 2012-03-12 19:28:27 - TARGET_ARCH=i386 TB --- 2012-03-12 19:28:27 - TZ=UTC TB --- 2012-03-12 19:28:27 - __MAKE_CONF=/dev/null TB --- 2012-03-12 19:28:27 - cd /src TB --- 2012-03-12 19:28:27 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Mon Mar 12 19:28:27 UTC 2012 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Mon Mar 12 19:58:02 UTC 2012 TB --- 2012-03-12 19:58:02 - cd /src/sys/i386/conf TB --- 2012-03-12 19:58:02 - /usr/sbin/config -m LINT-NOIP TB --- 2012-03-12 19:58:02 - building LINT-NOIP kernel TB --- 2012-03-12 19:58:02 - CROSS_BUILD_TESTING=YES TB --- 2012-03-12 19:58:02 - MAKEOBJDIRPREFIX=/obj TB --- 2012-03-12 19:58:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2
Re: x220 notes
On Fri, Mar 9, 2012 at 7:24 PM, matt wrote: > On 03/08/12 01:28, Ganael LAPLANCHE wrote: >> >> On Wed, 07 Mar 2012 20:29:16 +0200, Vrachnis Ilias-Dimitrios wrote >> >> Hi, >> 2. I've read bad reviews about webcam having poor quality on GNU/Linux, so I would assume it will be the same on FreeBSD with webcamd and not worth the $30? (which also frees up space for 3x3 antenna) >> >> Yep, the webcam works with webcamd but the quality is not great... >> 4. How far is the AMD64 kernel suspend/resume? What do you mean by video doesn't resume? >> >> I run 10-CURRENT : >> >> FreeBSD laptop.martymac.org 10.0-CURRENT FreeBSD 10.0-CURRENT #12 >> r231062M: Mon Feb 6 10:29:35 CET 2012 >> marty...@laptop.martymac.org:/usr/obj/files/Src/sys/GENERIC amd64 >> >> with all.13.1 patch (no more available) from : >> >> http://people.freebsd.org/~kib/drm/ >> >> 3D acceleration works well, as well as suspend/resume when Xorg has been >> started (black screen if on console). >> >> Best regards, >> >> -- >> Ganael LAPLANCHE >> http://www.martymac.org | http://contribs.martymac.org >> FreeBSD: martymac, http://www.FreeBSD.org >> ___ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> > This is great news! > > I just finished some other stuff, so hopefully I can take a renewed look at > brightness and the fan issue. Thanks for woking on this, Matt. I, for one, would be happy to have the volume and de-lighted to have brightness working on my T520! (Sorry or the weak pun.) -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
