Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun, 17 Oct 2010, Garrett Cooper wrote: On Sun, Oct 17, 2010 at 6:16 PM, Doug Barton wrote: On 10/17/2010 4:49 PM, Rob Farmer wrote: I am running 256.53 on amd64 current (r213747). I don't use anything linux (the module isn't loaded) and built the driver with all options off except ACPI_PM. My custom kernel does not have "device agp". Hmm. I had all the options off except linux. I'll try with your combination and see if that improves things. I've given up on linux emulation support since 256.3x as it was the factor that was causing lockups on my two machines. Thanks. I tried again without linux support, no change, it still froze up. I suppose I can try again tomorrow without any of the options selected. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic in uma_startup for many-core amd64 system
on 23/09/2010 21:25 Andriy Gapon said the following: > > Jeff, > > just for the kicks I tried to emulate a machine with 64 logical CPUs using > qemu-devel port: > qemu-system-x86_64 -smp sockets=4,cores=8,threads=2 ... > > It seems that FreeBSD agreed to recognize only first 32 CPUs, but it paniced > anyway. > > Here's a backtrace: > #34 0x804fe7f5 in zone_alloc_item (zone=0x80be1554, > udata=0x80be1550, flags=1924) at /usr/src/sys/vm/uma_core.c:2506 > #35 0x804ff35d in hash_alloc (hash=0xff001ffdb030) at > /usr/src/sys/vm/uma_core.c:483 > #36 0x804ff642 in keg_ctor (mem=Variable "mem" is not available. > ) at /usr/src/sys/vm/uma_core.c:1396 > #37 0x804fe91b in zone_alloc_item (zone=0x80a1f300, > udata=0x80be1b60, flags=2) at /usr/src/sys/vm/uma_core.c:2544 > #38 0x804ff92e in zone_ctor (mem=Variable "mem" is not available. > ) at /usr/src/sys/vm/uma_core.c:1832 > #39 0x804ffca4 in uma_startup (bootmem=0xff001ffac000, > boot_pages=48) > at /usr/src/sys/vm/uma_core.c:1741 > #40 0x80514822 in vm_page_startup (vaddr=18446744071576817664) at > /usr/src/sys/vm/vm_page.c:360 > #41 0x805060c5 in vm_mem_init (dummy=Variable "dummy" is not > available. > ) at /usr/src/sys/vm/vm_init.c:118 > #42 0x803258b9 in mi_startup () at /usr/src/sys/kern/init_main.c:253 > #43 0x8017177c in btext () at /usr/src/sys/amd64/amd64/locore.S:81 > [[[ > Note: > 1. Frame numbers are high because the backtrace is obtained via gdb remotely > connected to qemu and also there is bunch of extra frames from DDB, etc. > 2. Line numbers in uma_core. won't match those in FreeBSD tree, because I've > doing > some unrelated hacking in the file. > ]]] > > The problem seems to be with creation of "UMA Zones" zone and keg. > Because of the large number of processors, size argument in the following > snippet > is set to a value of 4480: > > args.name = "UMA Zones"; > args.size = sizeof(struct uma_zone) + > (sizeof(struct uma_cache) * (mp_maxid + 1)); > > Because of this, keg_ctor() calls keg_large_init(): > > else if ((keg->uk_size+UMA_FRITM_SZ) > > (UMA_SLAB_SIZE - sizeof(struct uma_slab))) > keg_large_init(keg); > else > keg_small_init(keg); > > keg_large_init sets UMA_ZONE_OFFPAGE and UMA_ZONE_HASH flags for this keg. > This leads to hash_alloc() being invoked from keg_ctor(): > > if (keg->uk_flags & UMA_ZONE_HASH) > hash_alloc(&keg->uk_hash); > > But the problem is that "UMA Hash" zone is not created yet and thus the call > leads > to the panic. "UMA Hash" zone is the last of system zones created. > > Not sure what the proper fix here could/should be. > Would it work to simply not set UMA_ZONE_HASH flag when UMA_ZFLAG_INTERNAL is > set? > > > And some final calculations. > On the test system sizeof(struct uma_cache) is 128 bytes and (mp_maxid + 1) > is 32, > so it's already UMA_SLAB_SIZE = PAGE_SIZE = 4096. > Here is a simple solution that seems to work: http://people.freebsd.org/~avg/uma-many-cpus.diff Not sure if it's the best we can do. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun, Oct 17, 2010 at 6:16 PM, Doug Barton wrote: > On 10/17/2010 4:49 PM, Rob Farmer wrote: >> >> I am running 256.53 on amd64 current (r213747). I don't use anything >> linux (the module isn't loaded) and built the driver with all options >> off except ACPI_PM. My custom kernel does not have "device agp". > > Hmm. I had all the options off except linux. I'll try with your combination > and see if that improves things. I've given up on linux emulation support since 256.3x as it was the factor that was causing lockups on my two machines. Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
LOR vfs_lookup.c + ffs_softdep.c + vfs_subr.c
$ uname -a FreeBSD satanasso.local.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Oct 11 09: 10:51 CEST 2010 r...@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO i386 lock order reversal: 1st 0xc68ec278 ufs (ufs) @ /usr/src/sys/kern/vfs_lookup.c:501 2nd 0xd995fc70 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_softdep.c:11310 3rd 0xc6993278 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2111 KDB: stack backtrace: db_trace_self_wrapper(c0914c5e,632e7262,3131323a,a0d31,70656474,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c065397b,c0917dd0,c5921168,c5924b80,e837b320,...) at kdb_backtrace+0x2a _witness_debugger(c0917dd0,c6993278,c0909713,c5924b80,c091f023,...) at _witness_debugger+0x26 witness_checkorder(c6993278,9,c091f023,83f,0,...) at witness_checkorder+0x839 __lockmgr_args(c6993278,80100,c6993298,0,0,...) at __lockmgr_args+0x816 ffs_lock(e837b448,c066428b,c091e452,80100,80100,...) at ffs_lock+0x82 VOP_LOCK1_APV(c0991580,e837b448,c67de91c,c09a9c80,c6993220,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c6993220,80100,c091f023,83f,4,...) at _vn_lock+0x5e vget(c6993220,80100,c67de870,50,0,...) at vget+0xb9 vfs_hash_get(c67a4798,2e00b,8,c67de870,e837b59c,...) at vfs_hash_get+0xe6 ffs_vgetf(c67a4798,2e00b,8,e837b59c,1,...) at ffs_vgetf+0x49 softdep_sync_metadata(c68ec220,0,c093400a,144,0,...) at softdep_sync_metadata+0xc92 ffs_syncvnode(c68ec220,1,c67de870,e837b65c,246,...) at ffs_syncvnode+0x3e2 ffs_truncate(c68ec220,200,0,880,c595a300,...) at ffs_truncate+0x87b ufs_direnter(c68ec220,c6993220,e837b914,e837bba4,0,...) at ufs_direnter+0x8d4 ufs_makeinode(e837bba4,0,e837bb00,e837ba5c,c08b7b25,...) at ufs_makeinode+0x557 ufs_create(e837bb00,e837bb18,0,0,e837bb78,...) at ufs_create+0x30 VOP_CREATE_APV(c0991580,e837bb00,e837bba4,e837ba98,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(e837bb78,e837bc2c,1a4,0,c595a300,...) at vn_open_cred+0x220 vn_open(e837bb78,e837bc2c,1a4,c67f0508,0,...) at vn_open+0x3b kern_openat(c67de870,ff9c,804c608,0,602,...) at kern_openat+0x128 kern_open(c67de870,804c608,0,601,21b6,...) at kern_open+0x35 open(c67de870,e837bcec,e837bd28,c09166de,0,...) at open+0x30 syscallenter(c67de870,e837bce4,e837bce4,0,c09c3210,...) at syscallenter+0x263 syscall(e837bd28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (5, FreeBSD ELF32, open), eip = 0x2817485b, esp = 0xbfbfec0c, ebp = 0xbfbfec78 --- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
LOR kern_sig.c + vm_kern.c
$ uname -a FreeBSD satanasso.local.net 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Mon Oct 11 09: 10:51 CEST 2010 r...@satanasso.local.net:/usr/obj/usr/src/sys/SATANASSO i386 lock order reversal: 1st 0xc6befdd0 process lock (process lock) @ /usr/src/sys/kern/kern_sig.c:3341 2nd 0xc19b60e4 system map (system map) @ /usr/src/sys/vm/vm_kern.c:315 KDB: stack backtrace: db_trace_self_wrapper(c0914c5e,762f7379,6d762f6d,72656b5f,3a632e6e,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c065397b,c0917db7,c591d340,c591e110,e83d1764,...) at kdb_backtrace+0x2a _witness_debugger(c0917db7,c19b60e4,c0936364,c591e110,c09366a4,...) at _witness_debugger+0x26 witness_checkorder(c19b60e4,9,c09366a4,13b,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c19b60e4,0,c09366a4,13b,c1995e80,...) at _mtx_lock_flags+0xc4 _vm_map_lock(c19b6088,c09366a4,13b,c09359b5,c6725b40,...) at _vm_map_lock+0x31 kmem_malloc(c19b6088,1000,101,e83d1834,c083e233,...) at kmem_malloc+0x3a page_alloc(c5de4a80,1000,e83d1827,101,c5de4a80,...) at page_alloc+0x27 keg_alloc_slab(c1995e88,4,c09359b5,83b,e83d1874,...) at keg_alloc_slab+0xe3 keg_fetch_slab(101,8,c5e1ef24,e83d18d4,c084008d,...) at keg_fetch_slab+0x17e zone_fetch_slab(c5de4a80,c1995e80,101,7f1,c0663577,...) at zone_fetch_slab+0x4c uma_zalloc_arg(c5de4a80,0,101,e83d1918,c061d135,...) at uma_zalloc_arg+0x5dd ksiginfo_alloc(0,e83d1918,e83d1970,17,c6befd48,...) at ksiginfo_alloc+0x37 sigqueue_add(c6d14aa8,0,c09116ff,81f,2,...) at sigqueue_add+0x175 tdsendsignal(c6befd48,c6bf6000,17,e83d1970,0,...) at tdsendsignal+0x3ce psignal(c6befd48,17,c09116ff,d0d,c5922140,...) at psignal+0x47 pgsigio(c5a7c0e0,17,0,c5a7c000,e83d1a98,...) at pgsigio+0xf1 tty_wakeup(c5a7c000,1,c091a9ec,447,3,...) at tty_wakeup+0x44 ttydisc_rint_done(c5a7c000,7f,0,c0,0,...) at ttydisc_rint_done+0xa4 sysmouse_event(c67064c0,14,2,0,2,...) at sysmouse_event+0x210 sc_mouse_ioctl(c5a7bc00,c014630a,c67064c0,c6725b40,c090ac47,...) at sc_mouse_ioctl+0x2a6 sctty_ioctl(c5a7bc00,c014630a,c67064c0,c6725b40,e83d1bb4,...) at sctty_ioctl+0xa4 consolectl_ioctl(c5c97b00,c014630a,c67064c0,3,c6725b40,...) at consolectl_ioctl+0x29 giant_ioctl(c5c97b00,c014630a,c67064c0,3,c6725b40,...) at giant_ioctl+0x75 devfs_ioctl_f(c67ef000,c014630a,c67064c0,c595a300,c6725b40,...) at devfs_ioctl_f+0x10b kern_ioctl(c6725b40,4,c014630a,c67064c0,13d1cec,...) at kern_ioctl+0x20d ioctl(c6725b40,e83d1cec,e83d1d28,e83d1d80,0,...) at ioctl+0x12f syscallenter(c6725b40,e83d1ce4,e83d1d1c,c089cc06,74a,...) at syscallenter+0x263 syscall(e83d1d28) at syscall+0x34 Xint0x80_syscall() at Xint0x80_syscall+0x21 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281b179b, esp = 0xbfbfe98c, ebp = 0xbfbfeb18 --- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 2TB HDD = TIMEOUT - READ_DMA48 ....
on 14/10/2010 01:59 Darren Reed said the following: > As another body that today bought a 2TB HDD, I can confirm the presence > of kernel messages relating to READ_DMA48 with FreeBSD 8. Sounds like sector number possibly overflowing 32-bit integer. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 2TB HDD = TIMEOUT - READ_DMA48 ....
Hi, On Wed, Oct 13, 2010 at 3:59 PM, Darren Reed wrote: > As another body that today bought a 2TB HDD, I can confirm the presence > of kernel messages relating to READ_DMA48 with FreeBSD 8. > The drive in question is a Hitachi one, not a Samsung. > > Is it the drive, system or operating system? > > Well, the drive works without any such error with both Windows 7 and NetBSD > 5.1. > > So it looks like the finger is now pointing as a bug in FreeBSD... and if it > is fixed in HEAD then it needs to be merged into the branch for 8.1. Have you tried the new ahci(4) driver? What controller are you using by the way? Cheers, -- Xin LI http://www.delphij.net ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [PATCH] Netdump for review and testing -- preliminary version
On Fri, 15 Oct 2010, Robert N. M. Watson wrote: On 15 Oct 2010, at 20:39, Garrett Cooper wrote: But there are already some cases that aren't properly handled today in the ddb area dealing with dumping that aren't handled properly. Take for instance the following two scenarios: 1. Call doadump twice from the debugger. 2. Call doadump, exit the debugger, reenter the debugger, and call doadump again. Both of these scenarios hang reliably for me. I'm not saying that we should regress things further, but I'm just noting that there are most likely a chunk of edgecases that aren't being handled properly when doing dumps that could be handled better / fixed. Even thinking about calling doadump even once from within the debugger is an error. I was asleep when the similar error for panic was committed, and this error has propagated. Debuggers should use a trampoline to call the "any" function, not the least so that they can be used to debug the "any" function without the extra complications to make themself reentrant. I think gdb has always used a trampoline for this outside of the kernel. Not sure what it does within the kernel, but it would have even larger problems than in userland finding a place for the trampoline. In the kernel, there is the additional problem of keeping control while the "any" function is run. Other CPUs must be kept stopped and interrupts must be kept masked, except when the "any" function really needs other CPUs or unmasked interrupts. Single stepping also needs this and doesn't have it (other CPUs and interrupt handlers can run and execute any number of instructions while you are trying to execute a single one). All ddb "commands" that change the system state are really non-ddb commands that should use an external function via a trampoline. Panicing and dumping are just the largest ones, so they are the most impossible to do correctly as commands and the most in need of ddb to debug them. Right: one of the points I've made to Attilio is that we need to move to a more principled model as to what sorts of things we allow in various kernel environments. The early boot is a special environment -- so is the debugger, but the debugger on panic is not the same as the debugger when you can continue. Likewise, the crash dumping code is special, but also not the same as the debugger. Right now, exceptional behaviour to limit hangs/etc is done inconsistently. We need to develop a set of principles that tell us what is permitted in what contexts, and then use that to drive design decisions, normalizing what's there already. ENONUNIXEDITOR. Format not recovered. panic() from within a debugger (or a fast interrupt handler, or a fast interrupt handler that has trappeded to the debugger by request...) is, although an error, not too bad since panic() must be prepared to work starting from the "any" state anyway, and as you mention it doesn'tneed to be able to return (except for RESTARTABLE_PANICS, which makes things impossibly difficult). Continuing from a debugger is feasible mainly because in the usual case the system state is not changed (except for time-dependent things). If you use it to modify memory or i/o or run one of its unsafe commands then you have to be careful. This is not dissimilar to what we do with locking already, BTW: we define a set of kernel environments (fast interrupt handlers, non-sleepable threads, sleepable thread holding non-sleepable locks, etc), and based on those principles prevent significant sources of instability that might otherwise arise in a complex, concurrent kernel. We need to apply the same sort of approach to handling kernel debugging and crashing. Locking has imposed considerable discipline, which if followed by panic() would should how wrong most of the things done by panic() are -- it will hit locks, but shouldn't even be calling functions that have locks, since such functions expect their locks to work. The rules for fast interrupt handlers are simple and mostly not followed. They are that a fast interrupt handler may not access any state not specially locked by its subsystem. This means that they may not call any other subsystem or any upper layer except the null set of ones documented to be safe to call. In practice, this means not calling the "any" function, but it is necessary for atomic ops, bus space accesses, and a couple of scheduling functions to be safe enough. BTW, my view is that except in very exceptional cases, it should not be possible to continue after generating a dump. Dumps often cause disk controllers to get reset, which may leave outstanding I/O in nasty situations. Unless the dump device and model is known not to interfere with operation, we should set state indicating that the system is non-continuable once a dump has occurred. It might be safe if the system reinitialized everything. Too hard for just dumping, but it is needed after resume anyway. So the following could reason
2TB HDD = TIMEOUT - READ_DMA48 ....
As another body that today bought a 2TB HDD, I can confirm the presence of kernel messages relating to READ_DMA48 with FreeBSD 8. The drive in question is a Hitachi one, not a Samsung. Is it the drive, system or operating system? Well, the drive works without any such error with both Windows 7 and NetBSD 5.1. So it looks like the finger is now pointing as a bug in FreeBSD... and if it is fixed in HEAD then it needs to be merged into the branch for 8.1. Darren ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
DTrace bindings are missing in FreeBSD 9.0 - CURRENT for userland apps
Hey,
I am not 100% sure this is the right list to approach with this problem but
let's try this one.
So I am trying to use dtrace on the previously mentioned system, I followed
the usual kernel rebuild process using the following wiki:
http://wiki.freebsd.org/DTrace
Dtrace works fine and I am able to trace the kernel.[1]
My problem is: I can't trace any user land application including PostgreSQL
and Ruby.
I added the following lines to the /etc/make.conf as it is written in the
wiki:
STRIP=
CFLAGS+=-fno-omit-frame-pointer
I compiled both of the softwares and trying to trace them but there are no
bindings in the dtrace -l ouput
# dtrace -l | grep -i ruby
i might have overlooked something important but not sure what.
Any help is appreciated. Pls cc my email since i am not on this list.
Thank you in advance.
I.
1.
[r...@freebsd9 ~]# uname -a
FreeBSD freebsd9 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Oct 8 21:09:20 UTC
2010 r...@freebsd9:/usr/obj/usr/src/sys/DTRACE amd64
[r...@freebsd9 ~]# kldstat
Id Refs AddressSize Name
1 26 0x8010 f49bb0 kernel
21 0x81212000 ad8 dtraceall.ko
31 0x81213000 4a59 profile.ko
4 11 0x81218000 3e2f opensolaris.ko
53 0x8121c000 3db0 cyclic.ko
69 0x8122 13af4b dtrace.ko
71 0x8135b000 fce0 systrace.ko
81 0x8136b000 4128 sdt.ko
91 0x8137 44b8 lockstat.ko
101 0x81375000 b94e fasttrap.ko
111 0x81381000 61ab fbt.ko
121 0x81388000 4a67 dtnfsclient.ko
131 0x8138d000 4118 dtmalloc.ko
[r...@freebsd9 ~]#
[r...@freebsd9 ~]# cat d.d
vfs:namecache:enter:done
{
@distribution = quantize(strlen((string)arg1));
}
[r...@freebsd9 ~]# dtrace -s d.d
dtrace: script 'd.d' matched 1 probe
^C
value - Distribution - count
2 | 0
4 |@@@ 1
8 |@5
16 | 0
--
the sun shines for all
http://blog.l1x.me
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun, Oct 17, 2010 at 11:32:00PM +, Alexander Best wrote: > i'm running 256.52 on HEAD (amd64) without any issues. the 260.X drivers all > freze my computer when i exit X. > > it's quite easy to work around the isse that the nvidia drivers fail to > compile > on HEAD. simply change the line #if __FreeBSD_version >= 90 in > src/nv-freebsd.h to #if __FreeBSD_version >= 100. Or install from ports, which also patch the driver to support -CURRENT. ./danfe ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bge0 does not work anymore
my last known usable kernel revision is r213813 with r213920, leds are extinguished when executing dhclient On Mon, Oct 18, 2010 at 2:07 AM, Manfred Antar wrote: > At 09:06 AM 10/17/2010, Rainer Hurling wrote: >>I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays >>kernel the driver 'bge0' does not work anymore. With kernel from October 9th >>it does. >> >>The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. >>0x00a002; CHIP ID 0xa0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. >> >>The entry in /etc/rc.conf is 'ifconfig_bge0="DHCP". >> >>Does anyone else observe this behaviour? Is there something I can try? >> >>Thanks in advance, >>Rainer Hurling > > Same here, the last time it worked was Oct 14. with Current source. > uname -a : > FreeBSD pozo.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Oct 14 14:13:47 PDT > 2010 r...@pozo.com:/sys/i386/compile/COMPAQ i386 > i have ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0" in rc.conf > > == > || n...@pozo.com || > || Ph. (415) 681-6235 || > == > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is nvidia-driver 256.53 expected to work on -current?
On 10/17/2010 4:49 PM, Rob Farmer wrote: I am running 256.53 on amd64 current (r213747). I don't use anything linux (the module isn't loaded) and built the driver with all options off except ACPI_PM. My custom kernel does not have "device agp". Hmm. I had all the options off except linux. I'll try with your combination and see if that improves things. Thanks, Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is nvidia-driver 256.53 expected to work on -current?
On 18/10/2010 10:18, Ralph Ellis wrote: Doug Barton wrote: Y'all will probably recall that I had a lot of problems with the nvidia-driver, and video generally (esp. flash) on i386 -current. Well I haven't had any problems recently because I haven't been using FreeBSD. :) But I have things I need to catch up on, so here's what I did: 1. Bought a new hard drive, and installed a snapshot of amd64 -current (this was actually done a while ago). 2. Yesterday I started configuring stuff, updated my source and ports trees, rebuilt the world, customized the kernel, etc. 3. With a newly up to date system I built the latest version of the nvidia-driver port, and started using it. My experience with it has been exactly the same as older versions of the port on previous versions of i386 -current. Sometimes it runs fine for a while, but whe n I exit the window manager (openbox) the system hangs and I never get back to the command prompt. (I'm using startx to try and minimize the number of variables.) Sometimes it will work fine for an hour, maybe two, then the whole thing just hangs. All the stuff is displayed on the screen, but the mouse won't move, I can't zap X, or even switch to the console. I have to power off. This is particularly frustrating because I haven't even loaded flash (or for that matter firefox) yet. Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. Doug I am currently running the Nvidia 195 driver on amd64 9 - current from the ports tree. It works without problems. When I tried to compile the 256 driver, it would not compile and said that it was not meant to work with 9 - current. Hope this helps. Ralph Ellis ralphell...@netscape.ca I have not had any trouble with the new Nvidia drivers at all - but I'm running i386, so it might be an amd64 issue. No compilation issues at all, no problems running, switching to VT etc. (and yes, I had the same problems as Doug a while ago) Kernel and world are not from today, but fairly recent though: FreeBSD 9.0-CURRENT #48 r213491M: Thu Oct 7 See: (--) PCI:*(0:1:0:0) 10de:06e4:1458:349c nVidia Corporation G98 [GeForce 8400 GS] rev 161, Mem @ 0xf200/16777216, 0xe000/268435456, 0xf000/33554432, I/O @ 0x2100/128, BIOS @ 0x/65536 (II) "extmod" will be loaded by default. (II) "dbe" will be loaded by default. (II) "glx" will be loaded. This was enabled by default and also specified in the config file. (II) "record" will be loaded by default. (II) "dri" will be loaded by default. (II) "dri2" will be loaded by default. (II) LoadModule: "glx" (II) Loading /usr/local/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Server Extension (II) NVIDIA GLX Module 256.53 Fri Aug 27 20:49:59 PDT 2010 (II) Loading extension GLX (II) LoadModule: "extmod" (II) Loading /usr/local/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: "dbe" (II) Loading /usr/local/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "record" (II) Loading /usr/local/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: "dri" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: "dri2" (II) Loading /usr/local/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor="X.Org Foundation" compiled for 1.7.5, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (II) LoadModule: "nvidia" (II) Loading /usr/local/lib/xorg/modules/drivers/nvidia_drv.so (II) Module nvidia: vendor="
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun, Oct 17, 2010 at 16:18, Ralph Ellis wrote: > I am currently running the Nvidia 195 driver on amd64 9 - current from the > ports tree. It works without problems. > When I tried to compile the 256 driver, it would not compile and said that > it was not meant to work with 9 - current. Some necessary support was removed recently, but it has be re-added. See r213739. -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun, Oct 17, 2010 at 15:55, Doug Barton wrote: > Windows and linux (ubuntu, with the nvidia driver) work great on this same > hardware, so I'm pretty thoroughly convinced that the problem is with > freebsd/current somewhere. In addition to the -current partition I also > installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask > here first if anyone else was having problems on -current. I am running 256.53 on amd64 current (r213747). I don't use anything linux (the module isn't loaded) and built the driver with all options off except ACPI_PM. My custom kernel does not have "device agp". I use XFCE 4, don't really run anything graphically intense, and shutdown at night. I haven't had any problems, but IIRC from your past threads, the issues sort of build over time so I simply may not be aggravating the problem enough. The system is a HP Pavillion dv6405us laptop with a GeForce Go 6150. This is a pretty crappy card, even in Windows (the whole system was $500 3 years ago - it was one of those computers that supposedly was "Vista Ready" but could barely boot it), so I doubt I am gaining much over vesa though. -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is nvidia-driver 256.53 expected to work on -current?
On Sun Oct 17 10, Ralph Ellis wrote: > Doug Barton wrote: > >Y'all will probably recall that I had a lot of problems with the > >nvidia-driver, and video generally (esp. flash) on i386 -current. Well > >I haven't had any problems recently because I haven't been using > >FreeBSD. :) But I have things I need to catch up on, so here's what I > >did: > > > >1. Bought a new hard drive, and installed a snapshot of amd64 -current > >(this was actually done a while ago). > >2. Yesterday I started configuring stuff, updated my source and ports > >trees, rebuilt the world, customized the kernel, etc. > >3. With a newly up to date system I built the latest version of the > >nvidia-driver port, and started using it. > > > >My experience with it has been exactly the same as older versions of > >the port on previous versions of i386 -current. Sometimes it runs fine > >for a while, but whe n I exit the window manager (openbox) the system > >hangs and I never get back to the command prompt. (I'm using startx to > >try and minimize the number of variables.) Sometimes it will work fine > >for an hour, maybe two, then the whole thing just hangs. All the stuff > >is displayed on the screen, but the mouse won't move, I can't zap X, > >or even switch to the console. I have to power off. This is > >particularly frustrating because I haven't even loaded flash (or for > >that matter firefox) yet. > > > >Windows and linux (ubuntu, with the nvidia driver) work great on this > >same hardware, so I'm pretty thoroughly convinced that the problem is > >with freebsd/current somewhere. In addition to the -current partition > >I also installed amd64 8.1-RELEASE so I'll give that a go next, but I > >wanted to ask here first if anyone else was having problems on -current. > > > > > >Doug > > > I am currently running the Nvidia 195 driver on amd64 9 - current from > the ports tree. It works without problems. > When I tried to compile the 256 driver, it would not compile and said > that it was not meant to work with 9 - current. i'm running 256.52 on HEAD (amd64) without any issues. the 260.X drivers all freze my computer when i exit X. it's quite easy to work around the isse that the nvidia drivers fail to compile on HEAD. simply change the line #if __FreeBSD_version >= 90 in src/nv-freebsd.h to #if __FreeBSD_version >= 100. cheers. alex > Hope this helps. > Ralph Ellis > ralphell...@netscape.ca > > -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Is nvidia-driver 256.53 expected to work on -current?
Doug Barton wrote: Y'all will probably recall that I had a lot of problems with the nvidia-driver, and video generally (esp. flash) on i386 -current. Well I haven't had any problems recently because I haven't been using FreeBSD. :) But I have things I need to catch up on, so here's what I did: 1. Bought a new hard drive, and installed a snapshot of amd64 -current (this was actually done a while ago). 2. Yesterday I started configuring stuff, updated my source and ports trees, rebuilt the world, customized the kernel, etc. 3. With a newly up to date system I built the latest version of the nvidia-driver port, and started using it. My experience with it has been exactly the same as older versions of the port on previous versions of i386 -current. Sometimes it runs fine for a while, but whe n I exit the window manager (openbox) the system hangs and I never get back to the command prompt. (I'm using startx to try and minimize the number of variables.) Sometimes it will work fine for an hour, maybe two, then the whole thing just hangs. All the stuff is displayed on the screen, but the mouse won't move, I can't zap X, or even switch to the console. I have to power off. This is particularly frustrating because I haven't even loaded flash (or for that matter firefox) yet. Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. Doug I am currently running the Nvidia 195 driver on amd64 9 - current from the ports tree. It works without problems. When I tried to compile the 256 driver, it would not compile and said that it was not meant to work with 9 - current. Hope this helps. Ralph Ellis ralphell...@netscape.ca ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Is nvidia-driver 256.53 expected to work on -current?
Y'all will probably recall that I had a lot of problems with the nvidia-driver, and video generally (esp. flash) on i386 -current. Well I haven't had any problems recently because I haven't been using FreeBSD. :) But I have things I need to catch up on, so here's what I did: 1. Bought a new hard drive, and installed a snapshot of amd64 -current (this was actually done a while ago). 2. Yesterday I started configuring stuff, updated my source and ports trees, rebuilt the world, customized the kernel, etc. 3. With a newly up to date system I built the latest version of the nvidia-driver port, and started using it. My experience with it has been exactly the same as older versions of the port on previous versions of i386 -current. Sometimes it runs fine for a while, but when I exit the window manager (openbox) the system hangs and I never get back to the command prompt. (I'm using startx to try and minimize the number of variables.) Sometimes it will work fine for an hour, maybe two, then the whole thing just hangs. All the stuff is displayed on the screen, but the mouse won't move, I can't zap X, or even switch to the console. I have to power off. This is particularly frustrating because I haven't even loaded flash (or for that matter firefox) yet. Windows and linux (ubuntu, with the nvidia driver) work great on this same hardware, so I'm pretty thoroughly convinced that the problem is with freebsd/current somewhere. In addition to the -current partition I also installed amd64 8.1-RELEASE so I'll give that a go next, but I wanted to ask here first if anyone else was having problems on -current. Doug -- Breadth of IT experience, and| Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Setting up IPv6 in /etc/rc.conf
On Sat, Oct 16, 2010 at 3:15 AM, Mark Murray wrote: > "Bjoern A. Zeeb" writes: >> On Fri, 15 Oct 2010, Mark Murray wrote: >> >> > Alexey Shuvaev writes: >> >>> gifconfig_gif0_ipv6="2001:::::2 2001:::::1 >> >>> prefixlen 128" >> >> >> >> I suppose you should prefix it with "inet6" keyword. >> >> There are 2 examples in rc.conf (search for "Sample IPv6"). >> > >> > Ah! >> > >> > It didn't occur to me that I might need TWO inet6's! I'll give that a go >> > when >> > I play with this again tomorrow. >> >> It's just one inet6; put there what you would pass to ifconfig on the >> command line. The fact that ifconfig defaults to "inet" is the >> problem leading to more confusion. > > In which case, I'm back to square one. What should work doesn't. > > I have the necessary commands in /etc/rc.local to bring up IPv6. > >> I think the samples in defaults/rc.conf will be more clear soon. > > Cool! Thanks. You have a few syntax errors in your rc.conf, try these adjustments and everything "should" work (as it works for me on a recent CURRENT.) gif_interfaces="gif0" gifconfig_gif0="192.168.0.2 11.22.33.44" ifconfig_gif0_ipv6="inet6 2001:::::2 2001:::::1 prefixlen 128" ipv6_defaultrouter="2001:::::1" -- Chris - http://twitter.com/chrisattack http://chrisattack.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: bge0 does not work anymore
At 09:06 AM 10/17/2010, Rainer Hurling wrote: >I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays >kernel the driver 'bge0' does not work anymore. With kernel from October 9th >it does. > >The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. >0x00a002; CHIP ID 0xa0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. > >The entry in /etc/rc.conf is 'ifconfig_bge0="DHCP". > >Does anyone else observe this behaviour? Is there something I can try? > >Thanks in advance, >Rainer Hurling Same here, the last time it worked was Oct 14. with Current source. uname -a : FreeBSD pozo.com 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Thu Oct 14 14:13:47 PDT 2010 r...@pozo.com:/sys/i386/compile/COMPAQ i386 i have ifconfig_bge0="inet 192.168.0.5 netmask 255.255.255.0" in rc.conf == || n...@pozo.com || || Ph. (415) 681-6235 || == -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
bge0 does not work anymore
I am using FreeBSD 9.0-CURRENT (amd64) on a DELL Latitude D630. With todays kernel the driver 'bge0' does not work anymore. With kernel from October 9th it does. The network controller is a Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x00a002; CHIP ID 0xa0002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E. The entry in /etc/rc.conf is 'ifconfig_bge0="DHCP". Does anyone else observe this behaviour? Is there something I can try? Thanks in advance, Rainer Hurling ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FYI: ACPI buffer overflow
-- Forwarded Message -- Subject: Re: MacBookPro 5,1 Date: Sunday 17 October 2010, 15:47:56 From: Hans Petter Selasky To: freebsd-a...@freebsd.org CC: linux-a...@vger.kernel.org Hi, CC'ing the Linux guys, hence I belive you are using the same ACPI code like in FreeBSD. It appears that when a string is present in the extended interrupt descriptor (6.4.3.6, ACPIspec30.pdf), then this is not handled correctly, meaning that the precomputed buffer space when encoding to AML, is incorrect and that data is written beyond the destination buffer! The error is catched on a MacBookPro 5,1 and is visible if you zero-pad all ACPI allocations to 4096 bytes, and verify that the freed buffer is not written beyond the allocation. Also the Extended interrupt descriptor must be the last element encoded in the AML. The quick patch is to disable these elements. I tried to figure out why this happens, but this particular handling in the code looks very obfuscated to me. src/sys/contrib/dev/acpica %svk diff === resources/rsmisc.c == --- resources/rsmisc.c (revision 213698) +++ resources/rsmisc.c (local) @@ -311,6 +311,8 @@ case ACPI_RSC_SOURCEX: + break; /* RSC_SOURCEX is broken */ + /* * Optional ResourceSource (Index and String). This is the more * complicated case used by the Interrupt() macro @@ -537,6 +539,8 @@ case ACPI_RSC_SOURCEX: + break; /* RSC_SOURCEX is broken */ + /* * Optional ResourceSource (Index and String) */ Any comments are welcome! --HPS - ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
