Re: powerd broken
Dominic Fandrey wrote: Since I updated to the 7.2 prerelease, powerd is broken. uname -a FreeBSD mobileKamikaze.norad 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Tue Mar 24 07:57:30 CET 2009 r...@mobilekamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 It increases the CPU frequency very aggressively in adaptive mode. That means full speed with a system load below 1%. I have to use the following nonsensical powerd_flags to make it work sensibly: -a adaptive -b minimum -i 95 -r 99 The system is a Core2 Duo, if that is of any help. Run powerd in foreground with -v option to get it's work trace. If it reaches full speed, there must be some reason to do it. Updated powerd indeed may behave a bit more aggressively (especially in new hiadaptive mode, default for AC power). But it was made several months ago and nobody have complained yet. I am personally using it on 8-CURRENT on my Core2Duo laptop every day. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: amr driver broken since March 12
> Danny Braniss wrote: > >> Danny Braniss wrote: > >>> it seems March 12 was a bit off :-) > >>> it took some time, but I managed to close the gap: > >>> 189100 ok > >>> 189150 fails > >>> I will continue tomorrow, but this should be helpful. > >>> > >>> > >> 189150 is in the middle of a big string of related commits. Try > >> updating to the following change numbers and retesting: > >> > >> 189088 > >> 189107 > >> 189161 > >> > >> If the last one does not work, try editing /sys/dev/amr/amr.c to change > >> > >> #define AMR_ENABLE_CAM 1 > >> > >> to > >> > >> #define AMR_ENABLE_CAM 0 > >> > >> Scott > > > > 189161 works, also for the iir > > now what? > > > > Next set to try: > > 189219 broken > 189229 broken any point in going on? danny > 189253 > 189402 > 189531 > 189569 > 189591 > > Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Alexander Motin wrote: > Dominic Fandrey wrote: >> Since I updated to the 7.2 prerelease, powerd is broken. >> >>> uname -a >> FreeBSD mobileKamikaze.norad 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: >> Tue Mar 24 07:57:30 CET 2009 >> r...@mobilekamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b >> amd64 >> >> It increases the CPU frequency very aggressively in adaptive mode. >> That means full speed with a system load below 1%. I have to use the >> following nonsensical powerd_flags to make it work sensibly: >> -a adaptive -b minimum -i 95 -r 99 >> >> The system is a Core2 Duo, if that is of any help. > > Run powerd in foreground with -v option to get it's work trace. If it > reaches full speed, there must be some reason to do it. > > Updated powerd indeed may behave a bit more aggressively (especially in > new hiadaptive mode, default for AC power). But it was made several > months ago and nobody have complained yet. I am personally using it on > 8-CURRENT on my Core2Duo laptop every day. > # grep powerd /etc/rc.conf powerd_enable="YES" #powerd_flags="-a adaptive -b minimum -i 95 -r 99" powerd_flags="-a adaptive -b minimum -v" # rcrestart powerd powerd not running? Starting powerd. powerd: using sysctl for AC line status powerd: using devd for AC line status load 77%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 74%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 78%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 79%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 65%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 72%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 76%, current freq 2400 MHz ( 0), wanted freq 2400 MHz ... The real load was between 3 and 7 % while these were recorded. Note that I use the normal/old adaptive mode. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problems with sata disks (taskqueue timeout)
On Tue, 20 Jan 2009 08:08:29 +0100 Marc "UBM" Bocklet wrote: > On Tue, 20 Jan 2009 09:39:51 +1100 > Andrew Snow wrote: > > > > > I think that if you use eSATA you probably need dedicated eSATA > > controller ports. eSATA standard specifies a higher voltage for > > the longer cable distances. > > > > Judging from the sporadic problem reports, Promise TX4 is probably > > not the best at signal purity to begin with so using it for eSATA > > pushes it over the edge. > > > > > > Hope that helps, > > Thanks for the fast answer! :-) > > Although my version of the TX4 has two dedicated e-sata ports, the > other posts seem to indicate that it got something to do with the > controller (maybe signal purity, like you said). I'll try upgrading > next and will report back after that. A very late followup here: I upgraded to the latest stable, but things did not improve: Mar 29 10:57:29 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=1087300992 Mar 29 10:57:34 hamstor kernel: ad10: FAILURE - SET_MULTI status=51 error=4 Mar 29 10:57:34 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying (0 retries left) LBA=1087300992 Mar 29 10:57:34 hamstor kernel: ad10: FAILURE - WRITE_DMA48 status=ff error=ff LBA=1087300992 Mar 29 10:57:34 hamstor root: ZFS: vdev I/O failure, zpool=gedaerm path=/dev/ad10 offset=556698042368 size=131072 error=5 Mar 29 10:57:43 hamstor kernel: ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 29 10:57:47 hamstor kernel: ad10: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Mar 29 10:57:51 hamstor kernel: ad10: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Mar 29 10:57:55 hamstor kernel: ad10: WARNING - SET_MULTI taskqueue timeout - completing request directly Mar 29 10:57:55 hamstor kernel: ad10: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=1087301248 Mar 29 10:57:55 hamstor kernel: ad10: WARNING - WRITE_DMA48 UDMA ICRC error (retrying request) LBA=1087301248 Mar 29 10:58:00 hamstor kernel: ad10: FAILURE - SET_MULTI status=51 error=4 Mar 29 10:58:00 hamstor kernel: ad10: FAILURE - WRITE_DMA48 timed out LBA=1087301248 Mar 29 10:58:00 hamstor root: ZFS: vdev I/O failure, zpool=gedaerm path=/dev/ad10 offset=556698173440 size=131072 error=5 Any further ideas anybody? :-) Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: amr driver broken since March 12
> Danny Braniss danny at cs.huji.ac.il writes: > > at least for me :-) > > [and sorry for the cross posting] > > > [...] > > > > amr0: mem > > 0xfbef-0xfbef,0xfe58-0xfe5f > > irq 27 at device 0.0 on pci4 > > amr0: [ITHREAD] > > amr0: delete logical drives supported by controller > > amr0: Firmware 414I, BIOS A100, > > 128MB RAM > > amr0: adapter is busy > > amr0: adapter is busy > > amr0: delete logical drives supported by controller > > (probe0:amr0:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > > (probe0:amr0:0:6:0): CAM Status: SCSI Status Error > > (probe0:amr0:0:6:0): SCSI Status: Check Condition > > (probe0:amr0:0:6:0): ILLEGAL REQUEST asc:24,0 > > (probe0:amr0:0:6:0): Invalid field in CDB > > (probe0:amr0:0:6:0): Unretryable error > > FWIW, I have a an amr device (Dell PERC 3/DC) which is working fine with > a -STABLE dated after March 12th: > > FreeBSD 7.2-PRERELEASE #2: Thu Mar 26 09:41:58 EDT 2009 > te...@test4.tmk.com:/usr/obj/usr/src/sys/PE1550 > [snip] > amr0: mem 0xf000-0xf7ff irq 25 at device 0.0 > on pci3 > amr0: [ITHREAD] > amr0: delete logical drives supported by controller > amr0: Firmware 199D, BIOS 3.35, 128MB RAM > amr0: delete logical drives supported by controller > amrd0: on amr0 > amrd0: 69360MB (142049280 sectors) RAID 5 (optimal) > ses0 at amr0 bus 0 target 6 lun 0 > ses0: Fixed Processor SCSI-2 device > ses0: SAF-TE Compliant Device > Trying to mount root from ufs:/dev/amrd0s1a > > This is on a dual-processor Dell PowerEdge 1550. > > So this may only affect certain models or firmware revisions of amr > devices. Of course, since each LSI OEM uses their own firmware and > BIOS numbering scheme, it'll be hard to tell which one is newer than > the other. > > I have a bazillion of these cards if one would be helpful to a de- > veloper. well, it's broken on my Dell PowerEdge 2940 amr0: amr0: Firmware 1.06 and pciconf: a...@pci0:0:2:1:class=0x0e0001 card=0x04671028 chip=0x19608086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '80960RP i960RP Microprocessor' class = intelligent I/O controller subclass = I2O now try to follow the rebranding trail :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Dominic Fandrey wrote: Alexander Motin wrote: Dominic Fandrey wrote: Since I updated to the 7.2 prerelease, powerd is broken. uname -a FreeBSD mobileKamikaze.norad 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0: Tue Mar 24 07:57:30 CET 2009 r...@mobilekamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b amd64 It increases the CPU frequency very aggressively in adaptive mode. That means full speed with a system load below 1%. I have to use the following nonsensical powerd_flags to make it work sensibly: -a adaptive -b minimum -i 95 -r 99 The system is a Core2 Duo, if that is of any help. Run powerd in foreground with -v option to get it's work trace. If it reaches full speed, there must be some reason to do it. Updated powerd indeed may behave a bit more aggressively (especially in new hiadaptive mode, default for AC power). But it was made several months ago and nobody have complained yet. I am personally using it on 8-CURRENT on my Core2Duo laptop every day. # grep powerd /etc/rc.conf powerd_enable="YES" #powerd_flags="-a adaptive -b minimum -i 95 -r 99" powerd_flags="-a adaptive -b minimum -v" # rcrestart powerd powerd not running? Starting powerd. powerd: using sysctl for AC line status powerd: using devd for AC line status load 77%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 74%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 78%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 79%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 65%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 72%, current freq 2400 MHz ( 0), wanted freq 2400 MHz load 76%, current freq 2400 MHz ( 0), wanted freq 2400 MHz ... The real load was between 3 and 7 % while these were recorded. Note that I use the normal/old adaptive mode. Reason is not in algorithm. Reason is in reporting so high load (65-79%). Run this test please at the same conditions to understand what's going on there: sysctl kern.cp_times && sleep 1 && \ sysctl kern.cp_times && sleep 1 && \ sysctl kern.cp_times && sleep 1 && \ sysctl kern.cp_times -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Alexander Motin wrote:
> Dominic Fandrey wrote:
>> Alexander Motin wrote:
>>> Dominic Fandrey wrote:
Since I updated to the 7.2 prerelease, powerd is broken.
> uname -a
FreeBSD mobileKamikaze.norad 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0:
Tue Mar 24 07:57:30 CET 2009
r...@mobilekamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b
amd64
It increases the CPU frequency very aggressively in adaptive mode.
That means full speed with a system load below 1%. I have to use the
following nonsensical powerd_flags to make it work sensibly:
-a adaptive -b minimum -i 95 -r 99
The system is a Core2 Duo, if that is of any help.
>>> Run powerd in foreground with -v option to get it's work trace. If it
>>> reaches full speed, there must be some reason to do it.
>>>
>>> Updated powerd indeed may behave a bit more aggressively (especially in
>>> new hiadaptive mode, default for AC power). But it was made several
>>> months ago and nobody have complained yet. I am personally using it on
>>> 8-CURRENT on my Core2Duo laptop every day.
>>>
>>
>> # grep powerd /etc/rc.conf
>> powerd_enable="YES"
>> #powerd_flags="-a adaptive -b minimum -i 95 -r 99"
>> powerd_flags="-a adaptive -b minimum -v"
>> # rcrestart powerd powerd not running?
>> Starting powerd.
>> powerd: using sysctl for AC line status
>> powerd: using devd for AC line status
>> load 77%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>> load 74%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>> load 78%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>> load 79%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>> load 65%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>> load 72%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>> load 76%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
>> ...
>>
>> The real load was between 3 and 7 % while these were recorded.
>>
>> Note that I use the normal/old adaptive mode.
>
> Reason is not in algorithm. Reason is in reporting so high load
> (65-79%). Run this test please at the same conditions to understand
> what's going on there:
>
> sysctl kern.cp_times && sleep 1 && \
> sysctl kern.cp_times && sleep 1 && \
> sysctl kern.cp_times && sleep 1 && \
> sysctl kern.cp_times
>
Measurings done with cpu speed set to 800MHz with ~6% CPU load.
# while sleep 1; do sysctl kern.cp_times; done
kern.cp_times: 27709 1 14989 900764 1019830 122302 0 34956 2705 1802746
kern.cp_times: 27711 1 14989 900835 1019891 122308 0 34959 2705 1802871
kern.cp_times: 27711 1 14991 900914 1019944 122316 0 34960 2705 1802996
kern.cp_times: 27712 1 14993 900992 1019997 122328 0 34966 2705 1803112
kern.cp_times: 27714 1 14994 901071 1020049 122339 0 34973 2705 1803228
kern.cp_times: 27714 1 14995 901149 1020104 122348 0 34975 2705 1803351
kern.cp_times: 27715 1 14997 901220 1020164 122363 0 34976 2705 1803468
kern.cp_times: 27716 1 14999 901295 1020220 122371 0 34977 2705 1803593
kern.cp_times: 27717 1 15002 901371 1020273 122385 0 34985 2705 1803705
kern.cp_times: 27719 1 15002 901449 1020327 122390 0 34985 2705 1803834
kern.cp_times: 27719 1 15004 901522 1020386 122398 0 34987 2705 1803958
kern.cp_times: 27720 1 15006 901599 1020440 122416 0 34987 2705 1804074
kern.cp_times: 27722 1 15006 901668 1020503 122424 0 34994 2705 1804192
A more convinient output:
# oldtimes=$(sysctl -n kern.cp_times); while sleep 1; do times=$(sysctl -n
kern.cp_times); for time in $times; do printf "%8s" $(($time - ${oldtimes%%
*})); oldtimes=${oldtimes#* }; done; echo; oldtimes=$times; done
0 0 3 66 64 10 0 3 0 121
1 0 3 78 56 7 0 8 0 122
1 0 4 64 68 23 0 4 0 111
2 0 2 85 56 7 0 12 0 126
1 0 1 79 55 7 0 2 0 127
0 0 1 70 68 17 0 4 0 118
2 0 1 95 39 16 0 5 0 116
0 0 0 77 60 9 0 5 0 123
0 0 0 88 48 8 0 2 0 126
1 0 1 79 57 14 0 6 0 118
1 0 0 88 48 12 0 5 0 120
0 0 0 80 58 12 0 6 0 119
3 0 0 82 53 13 0 3 0 122
2 0 3 85 47 11 0 7 0 120
1 0 0 81 54 8 0 3 1 124
2 0 2 69 65 13 0 7 0 117
0 0 4 73 60 8 0 4 0 126
2 0 4 81
Re: powerd broken
Dominic Fandrey wrote:
Alexander Motin wrote:
Dominic Fandrey wrote:
Alexander Motin wrote:
Dominic Fandrey wrote:
Since I updated to the 7.2 prerelease, powerd is broken.
uname -a
FreeBSD mobileKamikaze.norad 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #0:
Tue Mar 24 07:57:30 CET 2009
r...@mobilekamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b
amd64
It increases the CPU frequency very aggressively in adaptive mode.
That means full speed with a system load below 1%. I have to use the
following nonsensical powerd_flags to make it work sensibly:
-a adaptive -b minimum -i 95 -r 99
The system is a Core2 Duo, if that is of any help.
Run powerd in foreground with -v option to get it's work trace. If it
reaches full speed, there must be some reason to do it.
Updated powerd indeed may behave a bit more aggressively (especially in
new hiadaptive mode, default for AC power). But it was made several
months ago and nobody have complained yet. I am personally using it on
8-CURRENT on my Core2Duo laptop every day.
# grep powerd /etc/rc.conf
powerd_enable="YES"
#powerd_flags="-a adaptive -b minimum -i 95 -r 99"
powerd_flags="-a adaptive -b minimum -v"
# rcrestart powerd powerd not running?
Starting powerd.
powerd: using sysctl for AC line status
powerd: using devd for AC line status
load 77%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 74%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 78%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 79%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 65%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 72%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 76%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
...
The real load was between 3 and 7 % while these were recorded.
Note that I use the normal/old adaptive mode.
Reason is not in algorithm. Reason is in reporting so high load
(65-79%). Run this test please at the same conditions to understand
what's going on there:
sysctl kern.cp_times && sleep 1 && \
sysctl kern.cp_times && sleep 1 && \
sysctl kern.cp_times && sleep 1 && \
sysctl kern.cp_times
Measurings done with cpu speed set to 800MHz with ~6% CPU load.
# while sleep 1; do sysctl kern.cp_times; done
kern.cp_times: 27709 1 14989 900764 1019830 122302 0 34956 2705 1802746
kern.cp_times: 27711 1 14989 900835 1019891 122308 0 34959 2705 1802871
kern.cp_times: 27711 1 14991 900914 1019944 122316 0 34960 2705 1802996
kern.cp_times: 27712 1 14993 900992 1019997 122328 0 34966 2705 1803112
A more convinient output:
# oldtimes=$(sysctl -n kern.cp_times); while sleep 1; do times=$(sysctl -n
kern.cp_times); for time in $times; do printf "%8s" $(($time - ${oldtimes%%
*})); oldtimes=${oldtimes#* }; done; echo; oldtimes=$times; done
0 0 3 66 64 10 0 3 0 121
1 0 3 78 56 7 0 8 0 122
1 0 4 64 68 23 0 4 0 111
2 0 2 85 56 7 0 12 0 126
It means that one of your CPUs spent most of it's time in interrupt
processing and so far from idle. What does `top -P` shows you? Where
have you seen that ~6% CPU load?
--
Alexander Motin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Alexander Motin wrote:
> Dominic Fandrey wrote:
>> Alexander Motin wrote:
>>> Dominic Fandrey wrote:
Alexander Motin wrote:
> Dominic Fandrey wrote:
>> Since I updated to the 7.2 prerelease, powerd is broken.
>>
>>> uname -a
>> FreeBSD mobileKamikaze.norad 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE
>> #0:
>> Tue Mar 24 07:57:30 CET 2009
>> r...@mobilekamikaze.norad:/usr/obj/HP6510b/amd64/usr/src/sys/HP6510b
>> amd64
>>
>> It increases the CPU frequency very aggressively in adaptive mode.
>> That means full speed with a system load below 1%. I have to use the
>> following nonsensical powerd_flags to make it work sensibly:
>> -a adaptive -b minimum -i 95 -r 99
>>
>> The system is a Core2 Duo, if that is of any help.
> Run powerd in foreground with -v option to get it's work trace. If it
> reaches full speed, there must be some reason to do it.
>
> Updated powerd indeed may behave a bit more aggressively
> (especially in
> new hiadaptive mode, default for AC power). But it was made several
> months ago and nobody have complained yet. I am personally using it on
> 8-CURRENT on my Core2Duo laptop every day.
>
# grep powerd /etc/rc.conf
powerd_enable="YES"
#powerd_flags="-a adaptive -b minimum -i 95 -r 99"
powerd_flags="-a adaptive -b minimum -v"
# rcrestart powerd powerd not running?
Starting powerd.
powerd: using sysctl for AC line status
powerd: using devd for AC line status
load 77%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 74%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 78%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 79%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 65%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 72%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
load 76%, current freq 2400 MHz ( 0), wanted freq 2400 MHz
...
The real load was between 3 and 7 % while these were recorded.
Note that I use the normal/old adaptive mode.
>>> Reason is not in algorithm. Reason is in reporting so high load
>>> (65-79%). Run this test please at the same conditions to understand
>>> what's going on there:
>>>
>>> sysctl kern.cp_times && sleep 1 && \
>>> sysctl kern.cp_times && sleep 1 && \
>>> sysctl kern.cp_times && sleep 1 && \
>>> sysctl kern.cp_times
>>>
>>
>> Measurings done with cpu speed set to 800MHz with ~6% CPU load.
>>
>> # while sleep 1; do sysctl kern.cp_times; done
>> kern.cp_times: 27709 1 14989 900764 1019830 122302 0 34956 2705 1802746
>> kern.cp_times: 27711 1 14989 900835 1019891 122308 0 34959 2705 1802871
>> kern.cp_times: 27711 1 14991 900914 1019944 122316 0 34960 2705 1802996
>> kern.cp_times: 27712 1 14993 900992 1019997 122328 0 34966 2705 1803112
>>
>> A more convinient output:
>> # oldtimes=$(sysctl -n kern.cp_times); while sleep 1; do
>> times=$(sysctl -n kern.cp_times); for time in $times; do printf "%8s"
>> $(($time - ${oldtimes%% *})); oldtimes=${oldtimes#* }; done; echo;
>> oldtimes=$times; done
>>0 0 3 66 64 10 0 3
>> 0 121
>>1 0 3 78 56 7 0 8
>> 0 122
>>1 0 4 64 68 23 0 4
>> 0 111
>>2 0 2 85 56 7 0 12
>> 0 126
>
> It means that one of your CPUs spent most of it's time in interrupt
> processing and so far from idle. What does `top -P` shows you? Where
> have you seen that ~6% CPU load?
>
That is the load shown by the e17 CPU module. It's display has always
been in sync with top in the past, no longer though, it appears.
# top -PIS
last pid: 68235; load averages: 0.09, 0.16, 0.17
up 0+05:17:29 13:05:10
137 processes: 4 running, 117 sleeping, 16 waiting
CPU 0: 1.1% user, 0.0% nice, 1.1% system, 61.4% interrupt, 36.3% idle
CPU 1: 9.0% user, 0.0% nice, 3.4% system, 0.0% interrupt, 87.6% idle
Mem: 419M Active, 415M Inact, 416M Wired, 3752K Cache, 183M Buf, 716M Free
Swap: 4096M Total, 4096M Free
PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND
11 root 1 171 ki31 0K16K RUN1 286:42 93.46% idle: cpu1
23 root 1 -80- 0K16K RUN0 126:54 59.96% irq16:
hdac0 uhci+
12 root 1 171 ki31 0K16K RUN0 179:27 40.09% idle: cpu0
1318 root 1 460 439M 312M select 1 12:55 1.76% Xorg
4361 musicpd 4 440 91164K 14412K ucond 1 1:57 0.78% mpd
Some things strike me as odd. The difference between the load reported
by powerd and top is still very significant and of course the high
interrupt load.
I've got a mouse with a 1khz report rate (the only co
Re: powerd broken
Dominic Fandrey wrote: Alexander Motin wrote: It means that one of your CPUs spent most of it's time in interrupt processing and so far from idle. What does `top -P` shows you? Where have you seen that ~6% CPU load? That is the load shown by the e17 CPU module. It's display has always been in sync with top in the past, no longer though, it appears. # top -PIS last pid: 68235; load averages: 0.09, 0.16, 0.17 up 0+05:17:29 13:05:10 137 processes: 4 running, 117 sleeping, 16 waiting CPU 0: 1.1% user, 0.0% nice, 1.1% system, 61.4% interrupt, 36.3% idle CPU 1: 9.0% user, 0.0% nice, 3.4% system, 0.0% interrupt, 87.6% idle Mem: 419M Active, 415M Inact, 416M Wired, 3752K Cache, 183M Buf, 716M Free Swap: 4096M Total, 4096M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K16K RUN1 286:42 93.46% idle: cpu1 23 root 1 -80- 0K16K RUN0 126:54 59.96% irq16: hdac0 uhci+ 12 root 1 171 ki31 0K16K RUN0 179:27 40.09% idle: cpu0 1318 root 1 460 439M 312M select 1 12:55 1.76% Xorg 4361 musicpd 4 440 91164K 14412K ucond 1 1:57 0.78% mpd Some things strike me as odd. The difference between the load reported by powerd and top is still very significant and of course the high interrupt load. powerd now reports/uses summary load of all CPUs (it can be bigger then 100%), while top shows average. I've got a mouse with a 1khz report rate (the only connected USB device), but unplugging it doesn't change the load. Neither does stopping moused (I'm running the system without HAL). There also is a fingerprint reader, but it is only detected by ugen. I would start from identifying all devices sharing that IRQ and trying to disable them (or unload their drivers) one by one. `systat -vm 1` will show you how much interrupts actually happens there per second. On most of modern systems you can make hdac0 to not share that IRQ by enabling MSI there with hint.hdac.0.msi=1 in loader.conf. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 7.1 stable panics
Nathanael Jean-Francois wrote:
Hello all,
I've been getting some panics with a 7.1 stable machine from March 14th.
I've not been able to determine the cause nor reproduce them at will.
Here's a backtrace from the latest panic on March 23rd. Let me know if any
more information is needed. Thanks.
Unread portion of the kernel message buffer:
panic: lock (sleep mutex) Giant not locked @
/usr/src/sys/kern/kern_ntptime.c:965
This is strange because the corresponding mtx_lock is only a few lines
above. Can you provide your kernel config?
Kris
cpuid = 1
Uptime: 1d15h34m6s
Physical memory: 2034 MB
Dumping 377 MB: 362 346 330 314 298 282 266 250 234 218 202 186 170 154
138 122 106 90 74 58 42em0: watchdog timeout -- resetting
<5>em0: link state changed to DOWN
26 10
#0 doadump () at pcpu.h:195
195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
(kgdb) list
190 static __inline struct thread *
191 __curthread(void)
192 {
193 struct thread *td;
194
195 __asm __volatile("movq %%gs:0,%0" : "=r" (td));
196 return (td);
197 }
198 #define curthread (__curthread())
199
(kgdb) backtrace
#0 doadump () at pcpu.h:195
#1 0x0104 in ?? ()
#2 0x804e6fc2 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#3 0x804e73f2 in panic (fmt=0x104 )
at /usr/src/sys/kern/kern_shutdown.c:574
#4 0x805218b6 in witness_unlock (lock=0x80b0a400,
flags=8, file=0x0, line=965) at /usr/src/sys/kern/subr_witness.c:1284
#5 0x804dadb2 in _mtx_unlock_flags (m=0x80b0a400, opts=0,
file=0x8087a008 "/usr/src/sys/kern/kern_ntptime.c", line=965)
at /usr/src/sys/kern/kern_mutex.c:203
#6 0x804dc062 in kern_adjtime (td=0x80884bd0,
delta=0x674, olddelta=Variable "olddelta" is not available.
) at /usr/src/sys/kern/kern_ntptime.c:965
#7 0xff00019cf870 in ?? ()
#8 0x05a8 in ?? ()
#9 0x805430b6 in soreceive_generic (so=0xff0078a9f600,
psa=0x0, uio=0xfffebe695b10, mp0=Variable "mp0" is not available.
) at /usr/src/sys/kern/uipc_socket.c:1652
#10 0x80523e6d in dofileread (td=0xff000181b000, fd=3,
fp=0xff00016af200, auio=0xfffebe695b10, offset=Variable "offset"
is not available.
) at file.h:245
#11 0x805241de in kern_readv (td=0xff000181b000, fd=3,
auio=0xfffebe695b10) at /usr/src/sys/kern/sys_generic.c:192
#12 0x805242cc in read (td=0x0, uap=0x0) at
/usr/src/sys/kern/sys_generic.c:108
#13 0x8079d0dc in syscall (frame=0xfffebe695c80) at
/usr/src/sys/amd64/amd64/trap.c:907
#14 0x80781cbb in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:330
#15 0x00080076ad7c in ?? ()
Previous frame inner to this frame (corrupt stack?)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Alexander Motin wrote: > Dominic Fandrey wrote: >> Alexander Motin wrote: >>> It means that one of your CPUs spent most of it's time in interrupt >>> processing and so far from idle. What does `top -P` shows you? Where >>> have you seen that ~6% CPU load? >> >> That is the load shown by the e17 CPU module. It's display has always >> been in sync with top in the past, no longer though, it appears. >> >> # top -PIS >> last pid: 68235; load averages: 0.09, 0.16, >> 0.17 >> >> up 0+05:17:29 13:05:10 >> 137 processes: 4 running, 117 sleeping, 16 waiting >> CPU 0: 1.1% user, 0.0% nice, 1.1% system, 61.4% interrupt, 36.3% idle >> CPU 1: 9.0% user, 0.0% nice, 3.4% system, 0.0% interrupt, 87.6% idle >> Mem: 419M Active, 415M Inact, 416M Wired, 3752K Cache, 183M Buf, 716M >> Free >> Swap: 4096M Total, 4096M Free >> >> PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU >> COMMAND >>11 root 1 171 ki31 0K16K RUN1 286:42 93.46% >> idle: cpu1 >>23 root 1 -80- 0K16K RUN0 126:54 59.96% >> irq16: hdac0 uhci+ >>12 root 1 171 ki31 0K16K RUN0 179:27 40.09% >> idle: cpu0 >> 1318 root 1 460 439M 312M select 1 12:55 1.76% Xorg >> 4361 musicpd 4 440 91164K 14412K ucond 1 1:57 0.78% mpd >> >> Some things strike me as odd. The difference between the load reported >> by powerd and top is still very significant and of course the high >> interrupt load. > > powerd now reports/uses summary load of all CPUs (it can be bigger then > 100%), while top shows average. > >> I've got a mouse with a 1khz report rate (the only connected USB >> device), but unplugging it doesn't change the load. Neither does >> stopping moused (I'm running the system without HAL). There also >> is a fingerprint reader, but it is only detected by ugen. > > I would start from identifying all devices sharing that IRQ and trying > to disable them (or unload their drivers) one by one. `systat -vm 1` > will show you how much interrupts actually happens there per second. > > On most of modern systems you can make hdac0 to not share that IRQ by > enabling MSI there with hint.hdac.0.msi=1 in loader.conf. > I already did unplug all devices to no avail. Afterwards I tried to 'kldunload -f' all usb devices, but most refused. However during this I recognized that /boot/modules holds an old u3g.ko, back from the time when it was not in stable. Apparently modules in /boot/modules have preference over those in /boot/kernels. I deleted the old u3g.ko and rebooted (because I couldn't get the system to unload it). Now everything is fine, the interrupt load is gone. I'll monitor this and come back here if it turns out this has just been coincidence. Thank you for all that help. Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Dominic Fandrey wrote: > Alexander Motin wrote: >> Dominic Fandrey wrote: >>> Alexander Motin wrote: It means that one of your CPUs spent most of it's time in interrupt processing and so far from idle. What does `top -P` shows you? Where have you seen that ~6% CPU load? >>> That is the load shown by the e17 CPU module. It's display has always >>> been in sync with top in the past, no longer though, it appears. >>> >>> # top -PIS >>> last pid: 68235; load averages: 0.09, 0.16, >>> 0.17 >>> >>> up 0+05:17:29 13:05:10 >>> 137 processes: 4 running, 117 sleeping, 16 waiting >>> CPU 0: 1.1% user, 0.0% nice, 1.1% system, 61.4% interrupt, 36.3% idle >>> CPU 1: 9.0% user, 0.0% nice, 3.4% system, 0.0% interrupt, 87.6% idle >>> Mem: 419M Active, 415M Inact, 416M Wired, 3752K Cache, 183M Buf, 716M >>> Free >>> Swap: 4096M Total, 4096M Free >>> >>> PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU >>> COMMAND >>>11 root 1 171 ki31 0K16K RUN1 286:42 93.46% >>> idle: cpu1 >>>23 root 1 -80- 0K16K RUN0 126:54 59.96% >>> irq16: hdac0 uhci+ >>>12 root 1 171 ki31 0K16K RUN0 179:27 40.09% >>> idle: cpu0 >>> 1318 root 1 460 439M 312M select 1 12:55 1.76% Xorg >>> 4361 musicpd 4 440 91164K 14412K ucond 1 1:57 0.78% mpd >>> >>> Some things strike me as odd. The difference between the load reported >>> by powerd and top is still very significant and of course the high >>> interrupt load. >> powerd now reports/uses summary load of all CPUs (it can be bigger then >> 100%), while top shows average. >> >>> I've got a mouse with a 1khz report rate (the only connected USB >>> device), but unplugging it doesn't change the load. Neither does >>> stopping moused (I'm running the system without HAL). There also >>> is a fingerprint reader, but it is only detected by ugen. >> I would start from identifying all devices sharing that IRQ and trying >> to disable them (or unload their drivers) one by one. `systat -vm 1` >> will show you how much interrupts actually happens there per second. >> >> On most of modern systems you can make hdac0 to not share that IRQ by >> enabling MSI there with hint.hdac.0.msi=1 in loader.conf. >> > > I already did unplug all devices to no avail. Afterwards I tried > to 'kldunload -f' all usb devices, but most refused. However during > this I recognized that /boot/modules holds an old u3g.ko, back from > the time when it was not in stable. Apparently modules in > /boot/modules have preference over those in /boot/kernels. I deleted > the old u3g.ko and rebooted (because I couldn't get the system to > unload it). Now everything is fine, the interrupt load is gone. > > I'll monitor this and come back here if it turns out this has just > been coincidence. > > Thank you for all that help. > > Regards This has turned out to be an early call. I just happened to start skype_devel and the whole thing started over, so I think it's pretty certain, now, that this is a hdac issue. However after a reboot I tried to reproduce this and now skype and mpd are both running without causing an irq race. If the irq race reappears I will use the device hint you suggested to rule out that this is an interrupt sharing issue. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: amr driver broken since March 12
Danny Braniss wrote: Danny Braniss wrote: Danny Braniss wrote: it seems March 12 was a bit off :-) it took some time, but I managed to close the gap: 189100 ok 189150 fails I will continue tomorrow, but this should be helpful. 189150 is in the middle of a big string of related commits. Try updating to the following change numbers and retesting: 189088 189107 189161 If the last one does not work, try editing /sys/dev/amr/amr.c to change #define AMR_ENABLE_CAM 1 to #define AMR_ENABLE_CAM 0 Scott 189161 works, also for the iir now what? Next set to try: 189219 broken 189229 broken Ok, so 189161 works, 189219 doesn't, correct? If so, did you also make the change to amr.c yet? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Dominic Fandrey wrote: > Dominic Fandrey wrote: >> Alexander Motin wrote: >>> Dominic Fandrey wrote: Alexander Motin wrote: > It means that one of your CPUs spent most of it's time in interrupt > processing and so far from idle. What does `top -P` shows you? Where > have you seen that ~6% CPU load? That is the load shown by the e17 CPU module. It's display has always been in sync with top in the past, no longer though, it appears. # top -PIS last pid: 68235; load averages: 0.09, 0.16, 0.17 up 0+05:17:29 13:05:10 137 processes: 4 running, 117 sleeping, 16 waiting CPU 0: 1.1% user, 0.0% nice, 1.1% system, 61.4% interrupt, 36.3% idle CPU 1: 9.0% user, 0.0% nice, 3.4% system, 0.0% interrupt, 87.6% idle Mem: 419M Active, 415M Inact, 416M Wired, 3752K Cache, 183M Buf, 716M Free Swap: 4096M Total, 4096M Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 11 root 1 171 ki31 0K16K RUN1 286:42 93.46% idle: cpu1 23 root 1 -80- 0K16K RUN0 126:54 59.96% irq16: hdac0 uhci+ 12 root 1 171 ki31 0K16K RUN0 179:27 40.09% idle: cpu0 1318 root 1 460 439M 312M select 1 12:55 1.76% Xorg 4361 musicpd 4 440 91164K 14412K ucond 1 1:57 0.78% mpd Some things strike me as odd. The difference between the load reported by powerd and top is still very significant and of course the high interrupt load. >>> powerd now reports/uses summary load of all CPUs (it can be bigger then >>> 100%), while top shows average. >>> I've got a mouse with a 1khz report rate (the only connected USB device), but unplugging it doesn't change the load. Neither does stopping moused (I'm running the system without HAL). There also is a fingerprint reader, but it is only detected by ugen. >>> I would start from identifying all devices sharing that IRQ and trying >>> to disable them (or unload their drivers) one by one. `systat -vm 1` >>> will show you how much interrupts actually happens there per second. >>> >>> On most of modern systems you can make hdac0 to not share that IRQ by >>> enabling MSI there with hint.hdac.0.msi=1 in loader.conf. >>> >> I already did unplug all devices to no avail. Afterwards I tried >> to 'kldunload -f' all usb devices, but most refused. However during >> this I recognized that /boot/modules holds an old u3g.ko, back from >> the time when it was not in stable. Apparently modules in >> /boot/modules have preference over those in /boot/kernels. I deleted >> the old u3g.ko and rebooted (because I couldn't get the system to >> unload it). Now everything is fine, the interrupt load is gone. >> >> I'll monitor this and come back here if it turns out this has just >> been coincidence. >> >> Thank you for all that help. >> >> Regards > > This has turned out to be an early call. I just happened to start > skype_devel and the whole thing started over, so I think it's > pretty certain, now, that this is a hdac issue. > However after a reboot I tried to reproduce this and now skype > and mpd are both running without causing an irq race. > > If the irq race reappears I will use the device hint you suggested > to rule out that this is an interrupt sharing issue. Even after setting the device hint the problem has reoccurred. It simply starts after a while, I cannot make out any cause. As it turned out uhci0 is the violent interrupt with an interrupt rate between 130k and 190k. This is so incredible, I wonder why the interrupt throttling doesn't kick in. 7 usersLoad 0.16 0.27 0.28 29 Mar 17:02 Mem:KBREALVIRTUAL VN PAGER SWAP PAGER Tot Share TotShareFree in out in out Act 805472 76800 1252404 123696 615176 count All 1062992 97920 14120720 152840 pages Proc:Interrupts r p d s w Csw Trp Sys Int Sof Fltcow182k total 6 84 360k 2770 14k 178k 224 26 12 zfodatkbd0 1 ozfod acpi0 irq9 1.1%Sys 25.9%Intr 0.4%User 0.0%Nice 72.6%Idle%ozfod psm0 irq12 ||||||||||| daefr ata0 irq14 =+ 15 prcfr 177k uhci0 drm0 9 dtbuf 117 totfr23 wpi0 uhci1 Namei Name-cache Dir-cache10 desvn react ehci0 uhci Callshits %hits % 7632 numvn pdwak uhci2 ehci
Re: Xorg unbuildable - where to get: x11-xcb?
On Sat, 2009-03-28 at 21:04 -0700, Chris H wrote: > Greetings, > A fresh install of 7 followed by a cvsup to 7.2-PRE on the 26th > results in an inability to build Xorg on the system. A cvsup only > an hour ago provides no solution. > > An attempt at the following: > > cd /usr/ports/x11/xorg-minimal > make > > produces the following error: > ... > checking pkg-config files for X11 are available... yes > checking for LIBDRM... yes > checking for DRI2PROTO... yes > checking for DRIGL... gnome-config: not found > configure: error: Package requirements (x11 xext xxf86vm xdamage xfixes > x11-xcb > xcb-glx) were not met: > > No package 'x11-xcb' found I'm guessing that you installed Xorg from the 7.0 packages. You need to rebuild everything that depends on libxcb. See UPDATING. robert. > Consider adjusting the PKG_CONFIG_PATH environment variable if you > installed software in a non-standard prefix. > ... > > I was able to install /usr/ports/x11/xcb with no issue. But have > no idea where to find x11-xcb. Where can I get it? > > thank you for all your time and consideration in this matter. > > --Chris > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" -- Robert Noland FreeBSD signature.asc Description: This is a digitally signed message part
Re: powerd broken
Dominic Fandrey wrote: I can rule out drm0 as the cause, because uhci0 is the only common presence in all occurrences of this problem. You have other examples? If you mean "irq16: hdac0 uhci+" string, then "+" there means "and some other devices", which in this case is probably drm0. There were some drm related commits last time and there are also some IRQ related problems were reported/patched in CURRENT recently. So I would not ignore this possibility without additional testing. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS and NFS: changing handles between reboots
Dear colleagues, is it normal that between reboots NFS exported ZFS file systems change NFS handles? After server reboot, I have stale NFS handle on any request to previously mounted FS. On UFS, mounted NFS file systems survive server reboots... Thanks in advance. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: powerd broken
Alexander Motin wrote: > Dominic Fandrey wrote: >> I can rule out drm0 as the cause, because uhci0 is the only common >> presence in all occurrences of this problem. > > You have other examples? If you mean "irq16: hdac0 uhci+" string, then > "+" there means "and some other devices", which in this case is probably > drm0. I didn't know that. > There were some drm related commits last time and there are also some > IRQ related problems were reported/patched in CURRENT recently. So I > would not ignore this possibility without additional testing. > Thanks, will do. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
