Re[2]: TCP differences in 7.2 vs 7.1
Hello, Lars. You wrote 14 мая 2009 г., 12:28:43: > Reproducing the issue is as easy as setting net.inet.tcp.tso=1. > What's interesting is that I only see the issue on one of the eight em > interfaces. That interface is connected to a D-Link DIR-655 WLAN > router. When I tcpdump on the other interfaces with TSO enabled, I see > no "IP bad-len 0" messages. I have same problem (every one of 100-200 frames) on on-board if_em: e...@pci0:0:25:0:class=0x02 card=0x82681043 chip=0x10bd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82566DM-2 Gigabit Network Connection' class = network subclass = ethernet -- // Black Lion AKA Lev Serebryakov ___ 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"
double-fault in linux ioctl for atapicam cd device
This is recent i386 stable/7. The problem is 100% reproducible with the same stack trace. The problem happens when I start a Linux program that performs a check on a cd-rom device (atapi cd-rom that is presented as cd0 by atapicam driver). I examined the crash dump in kgdb but couldn't find anything peculiar in the variables, so I guess that this must be stack overflow or something like that. In fact, difference between values in %esp in frame 4 and frame 22 is 7500 which is quite close to KSTACK_PAGES * PAGE_SIZE for i386. If I did my calculations correctly then it seems that linux_ioctl_cdrom uses slightly more than 4K of stack, then cam_periph_error uses 828 bytes, scsi_command_string uses 696, cam_error_print uses 540. The backtrace is below. I am keeping the dump. (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc0556523 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #2 0xc055676f in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:574 #3 0xc0712b69 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:972 #4 0xc058380a in kvprintf (fmt=0xc075d204 " ", func=0xc05828e0 , arg=0xdabf0120, radix=10, ap=0xdabf015c "B") at /usr/src/sys/kern/subr_prf.c:823 #5 0xc0583c0b in vsnprintf (str=0xdabf03eb "", size=49, format=0xc075d202 "%x ", ap=0xdabf0158 "B") at /usr/src/sys/kern/subr_prf.c:483 #6 0xc0583cf9 in snprintf (str=0xdabf03eb "", size=49, format=0xc075d202 "%x ") at /usr/src/sys/kern/subr_prf.c:467 #7 0xc0449dc0 in scsi_cdb_string (cdb_ptr=0xc3187c9c "B", cdb_string=0xdabf03eb "", len=49) at /usr/src/sys/cam/scsi/scsi_all.c:2943 #8 0xc0449ffd in scsi_command_string (csio=0xc3187c00, sb=0xdabf0440) at /usr/src/sys/cam/scsi/scsi_all.c:3031 #9 0xc043db61 in cam_error_string (ccb=0xc3187c00, str=0xdabf04bc "(cd0:ata0:0:0:0): ", str_len=512, flags=Variable "flags" is not available. ) at /usr/src/sys/cam/cam.c:262 #10 0xc043dcb4 in cam_error_print (ccb=0xc3187c00, flags=CAM_ESF_ALL, proto_flags=CAM_EPF_ALL) at /usr/src/sys/cam/cam.c:341 #11 0xc043e500 in cam_periph_error (ccb=0xc3187c00, camflags=CAM_RETRY_SELTO, sense_flags=1, save_ccb=0xc32b3034) at /usr/src/sys/cam/cam_periph.c:1548 #12 0xc044bcb0 in cderror (ccb=0xc3187c00, cam_flags=2, sense_flags=1) at /usr/src/sys/cam/scsi/scsi_cd.c:3133 #13 0xc043ee1a in cam_periph_runccb (ccb=0xc3187c00, error_routine=0xc044bc10 , camflags=CAM_RETRY_SELTO, sense_flags=1, ds=0xc329fb40) at /usr/src/sys/cam/cam_periph.c:902 #14 0xc044c2cb in cdrunccb (ccb=0xc3187c00, error_routine=0xc044bc10 , cam_flags=2, sense_flags=1) at /usr/src/sys/cam/scsi/scsi_cd.c:1318 #15 0xc044f684 in cdioctl (dp=0xc3286000, cmd=3222037279, addr=0xdabf1c1c, flag=5, td=0xc354c230) at /usr/src/sys/cam/scsi/scsi_cd.c:3227 #16 0xc04f9fa4 in g_disk_ioctl (pp=0xc32c7000, cmd=3222037279, data=0xdabf1c1c, fflag=5, td=0xc354c230) at /usr/src/sys/geom/geom_disk.c:231 #17 0xc04f92dd in g_dev_ioctl (dev=0xc33faa00, cmd=3222037279, data=0xdabf1c1c "\001\001", fflag=5, td=0xc354c230) at /usr/src/sys/geom/geom_dev.c:332 #18 0xc04e5b87 in devfs_ioctl_f (fp=0xc32d1474, com=3222037279, data=0xdabf1c1c, cred=0xc4077800, td=0xc354c230) at /usr/src/sys/fs/devfs/devfs_vnops.c:602 #19 0xc3449ea4 in linux_ioctl_cdrom (td=0xc354c230, args=0xdabf1cfc) at file.h:269 #20 0xc344978a in linux_ioctl (td=0xc354c230, args=0xdabf1cfc) at /usr/src/sys/modules/linux/../../compat/linux/linux_ioctl.c:2621 #21 0xc0713495 in syscall (frame=0xdabf1d38) at /usr/src/sys/i386/i386/trap.c:1090 #22 0xc07006d0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:255 #23 0x0033 in ?? () -- Andriy Gapon ___ 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"
stack abuse by linux_ioctl_cdrom [Was: double-fault in linux ioctl for atapicam cd device]
on 18/05/2009 16:41 Andriy Gapon said the following: > This is recent i386 stable/7. The problem is 100% reproducible with the same > stack > trace. The problem happens when I start a Linux program that performs a check > on a > cd-rom device (atapi cd-rom that is presented as cd0 by atapicam driver). > I examined the crash dump in kgdb but couldn't find anything peculiar in the > variables, so I guess that this must be stack overflow or something like that. > > In fact, difference between values in %esp in frame 4 and frame 22 is 7500 > which > is quite close to KSTACK_PAGES * PAGE_SIZE for i386. > If I did my calculations correctly then it seems that linux_ioctl_cdrom uses > slightly more than 4K of stack, then cam_periph_error uses 828 bytes, > scsi_command_string uses 696, cam_error_print uses 540. In fact almost all of stack usage in linux_ioctl_cdrom comes from struct dvd_struct (2060 bytes) and l_dvd_struct (2056 bytes) variables declared on stack (for LINUX_DVD_READ_STRUCT case). Not sure what's the best way to fix - move to heap? > The backtrace is below. I am keeping the dump. > > (kgdb) bt > #0 doadump () at pcpu.h:196 > #1 0xc0556523 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 > #2 0xc055676f in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:574 > #3 0xc0712b69 in dblfault_handler () at /usr/src/sys/i386/i386/trap.c:972 > #4 0xc058380a in kvprintf (fmt=0xc075d204 " ", func=0xc05828e0 > , > arg=0xdabf0120, radix=10, ap=0xdabf015c "B") at > /usr/src/sys/kern/subr_prf.c:823 > #5 0xc0583c0b in vsnprintf (str=0xdabf03eb "", size=49, format=0xc075d202 > "%x ", > ap=0xdabf0158 "B") at /usr/src/sys/kern/subr_prf.c:483 > #6 0xc0583cf9 in snprintf (str=0xdabf03eb "", size=49, format=0xc075d202 "%x > ") > at /usr/src/sys/kern/subr_prf.c:467 > #7 0xc0449dc0 in scsi_cdb_string (cdb_ptr=0xc3187c9c "B", > cdb_string=0xdabf03eb > "", len=49) at /usr/src/sys/cam/scsi/scsi_all.c:2943 > #8 0xc0449ffd in scsi_command_string (csio=0xc3187c00, sb=0xdabf0440) at > /usr/src/sys/cam/scsi/scsi_all.c:3031 > #9 0xc043db61 in cam_error_string (ccb=0xc3187c00, str=0xdabf04bc > "(cd0:ata0:0:0:0): ", str_len=512, flags=Variable "flags" is not available. > ) at /usr/src/sys/cam/cam.c:262 > #10 0xc043dcb4 in cam_error_print (ccb=0xc3187c00, flags=CAM_ESF_ALL, > proto_flags=CAM_EPF_ALL) at /usr/src/sys/cam/cam.c:341 > #11 0xc043e500 in cam_periph_error (ccb=0xc3187c00, camflags=CAM_RETRY_SELTO, > sense_flags=1, save_ccb=0xc32b3034) at /usr/src/sys/cam/cam_periph.c:1548 > #12 0xc044bcb0 in cderror (ccb=0xc3187c00, cam_flags=2, sense_flags=1) at > /usr/src/sys/cam/scsi/scsi_cd.c:3133 > #13 0xc043ee1a in cam_periph_runccb (ccb=0xc3187c00, error_routine=0xc044bc10 > , camflags=CAM_RETRY_SELTO, sense_flags=1, ds=0xc329fb40) at > /usr/src/sys/cam/cam_periph.c:902 > #14 0xc044c2cb in cdrunccb (ccb=0xc3187c00, error_routine=0xc044bc10 > , > cam_flags=2, sense_flags=1) at /usr/src/sys/cam/scsi/scsi_cd.c:1318 > #15 0xc044f684 in cdioctl (dp=0xc3286000, cmd=3222037279, addr=0xdabf1c1c, > flag=5, > td=0xc354c230) at /usr/src/sys/cam/scsi/scsi_cd.c:3227 > #16 0xc04f9fa4 in g_disk_ioctl (pp=0xc32c7000, cmd=3222037279, > data=0xdabf1c1c, > fflag=5, td=0xc354c230) at /usr/src/sys/geom/geom_disk.c:231 > #17 0xc04f92dd in g_dev_ioctl (dev=0xc33faa00, cmd=3222037279, data=0xdabf1c1c > "\001\001", fflag=5, td=0xc354c230) at /usr/src/sys/geom/geom_dev.c:332 > #18 0xc04e5b87 in devfs_ioctl_f (fp=0xc32d1474, com=3222037279, > data=0xdabf1c1c, > cred=0xc4077800, td=0xc354c230) at /usr/src/sys/fs/devfs/devfs_vnops.c:602 > #19 0xc3449ea4 in linux_ioctl_cdrom (td=0xc354c230, args=0xdabf1cfc) at > file.h:269 > #20 0xc344978a in linux_ioctl (td=0xc354c230, args=0xdabf1cfc) at > /usr/src/sys/modules/linux/../../compat/linux/linux_ioctl.c:2621 > #21 0xc0713495 in syscall (frame=0xdabf1d38) at > /usr/src/sys/i386/i386/trap.c:1090 > #22 0xc07006d0 in Xint0x80_syscall () at > /usr/src/sys/i386/i386/exception.s:255 > #23 0x0033 in ?? () > -- Andriy Gapon ___ 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"
[releng_6 tinderbox] failure on amd64/amd64
TB --- 2009-05-18 14:02:42 - tinderbox 2.6 running on freebsd-legacy.sentex.ca TB --- 2009-05-18 14:02:42 - starting RELENG_6 tinderbox run for amd64/amd64 TB --- 2009-05-18 14:02:42 - cleaning the object tree TB --- 2009-05-18 14:02:57 - cvsupping the source tree TB --- 2009-05-18 14:02:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/RELENG_6/amd64/amd64/supfile TB --- 2009-05-18 14:03:05 - building world TB --- 2009-05-18 14:03:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-05-18 14:03:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-05-18 14:03:05 - TARGET=amd64 TB --- 2009-05-18 14:03:05 - TARGET_ARCH=amd64 TB --- 2009-05-18 14:03:05 - TZ=UTC TB --- 2009-05-18 14:03:05 - __MAKE_CONF=/dev/null TB --- 2009-05-18 14:03:05 - cd /src TB --- 2009-05-18 14:03:05 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -fno-strict-aliasing -pipe -I. -I/src/lib/libthread_db -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libthread_db/arch/amd64/libpthread_md.c /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_fpreg_to_ucontext': /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: implicit declaration of function `memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c:94: warning: nested extern declaration of `memcpy' :0: warning: redundant redeclaration of 'memcpy' /src/lib/libthread_db/arch/amd64/libpthread_md.c: In function `pt_ucontext_to_fpreg': /src/lib/libthread_db/arch/amd64/libpthread_md.c:100: warning: nested extern declaration of `memcpy' :0: warning: redundant redeclaration of 'memcpy' *** Error code 1 Stop in /src/lib/libthread_db. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-05-18 14:27:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-05-18 14:27:33 - ERROR: failed to build world TB --- 2009-05-18 14:27:33 - 1116.55 user 159.14 system 1490.53 real http://tinderbox.des.no/tinderbox-releng_6-RELENG_6-amd64-amd64.full ___ 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: Re: Unable to read from CCID USB reader
Hi, no I haven't tried it on CURRENT should I do that ? is there something new in the USB stuff there ? thank you regards, mgp >On Sunday 17 May 2009, Mario Pavlov wrote: >> Hi, >> I just got a CCID USB reader with my digital signature...unfortunately I >> can't make it work I installed pcsc-lite and libccid from ports... >> when I plug-in the reader I can see this: >> >> ugen0: on >> uhub4 >> >> then I do this: >> > >Is the problem the same on -current? > >--HPS >___ >freebsd-curr...@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ 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: Unable to read from CCID USB reader
On Sunday 17 May 2009, Mario Pavlov wrote: > Hi, > I just got a CCID USB reader with my digital signature...unfortunately I > can't make it work I installed pcsc-lite and libccid from ports... > when I plug-in the reader I can see this: > > ugen0: on > uhub4 > > then I do this: > Is the problem the same on -current? --HPS ___ 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: Unable to read from CCID USB reader
On Monday 18 May 2009, Mario Pavlov wrote: > Hi, > no I haven't tried it on CURRENT > should I do that ? > is there something new in the USB stuff there ? There is a new USB stack in 8-current and a new libusb which is installed as a part of the base system. --HPS ___ 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: Boot panic w/7.2-STABLE on amd64: resource_list_alloc
On Sunday 17 May 2009 6:51:19 pm Alexander Motin wrote: > John Baldwin wrote: > > Sounds like the ATA driver is allocating the same BAR twice. Hmm, yes, it > > allocates the resources once for each channel it seems in the ata_ali_sata > > attachment. Looking in ata-chipset.c, all the other chipsets are good about > > allocating these resources in their chipinit routines rather than the > > per-channel allocate routine. Well, except ata_pci_allocate() is also > > busted. *sigh* I can work on a patch for HEAD if you are willing to test. > > ata_pci_allocate() (now known as ata_pci_ch_attach()) is a different > case. It uses allocation functions wrapped by the atapci "bus", so every > channel uses it's own pair of RIDs. Hmm, ok. > Problem of ALI SATA is a bit different. As I understand, controller has > two pairs of RIDs for 4 channels, so each channel should share resources > with another one, just using different offset. Is there any other way to > correctly handle two halves of same resource separately without teaching > atapci to virtualize this as interrupts or handle it on controller level? I will just fix the ALI attachment to handle this possibly by using 'chipset_data' to cache resources. -- 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"
Re: RFT: ZFS MFC
On 2009-05-16 02:02, Kip Macy wrote: > I've MFC'd ZFS v13 to RELENG_7 in a work branch. Please test if you can. > > http://svn.freebsd.org/base/user/kmacy/ZFS_MFC/ > > The standard disclaimers apply. This has only been lightly tested in a > VM. Please do not use it with data you care about at this time. For people that would like to test this without building, e.g. to easily install on a spare box or VM, I have put up some snapshot ISOs of this branch, at r192269 (for i386): http://www.andric.com/freebsd/zfs13/r192269/ Note: these don't contain a full ports collection, but enough to get a basic system installed, or a LiveCD/DVD started. Also, if you encounter issues with these ISOs that don't have to do with ZFS, please don't bother Kip, but me instead. :) ___ 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"
mountd doean`t start when ZFS is enabled.
I have two servers with Identical FreeBSD7.2 system. On both I have such config in /etc/rc.conf: rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfs_client_enable="YES" nfs_server_enable="YES" nfs_server_flags="-u -t -n 5 -h 192.168.x.y" mountd_flags="-r" where "x" identical for both servers and "y" is differs by one. On one server I have ZFS storage, so that in rc.conf I have: zfs_enable="YES" On server where no ZFS storage NFS server works well and mountd starts at server startup automatically. But on the server with ZFS storage mountd couldn`t start on startup with such error: mountd[855]: bindresvport_sa: Address already in use when I correct rc.conf to: mountd_flags="-r -p 998" mountd begins to work. So, is it corrct behaviour of mountd with zfs? On 7.1 anything works well, but after cvsup and recompilation system has falled in such troube. May be it is a bug? ___ 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"
help with 7.0-p12 crash analysis "panic: lockmgr: upgrade without shared"
Hello,
We had a crash of a 7.0-RELEASE-p12 running on a dual quad-core Xeon
system with 6 gig RAM and mfi-based RAID. Pasted below are the output
of kgdb crashdump backtrace, custom kernel config, and boot log.
We really need to understand what happened and would greatly appreciate
assistance. What is the next step?
Thanks very much,
Charles
(kgdb) newcastle# kgdb kernel.debug /crash/vmcore.0
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol "ps_pglobal_lookup"]
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 "i386-marcel-freebsd".
Unread portion of the kernel message buffer:
panic: lockmgr: upgrade without shared
cpuid = 3
Uptime: 1d0h5m24s
Physical memory: 6126 MB
Dumping 495 MB: 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240
224 208 192 176 160 144 128 112 96 80 64 48 32 16
#0 doadump () at pcpu.h:195
195 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) backtrace
#0 doadump () at pcpu.h:195
#1 0xc0505537 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc05057f9 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3 0xc04f3cb7 in _lockmgr (lkp=0xcc69ee28, flags=8212, interlkp=0xcc69ee58,
td=0xcc11e660, file=0xc088d931 "/usr/src/sys/kern/vfs_subr.c", line=2213)
at /usr/src/sys/kern/kern_lock.c:310
#4 0xc05710b0 in vop_stdlock (ap=0xec5c6bfc)
at /usr/src/sys/kern/vfs_default.c:266
#5 0xc07734b6 in VOP_LOCK1_APV (vop=0xc0919180, a=0xec5c6bfc)
at vnode_if.c:1618
#6 0xc06cc3eb in ffs_lock (ap=0xec5c6bfc)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:391
#7 0xc07734b6 in VOP_LOCK1_APV (vop=0xc09296c0, a=0xec5c6bfc)
at vnode_if.c:1618
#8 0xc057f9b1 in vput (vp=0xcc69edd0) at vnode_if.h:851
#9 0xc06f9f54 in vm_pageout () at /usr/src/sys/vm/vm_pageout.c:1025
#10 0xc04e43c9 in fork_exit (callout=0xc06f8f30 , arg=0x0,
frame=0xec5c6d38) at /usr/src/sys/kern/kern_fork.c:781
#11 0xc0746f80 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:205
(kgdb)
* KERNEL CONF **
# Inherit config (most stuff) -- this is slightly customized version...
# inherits from GENERIC-cust (tweaked to disable the default scheduler)
include PAE-cust
# Name of this kernel
ident BEACON
# Scheduler -- From /usr/src/sys/conf/NOTES:
#
# SCHED_ULE provides significant performance advantages over 4BSD on many
# workloads on SMP machines. It supports cpu-affinity, per-cpu runqueues
# and scheduler locks. It also has a stronger notion of interactivity
# which leads to better responsiveness even on uniprocessor machines. This
# will eventually become the default scheduler.
#
optionsSCHED_ULE
# Note: we're compiling modules in statically since with PAE we don't want to
# load KLDs. See comments in pae(4) and PAE kernel conf file.
# Hardware Monitoring / Management
device ipmi
# Storage
options GEOM_JOURNAL
# Firewall
device pf #PF OpenBSD packet-filter firewall
device pflog #logging support interface for PF
# device pfsync #synchronization interface for PF
options ALTQ
options ALTQ_CBQ
options ALTQ_RED
options ALTQ_RIO
options ALTQ_HFSC
options ALTQ_CDNR
options ALTQ_PRIQ
options ALTQ_NOPCC # Required for SMP builds
# Linux Emulation
options COMPAT_LINUX
options LINPROCFS
options LINSYSFS
# Screen saver
device green_saver
### Network perf tuning
options ACCEPT_FILTER_HTTP
# See polling(4))
options DEVICE_POLLING
options HZ=1000
# End config
** Boot Log **
May 16 02:34:18 gbs01-etc kernel: mfi0: 4167 (295774362s/0x0020/0) - Patrol
Read complete
May 16 02:56:01 gbs01-etc heartbeat: [2685]: WARN: Gmain_timeout_dispatch:
Dispatch function for send local status took too long to execute: 789 ms (> 50
ms) (GSource: 0x28620930)
May 16 09:46:08 gbs01-etc su: beacon to root on /dev/ttyp0
May 16 16:03:47 gbs01-etc sshd[8012]: error: PAM: authentication error for
beacon from 10.102.144.81
May 16 16:05:41 gbs01-etc sshd[8017]: error: ssh_msg_send: write
May 18 13:52:10 gbs01-etc syslogd: kernel boot file is /boot/BEACON/kernel
May 18 13:52:10 gbs01-etc kernel: Copyright (c) 1992-2008 The FreeBSD Project.
May 18 13:52:10 gbs01-etc kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988,
1989, 1991, 1992, 1993, 1994
May 18 13:52:10 gbs01-etc kernel: The Regents of the University of California.
All rights reserved.
May 18 13:52:10 gbs01-etc kernel: FreeBSD is a regist
failed to set mtrr: invalid argument
Greetings, I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440. On 7.1-7.2 releases. I'm currently working (struggling) with it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday), I've seen only a few discussions regarding this, but no joy. I'm not sure what to post for additional information. So I'll provide the output of dmesg(8), and Xorg.0.log via links. Thank you for all your time and consideration in this matter. Sincerely, Chris H Xorg log: http://codewarehouse.NET/output/Xorg.0.log relevent dmesg(8) output: http://codewarehouse.NET/output/dmesg.output ___ 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: failed to set mtrr: invalid argument
Quoting Chris H : Greetings, I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440. On 7.1-7.2 releases. I'm currently working (struggling) with it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday), I've seen only a few discussions regarding this, but no joy. I'm not sure what to post for additional information. So I'll provide the output of dmesg(8), and Xorg.0.log via links. Thank you for all your time and consideration in this matter. Sincerely, Chris H Xorg log: http://codewarehouse.NET/output/Xorg.0.log relevent dmesg(8) output: http://codewarehouse.NET/output/dmesg.output OOPS! I guess the xorg config might be useful: http://codewarehouse.NET/output/xorg.conf.nvidia ___ 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" ___ 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: failed to set mtrr: invalid argument
Quoting Chris H : Quoting Chris H : Greetings, I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440. On 7.1-7.2 releases. I'm currently working (struggling) with it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday), I've seen only a few discussions regarding this, but no joy. I'm not sure what to post for additional information. So I'll provide the output of dmesg(8), and Xorg.0.log via links. Thank you for all your time and consideration in this matter. Sincerely, Chris H Xorg log: http://codewarehouse.NET/output/Xorg.0.log relevent dmesg(8) output: http://codewarehouse.NET/output/dmesg.output OOPS! I guess the xorg config might be useful: http://codewarehouse.NET/output/xorg.conf.nvidia SIGH... Seems that the registrar isn't paying attention. They happily accepted my money, but forgot to renew the domain. So here's trying to attach the files... ___ 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" ___ 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" ___ 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: failed to set mtrr: invalid argument
On 5/19/09, Chris H wrote: > Quoting Chris H : > >> Quoting Chris H : >> >>> Greetings, >>> I'm unable to get xorg-7.4 to accomodate my Gforce4 MX 440. >>> On 7.1-7.2 releases. I'm currently working (struggling) with >>> it on a 7.1 install/GENERIC with cvsup over the weekend (Sunday), >>> I've seen only a few discussions regarding this, but no joy. >>> >>> I'm not sure what to post for additional information. So I'll >>> provide the output of dmesg(8), and Xorg.0.log via links. >>> >>> Thank you for all your time and consideration in this matter. >>> >>> Sincerely, >>> Chris H >>> >>> Xorg log: >>> http://codewarehouse.NET/output/Xorg.0.log >>> >>> relevent dmesg(8) output: >>> http://codewarehouse.NET/output/dmesg.output >> >> OOPS! I guess the xorg config might be useful: >> http://codewarehouse.NET/output/xorg.conf.nvidia >> >>> > SIGH... Seems that the registrar isn't paying attention. > They happily accepted my money, but forgot to renew the domain. > > So here's trying to attach the files... That message appears for me only when I use xf86-video-vesa driver. -- Paul ___ 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"
