radeondrm testers wanted for 3.8.13.27 fixes
I'm looking for a few people to test some additional
radeondrm fixes from the recently released Linux 3.8.13.27:
https://lkml.org/lkml/2014/7/25/621
In particular on newer asics with displayport/eDP as I
can only test on r100/lvds at the moment.
commit 85cdd5e933c0f9fe3262067e707eed565db46378
Author: Alex Deucher
Date: Mon Apr 21 21:45:09 2014 -0400
drm/radeon: only apply hdmi bpc pll flags when encoder mode is hdmi
commit 7d5ab3009a8ca777174f6f469277b3922d56fd4b upstream.
May fix display issues with non-HDMI displays.
Signed-off-by: Alex Deucher
Signed-off-by: Kamal Mostafa
commit 9102ef0d290f01247918f5a519d8fa4a96eaf370
Author: Alex Deucher
Date: Tue May 27 16:40:51 2014 -0400
drm/radeon/atom: fix dithering on certain panels
commit 642528355c694f5ed68f6bff9ff520326a249f99 upstream.
We need to specify the encoder mode as LVDS for eDP
when using the Crtc_Source atom table in order to properly
set up the FMT hardware.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73911
Signed-off-by: Alex Deucher
Signed-off-by: Kamal Mostafa
commit c9a1adc31f78a30f33c591b61171f02d13a5b1a7
Author: Alex Deucher
Date: Tue May 27 13:48:05 2014 -0400
drm/radeon/dp: fix lane/clock setup for dp 1.2 capable devices
commit 3b6d9fd23e015b5397c438fd3cd74147d2c805b6 upstream.
Only DCE5+ asics support DP 1.2.
Noticed by ArtForz on IRC.
Signed-off-by: Alex Deucher
Signed-off-by: Kamal Mostafa
commit 94dfc49785ea1acc1dd2c086ffd8d61ea3a5ee8f
Author: Alex Deucher
Date: Tue May 27 13:11:36 2014 -0400
drm/radeon: fix typo in radeon_connector_is_dp12_capable()
commit af5d36539dfe043f1cf0f8b7334d6bb12cd14e75 upstream.
We were checking the ext clock rather than the display clock.
Noticed by ArtForz on IRC.
Signed-off-by: Alex Deucher
Signed-off-by: Kamal Mostafa
Index: sys/dev/pci/drm/radeon/atombios_crtc.c
===
RCS file: /cvs/src/sys/dev/pci/drm/radeon/atombios_crtc.c,v
retrieving revision 1.5
diff -u -p -r1.5 atombios_crtc.c
--- sys/dev/pci/drm/radeon/atombios_crtc.c 30 Mar 2014 02:17:50 -
1.5
+++ sys/dev/pci/drm/radeon/atombios_crtc.c 28 Jul 2014 11:25:25 -
@@ -840,14 +840,16 @@ static void atombios_crtc_program_pll(st
args.v5.ucMiscInfo = 0; /* HDMI depth, etc. */
if (ss_enabled && (ss->type & ATOM_EXTERNAL_SS_MASK))
args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_REF_DIV_SRC;
- switch (bpc) {
- case 8:
- default:
- args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_24BPP;
- break;
- case 10:
- args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
- break;
+ if (encoder_mode == ATOM_ENCODER_MODE_HDMI) {
+ switch (bpc) {
+ case 8:
+ default:
+ args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_24BPP;
+ break;
+ case 10:
+ args.v5.ucMiscInfo |=
PIXEL_CLOCK_V5_MISC_HDMI_30BPP;
+ break;
+ }
}
args.v5.ucTransmitterID = encoder_id;
args.v5.ucEncoderMode = encoder_mode;
@@ -862,20 +864,22 @@ static void atombios_crtc_program_pll(st
args.v6.ucMiscInfo = 0; /* HDMI depth, etc. */
if (ss_enabled && (ss->type & ATOM_EXTERNAL_SS_MASK))
args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_REF_DIV_SRC;
- switch (bpc) {
- case 8:
- default:
- args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_24BPP;
- break;
- case 10:
- args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_30BPP;
- break;
- case 12:
- args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_36BPP;
- break;
- case 16:
- args.v6.ucMiscInfo |=
PIXEL_CLOCK_V6_MISC_HDMI_48BPP;
- break;
+ if (encoder_mode == ATOM_ENCODER_MODE_HDMI) {
+ switch (bpc) {
+ case 8:
+ default:
+ a
Re: string.h __POSIX_VISIBLE
On Sun, Jul 27, 2014 at 9:14 AM, frantisek holop wrote: > is there a reason why this check should be done twice? > If the code is inextricable, check the history of how it got that way. In this case, there was a mostly mechanical elimination of unnecessary __BSD_VISIBLE clauses which changed different conditions to the same condition; I missed that those two ended up the same. No semantic I'll commit this after unlock... Philip Guenther
Re: [DIFF] sftp-server.8, sshd_config.5 after syslog_r change
Theo de Raadt wrote on Fri, Jul 18, 2014 at 03:04:28PM -0600: > Unfortunately, no. > > The ssh manual pages are also used by the -portable effort. We do not > bother documenting these divergences; there is little harm. > > Actually you could submit a new diff which suggest that logging > "might" need a /dev/log setup. If written carefully to cover both > kinds of systems, that would be accepted. OK? Ingo Index: sftp-server.8 === RCS file: /cvs/src/usr.bin/ssh/sftp-server.8,v retrieving revision 1.25 diff -u -r1.25 sftp-server.8 --- sftp-server.8 14 Oct 2013 14:18:56 - 1.25 +++ sftp-server.8 28 Jul 2014 15:14:45 - @@ -140,15 +140,21 @@ user's default mask. .El .Pp -For logging to work, +On many systems, .Nm must be able to access -.Pa /dev/log . -Use of +.Pa /dev/log +for logging to work, and use of .Nm in a chroot configuration therefore requires that .Xr syslogd 8 establish a logging socket inside the chroot directory. +This is not needed on systems implementing the +.Xr syslog 3 +family of functions in terms of a +.Xr sendsyslog 2 +system call, for example +.Ox . .Sh SEE ALSO .Xr sftp 1 , .Xr ssh 1 , Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.175 diff -u -r1.175 sshd_config.5 --- sshd_config.5 15 Jul 2014 15:54:14 - 1.175 +++ sshd_config.5 28 Jul 2014 15:14:45 - @@ -345,9 +345,9 @@ .Dq sftp , no additional configuration of the environment is necessary if the in-process sftp server is used, -though sessions which use logging do require +though sessions which use logging may require .Pa /dev/log -inside the chroot directory (see +inside the chroot directory on some operating systems (see .Xr sftp-server 8 for details). .Pp
Re: [DIFF] sftp-server.8, sshd_config.5 after syslog_r change
>> Unfortunately, no. >> >> The ssh manual pages are also used by the -portable effort. We do not >> bother documenting these divergences; there is little harm. >> >> Actually you could submit a new diff which suggest that logging >> "might" need a /dev/log setup. If written carefully to cover both >> kinds of systems, that would be accepted. The mention of sendsyslog is not acceptable. When this man page shows up on some other system, it will be an Xr pointing to nowhere. The information is too specific. Frankly, noone will care. Old systems will continue doing what they have, which is the provided advice to have /dev/log in the chroot space. In attempting to remove this advice for OpenBSD-only, you are just plain being too specific. Meaning if someone leaves /dev/log in an OpenBSD chroot space, nothing at all is harmed. >Index: sftp-server.8 >=== >RCS file: /cvs/src/usr.bin/ssh/sftp-server.8,v >retrieving revision 1.25 >diff -u -r1.25 sftp-server.8 >--- sftp-server.8 14 Oct 2013 14:18:56 - 1.25 >+++ sftp-server.8 28 Jul 2014 15:14:45 - >@@ -140,15 +140,21 @@ > user's default mask. > .El > .Pp >-For logging to work, >+On many systems, > .Nm > must be able to access >-.Pa /dev/log . >-Use of >+.Pa /dev/log >+for logging to work, and use of > .Nm > in a chroot configuration therefore requires that > .Xr syslogd 8 > establish a logging socket inside the chroot directory. >+This is not needed on systems implementing the >+.Xr syslog 3 >+family of functions in terms of a >+.Xr sendsyslog 2 >+system call, for example >+.Ox . > .Sh SEE ALSO > .Xr sftp 1 , > .Xr ssh 1 , >Index: sshd_config.5 >=== >RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v >retrieving revision 1.175 >diff -u -r1.175 sshd_config.5 >--- sshd_config.5 15 Jul 2014 15:54:14 - 1.175 >+++ sshd_config.5 28 Jul 2014 15:14:45 - >@@ -345,9 +345,9 @@ > .Dq sftp , > no additional configuration of the environment is necessary if the > in-process sftp server is used, >-though sessions which use logging do require >+though sessions which use logging may require > .Pa /dev/log >-inside the chroot directory (see >+inside the chroot directory on some operating systems (see > .Xr sftp-server 8 > for details). > .Pp >
Re: [DIFF] sftp-server.8, sshd_config.5 after syslog_r change
Theo de Raadt wrote on Mon, Jul 28, 2014 at 09:20:36AM -0600: > The mention of sendsyslog is not acceptable. When this man page shows up > on some other system, it will be an Xr pointing to nowhere. > > The information is too specific. Frankly, noone will care. Old systems > will continue doing what they have, which is the provided advice to have > /dev/log in the chroot space. In attempting to remove this advice for > OpenBSD-only, you are just plain being too specific. > > Meaning if someone leaves /dev/log in an OpenBSD chroot space, nothing at > all is harmed. Fair enough, that makes the patch even simpler. OK? Ingo Index: sftp-server.8 === RCS file: /cvs/src/usr.bin/ssh/sftp-server.8,v retrieving revision 1.25 diff -u -r1.25 sftp-server.8 --- sftp-server.8 14 Oct 2013 14:18:56 - 1.25 +++ sftp-server.8 28 Jul 2014 15:24:16 - @@ -140,11 +140,11 @@ user's default mask. .El .Pp -For logging to work, +On some systems, .Nm must be able to access -.Pa /dev/log . -Use of +.Pa /dev/log +for logging to work, and use of .Nm in a chroot configuration therefore requires that .Xr syslogd 8 Index: sshd_config.5 === RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.175 diff -u -r1.175 sshd_config.5 --- sshd_config.5 15 Jul 2014 15:54:14 - 1.175 +++ sshd_config.5 28 Jul 2014 15:24:17 - @@ -345,9 +345,9 @@ .Dq sftp , no additional configuration of the environment is necessary if the in-process sftp server is used, -though sessions which use logging do require +though sessions which use logging may require .Pa /dev/log -inside the chroot directory (see +inside the chroot directory on some operating systems (see .Xr sftp-server 8 for details). .Pp
Re: cvs log -r1.x vs. -r 1.x
Hi Stefan,
Stefan Sperling wrote on Tue, Jul 15, 2014 at 12:17:08PM +0200:
> cvs log -r1.x shows the log entry for HEAD, instead of the log entry
> for 1.x as cvs -r 1.x does.
The typos in this sentence confused me so thoroughly that when first
looking at your mail, i didn't get your intent at all. After looking
again, i now feel almost certain that what you actually wanted to say
was this:
"cvs log -r 1.x shows the log entry for HEAD, instead of the log
entry for 1.x as cvs log -r1.x does." (first -r *with* space
character, second *without*, and the -r in the second case
is a log option, too, not a *global* option)
> As a result I end up looking at the wrong
> log message rather often.
>
> The hysterical raisin is a quirk in rlog(1):
>
> Without argument, the -r option means the latest revision of the
> default branch.
That's more than just a quirk. Almost all RCS commands have
plenty of options taking optional arguments. They are that ancient...
> Which cvs emulates in 'cvs rlog' (comment from log.c):
>
> /* Unfortunately, rlog accepts -r without an argument to mean that
>latest revision on the default branch, so we must support that
>for compatibility. */
>
> I don't see a reason to keep this in 'cvs log' since it is not documented.
It is documented:
-Info: (cvs.info)log, 31 lines --All--
File: cvs.info, Node: log, Next: rdiff, Prev: import, Up: CVS commands
A.13 log--Print out log information for files
=
[...]
Display log information for files. `log' used to call the RCS
utility `rlog'. Although this is no longer true in the current
sources, this history determines the format of the output and the
options, which are not quite in the style of the other CVS commands.
-Info: (cvs.info)log options, 117 lines --Top--
A.13.1 log options
--
[...]
`-rREVISIONS'
[...]
A bare `-r' with no revisions means the latest revision on the
default branch, normally the trunk. There can be no space between
the `-r' option and its argument.
Also note that `-wLOGINS' has the same quirk.
It looks like cvs admin also has many options that do not allow
a space between the option and the argument (at least -b, -l, -t, -u).
> This behaviour is annoying because it differs from 'cvs diff' and other
> cvs commands, and also other tools which support -r (e.g. Subversion and
> Mercurial).
That is true.
> Alternatively, we could remove this quirk from 'cvs rlog' as well and make
> it incompatible with rlog(1). I never use cvs rlog so I don't really care.
Documentation is inconsistent with respect to rlog.
The cvs(1) info(1) manual doesn't mention `cvs rlog' at all.
The cvs(1) man(1) manual claims `cvs rlog' is a synonym of `cvs log'.
But that's not true, both behave quite differently.
> One downside is that a mistyped 'cvs log -r FILENAME' now runs cvs log
> on the entire directory looking for tag FILENAME, instead of showing
> the HEAD revision for FILENAME. That tends to produce a lot of output.
> I'd rather refrain from trying to catch this case and perhaps breaking
> something in unexpected ways.
I wouldn't worry about that point.
But it looks like it is hard, if not impossible, to get this
consistent. While log -r is probably the awkward case that is
most frequently used, it is by no means the only one, so changing
just this one cases merely shifts the inconsistencies around.
But changing the behaviour of at least half a dozen options
seems a questionable plan as well.
If we change anything, it would probably be best to only change
log -r and log -w but leave the obscure cvs rlog and the
notoriously nasty cvs admin alone.
However, that would require to at least change the info manual
as well, and maybe say there that cvs log now behaves differently
on OpenBSD in this respect than everywhere else.
I do like your proposed behaviour better, but i'm on the fence
as to whether it's worth the incompatibility with the rest of
the world.
Yours,
Ingo
> Index: log.c
> ===
> RCS file: /cvs/src/gnu/usr.bin/cvs/src/log.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 log.c
> --- log.c 3 Jun 2013 17:02:36 - 1.3
> +++ log.c 15 Jul 2014 09:40:39 -
> @@ -218,6 +218,7 @@ cvslog (argc, argv)
> int err = 0;
> int local = 0;
> struct option_revlist **prl;
> +const char *optstring;
>
> is_rlog = (strcmp (command_name, "rlog") == 0);
>
> @@ -228,7 +229,8 @@ cvslog (argc, argv)
> prl = &log_data.revlist;
>
> optind = 0;
> -while ((c = getopt (argc, argv, "+bd:hlNRr::s:tw::")) != -1)
> +optstring = is_rlog ? "+bd:hlNRr::s:tw::" : "+bd:hlNRr:s:tw::";
> +while ((c = getopt (argc, argv, optstring)) != -1)
> {
> switch (c)
> {
Re: mg: [macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.
Hello Miod,
Will certainly do, thanks for your input!
Miod Vallat wrote:
> > I recently used cppcheck on mg and I got this message:
> >
> > [macro.c:41]: (error) Memory pointed to by 'lp1' is freed twice.
> >
> > Looking at the code:
> >
> > /* free lines allocated for string arguments */
> > if (maclhead != NULL) {
> > for (lp1 = maclhead->l_fp; lp1 != maclhead; lp1 = lp2) {
> > lp2 = lp1->l_fp;
> > free(lp1);
> > }
> > free(lp1);
> > }
> >
> > What do you guys think?
>
> The
> for (a; b; c)
> d
> construct is equivalent to
> a;
> while (b) {
> d
> c
> }
>
> so we have
>
> lp1 = maclhead->l_fp;
> while (lp1 != maclhead) {
> lp2 = lp1->l_fp;
> free(lp1);
> lp1 = lp2;
> }
> free(lp1);
>
> which looks correct to me. Replacing the second free(lp1) with
> free(maclhead) should probably silence cppcheck, yet this should be
> reported as a bug to the cppcheck developers.
>
> Miod
>
# Han
--
\/A man without religion is like a fish without a bicycle.
)\__/(
|(oO)|
\||/
Ts (OO)
+vVv--vVv--+
Re: apmd -A induced hangs
On Sun, Jul 13, 2014 at 04:05:41PM +0200, Mark Kettenis wrote:
> Some people have reported that apmd -A makes their machines hang.
> Could those people try the diff below and see whether it helps?
I am running this diff and apmd -A on a thinkpad T430s. The machine
is idle, the X11 blank screen saver is on. When I type something,
it hangs. The fan gets loud after I type, it sounds like the cpu
starts spinning when I want to work again.
It happens with this diff and apmd -A.
It happens without this diff and with apmd -A or apmd -C.
I did not see the crash without this diff and without running apmd.
But this test was not long enough to be reliable.
Next I will try with this diff and without running apmd.
It crashes about once a week so testing will take a while.
bluhm
>
> Index: acpicpu.c
> ===
> RCS file: /home/cvs/src/sys/dev/acpi/acpicpu.c,v
> retrieving revision 1.60
> diff -u -p -r1.60 acpicpu.c
> --- acpicpu.c 12 Jul 2014 18:48:17 - 1.60
> +++ acpicpu.c 13 Jul 2014 14:00:03 -
> @@ -202,9 +202,7 @@ acpicpu_set_pdc(struct acpicpu_softc *sc
> static uint8_t cpu_oscuuid[16] = { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29,
> 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70,
> 0x58, 0x71, 0x39, 0x53 };
> - cap = ACPI_PDC_C_C1_HALT | ACPI_PDC_P_FFH | ACPI_PDC_C_C1_FFH
> - | ACPI_PDC_C_C2C3_FFH | ACPI_PDC_SMP_P_SWCOORD | ACPI_PDC_SMP_C2C3
> - | ACPI_PDC_SMP_C1PT;
> + cap = ACPI_PDC_P_FFH | ACPI_PDC_C_C1_FFH;
>
> if (aml_searchname(sc->sc_devnode, "_OSC")) {
> /* Query _OSC */
OpenBSD 5.6-beta (GENERIC.MP) #87: Fri Jul 25 18:23:23 CEST 2014
bluhm@t430s.bluhm.invalid:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 16845570048 (16065MB)
avail mem = 16388358144 (15629MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbae9d000 (68 entries)
bios0: vendor LENOVO version "G7ET94WW (2.54 )" date 04/30/2013
bios0: LENOVO 2355CTO
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI
UEFI MSDM SSDT SSDT UEFI DBG2
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3)
EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.82 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 2 (EXP1)
acpiprt3 at acpi0: bus 3 (EXP2)
acpiprt4 at acpi0: bus 4 (EXP3)
acpiprt5 at acpi0: bus 12 (EXP5)
acpiprt6 at acpi0: bus -1 (EXP6)
acpiprt7 at acpi0: bus -1 (EXP7)
acpiprt8 at acpi0: bus -1 (EXP8)
acpicpu0 at acp
Re: apmd -A induced hangs
On 2014 Jul 29 (Tue) at 00:19:43 +0200 (+0200), Alexander Bluhm wrote:
:On Sun, Jul 13, 2014 at 04:05:41PM +0200, Mark Kettenis wrote:
:> Some people have reported that apmd -A makes their machines hang.
:> Could those people try the diff below and see whether it helps?
:
:I am running this diff and apmd -A on a thinkpad T430s. The machine
:is idle, the X11 blank screen saver is on. When I type something,
:it hangs. The fan gets loud after I type, it sounds like the cpu
:starts spinning when I want to work again.
:
:It happens with this diff and apmd -A.
:It happens without this diff and with apmd -A or apmd -C.
:
:I did not see the crash without this diff and without running apmd.
:But this test was not long enough to be reliable.
:
:Next I will try with this diff and without running apmd.
:
:It crashes about once a week so testing will take a while.
:
:bluhm
:
I've been running with this diff (apmd -C) on a T430s since the diff was
mailed out, and have had no such problems. So, wtf.
:>
:> Index: acpicpu.c
:> ===
:> RCS file: /home/cvs/src/sys/dev/acpi/acpicpu.c,v
:> retrieving revision 1.60
:> diff -u -p -r1.60 acpicpu.c
:> --- acpicpu.c12 Jul 2014 18:48:17 - 1.60
:> +++ acpicpu.c13 Jul 2014 14:00:03 -
:> @@ -202,9 +202,7 @@ acpicpu_set_pdc(struct acpicpu_softc *sc
:> static uint8_t cpu_oscuuid[16] = { 0x16, 0xA6, 0x77, 0x40, 0x0C, 0x29,
:> 0xBE, 0x47, 0x9E, 0xBD, 0xD8, 0x70,
:> 0x58, 0x71, 0x39, 0x53 };
:> -cap = ACPI_PDC_C_C1_HALT | ACPI_PDC_P_FFH | ACPI_PDC_C_C1_FFH
:> -| ACPI_PDC_C_C2C3_FFH | ACPI_PDC_SMP_P_SWCOORD | ACPI_PDC_SMP_C2C3
:> -| ACPI_PDC_SMP_C1PT;
:> +cap = ACPI_PDC_P_FFH | ACPI_PDC_C_C1_FFH;
:>
:> if (aml_searchname(sc->sc_devnode, "_OSC")) {
:> /* Query _OSC */
:
:OpenBSD 5.6-beta (GENERIC.MP) #87: Fri Jul 25 18:23:23 CEST 2014
:bluhm@t430s.bluhm.invalid:/usr/src/sys/arch/amd64/compile/GENERIC.MP
:real mem = 16845570048 (16065MB)
:avail mem = 16388358144 (15629MB)
:mpath0 at root
:scsibus0 at mpath0: 256 targets
:mainbus0 at root
:bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xbae9d000 (68 entries)
:bios0: vendor LENOVO version "G7ET94WW (2.54 )" date 04/30/2013
:bios0: LENOVO 2355CTO
:acpi0 at bios0: rev 2
:acpi0: sleep states S0 S3 S4 S5
:acpi0: tables DSDT FACP TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI
UEFI MSDM SSDT SSDT UEFI DBG2
:acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3)
EHC2(S3) HDEF(S4)
:acpitimer0 at acpi0: 3579545 Hz, 24 bits
:acpihpet0 at acpi0: 14318179 Hz
:acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
:cpu0 at mainbus0: apid 0 (boot processor)
:cpu0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.82 MHz
:cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
:cpu0: 256KB 64b/line 8-way L2 cache
:cpu0: smt 0, core 0, package 0
:mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
:cpu0: apic clock running at 99MHz
:cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
:cpu1 at mainbus0: apid 1 (application processor)
:cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz
:cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
:cpu1: 256KB 64b/line 8-way L2 cache
:cpu1: smt 1, core 0, package 0
:cpu2 at mainbus0: apid 2 (application processor)
:cpu2: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz
:cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
:cpu2: 256KB 64b/line 8-way L2 cache
:cpu2: smt 0, core 1, package 0
:cpu3 at mainbus0: apid 3 (application processor)
:cpu3: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz
:cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS
:cpu3: 256KB 64b/line 8-way L2 cache
:cpu3: smt 1, core 1, package 0
:ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
:acpimcfg0 at acpi0 addr 0xf800, bus 0-63
:acpiec0 at acpi0
:acpiprt0 at acpi0:
