Re: trying to use xz on manuals.
On Mon, 6 Dec 2010 22:50:44 -0800 Tim Kientzle wrote: > >> Some time ago I do similar tests. Changing compression for base man's to > >> bz2 or xz doesn't make much sense. > > Oh, agreed. The issue with small files is that they will always take up at > > least one sector [*]; different compression routines don't gain any benefit > > if they don't change the number of sectors needed to store the file. > > More than half of the manpages end up as 1K .gz catman files as it is; ~90% > > are 2K or smaller. > It might make sense if XZ decompression were significantly > faster than GZip decompression. (Especially since man pages > are decompressed much more often than they are compressed.) Oh, that's good! But this setting causes pkg-plist break of ports. Maybe, some ports chase bsd.own.mk (COMPRESS_CMD, COMPRESS_EXT), but it assumed that MANEXT is .gz:-(. Thank you. -- Norikatsu Shigemura ___ 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"
trying to use xz on manuals.
Hi.
I tested like following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
--- share/mk/bsd.own.mk.orig2010-10-06 12:22:05.747697000 +0900
+++ share/mk/bsd.own.mk 2010-12-06 23:40:59.058632584 +0900
@@ -169,8 +169,8 @@
STRIP?=-s
.endif
-COMPRESS_CMD?= gzip -cn
-COMPRESS_EXT?= .gz
+COMPRESS_CMD?= xz -c
+COMPRESS_EXT?= .xz
.if !defined(_WITHOUT_SRCCONF)
#
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
So I got following results:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
$ find /usr/share/doc /usr/share/info /usr/share/man /usr/share/openssl/man
-name \*.gz | xargs stat -f %z | awk '{sum+=$0} END {print sum, NR}'
31186768 8629
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
$ find /usr/share/doc /usr/share/info /usr/share/man /usr/share/openssl/man
-name \*.xz | xargs stat -f %z | awk '{sum+=$0} END {print sum, NR}'
30010640 8631
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
.xz smaller than .gz, but effective is about 96.2%:-(.
Different from files.gz to files.xz:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
+/usr/share/man/man3/log2.3.xz
+/usr/share/man/man3/log2f.3.xz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
(Sorry, .gz environment is just older)
And I noticed that tooo long ObsoleteFiles.inc:-(.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
# MMDD: Remove *.gz (Replaced by *.xz)
OLD_FILES+=usr/share/doc/papers/beyond43.ascii.gz
OLD_FILES+=usr/share/doc/papers/bio.ascii.gz
OLD_FILES+=usr/share/doc/papers/contents.ascii.gz
:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
Humm.. JFYI.
--
Norikatsu Shigemura
___
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"
psm(4) - synaptics touch pad strange behavier
ATE (200) 00fa
psm: SET_SAMPLING_RATE (200) 00fa
psm: SET_SAMPLING_RATE (80) 00fa
psm: SEND_DEV_ID return code:00fa
psm: device ID:
psm: SET_SAMPLING_RATE (200) 00fa
psm: SET_SAMPLING_RATE (100) 00fa
psm: SET_SAMPLING_RATE (80) 00fa
psm: SET_SAMPLING_RATE (60) 00fa
psm: SET_SAMPLING_RATE (40) 00fa
psm: SET_SAMPLING_RATE (20) 00fa
psm: SEND_DEV_ID return code:00fa
psm: device ID:
psm: SEND_DEV_ID return code:00fa
psm: device ID:
* start enable_synaptics()
synaptics: BEGIN init
psm: SET_SCALING11 return code:00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 02 47 16
~~ ~~ extcmd(0x00)'s result is 0x16
synaptics signature, OK!
Synaptics Touchpad v6.2
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (3) 00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 39 a0 b2
~ extcmd(0x03)'s result is OK like following:
Model information:
infoRot180: 0
infoPortrait: 0
infoSensor: 57
infoHardware: 80
infoNewAbs: 1
capPen: 0
infoSimplC: 1
infoGeometry: 2
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (2) 00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status a0 47 51
~ extcmd(0x02)'s result is OK like following:
Extended capabilities:
capExtended: 1
capPassthrough: 0
capSleep: 1
capFourButtons: 0
capMultiFinger: 0
capPalmDetect: 1
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (2) 00fa
psm: SET_RESOLUTION (1) 00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 20 00 00
~ extcmd(0x09)'s result is OK like following:
Additional Buttons: 0
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (1) 00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 3b 47 41
~~ ~~ extcmd(0x01)'s result is 0x41
synaptics signature, OK!
psm: SET_RESOLUTION (3) 00fa<- 11--
psm: SET_RESOLUTION (0) 00fa<- --00
psm: SET_RESOLUTION (0) 00fa<- 00--
psm: SET_RESOLUTION (1) 00fa<- --01 | or
0b1101 = 0xc1
mode byte(0xc1) is set, OK.
0xc1 = Absolute mode with W, high packet rate
psm: SET_SAMPLING_RATE (20) 00fa
synaptics: END init (3 buttons)
psm0: found Synaptics Touchpad
* finish enable_synaptics()
psm: SET_SAMPLING_RATE (100) 00fa
psm: SET_RESOLUTION (2) 00fa
psm: SET_SCALING11 return code:00fa
psm: SET_STREAM_MODE return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 00 02 64
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (0) 00fa
psm: SET_RESOLUTION (1) 00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 3b 47 c1
psm: ENABLE_DEV return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 20 01 64
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
psm0: lost interrupt?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
* service moused stop
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
psm0: lost interrupt?
psm: DISABLE_DEV return code:00fa
psm: SEND_AUX_DEV_STATUS return code:00fa
psm: status 00 01 64
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
I read Synaptics's "Synaptics PS/2 TouchPad Interfacing Guide",
PN: 511-000275-01 Rev.A and sys/dev/atkbdc/psm.c. Accordingly
these, I think no problem about implementing synaptics processing
part, maybe.
But read_aux_data_no_wait is really OK? Accordingly, my dumped
data pointed out 'not synaptics data.'. Some initialization is
required? I didn't know what.
psmintr() in sys/dev/atkbdc/psm.c
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
while((c = read_aux_data_no_wait(sc->kbdc)) != -1) {
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
To fix this issue, should I do other?
--
Norikatsu Shigemura
___
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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi avg.
On Sun, 12 Sep 2010 18:38:58 +0300
Andriy Gapon wrote:
> > Observations are correct, but incomplete; the conclusions are wrong.
> > At the end of the boot there are message like this one:
> > PROCESSOR-0722 [402244] cpu_cx_cst: acpi_cpu0: Got C2 - 245
> > latency
> > This is a result of re-evaluation of _CST because of a notification from
> > ACPI.
> But still, as you suggest, a patch like the following should be tested and
> committed:
Thank you, I'll test your patch. But I'm rebuilding another
patches. So please wait next day.
--
Norikatsu Shigemura
___
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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi.
On Sun, 12 Sep 2010 20:26:07 +0900
Norikatsu Shigemura wrote:
> Humm.. Why only C3 state appear when unplug power? :-(
Ah, I got it. Every times, evaluating _CST on acpi_cpu_cx_cst,
and _CST is a black box because I couldn't see _CST. Maybe,
_CST look at AC status.
So I think that following patch is OK.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
--- sys/dev/acpica/acpi_cpu.c.orig 2010-09-12 01:31:38.144243000 +0900
+++ sys/dev/acpica/acpi_cpu.c 2010-09-12 20:53:49.252917961 +0900
@@ -690,19 +690,11 @@
sc->cpu_cx_count++;
continue;
case ACPI_STATE_C2:
- if (cx_ptr->trans_lat > 100) {
- ACPI_DEBUG_PRINT((ACPI_DB_INFO,
-"acpi_cpu%d: C2[%d] not available.\n",
-device_get_unit(sc->cpu_dev), i));
- continue;
- }
sc->cpu_non_c3 = i;
break;
case ACPI_STATE_C3:
default:
- if (cx_ptr->trans_lat > 1000 ||
- (cpu_quirks & CPU_QUIRK_NO_C3) != 0) {
-
+ if (cpu_quirks & CPU_QUIRK_NO_C3) {
ACPI_DEBUG_PRINT((ACPI_DB_INFO,
"acpi_cpu%d: C3[%d] not available.\n",
device_get_unit(sc->cpu_dev), i));
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
Thank you.
--
Norikatsu Shigemura
___
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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
% 93.21% 0.00% last 8038us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # sysctl hw.acpi.cpu.cx_lowest=C3 && sleep 10 && sysctl dev.cpu.0.cx_usage dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage hw.acpi.cpu.cx_lowest: C2 -> C3 dev.cpu.0.cx_usage: 0.73% 0.16% 99.10% last 2145us dev.cpu.1.cx_usage: 0.67% 0.22% 99.09% last 1559us dev.cpu.2.cx_usage: 0.27% 0.00% 99.72% last 13994us dev.cpu.3.cx_usage: 0.81% 0.27% 98.91% last 21592us - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Humm.. Why only C3 state appear when unplug power? :-( Thank you. -- Norikatsu Shigemura ___ 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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi mav.
On Sun, 12 Sep 2010 13:00:22 +0300
Alexander Motin wrote:
> `sysctl -a` is a bad tool to estimate C-states usage. It causes a lot of
> context switches, making data dirty. To get more precise data, try:
> sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage
> dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage
I tried, got following results:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
# sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage
dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage
hw.acpi.cpu.cx_lowest: C3 -> C2
dev.cpu.0.cx_usage: 2.37% 97.62% last 3028us
dev.cpu.1.cx_usage: 0.87% 99.12% last 4379us
dev.cpu.2.cx_usage: 0.54% 99.45% last 14314us
dev.cpu.3.cx_usage: 1.36% 98.63% last 16982us
# sysctl hw.acpi.cpu.cx_lowest=C2 && sleep 10 && sysctl dev.cpu.0.cx_usage
dev.cpu.1.cx_usage dev.cpu.2.cx_usage dev.cpu.3.cx_usage
hw.acpi.cpu.cx_lowest: C2 -> C2
dev.cpu.0.cx_usage: 1.82% 98.17% last 2672us
dev.cpu.1.cx_usage: 0.71% 99.28% last 3413us
dev.cpu.2.cx_usage: 0.00% 100.00% last 13543us
dev.cpu.3.cx_usage: 2.00% 97.99% last 16190us
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
That's perfect!
Thank you.
--
Norikatsu Shigemura
___
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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi avg. On Sun, 12 Sep 2010 19:05:37 +0900 Norikatsu Shigemura wrote: > I re-tried to test following patch. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > --- sys/dev/acpica/acpi_cpu.c.orig2010-09-12 01:31:38.144243000 +0900 > +++ sys/dev/acpica/acpi_cpu.c 2010-09-12 18:47:56.057309965 +0900 > @@ -690,19 +690,13 @@ > sc->cpu_cx_count++; > continue; > case ACPI_STATE_C2: : > + ACPI_DEBUG_PRINT((ACPI_DB_INFO, > + "acpi_cpu%d: C2[%d] not available.\n", > + device_get_unit(sc->cpu_dev), i)); > + continue; Logic is mistake. I'll re-make a patch and retry. Thank you. -- Norikatsu Shigemura ___ 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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi mav.
On Sun, 12 Sep 2010 12:29:37 +0300
Alexander Motin wrote:
> > But cx_lowest is not changed:
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - -
> > $ sysctl -a | grep cx
> > hw.acpi.cpu.cx_lowest: C1
:
> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > - - - -
> hw.acpi.cpu.cx_lowest has default in C1. Have you tried to rise it via
> sysctl?
Oops, I forgot usage of cx_lowest.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
# sysctl hw.acpi.cpu.cx_lowest=C2
hw.acpi.cpu.cx_lowest: C1 -> C2
# sysctl -a | grep cx
hw.acpi.cpu.cx_lowest: C2
dev.cpu.0.cx_supported: C1/3 C2/245
dev.cpu.0.cx_lowest: C2
dev.cpu.0.cx_usage: 19.34% 80.65% last 49us
dev.cpu.1.cx_supported: C1/3 C2/245
dev.cpu.1.cx_lowest: C2
dev.cpu.1.cx_usage: 15.28% 84.71% last 922us
dev.cpu.2.cx_supported: C1/3 C2/245
dev.cpu.2.cx_lowest: C2
dev.cpu.2.cx_usage: 77.90% 22.09% last 6034us
dev.cpu.3.cx_supported: C1/3 C2/245
dev.cpu.3.cx_lowest: C2
dev.cpu.3.cx_usage: 80.28% 19.71% last 398us
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
And I can get CPU cooling ~50C(about 45C). Before sysctl cx_lowest=C2,
I got 50C~!
Thank you.
--
Norikatsu Shigemura
___
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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
On Sun, 12 Sep 2010 08:14:09 +0900
Norikatsu Shigemura wrote:
> According to acpidump -dt, I could find CPU0CST table, but
> not found _CST.
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
> Scope (\)
> {
> Name (SSDT, Package (0x0C)
> {
> :
> "CPU0CST ",
> 0xDA9AB618,
> 0x05CD,
> :
> })
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - -
> Hum... ACPI CA 20100806 has a bug?
Humm... I wonder if CF-R9 required another initialization?
I don't know what is HI0 and HC0. But default values of HI0 and
HC0 is 0, and HI0 and HC0 are set CST related values by GCAP,
I think..
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Scope (\_PR.CPU0)
{
Name (HI0, Zero)
Name (HC0, Zero)
:
Method (GCAP, 1, NotSerialized)
{
CreateDWordField (Arg0, Zero, STS0)
CreateDWordField (Arg0, 0x04, CAP0)
If (LOr (LEqual (STS0, 0x06), LEqual (STS0, 0x0A)))
{
Return (Zero)
}
If (And (STS0, One))
{
And (CAP0, 0x0BFF, CAP0)
Return (Zero)
}
Or (And (PDC0, 0x7FFF), CAP0, PDC0)
If (And (CFGD, One))
{
If (LAnd (LAnd (And (CFGD, 0x0100), LEqual (And (PDC0,
0x09), 0x09)), LNot (And (SDTL, One
{
Or (SDTL, One, SDTL)
OperationRegion (IST0, SystemMemory, DerefOf (Index (SSDT,
One)), DerefOf (Index (SSDT, 0x02
)))
Load (IST0, HI0)
}
}
If (And (CFGD, 0xF0))
{
If (LAnd (LAnd (And (CFGD, 0x0100), And (PDC0, 0x18
)), LNot (And (SDTL, 0x02
{
Or (SDTL, 0x02, SDTL)
OperationRegion (CST0, SystemMemory, DerefOf (Index (SSDT,
0x07)), DerefOf (Index (SSDT, 0x08
)))
Load (CST0, HC0)
}
}
Return (Zero)
}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Thank you.
--
Norikatsu Shigemura
___
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: CPU C-state storange on Panasonic TOUGH BOOK CF-R9
Hi nate.
On Sat, 11 Sep 2010 11:30:29 -0700
Nate Lawson wrote:
> I think the issue is that C2 is not available for some reason and thus
> C3 can't be used either. The way to tell is to use acpidump and look for
> the CPU objects' _CST fields.
I attached acpidump -dt (nork-CFR9.asl.bz2) on previous mail, and
I couldn't find _CST, too.
And I added more ACPI debug option, ACPI_DB_INFO. I got following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
cpu0: on acpi0
PROCESSOR-0311 [230584] cpu_attach: acpi_cpu0: P_BLK at 0x410/6
ACPI: SSDT 0xda9adc18 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 002AA (v01 PmRef Cpu0Ist 3000 INTL 20061109)
ACPI: SSDT 0xda9ab618 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 005CD (v01 PmRef Cpu0Cst 3001 INTL 20061109)
PROCESSOR-0696 [241753] cpu_cx_cst: acpi_cpu0: C2[1] not available.
PROCESSOR-0730 [241753] cpu_cx_cst: acpi_cpu0: Got C3 - 245 latency
cpu1: on acpi0
PROCESSOR-0311 [241991] cpu_attach: acpi_cpu1: P_BLK at 0x410/6
ACPI: SSDT 0xda9aca98 00303 (v01 PmRefApIst 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 00303 (v01 PmRefApIst 3000 INTL 20061109)
ACPI: SSDT 0xda9aad98 00119 (v01 PmRefApCst 3000 INTL 20061109)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 00119 (v01 PmRefApCst 3000 INTL 20061109)
PROCESSOR-0696 [254000] cpu_cx_cst: acpi_cpu1: C2[1] not available.
PROCESSOR-0730 [254000] cpu_cx_cst: acpi_cpu1: Got C3 - 245 latency
cpu2: on acpi0
PROCESSOR-0311 [254238] cpu_attach: acpi_cpu2: P_BLK at 0x410/6
PROCESSOR-0696 [255657] cpu_cx_cst: acpi_cpu2: C2[1] not available.
PROCESSOR-0730 [255657] cpu_cx_cst: acpi_cpu2: Got C3 - 245 latency
cpu3: on acpi0
PROCESSOR-0311 [255895] cpu_attach: acpi_cpu3: P_BLK at 0x410/6
PROCESSOR-0696 [257314] cpu_cx_cst: acpi_cpu3: C2[1] not available.
PROCESSOR-0730 [257314] cpu_cx_cst: acpi_cpu3: Got C3 - 245 latency
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
According to acpidump -dt, I could find CPU0CST table, but
not found _CST.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Scope (\)
{
Name (SSDT, Package (0x0C)
{
:
"CPU0CST ",
0xDA9AB618,
0x05CD,
:
})
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Hum... ACPI CA 20100806 has a bug?
Thank you.
--
Norikatsu Shigemura
___
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"
Intel HD Graphics support ready?
Hi rnoland. Do you have any schedule to support Intel HD Graphics on Core i series like Clarkdale/Arrandle? I'm waiting for your patch:-). Thank you. -- Norikatsu Shigemura ___ 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: [CFT] Improved ZFS metaslab code (faster write speed)
Hi mm. On Fri, 27 Aug 2010 16:05:00 -0400 Scott Ullrich wrote: > On Sun, Aug 22, 2010 at 12:26 PM, Martin Matuska wrote: > > Thank you, I have updated the v15 patch for 8-STABLE. > I have been running your patch for a couple days now and no issues. > Nice work! Yes, me too. I'll try to zpool/zfs upgrade! I'm waiting for your update v15, metaslab and abe_stat_rrwlock:-). -- Norikatsu Shigemura ___ 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: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
Hi Kristof. On Sun, 20 Jun 2010 15:01:00 +0200 Kristof Provost wrote: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > /* Tell the MAC where to find the PHY so autoneg works */ > > - miisc = LIST_FIRST(&sc->mii->mii_phys); > > - MGE_WRITE(sc, MGE_REG_PHYDEV, miisc->mii_phy); > > + MGE_WRITE(sc, MGE_REG_PHYDEV, sc->phyaddr); > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > I think that's correct, but I haven't been able to test it on my board > yet. Does this work for you on a board with two GbE ports? If so I'll > try to get someone to commit it. Yes, good works well. I reported following: http://lists.freebsd.org/pipermail/freebsd-arm/2010-June/002402.html Thank you. -- Norikatsu Shigemura ___ 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: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
Hi yongari. On Tue, 15 Jun 2010 11:09:23 -0700 Pyun YongHyeon wrote: > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout > > Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up > ^ > This part looks like a bug in mge(4). Driver does not know how long > it would take to get a valid link. Waiting for valid link in driver > initialization does not work(e.g Starting controller without UTP > cable may always fail on mge(4)). I think mge(4) should implement > correct link state change handling. Thanks for your pointed out. I didn't notice. I'll fix this issue like following on mge_start_locked(). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - if ((ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != - IFF_DRV_RUNNING) + if (IFM_SUBTYPE(sc->mii->mii_media_active) == IFM_NONE || + (ifp->if_drv_flags & (IFF_DRV_RUNNING | IFF_DRV_OACTIVE)) != IFF_DRV_RUNNING) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > I found a initialize issue in e1000phy.c. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > --- sys/dev/mii/e1000phy.c.orig 2010-05-01 10:17:15.282196000 +0900 > > +++ sys/dev/mii/e1000phy.c 2010-06-13 16:19:46.616650536 +0900 > > @@ -278,6 +278,7 @@ > > case MII_MODEL_MARVELL_E1118: > > break; > > case MII_MODEL_MARVELL_E1116: > > + case MII_MODEL_MARVELL_E1149: > > page = PHY_READ(sc, E1000_EADR); > > /* Select page 3, LED control register. */ > > PHY_WRITE(sc, E1000_EADR, 3); > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > I confirmed OK on my environment, OpenRD Ultimate has a 88E1121(I > > saw it, physically): > Once it was there but I removed it due to some other issues seen on > Yukon Ultra. That part will program LED access so I guess it > wouldn't affect normal network activity. Hum..., like following? At least, by current way, second NIC doesn't link-up if link connected. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - case MII_MODEL_MARVELL_E1118: + case MII_MODEL_MARVELL_E1149: break; case MII_MODEL_MARVELL_E1116: page = PHY_READ(sc, E1000_EADR); /* Select page 3, LED control register. */ PHY_WRITE(sc, E1000_EADR, 3); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > 88E1116R might be RGMII variant of 88E1116. Because I don't have > controller that has 88E1116R I didn't treat it as 88E1116. With > that change could you use straight cable without help of MDI/MDI-X > converter? Sorry, I don't have 88E1116R machine, so I don't know. ___ 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: [OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
Hi Kristof. On Sun, 13 Jun 2010 22:13:31 +0200 Kristof Provost wrote: > > I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But > > I couldn't use mge1 like following. So I tried to investigate. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > > Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout > > Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - > I believe the mge(4) driver incorrectly configures the PHY address for > the second interface. Can you give the attached patch a try? Thank you. I think so, too. And, by FDT, I suggest following patch. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /* Tell the MAC where to find the PHY so autoneg works */ - miisc = LIST_FIRST(&sc->mii->mii_phys); - MGE_WRITE(sc, MGE_REG_PHYDEV, miisc->mii_phy); + MGE_WRITE(sc, MGE_REG_PHYDEV, sc->phyaddr); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Norikatsu Shigemura ___ 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"
[OpenRD Ultimate] e1000phy(88E1149/88E1121) has a initialize issue
Hi yongari!
I have a OpenRD Ultimate, which has two GbE ports - if_mge(4). But
I couldn't use mge1 like following. So I tried to investigate.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
Jun 13 05:02:14 sidearms kernel: mge1: watchdog timeout
Jun 13 05:02:14 sidearms kernel: mge1: Timeout on link-up
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
I found a initialize issue in e1000phy.c.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
--- sys/dev/mii/e1000phy.c.orig 2010-05-01 10:17:15.282196000 +0900
+++ sys/dev/mii/e1000phy.c 2010-06-13 16:19:46.616650536 +0900
@@ -278,6 +278,7 @@
case MII_MODEL_MARVELL_E1118:
break;
case MII_MODEL_MARVELL_E1116:
+ case MII_MODEL_MARVELL_E1149:
page = PHY_READ(sc, E1000_EADR);
/* Select page 3, LED control register. */
PHY_WRITE(sc, E1000_EADR, 3);
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
I confirmed OK on my environment, OpenRD Ultimate has a 88E1121(I
saw it, physically):
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
Jun 13 15:20:01 sidearms kernel: miibus0: miibus_probe: ma.mii_id1 = 0x141,
ma.mii_id2 = 0xcb3
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
And I confirmed that MII chipset ID is same as 88E1249.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
mge0
Marvell OBIO Memory:
4043776000-4043784191
Marvell OBIO IRQ:
11
12
13
14
46
miibus0
e1000phy0 pnpinfo oui=0x5043 model=0xb rev=0x3 at phyno=0
mge1
Marvell OBIO Memory:
4043792384-4043800575
Marvell OBIO IRQ:
15
16
17
18
47
miibus1
e1000phy1 pnpinfo oui=0x5043 model=0xb rev=0x3 at phyno=1
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
BTW, I knew same issue on OpenRD Client, it has a 88E1116R, maybe.
Sorry, I don't already have it. I couldn't confirm.
So accordingly my memo:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
miibus0: ma.mii_id1 = 0x141, ma.mii_id2 = 0xe40
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
I found many initialize issues on 88E1116R by not existing on
e1000phy.c. Maybe 88E1116 = 88E1116R like following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
switch (esc->mii_model) {
case MII_MODEL_MARVELL_E:
case MII_MODEL_MARVELL_E1112:
case MII_MODEL_MARVELL_E1116:
+ case MII_MODEL_MARVELL_E1116R:
case MII_MODEL_MARVELL_E1118:
case MII_MODEL_MARVELL_E1149:
case MII_MODEL_MARVELL_PHYG65G:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - -
But there are many points, I don't know that this modify is right.
--
Hayabusa, Okaerinasai!
Norikatsu Shigemura
___
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: clangBSD build error on r208621
Hi rdivacky. On Sat, 29 May 2010 02:17:41 +0900 Norikatsu Shigemura wrote: > error: unknown argument: '-ferror-limit' > mkdep: compile failed > Do you have any idea? Of cause I set following environment: > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - > $ cat /etc/src.conf > NO_WERROR= > WERROR= > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - OK, I got so that clang is too old. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ /usr/bin/clang --version clang version 1.5 (trunk) Target: x86_64-undermydesk-freebsd9.0 Thread model: posix - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So I did use latest clang by installing devel/llvm-devel. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ /usr/local/bin/clang --version clang version 2.0 (trunk) Target: x86_64-portbld-freebsd9.0 Thread model: posix - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I can compile to well-known error point. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ===> sys/boot/i386/boot2 (all) dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.27 secs (18837576 bytes/sec) /usr/local/bin/clang -isysroot /usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/lib/ -L/usr/obj/usr/src/tmp/usr/lib/ -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/boot2/sio.S clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-L/usr/obj/usr/src/tmp/usr/lib/' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '-mrtd' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' objcopy -S -O binary boot1.out boot1 /usr/local/bin/clang -isysroot /usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/lib/ -L/usr/obj/usr/src/tmp/usr/lib/ -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-L/usr/obj/usr/src/tmp/usr/lib/' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '-mrtd' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' /usr/src/sys/boot/i386/boot2/boot2.c:234:1: warning: no previous prototype for function 'main' [-Wmissing-prototypes] main(void) ^ 1 warning generated. sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/s
clangBSD build error on r208621
Hi rdivacky. I svn updated latest clangBSD: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ svn info Path: . URL: file:///home/nork/.svk/local/freebsd/base/projects/clangbsd Repository Root: file:///home/nork/.svk/local Repository UUID: c867b0bc-624e-df11-a429-00248c1b55b2 Revision: 208621 Node Kind: directory Schedule: normal Last Changed Author: rdivacky Last Changed Rev: 208621 Last Changed Date: 2010-05-29 00:45:17 +0900 (Sat, 29 May 2010) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - But I got following error: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- >>> stage 4.2: building libraries -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/usr/obj/usr/src/tmp VERSION="FreeBSD 9.0-CURRENT amd64 900010" INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/usr/obj/usr/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin CC="clang -isysroot /usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/lib/ -L/usr/obj/usr/src/tmp/usr/lib/" CXX="clang++ -isysroot /usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/lib/ -L/usr/obj/usr/src/tmp/usr/lib/" NO_CTF=1 make -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp -DNO_FSCHG -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN -DWITHOUT_ PROFILE libraries cd /usr/src; make -f Makefile.inc1 _prereq_libs; make -f Makefile.inc1 _startup_libs; make -f Makefile.inc1 _prebuild_libs; make -f Makefile.inc1 _generic_libs; ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend CC='clang -isysroot /usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/lib/ -L/usr/obj/usr/src/tmp/usr/lib/' mkdep -f .depend -a-DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libssp_nonshared/.. -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include -DPIC /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-local.c error: unknown argument: '-ferror-limit' mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Do you have any idea? Of cause I set following environment: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ cat /etc/src.conf NO_WERROR= WERROR= - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- Norikatsu Shigemura ___ 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: amdtemp(4) issue
Hi jkim. On Wed, 5 May 2010 13:51:10 -0400 Jung-uk Kim wrote: > > 11 - 0x01 = +10C > > 11 - 0x18 = -13C > > 11 - 0x3f = -52C > > [*] http://support.amd.com/us/Processor_TechDocs/31116.pdf > AMD keeps flipping the sign from core to core. :-( Please see > AMDTEMP_FLAG_DO_SIGN for Family 0Fh, for example. In fact, Linux > driver (k10temp) does not care about the DiodeOffset at all. > Instead, they just say "input" temperature. Oh my god... OK, I see. > > I got following thermal related registers in amdtemp_gettemp > > function: May 5 15:06:53 nadesico kernel: amdtemp0: F3x64 Hardware > > Thermal Control(HTC) Register = 0x3a4c0005 May 5 15:06:53 nadesico > > kernel: amdtemp0: F3x68 Software Thermal Control(STC) Register = > > 0x1000 May 5 15:06:53 nadesico kernel: amdtemp0: F3xA4 > > Reported Temperature Control Register = 0x000c1880 May 5 15:06:53 > > nadesico kernel: amdtemp0: F3xE4 Thermtrip Status Register > > = 0x1cc01830 May 5 15:06:53 nadesico kernel: amdtemp0: F3xE8 > > Northbridge Capabilities Register = 0x0207df19 > > But I don't have any idea to fix register's paraemters. Do you > > have any idea? > Sorry, I don't. You may find Linux k10temp driver > (drivers/hwmon/k10temp.c) useful, though. Thank you, I'll compare other implementations. ___ 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"
amdtemp(4) issue
Hi jkim.
I can't get CPU temperature via amdtemp(4). So I researched, but
I can't fix this issue, maybe initialization problem. Please help
me!
1st issue in amdtemp_gettemp function:
now:offset += (diode_offset - 11) * 10; is BAD
should fix: offset += (11 - diode_offset) * 10; is OK
According to AMD's BIOS and Kernel Developer's Guid (BKDG) For
AMD Family 10th Processors, Rev 3.48 - April 22, 2010 [*],
P327 - F3xE4 Thermtrip Status Register:
01h to 3Fh: correction = +11C - DiodeOffset, or {01h to 3Fh} = {+10C to -52C}.
In fact, in my environment, DiodeOffset = 0x18 so 11-0x18=-13C.
11 - 0x01 = +10C
11 - 0x18 = -13C
11 - 0x3f = -52C
[*] http://support.amd.com/us/Processor_TechDocs/31116.pdf
2nd issue, result of AMDTEMP_REPTMP_CTRL in amdtemp_gettemp function:
I got following result:
May 5 15:06:53 nadesico kernel: amdtemp0: AMDTEMP_REPTMP_CTRL(temp) = 0xc1880
So result (CurTmp: current temperature: 31:21) = 0C. (logic is OK)
I got following thermal related registers in amdtemp_gettemp function:
May 5 15:06:53 nadesico kernel: amdtemp0: F3x64 Hardware Thermal Control(HTC)
Register = 0x3a4c0005
May 5 15:06:53 nadesico kernel: amdtemp0: F3x68 Software Thermal Control(STC)
Register = 0x1000
May 5 15:06:53 nadesico kernel: amdtemp0: F3xA4 Reported Temperature Control
Register = 0x000c1880
May 5 15:06:53 nadesico kernel: amdtemp0: F3xE4 Thermtrip Status Register
= 0x1cc01830
May 5 15:06:53 nadesico kernel: amdtemp0: F3xE8 Northbridge Capabilities
Register = 0x0207df19
But I don't have any idea to fix register's paraemters. Do you
have any idea?
--
Norikatsu Shigemura
___
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: ATA_CAM-ed mvsata(4) on OpenRD-client
Hi mav. On Wed, 31 Mar 2010 10:25:38 +0300 Alexander Motin wrote: > > spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long > > panic: spin lock held too long > > KDB: enter: panic > > [ thread pid 0 tid 10 ] > > Stopped at 0xc09dcb50 = kdb_enter+0x48:ldrbr15, [r15, r15, ror > > r15]! > > db> > Fixed at SVN r205967. Oops, sorry! That's great news! I'll retry. ___ 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: Core i5 AES acceleration
Hi David. On Sun, 07 Mar 2010 09:59:07 -0800 David Ehrmann wrote: > I was thinking that if I did do it, I'd start with padlock as a base. > It looks like there are maybe 6 new opcodes. Maybe we could ask the > contributor of the Linux code (an Intel employee) if he'd be willing to > also release the code under a BSD license. According to http://en.wikipedia.org/wiki/AES-NI , we can get specification document: http://software.intel.com/file/20457 . I saw it, and consider that we can release under BSDL. Because of 'from specification'. > My problem is that I don't have a Core i5 system--I was asking because > it's an option for my new system--and I'm far from an x86 assembly expert. I have a machine equipped with Core i7 640UM, so I'll be able to test. But I'm far from an x86asm expert, too:-(. ___ 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: Core i5 AES acceleration
Hi Devid and Julian. On Sat, 06 Mar 2010 22:10:28 -0800 Julian Elischer wrote: > David Ehrmann wrote: > > Does FreeBSD currently support cryptographic acceleration for AES on the > > Core i5 CPU? I searched, but couldn't find anything, and the crypto(4) > > manpage only lists these divers in "see also:" > no, but if you write a driver for it we will... :-) > (most things in open source happen because someone needs it.) I found Linux's code: http://lwn.net/Articles/311094/ I think that it looks too easy, maybe, we should implement aesni(4) like padlock(4). ___ 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: ATA_CAM-ed mvsata(4) on OpenRD-client
Hi mav.
On Sun, 28 Feb 2010 13:31:45 +0900
Norikatsu Shigemura wrote:
> I didn't know what's happen. So I'll report code trace and
> cam related struct dump with ddb which I made.
Code trace with printf debug:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
periphdriver_init() @sys/cam/cam_periph.c
-> adainit() @sys/cam/ata/ata_da.c OK
-> probe_periph_init() @sys/cam/scsi/scsi_xpt.c OK
-> pmpinit() @sys/cam/ata/ata_pmp.c FREEZE
-> xpt_register_async() @sys/cam/cam_xpt.c
-> xpt_for_all_devices() @sys/cam/cam_xpt.c
-> xptbustraverse() @sys/cam/cam_xpt.c
- - - - - in xptbustraverse() - - - - -
for (bus = (start_bus ? start_bus : TAILQ_FIRST(&xsoftc.xpt_busses));
bus != NULL;
bus = next_bus) {
next_bus = TAILQ_NEXT(bus, links);
mtx_unlock(&xsoftc.xpt_topo_lock);
-> CAM_SIM_LOCK(bus->sim);
freeze at this point, because of not catch lock, in the first loop.
retval = tr_func(bus, arg);
CAM_SIM_UNLOCK(bus->sim);
if (retval == 0)
return(retval);
mtx_lock(&xsoftc.xpt_topo_lock);
}
- - - - - in xptbustraverse() - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
So I dumped following mtx, cam_eb IN (0xc36c88c0, 0xc3770840,
0xc35df5c0)->sim.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
db> show lock 0xc35e5974
class: spin mutex
name:
flags: {SPIN}
state: {OWNED, CONTESTED}
owner: 0xc36c8d00 (tid 0, pid -1062090240, "")
db> show lock 0xc35e5774
class: sleep mutex
name: ATA state lock
flags: {DEF}
state: {UNOWNED}
db> show lock 0xc0be5204
class: sleep mutex
name: XPT lock
flags: {DEF}
state: {UNOWNED}
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
___
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: ATA_CAM-ed mvsata(4) on OpenRD-client
Hi mav. I didn't know what's happen. So I'll report code trace and cam related struct dump with ddb which I made. The first, cam ddb patch: show cam show cam_eb show cam_et show cam_ed show cam_sim show cam_periph I saw gibbs'd document, and made it. If not enough, please tell me! (*) http://people.freebsd.org/~gibbs/ARTICLE-0001.html I got following results: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - : sata0: at mem 0xf108-0xf1085fff irq 21 on mbus0 sata0: [MPSAFE] sata0: [ITHREAD] ata0: on sata0 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on sata0 ata1: [MPSAFE] ata1: [ITHREAD] pcib0: at mem 0xf104-0xf1041fff on mbus0 pcib0: PCI IO/Memory space exhausted device_attach: pcib0 attach returned 12 Timecounter "CPU Timer" frequency 2 Hz quality 1000 Timecounters tick every 10.000 msec lo0: bpf attached spin lock 0xc36c8d00 () held by 0xc361bb08 (tid -1061281488) too long panic: spin lock held too long KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at 0xc09e1d04 = kdb_enter+0x48:ldrbr15, [r15, r15, ror r15]! db> show cam Transport layer configuration information: cam_eb = 0xc36c88c0: path_id = 0, sim_name = ata cam_et = 0xc36c8880: target_id = 4294967295 cam_ed = 0xc376e000: lun_id = 4294967295 cam_eb = 0xc3770840: path_id = 1, sim_name = ata cam_et = 0xc3770800: target_id = 4294967295 cam_ed = 0xc376e800: lun_id = 4294967295 cam_eb = 0xc35df5c0: path_id = 4294967295, sim_name = xpt cam_et = 0xc35df540: target_id = 4294967295 cam_ed = 0xc356d800: lun_id = 4294967295 cam_periph = 0xc3574b80: unit_number = 0, periph_name = xpt - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [cam_eb = 0xc36c88c0] OK line - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - db> show cam_eb 0xc36c88c0 CAM Existing Bus information: et_entries = -> 0xc36c8880 (struct cam_et *) links = -> 0xc3770840 (struct cam_eb *) path_id= 0 sim= 0xc3604780 (struct cam_sim *) last_reset = 0.0[s] flags = 0x0 refcount = 4 generation = 1 parent_dev = 0 (device_t) xport = 0xc0bbfe80 (struct xpt_xport *) db> show cam_sim 0xc3604780 SIM(SCSI Interface Module) information: sim_action = 0xc0929c38 sim_poll = 0xc09294e8 sim_name = ata softc = 0xc35e5800 (void *) mtx= 0xc35e5974 (struct mtx *) sim_doneq = -> 0 (struct ccb_hdr *) links = -> 0 (struct cam_sim *) path_id= 0 unit_number= 0 bus_id = 0 max_tagged_dev_openings = 0 max_dev_openings = 1 flags = 0x2 callout= 0xc36047bc (struct callout) devq = 0xc3604800 (struct cam_devq) refcount = 2 ccb_freeq = -> 0 (struct ccb_hdr *) max_ccbs = 9 ccb_count = 0 db> show cam_et 0xc36c8880 CAM Existing Target information: ed_entries = -> 0xc376e000 (struct cam_ed *) links = -> 0 (struct cam_et *) bus= 0xc36c88c0 (struct cam_eb *) target_id = 4294967295 refcount = 3 generation = 1 last_reset = 0.0[s] db> show cam_ed 0xc376e000 CAM Existing Device information: links = -> 0 (struct cam_ed *) alloc_ccb_entry send_ccb_entry target = 0xc36c8880 (struct cam_et *) sim= 0xc3604780 (struct cam_sim *) lun_id = 4294967295 drvq ccbq asyncs periphs= -> 0 (struct cam_periph *) generation = 0 owner = 0 (struct cam_periph *) quirk = 0 (void *) maxtags= 1 mintags= 1 protocol protocol_version = 0 transport transport_version = 0 inq_data ident_data inq_flags = 0x0 queue_flags= 0x0 serial_num_len = 0 serial_num = 0 (u_int8_t *) flags = 0x1 tag_delay_count= 0 tag_saved_openings = 0 refcount = 2 callout= 0xc376e3d0 (struct callout) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [cam_eb = 0xc35df5c0] Freeze Line - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - db> show cam_eb 0xc35df5c0 CAM Existing Bus information: et_entries = -> 0xc35df540 (struct cam_et *) links = -> 0 (struct cam_eb *) path_id= 4294967295 sim= 0xc3574c00 (struct cam_sim *) last_reset = 0.0[s] flags = 0x0 refcount = 3 generation = 3 parent_dev = 0 (device_t) xport = 0xc0bbfc6c (struct xpt_xport *) db>
Re: ATA_CAM-ed mvsata(4) on OpenRD-client
Hi mav.
On Fri, 19 Feb 2010 22:36:12 +0200
Alexander Motin wrote:
> > xpt_sim_opened() at 0xc0904048 = xpt_sim_opened+0x218
> > scp=0xc0904048 rlv=0xc0905940 (0xc0905940 = xpt_register_async+0xd0)
> > rsp=0xc0d62d8c rfp=0xc0d62e34
> > xpt_register_async() at 0xc0905880 = xpt_register_async+0x10
> > scp=0xc0905880 rlv=0xc090d484 (0xc090d484 = ata_get_xport+0x2198)
> > rsp=0xc0d62e38 rfp=0xc0d62e44
> > r10=0x r9=0x
> > r8=0x005fffcc r7=0xc35593c0 r6=0xc0b62170 r5=0xc0be74d0
> > r4=0x001c
> Even more unexpected. I've searched all sources for xpt_sim_opened()
> call and found only one place - in atapi-cam.c, which shouldn't be used
> in your case. You are using different sources, or there is a garbage in
> stack?
I tried to printf-debug, so I got what's happen.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
module_register_init: MOD_LOAD(elf32) called in
module_register_init: MOD_LOAD(elf32 on elf kernel/elf kernel) called out
module_register_init: MOD_LOAD(shell) called in
module_register_init: MOD_LOAD(shell on elf kernel/elf kernel) called out
module_register_init: MOD_LOAD(if_lo) called in
module_register_init: MOD_LOAD(if_lo on elf kernel/elf kernel) called out
lo0: bpf attached
[DEBUG] xpt_config called #4501@/usr/src/sys/cam/cam_xpt.c
[DEBUG] xpt_config #4532@/usr/src/sys/cam/cam_xpt.c
[DEBUG] xpt_config #4538@/usr/src/sys/cam/cam_xpt.c
[DEBUG] periphdriver_init(1), init = 1 #132@/usr/src/sys/cam/cam_periph.c
[DEBUG] periphdriver_init:, i = 0, driver_name = ada
[DEBUG] periphdriver_init:, i = 1, driver_name = probe
[DEBUG] periphdriver_init:, i = 2, driver_name = pmp
spin lock 0xc3789100 () held by 0xc3632348 (tid 0) too long
panic: spin lock held too long
KDB: enter: panic
[ thread pid 0 tid 10 ]
Stopped at 0xc09dede0 = kdb_enter+0x48:ldrbr15, [r15, r15, ror
r15]!
db> show lock 0xc3789100
class: spin mutex
name:
flags: {SPIN, RECURSE}
state: {OWNED}
owner: 0xc3632348 (tid 0, pid 0, "")
recursed: -251133952
db> bt
Tracing pid 0 tid 10 td 0xc0be6ab0
kdb_enter() at 0xc09deda8 = kdb_enter+0x10
scp=0xc09deda8 rlv=0xc09b572c (0xc09b572c = panic+0xcc)
rsp=0xc0d6ec10 rfp=0xc0d6ec24
r4=0x0100
panic() at 0xc09b5674 = panic+0x14
scp=0xc09b5674 rlv=0xc09a99fc (0xc09a99fc = _thread_lock_flags+0x170)
rsp=0xc0d6ec38 rfp=0xc0d6ec80
_thread_lock_flags() at 0xc09a989c = _thread_lock_flags+0x10
scp=0xc09a989c rlv=0xc09ec7c0 (0xc09ec7c0 = turnstile_claim+0x16c)
rsp=0xc0d6ec84 rfp=0xc0d6eca0
r10=0xc0bf244c r9=0x
r8=0xc3562000 r7=0x0044 r6=0xc3562000 r5=0xc3789100
r4=0xc0b68548
turnstile_claim() at 0xc09ec768 = turnstile_claim+0x114
scp=0xc09ec768 rlv=0xc09ecad8 (0xc09ecad8 = turnstile_wait+0x23c)
rsp=0xc0d6eca4 rfp=0xc0d6eccc
r7=0xc0be6ab0 r6=0xc3789100
r5=0xc0b68548 r4=0x
turnstile_wait() at 0xc09ec8ac = turnstile_wait+0x10
scp=0xc09ec8ac rlv=0xc09a9568 (0xc09a9568 = _mtx_lock_sleep+0x11c)
rsp=0xc0d6ecd0 rfp=0xc0d6ed00
r10=0xc0b4aa58 r9=0x
r8=0x r7=0x r6=0xc0be6ab0 r5=0xc3562000
r4=0xc35fe974
_mtx_lock_sleep() at 0xc09a945c = _mtx_lock_sleep+0x10
scp=0xc09a945c rlv=0xc09a9650 (0xc09a9650 = _mtx_lock_flags+0x88)
rsp=0xc0d6ed04 rfp=0xc0d6ed2c
r10=0xc0d6ed60 r9=0xc0903a68
r8=0x r7=0x07c7 r6=0xc0b4aa58 r5=0x
r4=0xc35fe974
_mtx_lock_flags() at 0xc09a95d8 = _mtx_lock_flags+0x10
scp=0xc09a95d8 rlv=0xc0903e98 (0xc0903e98 = xpt_unlock_buses+0x148)
rsp=0xc0d6ed30 rfp=0xc0d6ed58
r8=0xc0be33fc r7=0xc090e838
r6=0xc370 r5=0xc0b4aa58 r4=0xc3788b80
xpt_unlock_buses() at 0xc0903e28 = xpt_unlock_buses+0xd8
scp=0xc0903e28 rlv=0xc0903f54 (0xc0903f54 = xpt_unlock_buses+0x204)
rsp=0xc0d6ed5c rfp=0xc0d6ed78
r10=0xc0be3410 r9=0xc0b4aa58
r8=0x r7=0xc090e838 r6=0x0080 r5=0x
r4=0x0001
xpt_unlock_buses() at 0xc0903f34 = xpt_unlock_buses+0x1e4
scp=0xc0903f34 rlv=0xc0905d5c (0xc0905d5c = xpt_register_async+0xd0)
rsp=0xc0d6ed7c rfp=0xc0d6ee24
xpt_register_async() at 0xc0905c9c = xpt_register_async+0x10
scp=0xc0905c9c rlv=0xc090e818 (0xc090e818 = ata_get_xport+0x2d54)
rsp=0xc0d6ee28 rfp=0xc0d6ee34
r10=0x r9=0x
r8=0x005fffcc r7=0xc3584460 r6=0xc0b4aa58 r5=0x0002
r4=0x0008
ata_get_xport() at 0xc090e808 = ata_get_xport+0x2d44
scp=0xc090e808 rlv=0xc09008a4 (0xc09008a4 = periphdriver_init+0x9c)
rsp=0xc0d6ee38 rfp=0xc0d6ee50
periphdriver_init() at 0xc0900818 = periphdriver_init+0x10
scp=0xc0900818 rlv=0xc0904620 (0xc0904620 = xpt_alloc_ccb+0xbc)
rsp=0xc0d6ee54 rfp=0xc0d6ee74
r5=0xc0b4ab9c r4=0x
xpt_alloc_ccb() at 0xc09045a0 = xpt_alloc_ccb+0x3c
scp=0xc09045a0 rlv=0xc09d4e84 (0xc09d4e84 = vaccess_acl_posix1e+0x628)
rsp=0xc0d6ee78 rfp
Re: ATA_CAM-ed mvsata(4) on OpenRD-client
Hi Warner-san. On Fri, 19 Feb 2010 14:43:19 -0700 (MST) "M. Warner Losh" wrote: > : Even more unexpected. I've searched all sources for xpt_sim_opened() > : call and found only one place - in atapi-cam.c, which shouldn't be used > : in your case. You are using different sources, or there is a garbage in > : stack? > IIRC, I got better stack traces when I used the kernel.tramp kernel... How do I use kernel.tramp? I did 'tftpboot 0x90 kernel.tramp.bin' on uboot, but it's freeze after 'go 0x90'. ___ 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"
ATA_CAM-ed mvsata(4) on OpenRD-client
Hi mav! I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to make mvsata(4) ATA_CAM, like following: based on sys/arm/conf/DB-88F6XXX - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # SATA #device ata #device atadisk device atacore device atamvsata options ATA_CAM - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - But I got following panic, my I help you? In this time, I attached no devices to SATA/eSATA port. - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sata0: at mem 0xf108-0xf1085fff irq 21 on mbus0 sata0: [MPSAFE] sata0: [ITHREAD] ata0: on sata0 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on sata0 ata1: [MPSAFE] ata1: [ITHREAD] spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long panic: spin lock held too long KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at 0xc09dcb50 = kdb_enter+0x48:ldrbr15, [r15, r15, ror r15]! db> - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So I tried to get following information: - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - db> show locks exclusive sleep mutex Giant (Giant) r = 0 (0xc0be3ad4) locked @ /usr/src/sys/kern/kern_module.c:117 db> show alllocks Process 0 (kernel) thread 0xc0be1fa0 (10) exclusive sleep mutex Giant (Giant) r = 0 (0xc0be3ad4) locked @ /usr/src/sys/kern/kern_module.c:117 db> show lockedvnods Locked vnodes db> show pcpu cpuid= 0 dynamic pcpu= 0x17fc00 curthread= 0xc0be1fa0: pid 0 "swapper" curpcb = 0xc0d62ef8 fpcurthread = none idlethread = 0xc357bd80: pid 10 "idle" spin locks held: db> bt Tracing pid 0 tid 10 td 0xc0be1fa0 kdb_enter() at 0xc09dcb18 = kdb_enter+0x10 scp=0xc09dcb18 rlv=0xc09b2cf0 (0xc09b2cf0 = panic+0xcc) rsp=0xc0d62c1c rfp=0xc0d62c30 r4=0x0100 panic() at 0xc09b2c38 = panic+0x14 scp=0xc09b2c38 rlv=0xc09a6fb8 (0xc09a6fb8 = _thread_lock_flags+0x170) rsp=0xc0d62c44 rfp=0xc0d62c8c _thread_lock_flags() at 0xc09a6e58 = _thread_lock_flags+0x10 scp=0xc09a6e58 rlv=0xc09e9e98 (0xc09e9e98 = turnstile_claim+0x174) rsp=0xc0d62c90 rfp=0xc0d62cac r10=0xc3556000 r9=0x r8=0xc3556000 r7=0x0044 r6=0xc3556000 r5=0xc3766680 r4=0xc0b644c0 turnstile_claim() at 0xc09e9e40 = turnstile_claim+0x11c scp=0xc09e9e40 rlv=0xc09ea17c (0xc09ea17c = turnstile_wait+0x208) rsp=0xc0d62cb0 rfp=0xc0d62cdc r7=0xc0be1fa0 r6=0xc0be8e40 r5=0xc0b644c0 r4=0x turnstile_wait() at 0xc09e9f84 = turnstile_wait+0x10 scp=0xc09e9f84 rlv=0xc09a6b30 (0xc09a6b30 = _mtx_lock_sleep+0x11c) rsp=0xc0d62ce0 rfp=0xc0d62d10 r10=0xc0b47100 r9=0x r8=0x r7=0x r6=0xc0be1fa0 r5=0xc3556000 r4=0xc35dd974 _mtx_lock_sleep() at 0xc09a6a24 = _mtx_lock_sleep+0x10 scp=0xc09a6a24 rlv=0xc09a6c0c (0xc09a6c0c = _mtx_lock_flags+0x7c) rsp=0xc0d62d14 rfp=0xc0d62d3c r10=0xc0d62d70 r9=0xc09039a8 r8=0x r7=0x0851 r6=0xc0b47100 r5=0x r4=0xc35dd974 _mtx_lock_flags() at 0xc09a6ba0 = _mtx_lock_flags+0x10 scp=0xc09a6ba0 rlv=0xc0903fac (0xc0903fac = xpt_sim_opened+0x17c) rsp=0xc0d62d40 rfp=0xc0d62d68 r8=0xc0bde8f0 r7=0xc090d4a4 r6=0xc3765e00 r5=0xc0b47100 r4=0xc3766240 xpt_sim_opened() at 0xc0903f3c = xpt_sim_opened+0x10c scp=0xc0903f3c rlv=0xc0904068 (0xc0904068 = xpt_sim_opened+0x238) rsp=0xc0d62d6c rfp=0xc0d62d88 r10=0xc0bde904 r9=0xc0b47100 r8=0x r7=0xc090d4a4 r6=0x0080 r5=0x r4=0x0001 xpt_sim_opened() at 0xc0904048 = xpt_sim_opened+0x218 scp=0xc0904048 rlv=0xc0905940 (0xc0905940 = xpt_register_async+0xd0) rsp=0xc0d62d8c rfp=0xc0d62e34 xpt_register_async() at 0xc0905880 = xpt_register_async+0x10 scp=0xc0905880 rlv=0xc090d484 (0xc090d484 = ata_get_xport+0x2198) rsp=0xc0d62e38 rfp=0xc0d62e44 r10=0x r9=0x r8=0x005fffcc r7=0xc35593c0 r6=0xc0b62170 r5=0xc0be74d0 r4=0x001c ata_get_xport() at 0xc090d474 = ata_get_xport+0x2188 scp=0xc090d474 rlv=0xc0900868 (0xc0900868 = periphdriver_init+0x60) rsp=0xc0d62e48 rfp=0xc0d62e58 periphdriver_init() at 0xc0900818 = periphdriver_init+0x10 scp=0xc0900818 rlv=0xc0904584 (0xc0904584 = xpt_alloc_ccb+0x6c) rsp=0xc0d62e5c rfp=0xc0d62e74 r4=0x xpt_alloc_ccb() at 0xc0904554 = xpt_alloc_ccb+0x3c scp=0xc0904554 rlv=0xc09d2d9c (0xc09d2d9c = vaccess_acl_posix1e+0x628) rsp=0xc0d62e78 rfp=0xc0d62ee0 r4=0x vaccess_acl_posix1e() at 0xc09d2d44 = vaccess_acl_posix1e+0x5d0 scp=0xc09d2d44 rlv=0xc097b0ec (0xc097b0ec = mi_startup+0xdc) rsp=0xc0d62ee4 rfp=0xc0d62ef4 r7=0x00900040 r6=0x0002 r5=0x0090004c r4=0xc0b7e88c mi_startup() at 0xc097
NFSSERVER is strange, now?
Hi. I noticed that I can't kldload nfsserver.ko like following: on boot(rc script) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Clearing /tmp. link_elf_obj: symbol sysctl__vfs_nfs_children undefined linker_load_file: Unsupported file type kldload: can't load nfsserver : Exec format error /etc/rc: WARNING: Unable to load kernel module nfsserver - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So I added following line and recompile: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --- src/sys/nfsserver/nfs_srvsubs.c.orig 2009-07-01 10:32:48.651174000 +0900 +++ src/sys/nfsserver/nfs_srvsubs.c 2010-02-14 11:46:57.522314345 +0900 @@ -558,6 +558,7 @@ /* So that loader and kldload(2) can find us, wherever we are.. */ MODULE_VERSION(nfsserver, 1); +MODULE_DEPEND(nfsserver, nfs, 1, 1, 1); MODULE_DEPEND(nfsserver, nfssvc, 1, 1, 1); MODULE_DEPEND(nfsserver, krpc, 1, 1, 1); - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - And it's OK, but a little on boot(rc script) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Clearing /tmp. can't re-use a leaf (realign_count)! can't re-use a leaf (realign_test)! Starting mountd. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How about? ___ 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: FYI: VMware Workstation, ACPI support for FreeBSD guest
On Fri, 28 Nov 2003 21:03:24 +0900 Makoto Matsushita <[EMAIL PROTECTED]> wrote: > is enabled, etc. Moreover, it seems that long standing "random/slower/ > faster clock-time bug" is resolved! Wow! I want new one:-). > Please note that this is about FreeBSD as VMware's *guest* OS, not > as *host* OS. Anyone, do you try to support it like emulators/vmware[23]? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Flash Plugin report
On Fri, 24 Oct 2003 00:40:24 -0300 Roberto de Iriarte <[EMAIL PROTECTED]> wrote: > a) Problem > Right upon installing mozilla 1.5 from ports, i installed > flashpluginwrapper-20031006, and found out that mozilla would fail to > exit eating up CPU as if stuck in an infinite loop (Usage per top went > up into high 90%'s) if the plugin was triggered (by viewing a flash movie) > The same result was observed using the native java plugin (J2SE 1.4.1 > patchlevel 4 from ports) I heard this behavior like yours. But I don't have any idea to fix this behavior. > I decided to give libkse a try so i modified libmap.conf, and rebooted > the system for good measure and mozilla works perfectly. (And > responsivenes is excellent, and cpu usage much reduced, btw) Humm.. I use libkse, too. I wonder if we had better use libkse. > c) Ignorance from my part > Is linux.ko necessary to run flashpluginwrapper ? I forgot to enable it > in rc.conf and it seems to run equally well !? Theoretically, flashpluginwrapper uses userland COMPAT_LINUX technology:-), and is A killer application of libmap.conf feature:-)). So we don't need linux.ko (COMPAT_LINUX). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: threading problems
On Mon, 1 Sep 2003 03:13:31 +0100 (BST) RMH <[EMAIL PROTECTED]> wrote: > # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -pthread > # ./smp > 4Gb per pass mode > INTEGER | WRITING 8 Kb block: 1351 Mb/s > res0: 674 > res1: 677 > # gcc -O2 -fomit-frame-pointer -march=i686 -o smp2 smp.c -L/usr/local/lib > -llthread > # ./smp2 > 4Gb per pass mode > INTEGER | WRITING 8 Kb block: 2697 Mb/s > res0: 1349 > res1: 1348 Hum... with Linux Thread # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -I/usr/local/include/pthread -L/usr/local/lib -llthread # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 7613 Mb/s res0: 3808 res1: 3805 with libc_r (1:M thread model) # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lc_r # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 3828 Mb/s res0: 1902 res1: 1926 with libthr (1:1 thread model) # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lthr # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 7447 Mb/s res0: 3763 res1: 3684 with libkse (M:N thread model) # gcc -O2 -fomit-frame-pointer -march=i686 -o smp smp.c -lkse # ./smp 4Gb per pass mode INTEGER | WRITING 8 Kb block: 7592 Mb/s res0: 3789 res1: 3803 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Native JDK with libthr/libkse
I am testing about JDK1.4.1/1.3.1 with libthr/libkse using /etc/libmap.conf. 1. JDK1.3.1/libthr is not work. java is stop. 2. JDK1.3.1/libkse is not work. java is stop. 3. JDK1.4.1/libthr is not work. java is stop. 4. JDK1.4.1/libkse is good work. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ /usr/local/jdk1.4.1/bin/java -jar /usr/local/jdk1.4.1/demo/jfc/Java2D/Java2Demo.jar May 31, 2003 10:33:14 AM java.util.prefs.FileSystemPreferences$3 run WARNING: Could not create system preferences directory. System preferences are unusable. May 31, 2003 10:33:45 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode WARNING: Could not lock System prefs.Unix error code 136418560. May 31, 2003 10:33:45 AM java.util.prefs.FileSystemPreferences syncWorld WARNING: Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock. May 31, 2003 10:34:15 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode WARNING: Could not lock System prefs.Unix error code 136418560. May 31, 2003 10:34:15 AM java.util.prefs.FileSystemPreferences syncWorld WARNING: Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock. May 31, 2003 10:34:45 AM java.util.prefs.FileSystemPreferences checkLockFile0ErrorCode WARNING: Could not lock System prefs.Unix error code 136418560. May 31, 2003 10:34:45 AM java.util.prefs.FileSystemPreferences syncWorld WARNING: Couldn't flush system prefs: java.util.prefs.BackingStoreException: Couldn't get file lock. : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - top displays interesting message. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - last pid: 79860; load averages: 0.35, 0.19, 0.08 up 0+15:56:30 10:37:12 75 processes: 1 running, 74 sleeping CPU states: 16.6% user, 0.0% nice, 4.2% system, 1.5% interrupt, 77.6% idle Mem: 276M Active, 80M Inact, 111M Wired, 28M Cache, 60M Buf, 4164K Free Swap: 4096M Total, 6844K Used, 4089M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 597 root 970 109M99M select 6:37 3.91% 3.91% XFree86 : 79849 nork -84 -203 209M 41368K 0:00 0.00% 0.00% java - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - top is XFree86, bottom is java:-). And java is no state:-). Quite light! I cannot believe:-). java uses libkse. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ fstat -m /usr/lib/libc_r* /usr/lib/libthr* /usr/lib/libkse* nork java 79849 mmap /usr 447622 -r--r--r-- 112948 r /usr/lib/libkse.so.1 nork java 79849 mmap /usr 447622 -r--r--r-- 112948 r /usr/lib/libkse.so.1 nork java 79849 mmap /usr 447622 -r--r--r-- 112948 rw /usr/lib/libkse.so.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tested on 5.1-BETA. AthlonXP(1780MHz w/ overclock) x1 + 512MB DDR-SDRAM + ATI Radeon9100. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - FreeBSD melfina.ninth-nine.com 5.1-BETA FreeBSD 5.1-BETA #16: Thu May 29 22:17:51 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MELFINA i386 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Libthr stable enough for testing
Hi Lars. On Wed, 28 May 2003 22:20:19 -0700 Lars Eggert <[EMAIL PROTECTED]> wrote: > The problem was fixed by building/reinstalling the problematic ports > without libthr symlinked into place. Can you try to use WITH_LIBMAP=YES feature in /usr/src/libexec/ rtld-elf/Makefile(SEE ALSO: libmap.conf(5)). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fix for rtc, vmware modules and post-500104 -current
On Thu, 13 Mar 2003 04:09:27 +0900
Yoshinori KASAZAKI <[EMAIL PROTECTED]> wrote:
> > Hum.. This is not work in my environment. Because MOD_LOAD initializer
> > didn't kick rtc_attach. I fixed this problem and merge(but ADHOC:-).
> > Please, anyone, check following patch.
> I've just applied your patch and rebuilt rtc.ko.
> It gave me /dev/rtc and VMware2 doesn't complain about
> 'cannot open /dev/rtc...' any more.
> It seems to be working well.
Humm.. I saw it. I make MOD_LOAD initializer do only make_dev.
> (except
> WARNING: driver "rtc" used unreserved major device number 202
> message, which seems to be harmless)
:-).
> > BTW, vmmon_*.ko is not good. hum
> vmmon_up.ko is working for me now with Marcin's patch.
> My -current is dated as 2003/03/10.
Yes. vmmon_up.ko is works.. But when vmware2 reseted, vmware2
complains 'cannnot open /dev/vmmon'.
diff -urN emulators/rtc/Makefile local/rtc/Makefile
--- emulators/rtc/Makefile Fri Mar 7 15:01:17 2003
+++ local/rtc/Makefile Fri Mar 14 06:28:23 2003
@@ -6,7 +6,7 @@
#
PORTNAME= rtc
-PORTVERSION= 2001.09.16.1
+PORTVERSION= 2002.03.05.2
CATEGORIES= emulators linux
MASTER_SITES= # none
DISTFILES= # none
diff -urN emulators/rtc/files/rtc.c local/rtc/files/rtc.c
--- emulators/rtc/files/rtc.c Sun Sep 16 16:05:18 2001
+++ local/rtc/files/rtc.c Fri Mar 14 06:27:40 2003
@@ -85,6 +85,14 @@
static int rtc_modeevent(module_t mod, int cmd, void *arg);
static struct cdevsw rtc_cdevsw = {
+#if __FreeBSD_version >= 500104
+ .d_open = rtc_open,
+ .d_close = rtc_close,
+ .d_ioctl = rtc_ioctl,
+ .d_poll = rtc_poll,
+ .d_name = DEVICE_NAME,
+ .d_maj = CDEV_MAJOR,
+#else
/* open */ rtc_open,
/* close */ rtc_close,
/* read */ noread,
@@ -104,6 +112,7 @@
#if __FreeBSD_version >= 500018 || __FreeBSD_version >= 43
/* kqfilter */ nokqfilter,
#endif
+#endif
};
/*
@@ -135,10 +144,6 @@
if (rtc_sc!=NULL)
return NULL;
- dev = make_dev(&rtc_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
- if (dev==NULL)
- return (NULL);
-
MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
if (sc==NULL)
return NULL;
@@ -264,11 +269,18 @@
static int
init_module(void)
{
-int error;
+ int error = 0;
+ dev_t dev;
+#if __FreeBSD_version < 500104
error = cdevsw_add(&rtc_cdevsw);
if (error)
return error;
+#endif
+
+ dev = make_dev(&rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
+ if (dev==NULL)
+ error = ENOMEM;
return error;
}
@@ -286,7 +298,9 @@
DLog(Lfail, "%p busy", sc);
return error;
}
+#if __FreeBSD_version < 500104
error = cdevsw_remove(&rtc_cdevsw);
+#endif
DLog(Linfo, "return %d", error);
return error;
}
diff -urN emulators/rtc/files/rtc.sh local/rtc/files/rtc.sh
--- emulators/rtc/files/rtc.sh Fri Sep 22 20:08:22 2000
+++ local/rtc/files/rtc.sh Tue Mar 11 16:49:55 2003
@@ -7,11 +7,11 @@
start)
if [ -x $kmoddir/$kmod ]; then
echo -n ' rtc'
- kldload $kmoddir/$kmod
+ /sbin/kldload $kmoddir/$kmod
fi
;;
stop)
- kldunload $kmod && echo -n ' rtc'
+ /sbin/kldunload $kmod && echo -n ' rtc'
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003 18:08:01 +0900 Norikatsu Shigemura <[EMAIL PROTECTED]> wrote: > RAM speed setting! Ah, I don't test it yet. I'll change speed > setting and test. I seted FastCommand: normal from ultra on `Configure SDRAM Timing by, FastCommand'. More robust and reduce problem. I'll check other parameter. I wounder if I'm sorry.? :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003 00:41:37 -0800 (PST) Julian Elischer <[EMAIL PROTECTED]> wrote: > We had a similar problem some time ago that turned out to be bad RAM in > one case and a bad CMOS BIOS setting in another. (RAM speed setting). RAM speed setting! Ah, I don't test it yet. I'll change speed setting and test. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003 03:36:41 -0500 (EST) Jeff Roberson <[EMAIL PROTECTED]> wrote: > Does your machine log ECC errors? If so can you check for them in the > BIOS? If you don't make world and jdk14 does this problem still show up? My machine uses non-ECC unbuffered DDR SDRAM(Transcend - Samsung chips, this is not bulk memory:-). I already thinked memory problem and checked memory (using Ram Stress Test like memtest86). But according to result of 3 hours test, memory is OK. I tested to make only ja-openoffice on single user mode. But there is this problem... (T_T) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: big file became broken on 2003-03-11(cvsuped)
On Thu, 13 Mar 2003 01:23:00 -0500 (EST) Jeff Roberson <[EMAIL PROTECTED]> wrote: > > How much memory is in your machine? Can you go back to an earlier date > > and see if this is still a problem? Are you doing anything else with the > > machine while this is going on? 512MB. I used snapshots install image from snapshots.jp.freebsd.org, and installed on 3/8. And, I updated to now version on 3/11. There are no problem while using 3/8 version. Yes, I am making java/jdk14 and make world:-) (for heavy load). But, even if I only made ja-openoffice, there was this problem. > Also, can you do 'sysctl vfs.read_max=0' and retest? OK! But not good. But more robust. At least my machine don't freeze, yet:-). Thanks! - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (snip) Thu Mar 13 15:47:59 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:48:13 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:48:32 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 0b4e6ca19c5127a70bb60de149cfedde Thu Mar 13 15:49:54 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c Thu Mar 13 15:51:33 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = 5960c5ab9820cf928e04499012255f67 Thu Mar 13 15:56:15 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = a0f24a11305b601238a6ed277ce7b24d Thu Mar 13 15:58:10 JST 2003 MD5 (OOo_1.0.2_source.tar.bz2) = a0f24a11305b601238a6ed277ce7b24d (snip) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
big file became broken on 2003-03-11(cvsuped)
Big file like OOo_1.0.2_source.tar.bz2 became broken with making openoffice in my environment. # uname -a FreeBSD ***.*-.*** 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Wed Mar 12 18:39:05 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MELFINA i386 # mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/md0 on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /export (ufs, local, soft-updates) /dev/ad0s1d on /usr (ufs, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) /usr/compat on /compat (nullfs, local) linprocfs on /compat/linux/proc (linprocfs, local) /export/home on /home (nullfs, local) I tested on /, /var, /usr, /home, /tmp. There is a same problem. # cd /any/partition; scp -p mystable.machine:/usr/ports/distfiles/openoffice/OOo_1.0.2_source.tar.bz2 .; chflags schg OOo_1.0.2_source.tar.bz2; while true; do md5 OOo_1.0.2_source.tar.bz2; sleep 1; done OOo_1.0.2_source.tar 100% |*| 154 MB00:41 MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c MD5 (OOo_1.0.2_source.tar.bz2) = 8a82b4dbdd4e305b6f6db70ea65dce8c (snip) MD5 (OOo_1.0.2_source.tar.bz2) = 83d7c6e49bb4586ba9b8478798952c29 MD5 (OOo_1.0.2_source.tar.bz2) = 83d7c6e49bb4586ba9b8478798952c29 (snip) MD5 (OOo_1.0.2_source.tar.bz2) = 142ee73901a58445ebd4cccb3d0af223 MD5 (OOo_1.0.2_source.tar.bz2) = 2e9fa2b1b924595eb11760cd728ade95 MD5 (OOo_1.0.2_source.tar.bz2) = c3eee272f6f9b4c90f10c8ca0a2eb537 : To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
vfs panic on 2003-03-11(cvsuped)
Panic in my environment. # uname -a FreeBSD ***.*-.*** 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Wed Mar 12 18:39:05 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MELFINA i386 There are no dmesg in vmcore.0, but I saw process name as mount_procfs in after fsck(when panic). So I removed procfs in /etc/fstab. Then there are no problem. # gdb -k /usr/obj/usr/src/sys/MELFINA/kernel.debug vmcore.0 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-undermydesk-freebsd"... panic: bremfree: removing a buffer not on a queue panic messages: --- dmesg: kernel message buffer has different magic number --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 #1 0xc01c68ca in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xc01c6bc2 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #3 0xc0209070 in bremfreel (bp=0xce611278) at /usr/src/sys/kern/vfs_bio.c:630 #4 0xc0208f82 in bremfree (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:612 #5 0xc020af4c in vfs_bio_awrite (bp=0x0) at /usr/src/sys/kern/vfs_bio.c:1682 #6 0xc02e0e1a in ffs_fsync (ap=0xd68fdb60) at /usr/src/sys/ufs/ffs/ffs_vnops.c:257 #7 0xc02dfef7 in ffs_sync (mp=0xc43d6000, waitfor=2, cred=0xc150ae80, td=0xc039f640) at vnode_if.h:612 #8 0xc021f9c6 in sync (td=0xc039f640, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:138 #9 0xc01c63ef in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280 #10 0xc01c6bc2 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #11 0xc02d9152 in softdep_disk_io_initiation (bp=0xce611278) at /usr/src/sys/ufs/ffs/ffs_softdep.c:3466 #12 0xc02118af in cluster_wbuild (vp=0xc56b336c, size=16384, start_lbn=524, len=3) at buf.h:422 #13 0xc020af2a in vfs_bio_awrite (bp=0xce64a690) at /usr/src/sys/kern/vfs_bio.c:1675 #14 0xc020b9a9 in flushbufqueues () at /usr/src/sys/kern/vfs_bio.c:2132 #15 0xc020b775 in buf_daemon () at /usr/src/sys/kern/vfs_bio.c:2054 #16 0xc01b1a73 in fork_exit (callout=0xc020b650 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:871 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fix for rtc, vmware modules and post-500104 -current
On Wed, 5 Mar 2003 19:37:35 +0100 (MET)
Marcin CIE LAK <[EMAIL PROTECTED]> wrote:
> See the patches enclosed to emulators/rtc
> and emulators/vmware2 ports.
> Tested only for -current with:
> #define __FreeBSD_version 500104
Hum.. This is not work in my environment. Because MOD_LOAD initializer
didn't kick rtc_attach. I fixed this problem and merge(but ADHOC:-).
Please, anyone, check following patch.
BTW, vmmon_*.ko is not good. hum
diff -urN emulators/rtc/Makefile local/rtc/Makefile
--- emulators/rtc/Makefile Fri Mar 7 15:01:17 2003
+++ local/rtc/Makefile Tue Mar 11 16:48:46 2003
@@ -6,7 +6,7 @@
#
PORTNAME= rtc
-PORTVERSION= 2001.09.16.1
+PORTVERSION= 2002.03.05.1
CATEGORIES= emulators linux
MASTER_SITES= # none
DISTFILES= # none
diff -urN emulators/rtc/files/rtc.c local/rtc/files/rtc.c
--- emulators/rtc/files/rtc.c Sun Sep 16 16:05:18 2001
+++ local/rtc/files/rtc.c Tue Mar 11 19:40:39 2003
@@ -85,6 +85,14 @@
static int rtc_modeevent(module_t mod, int cmd, void *arg);
static struct cdevsw rtc_cdevsw = {
+#if __FreeBSD_version >= 500104
+ .d_open = rtc_open,
+ .d_close = rtc_close,
+ .d_ioctl = rtc_ioctl,
+ .d_poll = rtc_poll,
+ .d_name = DEVICE_NAME,
+ .d_maj = CDEV_MAJOR,
+#else
/* open */ rtc_open,
/* close */ rtc_close,
/* read */ noread,
@@ -104,6 +112,7 @@
#if __FreeBSD_version >= 500018 || __FreeBSD_version >= 43
/* kqfilter */ nokqfilter,
#endif
+#endif
};
/*
@@ -118,7 +127,6 @@
static struct rtc_softc *
rtc_attach(dev_t dev)
{
- struct rtc_softc *sc;
int unit;
#if __FreeBSD_version >= 500014
@@ -132,24 +140,8 @@
return dev->si_drv1;
}
- if (rtc_sc!=NULL)
- return NULL;
-
- dev = make_dev(&rtc_cdevsw, minor(dev), UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
- if (dev==NULL)
- return (NULL);
-
- MALLOC(sc, struct rtc_softc*, sizeof(*sc), M_DEVBUF, M_WAITOK);
- if (sc==NULL)
- return NULL;
-
- bzero(sc, sizeof(*sc));
- rtc_sc = sc;
- dev->si_drv1 = sc; /* Link together */
- sc->dev = dev;
-
- DLog(Lexit, "new %p,%p", dev, sc);
- return sc;
+ DLog(Lexit, "new %p,%p", dev, rtc_sc);
+ return rtc_sc;
}
static int
@@ -264,11 +256,26 @@
static int
init_module(void)
{
-int error;
+ int error = 0;
+ dev_t dev;
+#if __FreeBSD_version < 500104
error = cdevsw_add(&rtc_cdevsw);
if (error)
return error;
+#endif
+
+ dev = make_dev(&rtc_cdevsw, 0, UID_ROOT, GID_WHEEL, 0600, DEVICE_NAME);
+ if (dev==NULL)
+ return ENOMEM;
+
+ MALLOC(rtc_sc, struct rtc_softc*, sizeof(*rtc_sc), M_DEVBUF, M_WAITOK);
+ if (rtc_sc==NULL)
+ return ENOMEM;
+
+ bzero(rtc_sc, sizeof(*rtc_sc));
+ dev->si_drv1 = rtc_sc; /* Link together */
+ rtc_sc->dev = dev;
return error;
}
@@ -286,7 +293,9 @@
DLog(Lfail, "%p busy", sc);
return error;
}
+#if __FreeBSD_version < 500104
error = cdevsw_remove(&rtc_cdevsw);
+#endif
DLog(Linfo, "return %d", error);
return error;
}
diff -urN emulators/rtc/files/rtc.sh local/rtc/files/rtc.sh
--- emulators/rtc/files/rtc.sh Fri Sep 22 20:08:22 2000
+++ local/rtc/files/rtc.sh Tue Mar 11 16:49:55 2003
@@ -7,11 +7,11 @@
start)
if [ -x $kmoddir/$kmod ]; then
echo -n ' rtc'
- kldload $kmoddir/$kmod
+ /sbin/kldload $kmoddir/$kmod
fi
;;
stop)
- kldunload $kmod && echo -n ' rtc'
+ /sbin/kldunload $kmod && echo -n ' rtc'
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
