gmane.os.openbsd.tech

Kernel panic with alternative wscons console fonts

David Coppa — 2013-05-21T10:26:09

Hi!

So I have this netbook with a small screen (10 inch 1024x600)...

I have toyed with a custom kernel using an alternative font for the
wscons framebuffer console to get bigger screen estate.

---8<---

Index: GENERIC
===================================================================
RCS file: /cvs/src/sys/arch/i386/conf/GENERIC,v
retrieving revision 1.746
diff -u -p -u -p -r1.746 GENERIC
--- GENERIC5 Apr 2013 02:56:15 -00001.746
+++ GENERIC21 May 2013 10:06:05 -0000
< at >< at > -29,6 +29,8 < at >< at > optionPROCFS# /proc
 optionNTFS# NTFS support
 optionHIBERNATE# Hibernate support
 
+optionFONT_BOLD8x16_ISO1
+
 configbsdswap generic
 
 mainbus0 at root

---8<---

While experimenting, I've found that fonts with WSDISPLAY_FONTENC_ISO
encoding like bold8x16-iso1 or sony8x16 are ok, while fonts with
WSDISPLAY_FONTENC_IBM (bold8x16, vt220l8x8) cause the kernel panic
below:

---8<---

inteldrm0: 1024x600
wsdisplay0 at vga1 mux 1uvm_fault(0xd0ab0900, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped a

Re: Somewhat important ACPI diff

Jérémie Courrèges-Anglas — 2013-05-21T09:05:41

Hi,

No problem here on a samsung NC10, including suspend/resume.
No dmesg change.

Re: Somewhat important ACPI diff

Mark Kettenis — 2013-05-21T08:25:14

Good catch!

Here's a new diff.  That bug is in a codepath that will probably never
be executed by real-world AML.  So there is no real need to retest if
you already did.  But if you have yet to start your testing, please
use this diff instead.

Thanks,

Mark


Index: dsdt.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.200
diff -u -p -r1.200 dsdt.c
--- dsdt.c10 Apr 2013 01:35:55 -00001.200
+++ dsdt.c21 May 2013 08:21:17 -0000
< at >< at > -2221,8 +2221,9 < at >< at > aml_evalhid(struct aml_node *node, struc
 return (0);
 }
 
-void aml_rwfield(struct aml_value *, int, int, struct aml_value *, int);
 void aml_rwgas(struct aml_value *, int, int, struct aml_value *, int, int);
+void aml_rwindexfield(struct aml_value *, struct aml_value *val, int);
+void aml_rwfield(struct aml_value *, int, int, struct aml_value *, int);
 
 /* Get PCI address for opregion objects */
 int
< at >< at > -2341,6 +2342,81 < at >< at > aml_rwgas(struct aml_value *rgn, int bpo
 aml_fre

Re: Somewhat important ACPI diff

Gregor Best — 2013-05-21T07:46:34

Likewise with my Thinkpad R61i.

Re: Somewhat important ACPI diff

Vadim Zhukov — 2013-05-21T06:15:02

2013/5/20 Mark Kettenis <mark.kettenis< at >xs4all.nl>

ThinkPad X201i, fine here for an half a day (running since the time you
posted the diff). dmesg doesn't have any borked stuff, suspend/resume works
fine, both for short and long periods.

--
  WBR,
  Vadim Zhukov

Re: Somewhat important ACPI diff

Kyle Milz — 2013-05-21T03:12:23

Asus UX31E ultrabook here. This patch fixes kernel panics on boot in
acpivout (get_bcl()), panics on AC plug/unplug, and battery information
is now present in sysctl hw.

Suspend/resume also gets further but still panics.

Thanks for the patch!

Re: Somewhat important ACPI diff

Kenneth R Westerback — 2013-05-21T01:11:30

6 amd64 boxes checked. 3 laptops, 3 non-laptops. intel procs (core
and atom) amd procs. Various vintages, nothing more recent than
12 months or so.

No regressions seen.

.... Ken

Re: Somewhat important ACPI diff

James Turner — 2013-05-20T23:20:55

No regressions on Dell XPS 13 (L321X). hw.sensors.acpitz0.temp0 and
hw.sensors.acpitz1.temp0 still go from a normal reading (64 degC) to a
somewhat strange reading (27.80 degC) after suspend/resume. A reboot is
needed to get the normal temperature reading back.

hw.sensors.cpu{0-3}.temp0 continue to output correct readings post
suspend/resume.

amd64errata.c,v 1.4

Alexey Suslikov — 2013-05-20T21:35:51

For our crash, v 1.4 of amd64errata.c is no-op unless we de-static
functions' prototypes.

acpiprt0 at acpi0: bus 0 (PCI0)
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD Phenom(tm) 9550 Quad-Core Processor, 3600.54 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,
MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,POPCHT,HXE,MMXX,FFXSR,LOHG,3DNOW2,3DNOW,LAHF,CM
PLEG,SVM,AMCR8,ABM,SSE4A,MASSE,3DNOWP

cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 1
6-way L2 cache
cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped
kernel: protection fault trap, code=0
Stopped at amd64_errata_setmsr()+0x10: rdmsr
amd64_errata_setmsr() at amd64_errata_setmsr()+0x10

amd64_errata() at amd64 errata+0xc9
identifycpu() at identifycpu+0x729
cpu attach() at cpu_attach+0x2ce
config_attach() at config_attach+0x1d4
mpbios_cpu() at mpbios_cpu+0x5b
m

Re: iked(8) and GCM

Stuart Henderson — 2013-05-20T19:24:06

If you make it a couple of paragraphs past the table, there is this
paragraph, which is rather clear:

     Using AES-GMAC or NULL with ESP will only provide authentication.  This
     is useful in setups where AH can not be used, e.g. when NAT is involved.

Maybe a bit of redundancy would help, as this is a fairly important point,
perhaps if the table were split up:

Index: iked.conf.5
===================================================================
RCS file: /cvs/src/sbin/iked/iked.conf.5,v
retrieving revision 1.23
diff -u -p -r1.23 iked.conf.5
--- iked.conf.55 Mar 2013 19:16:01 -00001.23
+++ iked.conf.520 May 2013 19:22:45 -0000
< at >< at > -720,11 +720,16 < at >< at > keyword:
 .It Li aes-128-gcm Ta "160 bits" Ta "[ESP only]"
 .It Li aes-192-gcm Ta "224 bits" Ta "[ESP only]"
 .It Li aes-256-gcm Ta "288 bits" Ta "[ESP only]"
+.It Li blowfish Ta "160 bits" Ta "[ESP only]"
+.It Li cast Ta "128 bits" Ta "[ESP only]"
+.El
+.Pp
+The following cipher types provide only authentication,
+not encryption:
+.Bl -column "aes-128

Re: Somewhat important ACPI diff

Timo Myyrä — 2013-05-20T19:10:50


Anything specific to test with the diff?
So far I haven't noticed any regressions running this diff on Thinkpad X201.

timo

OpenBSD 5.3-current (GENERIC.MP) #4: Mon May 20 21:57:08 EEST 2013
    root< at >mandrake.wickedbsd.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8357658624 (7970MB)
avail mem = 8127467520 (7750MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 < at > 0xe0010 (78 entries)
bios0: vendor LENOVO version "6QET69WW (1.39 )" date 04/26/2012
bios0: LENOVO 32492EU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA DMAR SSDT SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5 CPU M 540 < at > 2.53GHz, 2793.53 MHz
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MT

Re: UPDATE: xf86-input-synaptics 1.7.0

Alexandr Shadchin — 2013-05-20T17:57:55

Prepare diff for xf86-input-synaptics 1.7.1
http://koba.devio.us/distfiles/xf86-input-synaptics-1.7.1.diff

Re: iked(8) and GCM

Aaron Stellman — 2013-05-20T17:56:48

I see. Seems somewhat contradictory to the fact that ESP is supposed to
provide confidentiality other than authenticity and integrity.


Thanks.

Somewhat important ACPI diff

Mark Kettenis — 2013-05-20T16:57:56

As diagnosed by some other people (armani< at >, jcs< at >?) a while ago, our
code to deal with IndexField() operators in our AML interpreter is
quite broken.  It works for fields that are less than a byte in size,
but anything else is pretty much completely busted.  I wouldn't be
surprised if this is the cause of many ACPI-related problems.  One
that comes to mind are the ridiculous temperatures reported by
acpitz(4) that have been plaguing us since basically forever.

I don't have a lot of machines that have AML with IndexField()
operators.  I've verified that those return the correct values, but
this defenitely could use further testing on a wide variety of
i386/amd64 hardware please.


Index: dsdt.c
===================================================================
RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v
retrieving revision 1.200
diff -u -p -r1.200 dsdt.c
--- dsdt.c10 Apr 2013 01:35:55 -00001.200
+++ dsdt.c20 May 2013 16:55:27 -0000
< at >< at > -2221,8 +2221,9 < at >< at > aml_evalhid(struct aml_node *node, struc
 return (0);

Re: add nl(1)

Todd C. Miller — 2013-05-20T13:38:32


That looks good to me.

 - todd

Re: add nl(1)

Arto Jonsson — 2013-05-20T09:43:19

Updated diff. I removed the int width handling and modified the
separator printing based on your comment.

Index: Makefile
===================================================================
RCS file: /cvs/src/usr.bin/Makefile,v
retrieving revision 1.129
diff -u -p -r1.129 Makefile
--- Makefile15 Mar 2013 06:01:41 -00001.129
+++ Makefile20 May 2013 09:28:57 -0000
< at >< at > -16,7 +16,7 < at >< at > SUBDIR= apply apropos ar arch asa asn1_c
 m4 mail make man mandoc mesg mg \
 midiplay mixerctl mkdep mklocale mkstr mktemp modstat nc netstat \
 newsyslog \
-nfsstat nice nm nohup oldrdist pagesize passwd paste patch pctr \
+nfsstat nice nm nl nohup oldrdist pagesize passwd paste patch pctr \
 pkg-config pkill \
 pr printenv printf quota radioctl ranlib rcs rdist rdistd \
 readlink renice rev rpcgen rpcinfo rs rsh rup ruptime rusers rwall \
Index: nl/Makefile
===================================================================
RCS file: nl/Makefile
diff -N nl/Makefile
--- /dev/null1 Jan 1970 00:00:00 -0000
+++ nl/Makefi

Re: iked(8) and GCM

Reyk Floeter — 2013-05-18T02:30:43

Hi,

On Fri, May 17, 2013 at 12:55:15PM -0700, Aaron Stellman wrote:
...
...
...
...

You're mixing up GCM and GMAC.  You have to update your config to use
aes-256-gcm instead of aes-256-gmac!  The GMAC is actually only the
authentication part and it is not encrypting the payload.  You can
see it as "childsa enc null auth aes-256-gmac", but it is technically
the encryption part that is calculating the GMAC.

But I have to admit that the iked.conf(5) manpage is not describing it
and is just listing the aes-???-gmac as encryption ciphers, so it is
also our fault.  I even see the point that a cipher AES-something is
misleading in a way that most people will asume that it is encrypting
the payload.  We will think about a way to improve this.

reyk

iked(8) and GCM

Aaron Stellman — 2013-05-17T19:55:15

Before I proceed, I realize that iked is not yet finished and is missing
some important security features. I am just pointing out something that
may not be known, and perhaps should be addressed.

I have a very simple instance of 2 qemu machines, running same snapshot
of 5.3-current:
OpenBSD openbsd00.foo.net 5.3 GENERIC#103 i386

openbsd00:
# cat /etc/iked.conf                                                           
# $OpenBSD: iked.conf,v 1.1 2010/06/07 10:09:05 reyk Exp $
#
# See iked.conf(5) for syntax and examples.


ikev2 esp from 10.92.19.85 to 10.92.20.160 \
        ikesa enc aes-256 prf hmac-sha2-512 group ecp521 \
        childsa enc aes-256-gmac group ecp521 \
        srcid openbsd00.foo.net dstid openbsd01.foo.net

openbsd01:
# cat /etc/iked.conf
# $OpenBSD: iked.conf,v 1.1 2010/06/07 10:09:05 reyk Exp $
#
# See iked.conf(5) for syntax and examples.

ikev2 active esp from 10.92.20.160 to 10.92.19.85 \
        ikesa enc aes-256 prf hmac-sha2-512 group ecp521 \
        childsa enc aes-256-gmac g

Re: Unify and document usbd_transfer(9)

Martin Pieuchot — 2013-05-17T18:19:39

Updated diff with two minors tweaks to make sure that:

  - no information is leaked to userland when USBD_SHORT_XFER_OK is set
    for ugen(4) reads 

  - do not bother checking for the actual transfered length for reads
    in urio(4), USBD_SHORT_XFER_OK being not set, an error is returned
    if actlen < len.

Plus includes some tweaks for the manpage by jmc< at >

Index: sys/dev/usb/ugen.c
===================================================================
RCS file: /cvs/src/sys/dev/usb/ugen.c,v
retrieving revision 1.72
diff -u -p -r1.72 ugen.c
--- sys/dev/usb/ugen.c17 May 2013 09:09:11 -00001.72
+++ sys/dev/usb/ugen.c17 May 2013 17:49:09 -0000
< at >< at > -478,7 +478,7 < at >< at > ugen_do_read(struct ugen_softc *sc, int 
 struct usbd_xfer *xfer;
 usbd_status err;
 int s;
-int error = 0;
+int flags, error = 0;
 u_char buffer[UGEN_CHUNK];
 
 DPRINTFN(5, ("%s: ugenread: %d\n", sc->sc_dev.dv_xname, endpt));
< at >< at > -546,14 +546,16 < at >< at > ugen_do_read(struct ugen_softc *sc, int 
 xfer = usbd_alloc_xfer(sc->sc_udev);
 if (xfe

"mpsafe" mutexes

Mark Kettenis — 2013-05-17T18:24:19

So now that we have a mechanism to install interrupt handlers, it is
time to look at our mutexes again.  To prevent lock ordering problems
with the kernel lock, we need to make sure we block all interrupts
that can grab the kernel lock.  The simplest way to achieve this is to
make sure mutexes always raise the ipl to the highest level that has
interrupts that grab the kernel lock.  On amd64 that currently is
IPL_AUDIO, but this will soon be IPL_VM or IPL_TTY.  In theory this
increases interrupt latency.  In practice it seems that this increase
is just noise compared to the latency we get due to kernel lock
contention.

I'd like to keep mutexes as lightweight as possible, and preferably
not add any code to the mtx_enter() and mtx_leave().  So the idea is
to adjust the ipl for the mutex when it gets initialized.  The diff
below implements this strategy for amd64.

An earlier version of this diff has been tested by a couple of
devlopers already.  IIRC mikeb< at > even did some network benchmarking
with it and didn't

Re: Wake from zzz causes panic on thinkpad x60

YASUOKA Masahiko — 2013-05-17T16:08:15

Hi,

On Fri, 17 May 2013 14:06:49 +0200
Martin Pieuchot <mpieuchot< at >nolizard.org> wrote:

Your diff seem to fix the problem more exactly.


Yes, it fixed the panic. 
But I needed to apply same changes to uhci.c like attached diff.

Index: sys/dev/usb/ehci.c
===================================================================
RCS file: /cvs/openbsd/src/sys/dev/usb/ehci.c,v
retrieving revision 1.131
diff -u -p -r1.131 ehci.c
--- sys/dev/usb/ehci.c19 Apr 2013 08:58:53 -00001.131
+++ sys/dev/usb/ehci.c17 May 2013 15:56:30 -0000
< at >< at > -800,6 +800,7 < at >< at > ehci_check_itd_intr(struct ehci_softc *s
 done:
 DPRINTFN(12, ("ehci_check_itd_intr: ex=%p done\n", ex));
 timeout_del(&ex->xfer.timeout_handle);
+usb_rem_task(ex->xfer.pipe->device, &ex->abort_task);
 ehci_idone(ex);
 }
 
< at >< at > -2859,6 +2860,7 < at >< at > ehci_abort_isoc_xfer(struct usbd_xfer *x
 s = splusb();
 xfer->status = status;
 timeout_del(&xfer->timeout_handle);
+usb_rem_task(epipe->pipe.device, &exfer->abort_task);
 usb_transfer_complete(xfer);
 splx(s);