Re: Best Known Methods for dual booting WinXP + -current
On Thu, Aug 07, 2003 at 03:40:27PM -0500, Cagle, John (ISS-Houston) wrote: Had to use FFS filesystem since Grub doesn't support UFS. ^^^ UFS1 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 in world
Terry Lambert wrote: He apparently doesn't understand that v6/v4 NATs and proxy servers would let him deploy today ...assuming that the Windows stack was there. What do you mean the Windows stack was there? XP supports IPv6, as long as you install it, so I assume there's something missing *in* XP's IPv6 support. What is it? -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I would rather say that a desire to drive fast sports cars is what sets man apart from the animals. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ML370 crash
Hi There, Following John Cagle instructions, I made an trace at db prompt, the result can be viewed at http://www.seudns.net/ftp/ale/Pictures/ml370/trace.jpg, the crash can be viewed at http://www.seudns.net/ftp/ale/Pictures/ml370/crash_boot.jpg As John told me, It looks like a bug that involves the ida driver. What can I do ?? Regards, Alexandre Biancalana Alexandre Biancalana wrote: Hi All, I have a Compaq ML370 that freezes during 5.1-RELEASE boot, I tryed the default boot, single user boot and disable ACPI boot. I installed 4.8-RELEASE and then upgraded to CURRENT, make buildworld and buildkernel was perfect, after make installkernel, I made a copy of /sys/i386/conf/GENERIC.hints to /boot/device.hints and the command ran ok too, but when booting with new kernel (/boot/kernel/kernel), the server freeze's at same point, after kernel display vga0 device, but now with an error message and a prompt to an debugger. Follow in attached an dmesg from 4.8-RELEASE that is working and a picture off machine's display at crash moment. Some Idea ?! Best Regards, Alexandre Biancalana Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-RELEASE #0: Thu Apr 3 10:53:38 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC Timecounter i8254 frequency 1193182 Hz CPU: Intel Pentium III (731.02-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073725440 (1048560K bytes) avail memory = 1039876096 (1015504K bytes) Preloaded elf kernel kernel at 0xc051d000. Pentium Pro MTRR support enabled md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: ServerWorks NB6635 3.0LE host to PCI bridge on motherboard pci0: PCI bus on pcib0 sym0: 1510d port 0x2000-0x20ff mem 0xc6efe000-0xc6efefff,0xc6effc00-0xc6ef irq 11 at device 1.0 on pci0 sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking sym1: 1510d port 0x2400-0x24ff mem 0xc6efc000-0xc6efcfff,0xc6efdc00-0xc6efdfff irq 15 at device 1.1 on pci0 sym1: No NVRAM, ID 7, Fast-40, LVD, parity checking fxp0: Intel Pro 10/100B/100+ Ethernet port 0x2800-0x283f mem 0xc6d0-0xc6df,0xc6efb000-0xc6efbfff irq 5 at device 2.0 on pci0 fxp0: Ethernet address 00:50:8b:de:72:26 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: ATI Mach64-GV graphics accelerator at 3.0 pci0: unknown card (vendor=0x0e11, dev=0xa0f0) at 4.0 xl0: 3Com 3c905B-TX Fast Etherlink XL port 0x3000-0x307f mem 0xc6cfee80-0xc6cfeeff irq 5 at device 5.0 on pci0 xl0: Ethernet address: 00:10:4b:c6:38:24 miibus1: MII bus on xl0 xlphy0: 3Com internal media interface on miibus1 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: ServerWorks IB6566 PCI to ISA bridge at device 15.0 on pci0 isa0: ISA bus on isab0 atapci0: ServerWorks ROSB4 ATA33 controller port 0x3080-0x308f at device 15.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pcib3: ServerWorks NB6635 3.0LE host to PCI bridge on motherboard pci3: PCI bus on pcib3 ida0: Compaq Smart Array 431 controller port 0x4000-0x40ff mem 0xc6fff000-0xc6ff irq 10 at device 3.0 on pci3 ida0: drives=2 firm_rev=1.02 idad0: Compaq Logical Drive on ida0 idad0: 17359MB (35553120 sectors), blocksize=512 idad1: Compaq Logical Drive on ida0 idad1: 17359MB (35553120 sectors), blocksize=512 eisa0: EISA bus on motherboard mainboard0: CPQ0690 (System Board) on eisa0 slot 0 orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xcbfff,0xe8000-0xedfff,0xee000-0xe on isa0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ata0-slave: ATAPI identify retries exceeded acd0: CDROM COMPAQ CDR-8435 at ata0-master PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/idad0s2a ___ [EMAIL PROTECTED]
Re: INET6 in world
Daniel C. Sobral wrote: Terry Lambert wrote: He apparently doesn't understand that v6/v4 NATs and proxy servers would let him deploy today ...assuming that the Windows stack was there. What do you mean the Windows stack was there? XP supports IPv6, as long as you install it, so I assume there's something missing *in* XP's IPv6 support. What is it? 1) Machines do not ship with it enabled by default; a Windows user has about as much probability of doing the necessary work to enable it as they do of making something other than Internet Explorer their default browser. 2) You have to go to a command line prompt and issue a cryptic command to enable it at all. 3) When you enable it, you get a huge scare warning about it being experimental. 4) 95% of the existing Windows machines in the world are not running XP, and the last time I saw the code for Windows 95/98 IPv6 support was the Summer of 2000; they took it down from their site after that. 5) AFAIK, it still doesn't support key exchange, so you have to manually configure the keys, which is a really difficult and tedious process, and won't work with any embedded device that depend on key exchange working (e.g. thing NAT gateways, etc.). 6) The last time I tried the experimental version, it did not correctly interoperate with AIX or FreeBSD, but worked fine Windows-to-Windows, so they've done *something* to it to embrace and extend it. In short: It's not ready for Prime Time. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum lock panic at startup -current
On Friday, 8 August 2003 at 10:27:31 +0200, Erwin Lansing wrote: On Fri, Aug 08, 2003 at 10:22:06AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Aaron Wohl writes: I just cvsuped -current this afternoon to get about 1 weeks updates. After that the kernel panics booting starting vinum. I removed the one vinum volume (reformated as UFS2) I had for testing. And it still panics. I changed the /etc/rc.conf start_vinum=YES to NO and can start ok now. What was the actual panic message ? Would http://people.freebsd.org/~erwin/koala.trace2 be related ? Hmm. I haven't seen this one before. This happens after a couple of hours of activity, things are fine again after reboot (for a while) on 5-1-RELEASE. This is a very different backtrace from the last one you showed me. Can I take a look at the dump? The easiest way would be to access it on your system, if that's possible. I have a horrible feeling it's going to be a memory corruption bug. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: ACLS on UFS2 from FreeBSD 5.1-RELEASE install.
Daniel C. Sobral wrote: You'll also notice I'm not questioning the _existence_ of ACL. My point is that FreeBSD is Unix (no matter what the lawyers say), and people don't usually think of ACL when they think of Unix. Ergo, enabling ACL by defautl violates POLA. Not if you never *set* an ACL on anything. It's only when there are ACL's set on things that POLA may be violated. One presumes that an ACL has to be set on purpose... And, in FreeBSD, POLA is king. (Or so we used to believe, no matter what we actually did. :) I'd be astonished if that weren't true. 8-) 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: spin lock sched lock held for 5 seconds
John Baldwin wrote: On 01-Aug-2003 Lars Eggert wrote: Hi, got the following panic overnight running with all debugging options on (WITNESS, MUTEX_DEBUG, DIAGNOSTIC, INVARIANTS; WITNESS_SKIPSPIN off): panic: spin lock sched lock held by 0xc658e130 for 5 seconds cpuid = 0; lapic.id = Stack backtrace: backtrace(c031d030,0,c031c4c5,df0dab8c,100) at backtrace+0x17 panic(c031c4c5,c031c62e,c658e130,c036f160,18b) at panic+0x13d _mtx_lock_spin(c036f160,2,c031a229,18b,c21b2ab0) at _mtx_lock_spin+0x83 _mtx_lock_spin_flags(c036f160,2,c031a229,18b,df0dac0c) at _mtx_lock_spin_flags+0xb9 statclock(df0dac00,df0dac44,c02d8a9c,0,c2198d00) at statclock+0x39 rtcintr(0) at rtcintr+0x4f Xfastunpend8(df0dacb8,c02d1f05,8,608,c0372e60) at Xfastunpend8+0x1c call_fast_unpend(8,608,c0372e60,ffc00034,0) at call_fast_unpend+0xd i386_unpend(c036f160,c21b0790,df0dacd0,c01b1ae0,df0dacec) at i386_unpend+0x8d cpu_unpend(df0dacec,c01a2534,c036f160,1,c031c2e2) at cpu_unpend+0x2d critical_exit(c036f160,1,c031c2e2,1bc,1) at critical_exit+0x2d _mtx_unlock_spin_flags(c036f160,0,c031ac9f,7c,c21b2ab0) at _mtx_unlock_spin_flags+0xbb idle_proc(0,df0dad48,c031ab89,312,c21b2ab0) at idle_proc+0xb0 fork_exit(c0199972,0,df0dad48) at fork_exit+0xc3 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf0dad7c, ebp = 0 --- Debugger(panic) timeout stopping cpus Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 db The machine is still in ddb, let me know if I can provide additional info. Try updating to a more recent current. I recently added some extra debugging here that will attempt to better show who owns the lock and where it was acquired. Same panic string, but a different call chain: spin lock sched lock held by 0xc21b2d10 for 5 seconds exclusive spin mutex sched lock r = 0 (0xc036efc0) locked @ /usr/src/sys/kern/kern_mutex.c:512 panic: spin lock held too long cpuid = 3; lapic.id = 0300 Stack backtrace: backtrace(c031ce60,300,c031c305,df0d0c30,100) at backtrace+0x17 panic(c031c305,c21b2d10,c21b2d10,c036efc0,bc) at panic+0x13d _mtx_lock_spin(c036efc0,2,c031a037,bc,c21b2720) at _mtx_lock_spin+0xb4 _mtx_lock_spin_flags(c036efc0,2,c031a037,bc,c21b2720) at _mtx_lock_spin_flags+0xb9 hardclock_process(df0d0ca0,df0d0ce4,c02d7062,0,c0390018) at hardclock_process+0x3c forwarded_hardclock(0) at forwarded_hardclock+0x11 Xhardclock(df0d0d10,c01998d7,c036f000,2,c031aaad) at Xhardclock+0x52 cpu_idle(c036f000,2,c031aaad,5f,c21b2720) at cpu_idle+0x8 idle_proc(0,df0d0d48,c031a997,30e,0) at idle_proc+0x45 fork_exit(c0199892,0,df0d0d48) at fork_exit+0xc3 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdf0d0d7c, ebp = 0 --- Debugger(panic) timeout stopping cpus Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 db Machine is still in ddb, in case you'd like me to poke around some more. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: ath0 driver
In message: [EMAIL PROTECTED] David Gilbert [EMAIL PROTECTED] writes: : Sam == Sam Leffler [EMAIL PROTECTED] writes: : : I just have to ask: is this in any way related to the a/b/g network : card in my laptop that shows up as: : : [EMAIL PROTECTED]:3:0: class=0x028000 card=0x00011028 chip=0x432414e4 : rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' class = network : : Sam if (broadcom == atheros) use ath driver; else ask broadcom : Sam for specs on their hardware. : : I was hoping for some more contructive help on that... like how I : might figure this out. The ath driver doesn't work with broadcom hardware. You will need to write your own driver, or find someone else that can write a broadcom one for you. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: INET6 in world
Bruce Cran wrote: On Fri, Aug 08, 2003 at 08:01:30AM -0300, Daniel C. Sobral wrote: Terry Lambert wrote: 1) Machines do not ship with it enabled by default; a Windows user has about as much probability of doing the necessary work to enable it as they do of making something other than Internet Explorer their default browser. 2) You have to go to a command line prompt and issue a cryptic command to enable it at all. Err, not at all. You go to install/remove additional windows components (I do not recall the exact phrasing) and select IPv6. 3) When you enable it, you get a huge scare warning about it being experimental. I didn't. :-) And the bastard stopped doing A queries. :-) That'll be because, according to http://www.microsoft.com/windowsxp/pro/techinfo/administration/ipv6/default.asp there's no support in Windows XP's IPv6 stack for DNS. I wonder about their definition of support. There *were* queries being made, but only . It never asked for A, even when IPv6 was disabled in (but added to) the interface. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Westheimer's Discovery: A couple of months in the laboratory can frequently save a couple of hours in the library. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI battery state and resume not working on Inspiron 5150
From: Joe Marcus Clarke [EMAIL PROTECTED] Date: Wed, 06 Aug 2003 16:01:37 -0400 Sender: [EMAIL PROTECTED] --=-MHp9eSkqmbnyoWl+2a1w Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2003-08-06 at 15:56, Barney Wolff wrote: On Wed, Aug 06, 2003 at 03:31:01PM -0400, Joe Marcus Clarke wrote: ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPCB.BAT1._STA] (Node 0xc6137640), AE_NOT_EXIST =20 I would not expect BAT1 to exist unless you have 2 batteries installed. Ah, good point. However, I don't see any battery sysctls, and I do have at least one battery installed. As to resume, on my I5000 it takes almost a minute to come back from S3, but does eventually come back on a -current from 7/30. Thanks for the suggestion. I'll wait a bit longer. Well, I did some experimenting yesterday with the ACPI code on my IBM T30 and learned one thing...if you plan on suspending, you need to set a sleep delay. Before I set the delay I had some nasty problems because power went away immediately and the disk cache did not have a chance to flush (ouch!) and left the display where it should not be. I noticed that Windows XP has a delay of about 5 seconds. I set the sysctl and tried again and things went MUCH better. The suspend didn't leave the disk corrupt (whew!) and the display dropped to low resolution before the graphics was shut down and switched back on resume! My Radeon M7 even retained sync. Of course, the USB driver simply does not recover from a suspend on ACPI and this should be fixed before too long. Also, the backlight stays on making the suspend NVU (not very useful). But it is a huge improvement and adding a delay MAY help a lot of other laptop suspend/resume areas. Whether this will help th I5000 problems, I can't say, but it seems like suspend/resume is the most common show-stopper for ACPI on laptops, so it's worth a shot. If there is a trend that indicates that a short delay in suspending fixes a number of problems, the default delay should probably be modified from 0 to 4 or 5. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[no subject]
Gentlemen, I have been unable to install 5.1, 5 or 4.8 releases on MSI 875P-NEO-FIS2R motherboard. I am led to believe, from reading the documentation, that the Intel ICH5R chipset and the Intel 82547EI (CSA interface) for Lan are not supported. Is there a foreseeable future when these will be integrated? I am using a 3Ghz P4 and would love to use my system with FreeBSD (5.1 preferred) as my 4.8 is running on an old dog. P. J. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ML370 crash
On Thu, 7 Aug 2003, Alexandre Biancalana wrote: Following John Cagle instructions, I made an trace at db prompt, the result can be viewed at http://www.seudns.net/ftp/ale/Pictures/ml370/trace.jpg, the crash can be viewed at http://www.seudns.net/ftp/ale/Pictures/ml370/crash_boot.jpg As John told me, It looks like a bug that involves the ida driver. What can I do ?? I just committed the fix to ida_disk.c (1.41). -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: wi0 Doesn't on 11Mbps!!!
In message: [EMAIL PROTECTED] Marcos Biscaysaqu [EMAIL PROTECTED] writes: : I have a prism 2.5 firmaware 1.5.6 but I can't make work this in 11Mbps The firmware always reports 2Mbps in hostap mode, so the driver always reports 2mbps. this is a cosmetic issue. it would be better if the driver looked at the last N packets to report the speed or something, but each client can be at a different speed Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fun with gdb and threads...
Hi. This might be of interest to anyone who has tried debugging multi-threaded programs (of the libc_r variety) with gdb. This has been bugging me for months, and I finally got frustrated enough to find out what was going on. The symptom: Once you call any function that puts a thread to sleep, the target process crashes (simple program, 1.c attached, and log of gdb killing it in crash.txt) The problem: I traced this to an interaction between gdb and the threads scheduler. The initial crash comes from gdb adding internal breakpoints in the (_)?(sig)?longjmp functions. This breakpoint gets hit when the thread scheduler calls _thread_kern_sched After handling the breakpoint, gdb then needs to reset the instruction pointer in the current thread to re-run the instruction the breakpoint was at. However, at that point, gdb's freebsd_uthread_store_registers() barfs, thinking that the thread in question is not active, because its not in state PS_RUNNING (it's just about to go to sleep). As a result, it mucks up the resetting of the instruction pointer, because it thinks it just needs to twiddle with the threads context, rather than the live registers. Once the process is resumed, it starts in the middle of whatever instruction the breakpoint overwrote, and generally fscking things up. The fix: I added a couple of nops to ___longjmp, and created a new entrypoint below them called ___longjmp_raw. This provides a way for the libc_r library to avoid hitting the gdb breakpoints at sensitive moments. All other consumers still work the exact same way (modulo the time spent executing a couple of nops). The patch is attached, and makes gdb behave perfectly for me. Does anyone have any comments on this, or ideas on how to improve on it? The only penalty I can see is an extra nop instruction for normal longjmps, which I'll gladly trade for a usable debugger. PS: before anyone suggests it, I initially tried changing freebsd_uthread.c to check for the active thread more effectively, as is done in freebsd_uthread_fetch_registers, by comparing it with _pthread_run, rather than checking the state. This improved things, but gdb still got confused, and started stopping unexpectedly when it lost it's breakpoints, etc, so I figured the other approach was probably going to be more stable. Index: lib/libc/i386/gen/_setjmp.S === RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/lib/libc/i386/gen/_setjmp.S,v retrieving revision 1.16 diff -u -r1.16 _setjmp.S --- lib/libc/i386/gen/_setjmp.S 23 Mar 2002 02:05:17 - 1.16 +++ lib/libc/i386/gen/_setjmp.S 7 Aug 2003 20:42:08 - @@ -66,6 +66,17 @@ .weak CNAME(_longjmp) .set CNAME(_longjmp),CNAME(___longjmp) ENTRY(___longjmp) +/* + * Debuggers tend to put breakpoints in longjmp, while + * threads libraries don't like to be interrupted. + * The extra nop for the exposed _longjmp stops + * ___longjmp getting mucked about with by the debugger + * The threads library can then call ___longjmp_raw + * with impunity. + */ + nop + nop +ENTRY(___longjmp_raw) movl 4(%esp),%edx movl 8(%esp),%eax movl 0(%edx),%ecx Index: lib/libc_r/uthread/uthread_kern.c === RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/lib/libc_r/uthread/uthread_kern.c,v retrieving revision 1.45 diff -u -r1.45 uthread_kern.c --- lib/libc_r/uthread/uthread_kern.c 5 Oct 2002 02:22:26 - 1.45 +++ lib/libc_r/uthread/uthread_kern.c 7 Aug 2003 20:39:44 - @@ -95,7 +95,7 @@ curthread-check_pending = 1; /* Switch to the thread scheduler: */ - ___longjmp(_thread_kern_sched_jb, 1); + ___longjmp_raw(_thread_kern_sched_jb, 1); } @@ -165,7 +165,7 @@ } } /* Switch to the thread scheduler: */ - ___longjmp(_thread_kern_sched_jb, 1); + ___longjmp_raw(_thread_kern_sched_jb, 1); } void @@ -582,7 +582,7 @@ #if NOT_YET _setcontext(curthread-ctx.uc); #else - ___longjmp(curthread-ctx.jb, 1); + ___longjmp_raw(curthread-ctx.jb, 1); #endif /* This point should not be reached. */ PANIC(Thread has returned from sigreturn or longjmp); [EMAIL PROTECTED] gcc -o 1 -g -Wall -pthread 1.c [EMAIL PROTECTED] gdb ./1 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 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-undermydesk-freebsd... (gdb) b threadFunc Breakpoint 1 at 0x804861e: file 1.c, line 10. (gdb) run Starting program: /local/petere/1 Breakpoint 1, threadFunc (arg=0x0) at 1.c:10 10 sleep(1); (gdb) n Program received signal SIGSEGV, Segmentation fault. 0x280d0138 in _longjmp () from /usr/lib/libc.so.5 (gdb) ___ [EMAIL PROTECTED]
Re: problem with nvidia graphics card and -current
On Tuesday, 05 August 2003 14:34, Matthew N. Dodd wrote: On Mon, 4 Aug 2003, Glenn Johnson wrote: Question for the developers: Is there someway to avoid having the combination of vesa and nvidia cause a total lockup of the machine? I have a feeling I may not be the last person to try the nvidia driver with vesa enabled, either as a module, or compiled in the kernel. I'm running a system with the VESA stuff compiled in; the nvidia drivers work just fine. IIRC you're running with ACPI; try not doing that. I'm also running a system with the vesa module loaded. I'm also running ACPI. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ath0 driver
Hi, The version should be 0.9.5.3 or better (can't remember if I committed .4 or .3). Shouldn't that be 0.9.5.2? I run the latest current, and hw.ath.hal.version is 0.9.5.2. You're right; I committed a slightly older version to FreeBSD than to Linux. The version The version I have is 0.9.5.2. As to the tcpdump, I get er# tcpdump -i ath0 -y IEEE802_11 tcpdump: data link type DLT_IEEE802_11 tcpdump: listening on ath0 00:18:02.152294 10.0.0.1.netbios-dgm 10.0.0.255.netbios-dgm: NBT UDP PACKET(138) 00:18:02.152502 10.0.0.1.netbios-dgm 10.0.0.255.netbios-dgm: NBT UDP PACKET(138) and thats all that comes up. Does this driver support being set up as an access point yet? I figured it did because ifconfig ath0 mediaopt hostap didnt return any errors. Please let me know if Im doing something wrong. Im sure ive got my *.conf files set up right as I have used them before, however I could be wrong. Thanks for the help David Ive got a Dlink DWL-G520 that Ive installed into a Freebsd system. Ive set up the card with the following00:18:02.152294 10.0.0.1.netbios-dgm 10.0.0.255.netbios-dgm: NBT UDP PACKET(138) 00:18:02.152502 10.0.0.1.netbios-dgm 10.0.0.255.netbios-dgm: NBT UDP PACKET(138) ifconfig_ath0=inet 10.0.0.1 netmask 255.255.255.0 ssid daves channel 10 media DS11 mediaopt hostap This system was cvsuped and buildworld about 3 days ago. The card appears to be working because when I try to connect with my PDA it shows full Link and quality, and when I ifconfig ath0 down , the link and quality go down to nothing. However it doesn't give out dhcp addresses over this interface. Im sure my dhcpd.conf is fine because I've used a similar one on a laptop = aka wireless access point that worked very well. So I tried to use dstumbler to see if it could detect the PDA, however it gives me the following error error: unable to ioctl device socket: Operation now in progress and it stays that way. Has anyone had this issue as well or now what it means? Verify you have the latest HAL using sysctl hw.ath The version should be 0.9.5.3 or better (can't remember if I committed .4 or .3). If you have an old version update. Otherwise you might try tapping 802.11 frames with tcpdump on the AP to see what's going on: tcpdump -i ath0 -y IEEE802_11 As to dstumbler, it is intimately tied to the wi driver at the moment. I have a version that works w/ wi and ath drivers but it's a major rewrite and incomplete. If someone wants to pick it up I'd be happy to pass the (incomplete) work on... Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
another buildworld -j4 panic
ok, here goes: duplicate free from zone FFS1 dinode traceback: Debugger panic uma_dbg_free uma_zfree_arg ffs_ifree ufs_reclaim ufs_vnoperate vclean gdonel getnewvnode ffs_vget ufs_lookup ufs_vnoperate vfs_cache_lookup ufs_vnoperate lookup namei stat syscall Xint0x80_syscall Whee! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new panic during buildworld -j4
This is from a kernel with sources from soon after i386/pmap.c 1.423 was committed, FWIW. On Wed, 6 Aug 2003, Mike Silbersack wrote: I suppose a coredump would be nice here, but I didn't have that enabled... And it turns out that I'm too lazy to actually type in all of the arguments, but I'll leave the machine sitting at the backtrace. If anyone wants any more info, please ask. panic uma_dbg_free uma_zfree_arg free workitem_free free_diradd handle_written_filepage softdep_disk_write_complete bufdone bufdonebio biodone g_dev_done biodone g_io_schedule g_up_procbody fork_exit fork_trampoline --- trap 0x1, eip = 0, esp = 0xd23a5d7c, ebp = 0 --- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: new panic during buildworld -j4
On Wed, Aug 06, 2003 at 11:13:41PM -0500, Mike Silbersack wrote: I suppose a coredump would be nice here, but I didn't have that enabled... And it turns out that I'm too lazy to actually type in all of the arguments, but I'll leave the machine sitting at the backtrace. If anyone wants any more info, please ask. panic uma_dbg_free uma_zfree_arg free workitem_free free_diradd handle_written_filepage softdep_disk_write_complete bufdone bufdonebio biodone g_dev_done biodone g_io_schedule g_up_procbody fork_exit fork_trampoline --- trap 0x1, eip = 0, esp = 0xd23a5d7c, ebp = 0 --- How about the panic message? There are 4 different panics that could have occured from uma_dbg_free(). Arguments would also be nice, I guess. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
