Re: RFC: Optionally verbose SYSINIT
This would be awesome, please do it.
Scott
Benno Rice wrote:
One of the things that I found useful both in starting the PowerPC port
and in doing the XScale stuff I'm working on is making the SYSINIT stuff
done by mi_startup() verbose. This generally requires hacking your own
code into mi_startup() to print out which SYSINIT you're up to and the
like. jhb recently pointed me at this version he wrote which uses DDB
to look up the symbol corresponding to the SYSINIT in question which
makes it even more useful.
I would like to commit this version, which I've made optional based on a
VERBOSE_SYSINIT option, so as to make it available to anyone else
further down the line who's porting to a new architecture.
Comments? Questions?
Index: conf/options
===
RCS file: /home/ncvs/src/sys/conf/options,v
retrieving revision 1.540
diff -u -r1.540 options
--- conf/options7 May 2006 18:12:17 - 1.540
+++ conf/options11 May 2006 05:34:26 -
@@ -158,6 +158,7 @@
TURNSTILE_PROFILING
TTYHOG opt_tty.h
VFS_AIO
+VERBOSE_SYSINITopt_global.h
WLCACHEopt_wavelan.h
WLDEBUGopt_wavelan.h
Index: kern/init_main.c
===
RCS file: /home/ncvs/src/sys/kern/init_main.c,v
retrieving revision 1.262
diff -u -r1.262 init_main.c
--- kern/init_main.c7 Feb 2006 21:22:01 - 1.262
+++ kern/init_main.c11 May 2006 05:35:21 -
@@ -84,6 +84,9 @@
#include
#include
+#include
+#include
+
void mi_startup(void); /* Should be elsewhere */
/* Components of the first process -- never freed. */
@@ -169,6 +172,11 @@
register struct sysinit **xipp; /* interior loop of sort*/
register struct sysinit *save; /* bubble*/
+#if defined(VERBOSE_SYSINIT)
+ int last;
+ int verbose;
+#endif
+
if (sysinit == NULL) {
sysinit = SET_BEGIN(sysinit_set);
sysinit_end = SET_LIMIT(sysinit_set);
@@ -191,6 +199,14 @@
}
}
+#if defined(VERBOSE_SYSINIT)
+ last = SI_SUB_COPYRIGHT;
+ verbose = 0;
+#if !defined(DDB)
+ printf("VERBOSE_SYSINIT: DDB not enabled, symbol lookups disabled.\n");
+#endif
+#endif
+
/*
* Traverse the (now) ordered list of system initialization tasks.
* Perform each task, and continue on to the next task.
@@ -206,9 +222,38 @@
if ((*sipp)->subsystem == SI_SUB_DONE)
continue;
+#if defined(VERBOSE_SYSINIT)
+ if ((*sipp)->subsystem > last) {
+ verbose = 1;
+ last = (*sipp)->subsystem;
+ printf("subsystem %x\n", last);
+ }
+ if (verbose) {
+#if defined(DDB)
+ const char *name;
+ c_db_sym_t sym;
+ db_expr_t offset;
+
+ sym = db_search_symbol((vm_offset_t)(*sipp)->func,
+ DB_STGY_PROC, &offset);
+ db_symbol_values(sym, &name, NULL);
+ if (name != NULL)
+ printf(" %s(%p)... ", name, (*sipp)->udata);
+ else
+#endif
+ printf(" %p(%p)... ", (*sipp)->func,
+ (*sipp)->udata);
+ }
+#endif
+
/* Call function */
(*((*sipp)->func))((*sipp)->udata);
+#if defined(VERBOSE_SYSINIT)
+ if (verbose)
+ printf("done.\n");
+#endif
+
/* Check off the one we're just done */
(*sipp)->subsystem = SI_SUB_DONE;
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Xnu, and 'L4BSD'
L4Linux exists, but it seems to be more of a means for testing out and developing the L4 microkernel, but would there be any practical reason to sandbox the FreeBSD kernel and force it to run as a user- land service on top of the L4::Pistachio kernel? (for example) Well, you could do neat stuff like migrating VMs between machines 'on-the-fly', as described in the following paper: http://www.cl.cam.ac.uk/Research/SRG/netos/papers/2005-migration-nsdi-pre.pdf Also, L4::Pistachio is BSD-licensed. -- FreeBSD Developer, http://people.freebsd.org/~jkoshy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Heavy system load by pagedaemon
On Wed, 2006-05-10 at 11:49 -0500, Dan Nelson wrote: > In the last episode (May 10), Iasen Kostov said: > > On Wed, 2006-05-10 at 11:18 -0500, Dan Nelson wrote: > > > In the last episode (May 10), Iasen Kostov said: > > > > On Wed, 2006-05-10 at 15:32 +0300, Iasen Kostov wrote: > > > > > On Wed, 2006-05-10 at 15:28 +0300, Iasen Kostov wrote: > > > > > > I (probably) have some problem with a hosting server machine > > > > > > halting about once a 30 to minute (probably when the free > > > > > > memory falls under some threshold). At that moment the > > > > > > machine totally halts for about 5 sec then resumes normal > > > > > > work with load average around 9-15 (depends on system load) > > > > > > from about 2-3. The system is: > > > > > > (nice try :() > > > > > FreeBSD 6.1-PRERELEASE #7: Wed Mar 15 17:35:21 EET 2006 > > > > > > > > > > ACPI APIC Table: > > > > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > > > > CPU: Dual Core AMD Opteron(tm) Processor 270 (2004.56-MHz K8-class > > > > > CPU) > > > > >Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 > > > > > > > > > > Features=0x178bfbff > > > > >Features2=0x1 > > > > >AMD Features=0xe2500800,LM,3DNow+,3DNow> > > > > > real memory = 8724152320 (8320 MB) > > > > > avail memory = 8315379712 (7930 MB) > > > > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > > > > > > > Hum, I was probably wrong about the free memory threshold - it > > > > currently has ~1600MB of free and it is doing it again. When the > > > > free memory falls under ~30MB it is just doing it more > > > > frequently. > > > > > > Are you swapping? Paste in the output "top -o size". If you have > > > processes that are in the 1gb range, then when one exits you will > > > end up with a lot of "free" memory for a short period of time, and > > > it may try paging in another process that was completely paged out > > > (if you are low enough on RAM for that to have happened). That > > > could cause pagedaemon activity. > > > > > > > last pid: 81499; load averages: 4.55, 6.48, 7.06 > > up 39+02:03:35 19:20:24 > > 361 processes: 6 running, 340 sleeping, 15 waiting > > CPU states: 7.8% user, 0.0% nice, 5.6% system, 0.6% interrupt, 86.0% > > idle > > Mem: 3435M Active, 3422M Inact, 462M Wired, 357M Cache, 214M Buf, 63M Free > > Swap: 4096M Total, 1884K Used, 4094M Free > > Well, you're not swapping, which is good. > > > PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND > > 80053 mysql 8 200 467M 45904K kserel 0 2:01 0.00% mysqld > > 79134 nobody 1 40 243M 8332K sbwait 3 0:09 0.49% httpd > > 79402 nobody 1 40 243M 58332K sbwait 3 0:10 0.00% httpd > > 79341 nobody 1 40 242M 30156K sbwait 0 0:11 0.00% httpd > > 79283 nobody 1 40 242M 56796K accept 0 0:07 0.10% httpd > > 79281 nobody 1 -40 242M 63012K getblk 1 0:05 0.24% httpd > > 79917 nobody 1 40 242M 59636K sbwait 3 0:10 0.00% httpd > > ... > > > > httpds are eating 242MB because I'm using eaccelerator which allocates > > 100MB shared memory (or atleast that's what is in conf :) ) and I have > > ~400 users. > > I would have expected RES to be at least 100MB to account for that > shared memory, but I could be wrong. I don't have any suggestions on > your paging problem, though. > OK, if somebody can tell me - if this is normal for pagedaemon to lock the machine under heavy fragmentation and ~8G RAM or it's just FreeBSD pagedaemon is Crappy (or the whole VM ?) and can't handle it and I should explore other options (Linux, Solaris, older FreeBSD, other BSDs ?) or it is just a bug (it's ~2 month before release but it should be stable right ?). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: Optionally verbose SYSINIT
> This would be awesome, please do it. I agree, I've done something like this in a much more hackishly-way for the XBox port as well, but your code is much cleaner than mine was :-) Go for it, may others benefit from it! -- Rink P.W. Springer- http://rink.nu "Richter: Tribute? You steal men's souls, and make them your slaves! Dracula: Perhaps the same could be said of all religions." - Castlevania: Symphony of the Night ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exiting Xorg panics Core Duo laptop
John Baldwin wrote: On Tuesday 09 May 2006 16:34, Eric Anderson wrote: I have a Core Duo system (2 2GHz CPUs), that continually locks up (I believe it panics) when exiting xorg with both CPU's enabled. If I have: hint.apic.0.disabled="1" in device.hints, I only use one CPU, however it exits from xorg just fine. When the system locks, I still have some keyboard control (num lock lights, etc), but I can't seem to do anything else. I can't see the screen, it goes black during that time. All my system configs/dmesg/etc are here: Booted with apic not disabled: http://www.googlebit.com/freebsd/200605090613/ Booted with apic disabled: http://www.googlebit.com/freebsd/200605091117/ How can I debug (or help debug) this? What if you disable just SMP but leave APIC enabled (kern.smp.disabled=1)? If I disable only SMP and leave APIC enabled, everything seems to work fine. What other info can I give you? Thanks! Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
help:How to map a physical address into a kernel address?
Hi guys: To access sg_table in kernel address, I need to map the starting physical address of a segment into a kernel address. As I know that, we can use phystovirt()/bustovirt(), or kmap()/kmap_atomic() to map a bus/physical address or a physical page into a kernel address in Linux, but I did not find such a function in FreeBSD. Please help me on this, it is very urgent! Thanks a lot! Hong ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Atomic updates of NFS export lists
On Wed, May 10, 2006 at 04:36:24PM -0600, Scott Long wrote:
> >In my environment non-atomic updates of NFS export lists are not
> >acceptable. So, I decided to correct this problem. As the result
> >mountd, kern/vfs_export.c were completely rewritten, mount.h,
> >vfs_mount.c and nfs_srvsubs.c also got changes.
> >
> >For details see kern/9619.
> >
>
> I've been looking at this since my company is also running into these
> problems. I've integrated your patchset into my tree, and I'll let you
> know how it works after a few days of testing. One thing to note is
> that you've significantly re-written much of mountd, as well as changed
> the API/ABI a bit and removed some command line switches.
I removed only the "-p " option from mountd. Initially I added
several options for mountd to allow to specify UDP, TCP services,
addresses and ports, but that gave many lines of code. One of examples
of such code is located in nfsd.c.
Sockconf library allows in a configuration file to specify all settings
for sockets and an application can use getsockconf() function for getting
all settings in a linked list (similar to the result of the getaddrinfo()
function).
One new important option is -t, which allows to check exports file
and dump parsed configuration. I thought about changing format of
exports file, but decided to not change anything (almost).
> That makes it
> less attractive for inclusion in RELENG_6, but is fine for 7-CURRENT.
> With that in mind, you should switch over to using nmount() instead of
> mount(), that way you can completely remove the per-filesystem handling
> code that you added.
What about using nfssvc(2) for this task?
Yes it is possible to use nmount() and remove export_args from all
filesystems, and remove mount_arg("export"...) from all vfs_cmount()
implementation, but...
New version of mountd is very strict about errors and does not ignore
them. There is a race condition between parsing exports file, passing
parsed configuration to the kernel and mounting/umounting filesystems.
It is possible to make mount(8), umount(8) and mountd(8) to work
synchronous, but this will require changing of mount(8) and umount(8).
In current implementation there are several situations when mountd
can exit with error, e.g. a filesystem was mounted and exported,
then it was unmounted and mountd rereads exports file, since old
filesystem does not exist any more, mountd will report about error
(the kernel will refuse to clear export list for non-existent
filesystem) and exit. This problem exist before.
This question must be discussed.
> If there is any way that you can trim the changes to just implement the
> new export primitives and leave out the libsock stuff, it would be much
> easier to justify getting into RELENG_6.
This will make code a bit complex as it is now... The idea of
sockconf library is to simplify some part of code in applications.
> I don't have an opinion on the
> libsock design, but you should talk to people like Robert Watson about
> that before this goes into 7-CURRENT.
Can you and others also discuss "open questions" from the first letter?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: help:How to map a physical address into a kernel address?
[EMAIL PROTECTED] wrote this message on Thu, May 11, 2006 at 17:45 +0800: > To access sg_table in kernel address, I need to map the starting physical > address of a segment into a kernel address. As I know that, we can use > phystovirt()/bustovirt(), or kmap()/kmap_atomic() to map a bus/physical > address or a physical page into a kernel address in Linux, but I did not > find such a function in FreeBSD. Please help me on this, it is very urgent! That's what bus_space is used for... You need to allocate the resource that contains the sg_table, and then you can use the bus_space macros to access the table.. you could use bus_space_write_region to copy the table from kernel memory to your device, or just write the updated values... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Heavy system load by pagedaemon
On Wed, 2006-05-10 at 15:43 +0300, Iasen Kostov wrote: > On Wed, 2006-05-10 at 15:32 +0300, Iasen Kostov wrote: > > On Wed, 2006-05-10 at 15:28 +0300, Iasen Kostov wrote: > > > Hello > > > I (probably) have some problem with a hosting server machine halting > > > about once a 30 to minute (probably when the free memory falls under > > > some threshold). At that moment the machine totally halts for about 5 sec > > > then resumes normal work with load average around 9-15 (depends on > > > system load) from about 2-3. The system is: > > > (nice try :() > > FreeBSD 6.1-PRERELEASE #7: Wed Mar 15 17:35:21 EET 2006 > > > > ACPI APIC Table: > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Dual Core AMD Opteron(tm) Processor 270 (2004.56-MHz K8-class CPU) > >Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 > > > > Features=0x178bfbff > >Features2=0x1 > >AMD Features=0xe2500800,LM,3DNow+,3DNow> > > real memory = 8724152320 (8320 MB) > > avail memory = 8315379712 (7930 MB) > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > Hum, I was probably wrong about the free memory threshold - it > currently has ~1600MB of free and it is doing it again. When the free > memory falls under ~30MB it is just doing it more frequently. > And another odd thing (to me atleast): ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Heavy system load by pagedaemon
On Wed, 2006-05-10 at 15:43 +0300, Iasen Kostov wrote: > On Wed, 2006-05-10 at 15:32 +0300, Iasen Kostov wrote: > > On Wed, 2006-05-10 at 15:28 +0300, Iasen Kostov wrote: > > > Hello > > > I (probably) have some problem with a hosting server machine halting > > > about once a 30 to minute (probably when the free memory falls under > > > some threshold). At that moment the machine totally halts for about 5 sec > > > then resumes normal work with load average around 9-15 (depends on > > > system load) from about 2-3. The system is: > > > (nice try :() > > FreeBSD 6.1-PRERELEASE #7: Wed Mar 15 17:35:21 EET 2006 > > > > ACPI APIC Table: > > Timecounter "i8254" frequency 1193182 Hz quality 0 > > CPU: Dual Core AMD Opteron(tm) Processor 270 (2004.56-MHz K8-class CPU) > >Origin = "AuthenticAMD" Id = 0x20f12 Stepping = 2 > > > > Features=0x178bfbff > >Features2=0x1 > >AMD Features=0xe2500800,LM,3DNow+,3DNow> > > real memory = 8724152320 (8320 MB) > > avail memory = 8315379712 (7930 MB) > > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > > > Hum, I was probably wrong about the free memory threshold - it > currently has ~1600MB of free and it is doing it again. When the free > memory falls under ~30MB it is just doing it more frequently. > And another odd thing (to me atleast): #:> vmstat -s | grep "daemon\|fault" 0 page daemon wakeups 0 pages examined by the page daemon 4992608 copy-on-write faults 29021 copy-on-write optimized faults 75167 intransit blocking page faults 66956262 total VM faults taken 0 pages freed by daemon Acording to vmstat pagedaemon has never been awake. But after every 5 sec. lock I can see it eating ~25% of cpu (100/4 cpus) and I can see processes in "*Giant" and "*vm ob" states. Worst thing it that the machine is freshly rebooted and it was doing it even with ~6G of free RAM and no swapping at all. Kamal R. Prasad suggested that "Belady's anomaly" might occur. If it's true or possible what could be done about this ? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
enabling hyper-threading on intel dual-core
hi! i just bought an Intel Pentium D-930 (3ghz dual-core) and wonder why i just only have CPU0 and CPU1, when i compile with SMP... sysctl says: machdep.cpu_idle_hlt: 0 is it right or i should see CPU 2 and 3 starting during the boot? thanks for your help! ps: i even compiled this option in kernel, can't see any change options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: enabling hyper-threading on intel dual-core
I think intel chips with dual core don't have hyperthreading. The operating system sees the second core like it would with hyperthreading only. On May 11, 2006, at 12:00 PM, OxY wrote: hi! i just bought an Intel Pentium D-930 (3ghz dual-core) and wonder why i just only have CPU0 and CPU1, when i compile with SMP... sysctl says: machdep.cpu_idle_hlt: 0 is it right or i should see CPU 2 and 3 starting during the boot? thanks for your help! ps: i even compiled this option in kernel, can't see any change options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance- [EMAIL PROTECTED]" Lucas Holt [EMAIL PROTECTED] FoolishGames.com (Jewel Fan Site) JustJournal.com (Free blogging) FoolishGames.net (Enemy Territory site) ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: enabling hyper-threading on intel dual-core
thanks a lot for your help! - Original Message - From: "Shane Ambler" <[EMAIL PROTECTED]> To: "FreeBSD Mailing Lists" Sent: Thursday, May 11, 2006 7:34 PM Subject: Re: enabling hyper-threading on intel dual-core On 12/5/2006 1:30, "OxY" <[EMAIL PROTECTED]> wrote: hi! i just bought an Intel Pentium D-930 (3ghz dual-core) and wonder why i just only have CPU0 and CPU1, when i compile with SMP... sysctl says: machdep.cpu_idle_hlt: 0 is it right or i should see CPU 2 and 3 starting during the boot? thanks for your help! ps: i even compiled this option in kernel, can't see any change options MPTABLE_FORCE_HTT # Enable HTT CPUs with the MP Table ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]" Sounds right to me - the 930 is a dual core and will show up as two cpu's cpu0 and cpu1. The early dual core's don't support hyperthreading - the Pentium-D extreme edition does (Pentium D-955 at 3.46Ghz is one) and will show up as 4 cpu's. Currently at 3x the price. -- Shane Ambler [EMAIL PROTECTED] ___ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: About amd64 dualcore problems with two SATA disks and nforce4
Hello, A few months ago I pointed out a problem with AMD64 dualcore, and I even tracked the problem down to a few commits at a particular date and time... Now that 6.1 is finally released, I tried it, and the problem is still there... the boot process will crash when detecting the second SATA disk in my system... If there is anything I can do to help fix that problem (like testing and such), please let me know... - Daniel --- Daniel Valencia <[EMAIL PROTECTED]> wrote: > Hi, > > Well... Hopeful with your mailings, I updated the > kernel (cvsup) and rebuilt it... the problem's still > there... detects one SATA disk (ad4) and crashes > before acknowledging the second (ad6)... > > - Daniel > > > S�ren Schmidt <[EMAIL PROTECTED]> wrote: Daniel > Valencia wrote: > > Hi, > > > > So, what's your last src/ cvsup date/time? is your > machine dualcore? if > > so, are you building using the SMP option? > > yep: > > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ > (2412.37-MHz > K8-class CPU) > > and yep: > > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > > > mine breaks when in SMP mode... in GENERIC it > works, just it doesn't > > detect the second SATA disk > > Well, no problems here with that, the nve interface > is something else > though :) > > -S�ren > > > > - Daniel > > > > > > */S�ren Schmidt /* wrote: > > > > Daniel Valencia wrote: > > > Hello, > > > > > > I started a short thread a few weeks ago, > pointing out a problem > > with my dualcore athlon64, when detecting the > second SATA disk > > (/dev/ad6)... my chipset is an nForce4... The > problem was narrowed > > down to a few commits performed at a > particular date and time. My > > questions are: is it safe to update my kernel > now? have those > > problems been fixed? is there something I can > do to help (like > > testing or so)? > > > > > For whatever its worth my NF4 board finds all > 4 SATA disks perfectly > > both in i386 and amd64 mode: > > > > atapci0: port > > > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe000-0xe00f at > device 6.0 on pci0 > > ata0: on atapci0 > > ata1: on atapci0 > > atapci1: port > > > 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xcc00-0xcc0f > mem > > 0xfe02b000-0xfe02bfff irq 21 at device 7.0 on > pci0 > > ata2: on atapci1 > > ata3: on atapci1 > > atapci2: port > > > 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xb800-0xb80f > mem > > 0xfe02a000-0xfe02afff irq 22 at device 8.0 on > pci0 > > ata4: on atapci2 > > ata5: on atapci2 > > ad0: 38166MB at ata0-master UDMA100 > > ad1: 78533MB at ata2-master SATA300 > > ad2: 78533MB at ata3-master SATA300 > > ad3: 70911MB at ata4-master SATA150 > > ad4: 70911MB at ata5-master SATA150 > > atausb0: > > addr 2> on uhub1 > > atausb0: using SCSI over Bulk-Only > > ata6: on atausb0 > > acd0: CDRW at ata6-master USB2 > > Trying to mount root from ufs:/dev/ad0s1a > > > > -S�ren > > > > > > > > > Yahoo! Mail > > Bring photos to life! New PhotoMail > > > > makes sharing a breeze. > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > > > > - > Yahoo! Mail > Bring photos to life! New PhotoMail makes sharing a > breeze. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "[EMAIL PROTECTED]" > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: enabling hyper-threading on intel dual-core
930 is perfect, fast enough, no need to spend more money, thanks :) - Original Message - From: "Achim Patzner" <[EMAIL PROTECTED]> To: "OxY" <[EMAIL PROTECTED]> Cc: ; Sent: Thursday, May 11, 2006 8:16 PM Subject: Re: enabling hyper-threading on intel dual-core i just bought an Intel Pentium D-930 (3ghz dual-core) and wonder why i just only have CPU0 and CPU1, when i compile with SMP... You would need a Pentium Extreme (840, 955 or 965) for this. And quite a bit of cash. Achim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: enabling hyper-threading on intel dual-core
i just bought an Intel Pentium D-930 (3ghz dual-core) and wonder why i just only have CPU0 and CPU1, when i compile with SMP... You would need a Pentium Extreme (840, 955 or 965) for this. And quite a bit of cash. Achim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exiting Xorg panics Core Duo laptop
Eric Anderson wrote: John Baldwin wrote: On Tuesday 09 May 2006 16:34, Eric Anderson wrote: I have a Core Duo system (2 2GHz CPUs), that continually locks up (I believe it panics) when exiting xorg with both CPU's enabled. If I have: hint.apic.0.disabled="1" in device.hints, I only use one CPU, however it exits from xorg just fine. When the system locks, I still have some keyboard control (num lock lights, etc), but I can't seem to do anything else. I can't see the screen, it goes black during that time. All my system configs/dmesg/etc are here: Booted with apic not disabled: http://www.googlebit.com/freebsd/200605090613/ Booted with apic disabled: http://www.googlebit.com/freebsd/200605091117/ How can I debug (or help debug) this? What if you disable just SMP but leave APIC enabled (kern.smp.disabled=1)? If I disable only SMP and leave APIC enabled, everything seems to work fine. What other info can I give you? I was able to get a backtrace, and a core from this. Here's some details: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc6263000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0d89e43 stack pointer = 0x28:0xe590d4a4 frame pointer = 0x28:0xe590d4bc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 3 current process = 790 (Xorg) [thread pid 790 tid 100057 ] Stopped at _nv002872rm+0x4b: movl0(%edx,%eax,4),%ebx db> bt Tracing pid 790 tid 100057 td 0xc55b4a80 _nv002872rm(c5e2c000,c5b15d00,0,408000,c5e2c000) at _nv002872rm+0x4b _nv004617rm(c5e2c000,c52d2800,1f,e590d704,20) at _nv004617rm+0x617 _nv004359rm(c5e2c000,c52d2800,e590d704,0,3d0900) at _nv004359rm+0x123 _nv004373rm(c5e2c000,c52d2800,0,c53ac400,4) at _nv004373rm+0x38 _nv003961rm(c5e2c000,c0e8b250,18,c0d38b2a,c5e2c000) at _nv003961rm+0x58 _nv003962rm(c5e2c000,c5e35000,0,c0bfdd56,c53919c0) at _nv003962rm+0x5a _nv008284rm(c53d6700,4,e590d7dc,c0c04a7e,c53919c0) at _nv008284rm+0xe5 rm_disable_adapter(c53d6700,0,c576dc00,c53d6600,c53d6700) at rm_disable_adapter+0x55 nvidia_close_dev(c53d6600,c53d6800,c55b4a80,4,c53d6800) at nvidia_close_dev+0x63 nvidia_dev_close(c53d6800,3,2000,c55b4a80,c068d154) at nvidia_dev_close+0x4b giant_close(c53d6800,3,2000,c55b4a80,0) at giant_close+0x4c devfs_close(e590d890,e590d8bc,c073e868,c09d19e0,e590d890) at devfs_close+0x240 VOP_CLOSE_APV(c09d19e0,e590d890,c55b4a80,c5784400,c0a22140) at VOP_CLOSE_APV+0x36 vn_close(c5e10440,3,c5de6380,c55b4a80,e590d900) at vn_close+0x78 vn_closefile(c581c558,c55b4a80,0,c5e2c000,c64a5620) at vn_closefile+0x92 fdrop_locked(c581c558,c55b4a80,c5e2c000,2e,e590d980,0,0,c58b1800,e590d9a0,c0d380f4,c53ac400,c5e2c000,e590d5 closef(c581c558,c55b4a80,ff,c55b4bd4,c5d0e380) at closef+0x382 fdfree(c55b4a80,c09d68a0,2,0,c5de4168) at fdfree+0x28b exit1(c55b4a80,9,0,0,e590dae8) at exit1+0x40a sigexit(c55b4a80,9,100,0,0) at sigexit+0x72 ast(e590dd38) at ast+0x47c doreti_ast() at doreti_ast+0x17 What else can I do? Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exiting Xorg panics Core Duo laptop
On Thursday 11 May 2006 16:45, Eric Anderson wrote: > Eric Anderson wrote: > > John Baldwin wrote: > >> On Tuesday 09 May 2006 16:34, Eric Anderson wrote: > >>> I have a Core Duo system (2 2GHz CPUs), that continually locks up (I > >>> believe it panics) when exiting xorg with both CPU's enabled. If I > >>> have: > >>> > >>> hint.apic.0.disabled="1" > >>> > >>> in device.hints, I only use one CPU, however it exits from xorg just > >>> fine. When the system locks, I still have some keyboard control (num > >>> lock lights, etc), but I can't seem to do anything else. I can't see > >>> the screen, it goes black during that time. All my system > >>> configs/dmesg/etc are here: > >>> > >>> Booted with apic not disabled: > >>> http://www.googlebit.com/freebsd/200605090613/ > >>> > >>> Booted with apic disabled: > >>> http://www.googlebit.com/freebsd/200605091117/ > >>> > >>> How can I debug (or help debug) this? > >> > >> What if you disable just SMP but leave APIC enabled > >> (kern.smp.disabled=1)? > > > > If I disable only SMP and leave APIC enabled, everything seems to work > > fine. What other info can I give you? > > I was able to get a backtrace, and a core from this. Here's some details: > > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0xc6263000 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0d89e43 > stack pointer = 0x28:0xe590d4a4 > frame pointer = 0x28:0xe590d4bc > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 3 > current process = 790 (Xorg) > [thread pid 790 tid 100057 ] > Stopped at _nv002872rm+0x4b: movl0(%edx,%eax,4),%ebx > db> bt > Tracing pid 790 tid 100057 td 0xc55b4a80 > _nv002872rm(c5e2c000,c5b15d00,0,408000,c5e2c000) at _nv002872rm+0x4b > _nv004617rm(c5e2c000,c52d2800,1f,e590d704,20) at _nv004617rm+0x617 > _nv004359rm(c5e2c000,c52d2800,e590d704,0,3d0900) at _nv004359rm+0x123 > _nv004373rm(c5e2c000,c52d2800,0,c53ac400,4) at _nv004373rm+0x38 > _nv003961rm(c5e2c000,c0e8b250,18,c0d38b2a,c5e2c000) at _nv003961rm+0x58 > _nv003962rm(c5e2c000,c5e35000,0,c0bfdd56,c53919c0) at _nv003962rm+0x5a > _nv008284rm(c53d6700,4,e590d7dc,c0c04a7e,c53919c0) at _nv008284rm+0xe5 > rm_disable_adapter(c53d6700,0,c576dc00,c53d6600,c53d6700) at > rm_disable_adapter+0x55 > nvidia_close_dev(c53d6600,c53d6800,c55b4a80,4,c53d6800) at > nvidia_close_dev+0x63 > nvidia_dev_close(c53d6800,3,2000,c55b4a80,c068d154) at > nvidia_dev_close+0x4b giant_close(c53d6800,3,2000,c55b4a80,0) at > giant_close+0x4c > devfs_close(e590d890,e590d8bc,c073e868,c09d19e0,e590d890) at > devfs_close+0x240 > VOP_CLOSE_APV(c09d19e0,e590d890,c55b4a80,c5784400,c0a22140) at > VOP_CLOSE_APV+0x36 > vn_close(c5e10440,3,c5de6380,c55b4a80,e590d900) at vn_close+0x78 > vn_closefile(c581c558,c55b4a80,0,c5e2c000,c64a5620) at vn_closefile+0x92 > fdrop_locked(c581c558,c55b4a80,c5e2c000,2e,e590d980,0,0,c58b1800,e590d9a0,c >0d380f4,c53ac400,c5e2c000,e590d5 > closef(c581c558,c55b4a80,ff,c55b4bd4,c5d0e380) at closef+0x382 > fdfree(c55b4a80,c09d68a0,2,0,c5de4168) at fdfree+0x28b > exit1(c55b4a80,9,0,0,e590dae8) at exit1+0x40a > sigexit(c55b4a80,9,100,0,0) at sigexit+0x72 > ast(e590dd38) at ast+0x47c > doreti_ast() at doreti_ast+0x17 > > > What else can I do? Well, it's a problem with the nvidia-driver module. Are you sure that the nvidia-driver is up to date and in sync with your world + kernel? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1 Released
On 2006.05.09 01:00:14 -0400, Mike Jakubik wrote: > Julian Elischer wrote: [...] > >the above points to a filel that says "6.0 errata" > > Indeed. Where is the mention of current quota/bge/em/ufs problems? Don't > tell me these will be shoved under the rug. Send patches. -- Simon L. Nielsen pgpdIZZE2L9Q8.pgp Description: PGP signature
Re: Exiting Xorg panics Core Duo laptop
On Thursday 11 May 2006 07:41, Eric Anderson wrote: > John Baldwin wrote: > > On Tuesday 09 May 2006 16:34, Eric Anderson wrote: > >> I have a Core Duo system (2 2GHz CPUs), that continually locks up (I > >> believe it panics) when exiting xorg with both CPU's enabled. If I > >> have: > >> > >> hint.apic.0.disabled="1" > >> > >> in device.hints, I only use one CPU, however it exits from xorg just > >> fine. When the system locks, I still have some keyboard control (num > >> lock lights, etc), but I can't seem to do anything else. I can't see > >> the screen, it goes black during that time. All my system > >> configs/dmesg/etc are here: > >> > >> Booted with apic not disabled: > >> http://www.googlebit.com/freebsd/200605090613/ > >> > >> Booted with apic disabled: > >> http://www.googlebit.com/freebsd/200605091117/ > >> > >> How can I debug (or help debug) this? > > > > What if you disable just SMP but leave APIC enabled > > (kern.smp.disabled=1)? > > If I disable only SMP and leave APIC enabled, everything seems to work > fine. What other info can I give you? Ok, that helps to narrow it down. Can you hook up a serial console and obtain the panic messages along with a stack trace as described in the handbook? -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1 Released
On 2006.05.11 20:53:42 -0400, Mike Jakubik wrote: > Simon L. Nielsen wrote: > >On 2006.05.09 01:00:14 -0400, Mike Jakubik wrote: > > > >>Julian Elischer wrote: > >> > >[...] > > > >>>the above points to a filel that says "6.0 errata" > >>> > >>Indeed. Where is the mention of current quota/bge/em/ufs problems? Don't > >>tell me these will be shoved under the rug. > >> > > > >Send patches. > > > > Patches? For what? [...] For the errata page, which was what the above text mentioned. -- Simon L. Nielsen pgpD9OAM14iWo.pgp Description: PGP signature
Re: Exiting Xorg panics Core Duo laptop
John Baldwin wrote: On Thursday 11 May 2006 16:45, Eric Anderson wrote: Eric Anderson wrote: John Baldwin wrote: On Tuesday 09 May 2006 16:34, Eric Anderson wrote: I have a Core Duo system (2 2GHz CPUs), that continually locks up (I believe it panics) when exiting xorg with both CPU's enabled. If I have: hint.apic.0.disabled="1" in device.hints, I only use one CPU, however it exits from xorg just fine. When the system locks, I still have some keyboard control (num lock lights, etc), but I can't seem to do anything else. I can't see the screen, it goes black during that time. All my system configs/dmesg/etc are here: Booted with apic not disabled: http://www.googlebit.com/freebsd/200605090613/ Booted with apic disabled: http://www.googlebit.com/freebsd/200605091117/ How can I debug (or help debug) this? What if you disable just SMP but leave APIC enabled (kern.smp.disabled=1)? If I disable only SMP and leave APIC enabled, everything seems to work fine. What other info can I give you? I was able to get a backtrace, and a core from this. Here's some details: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc6263000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0d89e43 stack pointer = 0x28:0xe590d4a4 frame pointer = 0x28:0xe590d4bc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 3 current process = 790 (Xorg) [thread pid 790 tid 100057 ] Stopped at _nv002872rm+0x4b: movl0(%edx,%eax,4),%ebx db> bt Tracing pid 790 tid 100057 td 0xc55b4a80 _nv002872rm(c5e2c000,c5b15d00,0,408000,c5e2c000) at _nv002872rm+0x4b _nv004617rm(c5e2c000,c52d2800,1f,e590d704,20) at _nv004617rm+0x617 _nv004359rm(c5e2c000,c52d2800,e590d704,0,3d0900) at _nv004359rm+0x123 _nv004373rm(c5e2c000,c52d2800,0,c53ac400,4) at _nv004373rm+0x38 _nv003961rm(c5e2c000,c0e8b250,18,c0d38b2a,c5e2c000) at _nv003961rm+0x58 _nv003962rm(c5e2c000,c5e35000,0,c0bfdd56,c53919c0) at _nv003962rm+0x5a _nv008284rm(c53d6700,4,e590d7dc,c0c04a7e,c53919c0) at _nv008284rm+0xe5 rm_disable_adapter(c53d6700,0,c576dc00,c53d6600,c53d6700) at rm_disable_adapter+0x55 nvidia_close_dev(c53d6600,c53d6800,c55b4a80,4,c53d6800) at nvidia_close_dev+0x63 nvidia_dev_close(c53d6800,3,2000,c55b4a80,c068d154) at nvidia_dev_close+0x4b giant_close(c53d6800,3,2000,c55b4a80,0) at giant_close+0x4c devfs_close(e590d890,e590d8bc,c073e868,c09d19e0,e590d890) at devfs_close+0x240 VOP_CLOSE_APV(c09d19e0,e590d890,c55b4a80,c5784400,c0a22140) at VOP_CLOSE_APV+0x36 vn_close(c5e10440,3,c5de6380,c55b4a80,e590d900) at vn_close+0x78 vn_closefile(c581c558,c55b4a80,0,c5e2c000,c64a5620) at vn_closefile+0x92 fdrop_locked(c581c558,c55b4a80,c5e2c000,2e,e590d980,0,0,c58b1800,e590d9a0,c 0d380f4,c53ac400,c5e2c000,e590d5 closef(c581c558,c55b4a80,ff,c55b4bd4,c5d0e380) at closef+0x382 fdfree(c55b4a80,c09d68a0,2,0,c5de4168) at fdfree+0x28b exit1(c55b4a80,9,0,0,e590dae8) at exit1+0x40a sigexit(c55b4a80,9,100,0,0) at sigexit+0x72 ast(e590dd38) at ast+0x47c doreti_ast() at doreti_ast+0x17 What else can I do? Well, it's a problem with the nvidia-driver module. Are you sure that the nvidia-driver is up to date and in sync with your world + kernel? I've just downloaded the latest driver from nvidia's website (not yet in ports), and installed it. It seems to work just fine! Thanks, now we just need to have somebody update the port.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1 Released
Mike Jakubik wrote: Patches? For what? It's too late now, 6.1 has been released. I sent reminders to the RE team and i made it quite clear on the lists that the quota issue should be described in the relnotes/errata before the release. If the RE team chooses to ignore major bugs and pretend all is fine and dandy, then there is not much patches will do. Heck, im still waiting for Scott to personally fix the problems, as he so graciously offered, but couldn't deliver. I offered to work with him and provide help, he never replied to my emails. I'm almost afraid to enter into this discussion (puts on flame suit), but might it be better to gently encourage the re/development team to make some of these a priority for 6.2? (as that gives everyone more lead time, and in the end what we all want is FreeBSD to steadily improve). Cheers Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1 Released
Simon L. Nielsen wrote: On 2006.05.09 01:00:14 -0400, Mike Jakubik wrote: Julian Elischer wrote: [...] the above points to a filel that says "6.0 errata" Indeed. Where is the mention of current quota/bge/em/ufs problems? Don't tell me these will be shoved under the rug. Send patches. Patches? For what? It's too late now, 6.1 has been released. I sent reminders to the RE team and i made it quite clear on the lists that the quota issue should be described in the relnotes/errata before the release. If the RE team chooses to ignore major bugs and pretend all is fine and dandy, then there is not much patches will do. Heck, im still waiting for Scott to personally fix the problems, as he so graciously offered, but couldn't deliver. I offered to work with him and provide help, he never replied to my emails. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Exiting Xorg panics Core Duo laptop
John Baldwin wrote: On Thursday 11 May 2006 16:45, Eric Anderson wrote: Eric Anderson wrote: John Baldwin wrote: On Tuesday 09 May 2006 16:34, Eric Anderson wrote: I have a Core Duo system (2 2GHz CPUs), that continually locks up (I believe it panics) when exiting xorg with both CPU's enabled. If I have: hint.apic.0.disabled="1" in device.hints, I only use one CPU, however it exits from xorg just fine. When the system locks, I still have some keyboard control (num lock lights, etc), but I can't seem to do anything else. I can't see the screen, it goes black during that time. All my system configs/dmesg/etc are here: Booted with apic not disabled: http://www.googlebit.com/freebsd/200605090613/ Booted with apic disabled: http://www.googlebit.com/freebsd/200605091117/ How can I debug (or help debug) this? What if you disable just SMP but leave APIC enabled (kern.smp.disabled=1)? If I disable only SMP and leave APIC enabled, everything seems to work fine. What other info can I give you? I was able to get a backtrace, and a core from this. Here's some details: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0xc6263000 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0d89e43 stack pointer = 0x28:0xe590d4a4 frame pointer = 0x28:0xe590d4bc code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 3 current process = 790 (Xorg) [thread pid 790 tid 100057 ] Stopped at _nv002872rm+0x4b: movl0(%edx,%eax,4),%ebx db> bt Tracing pid 790 tid 100057 td 0xc55b4a80 _nv002872rm(c5e2c000,c5b15d00,0,408000,c5e2c000) at _nv002872rm+0x4b _nv004617rm(c5e2c000,c52d2800,1f,e590d704,20) at _nv004617rm+0x617 _nv004359rm(c5e2c000,c52d2800,e590d704,0,3d0900) at _nv004359rm+0x123 _nv004373rm(c5e2c000,c52d2800,0,c53ac400,4) at _nv004373rm+0x38 _nv003961rm(c5e2c000,c0e8b250,18,c0d38b2a,c5e2c000) at _nv003961rm+0x58 _nv003962rm(c5e2c000,c5e35000,0,c0bfdd56,c53919c0) at _nv003962rm+0x5a _nv008284rm(c53d6700,4,e590d7dc,c0c04a7e,c53919c0) at _nv008284rm+0xe5 rm_disable_adapter(c53d6700,0,c576dc00,c53d6600,c53d6700) at rm_disable_adapter+0x55 nvidia_close_dev(c53d6600,c53d6800,c55b4a80,4,c53d6800) at nvidia_close_dev+0x63 nvidia_dev_close(c53d6800,3,2000,c55b4a80,c068d154) at nvidia_dev_close+0x4b giant_close(c53d6800,3,2000,c55b4a80,0) at giant_close+0x4c devfs_close(e590d890,e590d8bc,c073e868,c09d19e0,e590d890) at devfs_close+0x240 VOP_CLOSE_APV(c09d19e0,e590d890,c55b4a80,c5784400,c0a22140) at VOP_CLOSE_APV+0x36 vn_close(c5e10440,3,c5de6380,c55b4a80,e590d900) at vn_close+0x78 vn_closefile(c581c558,c55b4a80,0,c5e2c000,c64a5620) at vn_closefile+0x92 fdrop_locked(c581c558,c55b4a80,c5e2c000,2e,e590d980,0,0,c58b1800,e590d9a0,c 0d380f4,c53ac400,c5e2c000,e590d5 closef(c581c558,c55b4a80,ff,c55b4bd4,c5d0e380) at closef+0x382 fdfree(c55b4a80,c09d68a0,2,0,c5de4168) at fdfree+0x28b exit1(c55b4a80,9,0,0,e590dae8) at exit1+0x40a sigexit(c55b4a80,9,100,0,0) at sigexit+0x72 ast(e590dd38) at ast+0x47c doreti_ast() at doreti_ast+0x17 What else can I do? Well, it's a problem with the nvidia-driver module. Are you sure that the nvidia-driver is up to date and in sync with your world + kernel? I compiled it right from the latest port (x11/nvidia-driver/). I just recompiled it, and comparing the newly compiled version to the one I'm using (md5 checksums) and they match up. I'd use the nv driver instead, however I'm not sure how to make it work with this screen (1920x1200). I guess I can't count on nvidia's help here much.. *sigh* Thanks John.. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology Anything that works is better than anything that doesn't. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
What did you do for Earth Day?
I hope you had a great Earth Day! I thought you'd want to try this: Adopt your earth and get a free screensaver! Click here to get started: http://friends.earthscreen.com/?r=kTFUNzQgFBdWBmINASkC&i=gmail&[EMAIL PROTECTED]&p=1&z=1&tc=11 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Keep celebrating Earth Day
I hope you had a great Earth Day! I thought you'd want to try this: I'm getting a $25 gift card for Vivavi earth-friendly products. Get yours too. Click here to get started: http://friends.earthscreen.com/?r=MTFUNzQgFBdWBmINASkC&i=gmail&[EMAIL PROTECTED]&p=8&z=1&tc=11 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1 Released
On 05/11/06 20:53, Mike Jakubik wrote: > Simon L. Nielsen wrote: >> On 2006.05.09 01:00:14 -0400, Mike Jakubik wrote: >>> Julian Elischer wrote: >> >> [...] >> the above points to a filel that says "6.0 errata" >>> Indeed. Where is the mention of current quota/bge/em/ufs problems? >>> Don't tell me these will be shoved under the rug. >> >> Send patches. > > Patches? For what? It's too late now, 6.1 has been released. I sent > reminders to the RE team and i made it quite clear on the lists that the > quota issue should be described in the relnotes/errata before the > release. If the RE team chooses to ignore major bugs and pretend all is > fine and dandy, then there is not much patches will do. Heck, im still > waiting for Scott to personally fix the problems, as he so graciously > offered, but couldn't deliver. I offered to work with him and provide > help, he never replied to my emails. The *entire* errata page was from 6.0; it was a mistake. This wasn't some "put on the rose-colored classes and gloss over major issues" thing. It was a long release cycle and something was forgotten. C'est la vie. It's always a good idea to check the most up-to-date version of the errata page on the web anyway, so it's *not* too late to update it. So, you're still waiting for Scott to personally fix the problems and he couldn't deliver? Huh? I quote you (http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025209.html): "Scott, thanks for the very generous gesture, but i cant ask you something like this." -Jonathan -- Jonathan Noack | [EMAIL PROTECTED] | OpenPGP: 0x991D8195 signature.asc Description: OpenPGP digital signature
Re: FreeBSD 6.1 Released
Jonathan Noack wrote: The *entire* errata page was from 6.0; it was a mistake. This wasn't some "put on the rose-colored classes and gloss over major issues" thing. It was a long release cycle and something was forgotten. C'est la vie. It's always a good idea to check the most up-to-date version of the errata page on the web anyway, so it's *not* too late to update it. How convenient. These problems needed to be addressed in the release notes, not some on line version. So, you're still waiting for Scott to personally fix the problems and he couldn't deliver? Huh? I quote you (http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025209.html): "Scott, thanks for the very generous gesture, but i cant ask you something like this." He emailed me personally, i accepted his help offer, never heard from him since. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1 Released
Mike Jakubik wrote: Jonathan Noack wrote: The *entire* errata page was from 6.0; it was a mistake. This wasn't some "put on the rose-colored classes and gloss over major issues" thing. It was a long release cycle and something was forgotten. C'est la vie. It's always a good idea to check the most up-to-date version of the errata page on the web anyway, so it's *not* too late to update it. How convenient. These problems needed to be addressed in the release notes, not some on line version. So, you're still waiting for Scott to personally fix the problems and he couldn't deliver? Huh? I quote you (http://lists.freebsd.org/pipermail/freebsd-stable/2006-May/025209.html): "Scott, thanks for the very generous gesture, but i cant ask you something like this." He emailed me personally, i accepted his help offer, never heard from him since. Sorry, things got lost in the shuffle to get this released. For your specific snapshot deadlocks, please test the changes that have gone into 7-CURRENT and report back if they fix your problem. Only with active testing will we know if they are good to be backported in time for 6.2. Scott ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
