Re: Strange reboot since 9.1
Hi Marius Thanks for your patch, but it has no effect for stability. The server has rebooted this night after 8h uptime, same backtrace appears. -- Best regards, Loïc BLOT, UNIX systems, security and network expert http://www.unix-experience.fr Le vendredi 08 mars 2013 à 17:16 +0100, Marius Strobl a écrit : On Fri, Mar 08, 2013 at 11:32:54AM +0900, YongHyeon PYUN wrote: On Thu, Mar 07, 2013 at 08:38:27AM -0800, Jeremy Chadwick wrote: On Thu, Mar 07, 2013 at 04:38:54PM +0100, Lo?c Blot wrote: Hi Marcelo, thanks. Here is a better trace: - kgdb /boot/kernel/kernel.symbols /var/crash/vmcore.11 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a84414 stack pointer = 0x28:0xff822fc267a0 frame pointer = 0x28:0xff822fc26830 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 = 12 (irq265: bce0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0x809208a6 at kdb_backtrace+0x66 #1 0x808ea8be at panic+0x1ce #2 0x80bd8240 at trap_fatal+0x290 #3 0x80bd857d at trap_pfault+0x1ed #4 0x80bd8b9e at trap+0x3ce #5 0x80bc315f at calltrap+0x8 #6 0x80a861d5 at udp_input+0x475 #7 0x80a043dc at ip_input+0xac #8 0x809adafb at netisr_dispatch_src+0x20b #9 0x809a35cd at ether_demux+0x14d #10 0x809a38a4 at ether_nh_input+0x1f4 #11 0x809adafb at netisr_dispatch_src+0x20b #12 0x80438fd7 at bce_intr+0x487 #13 0x808be8d4 at intr_event_execute_handlers+0x104 #14 0x808c0076 at ithread_loop+0xa6 #15 0x808bb9ef at fork_exit+0x11f #16 0x80bc368e at fork_trampoline+0xe Uptime: 27m20s Dumping 1265 out of 8162 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..92% #0 doadump (textdump=Variable textdump is not available. ) at pcpu.h:224 224 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt f #0 doadump (textdump=Variable textdump is not available. ) at pcpu.h:224 No locals. #1 0x808ea3a1 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 _ep = Variable _ep is not available. (kgdb) bt #0 doadump (textdump=Variable textdump is not available. ) at pcpu.h:224 #1 0x808ea3a1 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0x808ea897 in panic (fmt=0x1 Address 0x1 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0x80bd8240 in trap_fatal (frame=0xc, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #4 0x80bd857d in trap_pfault (frame=0xff822fc266f0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:773 #5 0x80bd8b9e in trap (frame=0xff822fc266f0) at /usr/src/sys/amd64/amd64/trap.c:456 #6 0x80bc315f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0x80a84414 in udp_append (inp=0xfe019e2a1000, ip=0xfe00444b6c80, n=0xfe00444b6c00, off=20, udp_in=0xff822fc268a0) at /usr/src/sys/netinet/udp_usrreq.c:252 #8 0x80a861d5 in udp_input (m=0xfe00444b6c00, off=Variable off is not available. ) at /usr/src/sys/netinet/udp_usrreq.c:618 #9 0x80a043dc in ip_input (m=0xfe00444b6c00) at /usr/src/sys/netinet/ip_input.c:760 #10 0x809adafb in netisr_dispatch_src (proto=1, source=Variable source is not available. ) at /usr/src/sys/net/netisr.c:1013 #11 0x809a35cd in ether_demux (ifp=0xfe00053fa000, m=0xfe00444b6c00) at /usr/src/sys/net/if_ethersubr.c:940 #12 0x809a38a4 in ether_nh_input (m=Variable m is not available. ) at /usr/src/sys/net/if_ethersubr.c:759 #13 0x809adafb in netisr_dispatch_src (proto=9, source=Variable source is not available. ) at /usr/src/sys/net/netisr.c:1013 #14 0x80438fd7 in bce_intr
lang/ruby19: ruby-1.9.3.392,1 is vulnerable: ** [check-vulnerable] Error code 1
I try to compile port lang/ruby19 and I always get on a FreeBSD 9.1-STABLE box the following error message, which is obviously triggered by some port auditing - but I do not find the knob to switch it off. Can someone give a hint, please? Regards, Oliver === Cleaning for ruby-1.9.3.392,1 === ruby-1.9.3.392,1 has known vulnerabilities: ruby-1.9.3.392,1 is vulnerable: Ruby -- XSS exploit of RDoc documentation generated by rdoc WWW: http://portaudit.FreeBSD.org/d3e96508-056b-4259-88ad-50dc8d1978a6.html ruby-1.9.3.392,1 is vulnerable: Ruby -- Denial of Service and Unsafe Object Creation Vulnerability in JSON WWW: http://portaudit.FreeBSD.org/c79eb109-a754-45d7-b552-a42099eb2265.html = Please update your ports tree and try again. *** [check-vulnerable] Error code 1 Stop in /usr/ports/lang/ruby19. *** [build] Error code 1 Stop in /usr/ports/lang/ruby19. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lang/ruby19: ruby-1.9.3.392,1 is vulnerable: ** [check-vulnerable] Error code 1
On 9 March 2013 09:37, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I try to compile port lang/ruby19 and I always get on a FreeBSD 9.1-STABLE box the following error message, which is obviously triggered by some port auditing - but I do not find the knob to switch it off. Can someone give a hint, please? I guess you sent it to -stable by mistake-- the knob you need is DISABLE_VULNERABILITIES=yes. I'm sure I don't need to lecture you on Be careful with this :) Chris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Strange reboot since 9.1
On Sat, Mar 09, 2013 at 09:53:54AM +0100, Loïc BLOT wrote: Hi Marius Thanks for your patch, but it has no effect for stability. The server has rebooted this night after 8h uptime, same backtrace appears. Okay, could you please give the following patch a try instead in order to test another theory? http://people.freebsd.org/~marius/bce_rx_corruption.diff Marius ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
problem compiling openjdk6
I get the following compile error when attempting to build openjdk6 on FreeBSD STING.teletu.it 9.1-STABLE FreeBSD 9.1-STABLE #0: Sun Mar 3 00:09:06 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 va/openjdk6/work/hotspot/src/share/vm/adlc/adlparse.cpp /usr/ports/java/openjdk6/work/hotspot/src/share/vm/adlc/adlparse.cpp:1: sorry, unimplemented: 64-bit mode not compiled in gmake[6]: *** [../generated/adfiles/adlparse.o] Error 1 gmake[6]: Leaving directory `/usr/ports/java/openjdk6/work/build/bsd-i386/hotspot/outputdir/bsd_amd64_compiler2/product' gmake[5]: *** [ad_stuff] Error 2 gmake[5]: Leaving directory `/usr/ports/java/openjdk6/work/build/bsd-i386/hotspot/outputdir/bsd_amd64_compiler2/product' gmake[4]: *** [product] Error 2 gmake[4]: Leaving directory `/usr/ports/java/openjdk6/work/build/bsd-i386/hotspot/outputdir' gmake[3]: *** [generic_build2] Error 2 gmake[3]: Leaving directory `/usr/ports/java/openjdk6/work/hotspot/make' gmake[2]: *** [product] Error 2 gmake[2]: Leaving directory `/usr/ports/java/openjdk6/work/hotspot/make' gmake[1]: *** [hotspot-build] Error 2 gmake[1]: Leaving directory `/usr/ports/java/openjdk6/work' gmake: *** [build_product_image] Error 2 *** [do-build] Error code 1 Stop in /usr/ports/java/openjdk6. *** [install] Error code 1 Stop in /usr/ports/java/openjdk6. *** [build-depends] Error code 1 Stop in /usr/ports/java/icedtea-web. *** [install] Error code 1 Stop in /usr/ports/java/icedtea-web. sincerely Filippo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sanity Check on Mac Mini
I have documented what I have completed and what remains to be done for the install of 9.1 on a Mini. I wrote this as a section of the Handbook, although its not in the right format as I don't know what that format is. I believe this needs to be retained in the documentation somewhere easily found for those who need it in the future. 2.12Installing FreeBSD on an Apple Mac Mini The Mac Mini is an attractive server platform. Its small, runs cool, low powered, and reasonably cheap. There a variety of configurations available. However, the bottom of the line seems to be a powerful server. There are a few issues with installing FreeBSD on the mini. Mostly they derive from the newer hardware it uses and that it uses EFI rather than a BIOS for booting. There is not a simple install that will get the unit working, but the additional steps required are quite simple. The goal of these instructions is to get FreeBSD 9.1-Release running as a headless server on a Late 2012 Mini. Its probably possible to setup the mini as a workstation, but that would require some additional effort to test the display and mouse interfaces and find fixes for any issues with those. The original intent was to have the server without system source so that it could be maintained using freebsd-update. However, that will probably have to wait until 9.2-Release is available. In the meantime, freebsd-update has to be used with care since I believe it will replace the modified bge files. 2.12.1 Preparing for the Install You can select either the i386 or the amd64 distributions. Both have been tested with these procedures and yield a working server. The bottom of the line mini comes with 4 GB of memory installed. The i386 distribution will only use 2 GB. The remainder will not be used. The amd64 distribution builds larger binary modules, but it will use all the memory. Download the 9.1 Release distribution Memstick Image. You will need to copy that to a memstick. There are instructions in section 2.3.5 for copying the image to the memstick. Obtain a display and USB keyboard and connect them to the mini. With a browser go to svnweb.freebsd.org/base/head/sys/dev. Click on the bge folder. Click on the name if_bge.c. Find Revision 245931. Click on the download link and save the file. Go back to the bge page and click on if_bgereg.h. Find Revision 243686. Click on the download link and save the file. Edit the saved if_bgereg.h file and add the following to the end: #define PCIER_DEVICE_CAP0x4 #define PCIER_DEVICE_CTL0x8 #define PCIEM_CAP_MAX_PAYLOAD 0x0007 #define PCIEM_CTL_RELAXED_ORD_ENABLE0x0010 #define PCIEM_CTL_NOSNOOP_ENABLE0x0800 #define PCIER_DEVICE_STA0xa #define PCIEM_STA_CORRECTABLE_ERROR 0x0001 #define PCIEM_STA_NON_FATAL_ERROR 0x0002 #define PCIEM_STA_FATAL_ERROR 0x0004 #define PCIEM_STA_UNSUPPORTED_REQ 0x0008 There was a change to some of the names in if_bgereg.h after the 9.1 Release was created, but before the corrections to the bge driver were included. It would be possible to grab the appropriate earlier verion of if_bgereg.h, however, when rebuilding the kernel, there are other drivers that use the new names. This seems to be the easiest approach. Also, it worked. Go back to the dev page and click on the mii folder. Click on brgphy.c. Find revision 244482. Click on the download link and save the file. Copy the saved files to another memstick. 2.12.2 Installing the 9.1 Release Boot the mini using the memstick. Hold down the Option key on the keyboard and power up the mini. You will hear the hardware check beep and shortly thereafter the screen will show one or more boot icons. Double click on the one named Windows. It will have a USB icon. Continue through the normal installation procedure as detailed earlier in this chapter. If you are building a FreeBSD only server, use the entire disk. Also, be sure to install the system source. You will need it later. At the end of the install you will be asked to reboot the mini. Here is where the first problem occurs. If you pop out the memstick and let the system reboot, it will hang with an empty folder icon in the center of the display. The problem is that the EFI boot loader can't find anything to boot. There are several approaches that may work. The Mac bless utility has been used to bless the boot disk so the boot loader can find it. There are currently no instructions available for this approach. The one way that has been shown to work is to make sure the memstick is removed when you boot the mini. Once you get the empty folder icon, plug the memstick back in. The system will shortly boot from the internal disk. There is no known explanation for this phenomena other than it just works. 2.12.3 Rebuilding the kernel to support the Ethernet Interface Once the system has been rebooted, you
Re: Sanity Check on Mac Mini
On 08 Mar 2013, at 17:43, Doug Hardie bc...@lafn.org wrote: On 7 March 2013, at 17:00, John Mehr j...@visi.com wrote: On Thu, 7 Mar 2013 14:18:23 -0800 Doug Hardie bc...@lafn.org wrote: On 7 March 2013, at 11:57, Kevin Oberman rkober...@gmail.com wrote: [ ... ] Thanks. Well, I got 9.1 Release installed, but it won't boot from the internal disk. It doesn't see the disk as bootable. I installed using the entire disk for FreeBSD. I used the i386 release. Perhaps I need to switch to the amd64 release? I would generally recommend using the amd64 release, but it may not get your system to boot. How is your disk partitioned? GPT? Some BIOSes are broken and assume that a GPT formatted disk is UEFI and will not recognize them if they lack the UEFI boot partition. UEFI boot is a current project that seems likely to reach head in the fairly near future, but it's not possible now. No idea what the default partitioning is for BSDInstall. However the Mini is only EFI or UFEI with some fallbacks although the comments I find in the web indicate that different models have different fallbacks. One comment indicates that an older unit will boot if its MBR partitioning. I don't know if the new installer supports that or not. You may be able to tweak your BIOS to get it to work or you may have to install using the traditional partitioning system. The installer defaults to GPT, but can create either. I have such a system (ThinkPad T520) and I have two disks... one that came with the system and containing Windows, and my GPT formatted FreeBSD disk. I wrote a FreeBSD BootEasy boot into the MBR of the Windows disk and it CAN boot the GPT disk just fine. Not ideal for most, but it works well for me Based on a comment I say, waiting till the empty folder icon appears and then plugging in the install memstick causes the mini to boot from disk. That just downright weird, but it works. I could live with that, but this is an unattended server and would experience some down time if I am not there when there is a power failure. I just found some instructions for using MBR with bsdinstall, but given there is an effort to create a UEFI boot which I suspect would expect to find the GPT boot partition, perhaps I should just go with the memstick approach? Hello, If you still have a drive with OS X on it, you may have some luck with OS X's bless command: https://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man8/bless.8.html I got a late 2012 mac mini to boot FreeBSD 9.1 (AMD64) from a hard drive using 'bless' (unfortunately I don't remember the exact command line parameters I used). If you're looking to dual boot, the only luck I had (without resorting to using third party software like rEFIt) was to put the OS's on different drives and install FreeBSD using MBR on the second drive. I have investigated the bless command and nothing I find on google gives me any good ideal on what folder/file to bless. I am wondering if just using the volume command and ignoring folder and file would work? When I was setting up FreeBSD (9/amd64) to run on a MacBook Air, I used (from within Terminal while booted into an OS X boot image): sudo bless --device /dev/disk0s2 --setBoot --legacy (s2 was the FreeBSD boot slice.) My notes also claim that the drive needed to have MBR boot code installed first (e.g., via fdisk -B ada0 or the gpart equivalent) in order for the blessing to work. This was about a year ago (December 2011), on whatever hardware/firmware/OS X were current at the time. -- Molly ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: top's CPUn vs C column
That patch does in fact work, and removes the inconsistency that I
noted earlier. I would be happy to see it committed. If no one else
has objections, please do.
Thanks...
- Chris
On Mar 4, 2013, at 11:37 , John Baldwin j...@freebsd.org wrote:
On Friday, March 01, 2013 1:17:41 pm Chris Ross wrote:
So, I was looking at a v240 I have running stable/9 (9.1-STABLE), and
noticed something odd. The per-CPU information displayed by top seems
inconsistent. To simplify things, while I'm running a make release in
/usr/src/release, I just started running the following command over and over
(by hand):
cross: top | grep CPU
cross: top | grep CPU
1044 cross 1 720 17128K 4464K CPU10 0:01 1.27% zsh
22528 root 1 775 11672K 2592K CPU11 0:00 0.00% sh
cross: top | grep CPU
cross: top | grep CPU
22634 cross 1 720 12808K 2872K CPU11 0:00 0.00% top
22633 root 1 775 6272K 880K CPU01 0:00 0.00% make
cross: top | grep CPU
22637 root 1 775 6272K 1656K CPU00 0:00 0.00% make
cross: top | grep CPU
cross: top | grep CPU
22684 root 1 775 11672K 2592K CPU00 0:00 0.00% sh
cross:
This displayed what I had earlier seen in the full-screen top. There
doesn't appear to be any specific binding between the n in the CPUn
state
value, and the number in the C column, which is according to the man page,
should mean the same thing.
No, they are different things. The man page is a bit stale. The 'C' column
is the CPU that the process last ran on. Hmm, it's actually easiest to fix
the code I think. Try this (untested) change:
Index: usr.bin/top/machine.c
===
--- machine.c (revision 247792)
+++ machine.c (working copy)
@@ -797,7 +797,7 @@ format_next_process(caddr_t handle, char *(*get_us
double pct;
struct handle *hp;
char status[16];
- int state;
+ int cpu, state;
struct rusage ru, *rup;
long p_tot, s_tot;
char *proc_fmt, thr_buf[6], jid_buf[6];
@@ -997,6 +997,13 @@ format_next_process(caddr_t handle, char *(*get_us
}
/* format this entry */
+ if (smpmode) {
+ if (state == SRUN pp-ki_oncpu != 0xff)
+ cpu = pp-ki_oncpu;
+ else
+ cpu = pp-ki_lastcpu;
+ } else
+ cpu = 0;
proc_fmt = smpmode ? smp_Proc_format : up_Proc_format;
if (ps.thread != 0)
thr_buf[0] = '\0';
@@ -1014,7 +1021,7 @@ format_next_process(caddr_t handle, char *(*get_us
format_k2(PROCSIZE(pp)),
format_k2(pagetok(pp-ki_rssize)),
status,
- smpmode ? pp-ki_lastcpu : 0,
+ cpu,
format_time(cputime),
ps.wcpu ? 100.0 * weighted_cpu(pct, pp) : 100.0 * pct,
screen_width cmdlengthdelta ? screen_width - cmdlengthdelta : 0,
--
John Baldwin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
