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: