Re: amd64/185353: nc does not exit after transfer
The following reply was made to PR amd64/185353; it has been noted by GNATS. From: Peter Wemm pe...@wemm.org To: Robert r...@robert-eckardt.de Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/185353: nc does not exit after transfer Date: Mon, 30 Dec 2013 16:40:42 -0800 -N shutdown(2) the network socket after EOF on the input. Some servers require this to finish their work. Try: nc -N machineA 12345 bar.txt from your example -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV Yes, I know, gmail sucks now. If you see this then I forgot. Habits are hard to break. ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/173235: Have received two crashes within 1 day after installing new packages: Fatal trap 12: page fault in kernel mode
On Thu, Nov 8, 2012 at 10:29 AM, John Baldwin j...@freebsd.org wrote: On 10/31/12 8:50 AM, Tommy Sonne Alstrøm wrote: The following reply was made to PR amd64/173235; it has been noted by GNATS. From: =?ISO-8859-1?Q?Tommy_Sonne_Alstr=F8m?= to...@anakin.ws To: Andriy Gapon a...@freebsd.org Cc: bug-follo...@freebsd.org Subject: Re: amd64/173235: Have received two crashes within 1 day after installing new packages: Fatal trap 12: page fault in kernel mode Date: Wed, 31 Oct 2012 13:44:01 +0100 I'm very sorry, I just realized that I copied the 1st readout twice. The 2nd readout was like this Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x6 fault code = supervisor read data, page not present instruction pointer = 0x20:0x809da0cc stack pointer = 0x28:0xff8451f549b0 frame pointer = 0x28:0xff8451f54a40 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1068 (named) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x808680fe at kdb_backtrace+0x5e #1 0x80832cb7 at panic+0x187 #2 0x80b185a0 at trap_fatal+0x290 #3 0x80b188e9 at trap_pfault+0x1f9 #4 0x80b18daf at trap+0x3df #5 0x80b0324f at calltrap+0x8 #6 0x809f75a7 at udp6_bind+0xa7 #7 0x808a152e at kern_bind+0xde #8 0x808a15a1 at sys_bind+0x41 #9 0x80b17e90 at amd64_syscall+0x4e0 #10 0x80b03537 at Xfast_syscall+0xf7 Uptime: 9h41m13s Dumping 3411 out of 16088 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Both of your panics involve faults where the bad pointer only has a single bit set. They are also in very different places. I suspect you are having a hardware failure (e.g. single-bit memory errors). Which ones are you looking at? A fault va of 0x20 and 0x6 is what I'd normally suspect of being a null pointer + structure member offset dereference. Given: instruction pointer = 0x20:0x809da0cc I'd be curious to see the kgdb output of (kgdb) l *0x809da0cc (and same for the first crash if that kernel is still available) -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Bug Report: IBM x3650M4 (32GB, 2x4-core Xeon E5-2600, IBM ServeRaid M5110e): fails in install with NMI
On Sun, Oct 21, 2012 at 11:40 PM, Peter Wemm pe...@wemm.org wrote: On Tue, Aug 28, 2012 at 9:38 AM, John Baldwin j...@freebsd.org wrote: On Tuesday, August 28, 2012 10:05:07 am Mike A wrote: On Tue, Aug 28, 2012 at 09:34:14AM -0400, John Baldwin wrote: On Monday, August 27, 2012 4:38:17 pm Mike A wrote: IBM x3650M4 (32GB, 2x4-core Xeon E5-2600, IBM ServeRaid M5110e) I just got handed 4 of the subject boxes with instructions put 'em to work. Naturally I tried FreeBSD first, on one of the machines. Boot from the 9.0 AMD64 boot-only install CD fails. Things look fine until the last several lines of the (verbose enabled) boot sequence, which (from an insufficiently-wide phone camera capture) are: mpt0: LSILogic SAS/SATA Adapter port 0x3000-0x[lost off right edge of phone] xc5d0-0xc5de irq 34 at device 0.0 on pci[lost] mpt0: attempting to allocate 1 MSI vectors (1 su[lost] msi: routing MSI IRQ 256 to local APIC 0 vector [lost] mpt0: using IRQ 256 for MSI mpt0: soft reset failed, device not running NMI ISA 2c, EISA 0 NMI ... going to debugger mpt0: hard reset failed Does setting 'hint.mpt.0.msi_enable=0' in the loader make a difference? Thanks VERY MUCH (and come collect your steak dinner at Cattlemen's Cafe in OKC, next time you're in the area) for the very quick response. I will be happy to try that, but need guidance. This is an install from CD (burned from FreeBSD-9.1-RC1-amd64-disc1.iso), and I don't know how to insert a loader hint in that process. When the loader menu pops up, choose the escape to loader prompt option, then type 'set hint.mpt.0.msi_enable=0' followed by 'boot'. There's no guarantee this will help, btw, just something to try out first. If that doesn't work, you can also try setting 'machdep.kdb_on_nmi=0' using the same trick. If that still doesn't help, please boot another OS that does and get the output of 'lspci -v' or 'pciconf -lvb' or equivalent so we can see exactly which mpt adapter it is. I think there is one class of mpt(4) cards that we do not yet support properly. Ah, yes, this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=149220 I think this may in fact be your adapter. This was fixed after 9.0, so try a 9.1-RC1 install disk instead and see if it works better. Is it actually an mpt? There's a number of current servers that have *mfi* raid controllers that are mis-identified as mpt and being claimed by the mpt driver. Naturally this does not work well. I recognize the exact failure text from a failure we had in the freebsd.org cluster a few days ago with 9.0-RELEASE. The good news is that 9-STABLE or 9.1-RC get it right, at least on our hardware. It correctly attaches as mpt. Argh! Correctly attaches as mfi, damn it. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Updating messed up motd
On Mon, Apr 23, 2012 at 9:08 PM, Thomas D. Dean tomd...@speakeasy.org wrote: uname -a FreeBSD P9X79.tddhome 9.0-STABLE FreeBSD 9.0-STABLE #0: Mon Apr 23 \ 18:48:29 PDT 2012 root@P9X79.tddhome:/usr/obj/usr/src/sys/GENERIC \ amd64 I updated via cvsup an hour ago. Running mergemaster shows a loss of version in /etc/motd. env -i make buildworld ... env -i make kernel ... reboot mergemaster -p ... make installworld ... make delete-old ... mergemaster -i -F ... == *** Displaying differences between ./etc/motd and installed version: --- /etc/motd 2012-04-23 20:54:14.0 -0700 +++ ./etc/motd 2012-04-23 21:01:48.0 -0700 @@ -1,4 +1,4 @@ -FreeBSD 9.0-STABLE (GENERIC) #0: Mon Apr 23 18:48:29 PDT 2012 +FreeBSD ?.?.? (UNKNOWN) Welcome to FreeBSD! ... all else seems OK. Mergemaster is pretty bone-headed about files like motd. For what its worth, the tag line on motd is updated by the /etc/rc.d/motd file. Normally you'd just ignore or skip the file in mergemaster. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/163710: setjump in userboot.so causes stack corruption
The following reply was made to PR amd64/163710; it has been noted by GNATS.
From: Peter Wemm pe...@wemm.org
To: Russell Cattelan catte...@thebarn.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/163710: setjump in userboot.so causes stack corruption
Date: Fri, 16 Mar 2012 09:56:55 -0700
On Thu, Mar 15, 2012 at 2:40 PM, Russell Cattelan catte...@thebarn.com wr=
ote:
The following reply was made to PR amd64/163710; it has been noted by GNA=
TS.
[..]
=A0Does the last patch seem acceptable?
=A0Can we close this issue out?
Sadly not,
+no-machine:
+ rm -f ${.CURDIR}/../../ficl/machine
.. this is definitely bogus no matter what. This attempts to modify
the source tree which may be read only, and should never even have a
machine-... symlink in it to remove in the first place.
I see sys/boot/userboot/ficl/Makefile has commented out the code that
sets up the ./machine links in its ${.OBJDIR} and there's -I paths all
over the place so my guess is that it's picking up some of the i386
machine links rather than setting up its own. You probably need to
look at the userboot/ficl/Makefile code and make sure its setting up
the correct links rather than accidently using one belonging to
something else.
Or your source tree is contaminated somehow with a machine- link
somewhere that it isn't supposed to be.
--=20
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
All of this is for nothing if we don't go to the stars - JMS/B5
If Java had true garbage collection, most programs would delete
themselves upon execution. -- Robert Sewell
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/163710: setjump in userboot.so causes stack corruption
The following reply was made to PR amd64/163710; it has been noted by GNATS.
From: Peter Wemm pe...@wemm.org
To: Russell Cattelan catte...@thebarn.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: amd64/163710: setjump in userboot.so causes stack corruption
Date: Fri, 16 Mar 2012 13:51:18 -0700
2012/3/16 Russell Cattelan catte...@thebarn.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/16/12 11:56 AM, Peter Wemm wrote:
On Thu, Mar 15, 2012 at 2:40 PM, Russell Cattelan
catte...@thebarn.com wrote:
The following reply was made to PR amd64/163710; it has been
noted by GNATS.
[..]
Does the last patch seem acceptable?
Can we close this issue out?
Sadly not,
+no-machine: + rm -f =A0 ${.CURDIR}/../../ficl/machine
.. this is definitely bogus no matter what. This attempts to
modify the source tree which may be read only, and should never
even have a machine-... symlink in it to remove in the first
place.
The sym link is created by the build of ficl for the loader.
See: boot/ficl/Makefile
machine:
=A0 =A0 =A0 =A0ln -sf ${.CURDIR}/../../i386/include machine
Are you suggesting that is incorrect and should be fixed?
No, you're reading it wrong:
ln -sf ${.CURDIR}/../../i386/include machine
creates ${.OBJDIR}/machine
Your patch does a rm -f ${.CURDIR}/../../ficl/machine which is in
the source tree, not the obj tree, so it would never exist. And if it
does, then something is wrong with your build environment.
--=20
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
All of this is for nothing if we don't go to the stars - JMS/B5
If Java had true garbage collection, most programs would delete
themselves upon execution. -- Robert Sewell
___
freebsd-amd64@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Gcc46 and 128 Bit Floating Point
On Fri, Feb 17, 2012 at 10:59 AM, Thomas D. Dean tomd...@speakeasy.org wrote: [..] gcc46 is generating 80-bit floating point instructions. The gcc docs state gcc46 will generate 128-bit instructions. I can get gfortran46 to generate 128-bit instructions. How do I get gcc46 to generate 128-bit floating point instructions? As of gcc 4.3, a quadruple precision is also supported on x86, but as the nonstandard type __float128 rather than long double. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/163710: setjump in userboot.so causes stack corruption
The following reply was made to PR amd64/163710; it has been noted by GNATS. From: Peter Wemm pe...@wemm.org To: Russell Cattelan catte...@digitalelves.com Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: amd64/163710: setjump in userboot.so causes stack corruption Date: Thu, 29 Dec 2011 23:33:37 -0800 On Thu, Dec 29, 2011 at 7:16 PM, Russell Cattelan catte...@digitalelves.com wrote: Description: For some reason the forth interpreter is built and linked as 32bit even on amd64. That's the catch. We use the same 32 bit loader on i386 and amd64. The common loader understands both kernel formats. This unfortunately has meant that the libstand and sys/boot environment has had to be 32 bit. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: Where to find amd64 ABI information for FreeBSD?
On Tue, Apr 5, 2011 at 3:49 PM, Kostik Belousov kostik...@gmail.com wrote: On Tue, Apr 05, 2011 at 03:10:37PM -0700, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Is there a place to find ABI information for GCC on FreeBSD? Specifically, I'm looking for which registers has to be preserved across function call? (Or do we follow System V Application Binary Interface AMD64 Architecture Processor Supplement Draft Version 0.99.5?) The parts of the mentioned document that depend on compiler and toolchain, are fully valid for FreeBSD. Our non-compliance is mostly in the specified bits of the kernel/usermode interface. There is also an accidental deviation with register usage in the way we start up applications. But as far as calling conventions go for preserved/scratch registers, we are compliant. Of note our i386 syscall abi is not consistent with i386 calling conventions. In particular, i386 syscalls save/restore ALL registers except for those used in return values. eg: %eax is changed, and %edx is changed for SOME syscalls that have a 64 bit or dual return (and preserved otherwise). Unlike i386, our amd64 syscalls do not preserve registers that are designated as scratch in the abi. There is an inconsistency between the syscall instruction and the ABI, but that is repaired in the libc syscall wrappers. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
