Re: dmesg: write fail ??

2011-09-22 Thread Stuart Henderson
On 2011-09-22, Philip Guenther guent...@gmail.com wrote:
 2011/9/21 johnw johnw.m...@gmail.com:
 Hi, i see it in dmesg
 bsdbox /bsd: pid 9648 (mlnet): user write of 4096@0x202d4000 at 5328
 failed: 14

 what is this mean?

 14 == EFAULT.  Sounds like that process (mlnet) passed a system call a
 memory address for the kernel to write to (for example, to return a
 socket address in accept(), or file data in read()) that wasn't
 actually writable by that process, whether because it wasn't validly
 mapped, was kernel memory, or was mapped but read-only.

 That's an utter guess from a single line taken out of context, so it
 may be completely wrong.  You provided no standard info (not even
 platform?  hello?), so I won't waste time looking for details.

Happens from time to time, at least on i386 and amd64:

amd64:- (logs start aug 3rd; it may have happened before then)

/var/log/messages:Sep 20 13:09:13 zephyr /bsd: pid 6645 (chrome): user write of 
8192@0x204d24000 at 10733232 failed: 14
/var/log/messages.3.gz:Aug 18 10:05:23 zephyr /bsd: pid 7534 (chrome): user 
write of 368640@0x27e3a3000 at 1190417880 failed: 28

i386:- (logs start aug 11th; it may have happened before then)

/var/log/messages.3.gz:Sep  9 17:35:07 zoo /bsd: pid 5799 (openssl): user write 
of 73728@0x23b8e000 at 42128 failed: 14

also on an i386 (alix) running something that isn't OpenBSD but is based
on it (custom ramdisk kernel), included here partly to show the program
name and partly to mention that it's not MP.

/var/log/messages.52.gz:Sep 13 00:18:53 vpn /bsd: pid 11416 (watchdogd): user 
write of 64@0xcfbbdda8 at 612 failed: 14

dmesg from the amd64 here, followed by the i386 running OpenBSD:

OpenBSD 5.0-current (GENERIC.MP) #65: Wed Sep  7 20:18:56 MDT 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8453160960 (8061MB)
avail mem = 8214016000 (7833MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xdc010 (45 entries)
bios0: vendor HP version O15 date 03/12/2009
bios0: HP ProLiant ML110 G5
acpi0 at bios0: rev 2
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SPMI EINJ HEST BERT SSDT ERST MCFG APIC BOOT SPCR SSDT 
SSDT SSDT
acpi0: wakeup devices USB4(S3) USB5(S3) USB7(S3) ESB2(S4) EXP1(S4) EXP2(S4) 
EXP3(S4) EXP4(S4) EXP5(S4) EXP6(S4) USB1(S3) USB2(S3) USB3(S3) USB6(S3) 
ESB1(S3) PCIB(S3) PWRB(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimcfg0 at acpi0 addr 0xf000, bus 0-16
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz, 1795.74 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,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG
cpu0: 1MB 64b/line 4-way L2 cache
cpu0: apic clock running at 199MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz, 1795.50 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,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG
cpu1: 1MB 64b/line 4-way L2 cache
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEG1)
acpiprt2 at acpi0: bus -1 (PEG2)
acpiprt3 at acpi0: bus 5 (EXP1)
acpiprt4 at acpi0: bus -1 (EXP2)
acpiprt5 at acpi0: bus -1 (EXP3)
acpiprt6 at acpi0: bus -1 (EXP4)
acpiprt7 at acpi0: bus 13 (EXP5)
acpiprt8 at acpi0: bus 14 (EXP6)
acpiprt9 at acpi0: bus 17 (PCIB)
acpicpu0 at acpi0: C3, PSS
acpicpu1 at acpi0: C3, PSS
acpibtn0 at acpi0: PWRB
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 1795 MHz: speeds: 1800, 1200 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 Intel 3200/3210 Host rev 0x01
ppb0 at pci0 dev 1 function 0 Intel 3200/3210 PCIE rev 0x01: msi
pci1 at ppb0 bus 1
uhci0 at pci0 dev 26 function 0 Intel 82801I USB rev 0x02: apic 2 int 16
uhci1 at pci0 dev 26 function 1 Intel 82801I USB rev 0x02: apic 2 int 17
uhci2 at pci0 dev 26 function 2 Intel 82801I USB rev 0x02: apic 2 int 18
ehci0 at pci0 dev 26 function 7 Intel 82801I USB rev 0x02: apic 2 int 18
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb1 at pci0 dev 28 function 0 Intel 82801I PCIE rev 0x02: msi
pci2 at ppb1 bus 5
em0 at pci2 dev 0 function 0 Intel PRO/1000 PT (82572EI) rev 0x06: msi, 
address 00:1b:21:2d:f7:0c
ppb2 at pci0 dev 28 function 4 Intel 82801I PCIE rev 0x02: msi
pci3 at ppb2 bus 13
Matrox MGA G200e (ServerEngines) rev 0x02 at pci3 dev 0 function 0 not 
configured
ppb3 at pci0 dev 28 function 5 Intel 82801I PCIE rev 0x02: msi
pci4 at ppb3 bus 14
bge0 at pci4 dev 0 function 0 Broadcom BCM5722 rev 0x00, BCM5755 C0 (0xa200): 
apic 2 int 17, address 00:26:55:03:71:76
brgphy0 at bge0 phy 1: BCM5722 10/100/1000baseT PHY, rev. 0
uhci3 at pci0 dev 29 function 0 Intel 82801I USB rev 0x02: apic 2 int 16
uhci4 at pci0 dev 29 

Re: dmesg: write fail ??

2011-09-22 Thread Brynet
It seems to be from coredump_write(), in kern/kern_sig.c. The printf itself is 
conditional though.

Perhaps you're both seeing it when the kernel doesn't have enough resources to 
generate a core dump? That makes sense for chrome.

I guess someone figured if they couldn't write the core, make noise.

-Bryan.



Re: dmesg: write fail ??

2011-09-21 Thread Philip Guenther
2011/9/21 johnw johnw.m...@gmail.com:
 Hi, i see it in dmesg
 bsdbox /bsd: pid 9648 (mlnet): user write of 4096@0x202d4000 at 5328
 failed: 14

 what is this mean?

14 == EFAULT.  Sounds like that process (mlnet) passed a system call a
memory address for the kernel to write to (for example, to return a
socket address in accept(), or file data in read()) that wasn't
actually writable by that process, whether because it wasn't validly
mapped, was kernel memory, or was mapped but read-only.

That's an utter guess from a single line taken out of context, so it
may be completely wrong.  You provided no standard info (not even
platform?  hello?), so I won't waste time looking for details.


Philip Guenther