Re: Fatal double fault with 20031116-JPSNAP
(Re-sending, my original post was accepted by mx1.freebsd.org, but seems to have been lost somewhere.) Thus spake Damian Gerow ([EMAIL PROTECTED]) [29/11/03 17:04]: But this is a little OT. I'll find some way to update my system, and respond back if the problem's fixed or not in a later -CURRENT. Nope, I'm still seeing the double fault: # uname -a FreeBSD 5.2-BETA-20031129-JPSNAP FreeBSD 5.2-BETA-20031129-JPSNAP #0: Sat Nov 29 02:47:57 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 # make buildworld snip panic: Duplicate free of item 0xc1cd8e1c from zone 0xc102e1c0(PV ENTRY) cpuid = 0; Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c0898ddc,0,c08b186e,d8a11c10,100) at Debugger+0x55 panic(c08b186e,c1cd8e1c,c102e1c0,c08b66c4,c08b13a5) at panic+0x156 uma_dbg_free(c102e1c0,0,c1cd8e1c,6d0,0) at uma_dbg_free+0x111 uma_zfree_arg(c102e1c0,c1cd8e1c,0,a2f,c08968de) at uma_zfree_arg+0x123 pmap_remove_pages(c1d0ef60,0,bfc0,11a,c08968de) at pmap_remove_pages+0x209 exit1(c4712c80,0,c08968de,65,d8a11d40) at exit1+0x66c sys_exit(c4712c80,d8a11d14,c08b6d61,3ee,1) at sys_exit+0x41 syscall(2f,2f,2f,bfbfe938,0) at syscall+0x2c0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x826aa63, esp = 0xbfbfe8f4, ebp = 0xbfbfe910 --- db show pcpu 0 cpuid= 0 curthread= 0xc4712c80: pid 34357 cc1 curpcb = 0xd8a11da0 fpcurthread = none idlethread = 0xc1cff640: pid 11 idle: cpu0 APIC ID = 0 currentldt = 0x28 spin locks held: db It /does/ take a bit longer to get to, and I didn't see any of the previous console-flooding messages. But the panic still happens. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fatal double fault with 20031116-JPSNAP
A couple days ago, I downloaded 20031116-JPSNAP to install on a new system -- this box had been running 5.1-R without issues for some time, but wasn't doing anything particular, and I had mucked up the 5.1 - 5.2 upgrade (statfs stuff). Whenever I boot the system into multi-user mode, I see a *lot* of this: checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/kern_synch.c:293 checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/subr_trap.c:260 checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r = 0 (0xc48f9aa8) locked @ /usr/src/sys/kern/subr_trap.c:260 over and over and over -- it makes the console essentially unusable. Thinking an update might fix it, I booted into single user mode, cvsup'ed, and started building. However, six buildworlds later, it appears that I'm constantly getting a fatal double fault, but in differing places. This looks like the turnstile double-panic outlined in 5.2R-TODO -- I hope this is enough information. Anyhow, here's what I see (I don't know how to use the debugger, so I've just guessed at commands): panic: Duplicate free of item 0xc1cda71c from zone 0xc103b780(PV ENTRY) cpuid = 0; Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c0895cb8,0,c08ae388,d8a48c04,100) at Debugger+0x55 panic(c08ae388,c1cc72bc,c103b780,c08b3233,6d0) at panic+0x156 uma_dbg_free(c103b780,0,c1cc72bc,6d0,0) at uma_dbg_free+0x111 uma_zfree_arg(c103b780,c1cc72bc,0,a2f,c0893811) at uma_zfree_arg+0x123 pmap_remove_pages(c1d0d364,0,bfc0,11a,c0893811) at pmap_remove_pages+0x209 exit1(c4796c80,0,c0893811,65,d8a48d40) at exit1+0x68c sys_exit(c4796c80,d8a48d10,c08b38d0,3ee,1) at sys_exit+0x41 syscall(2f,2f,2f,bfbfece0,0) at syscall+0x2e0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x806427b, esp = 0xbfbfec9c, ebp = 0xbfbfecb8 --- db match After 6 instructions (0 loads, 0 stores), Stopped at Debugger+0x66: ret db match syncing disks, buffers remaining... panic: sleeping thread (pid 14015) owns a non-sleepable lock cpuid = 0; Debugger(panic) Uptime: 18m4s panic: Assertion td-td_turnstile != NULL failed at /usr/src/sys/kern/subr_turnstile.c:437 [the above four lines, thirteen times] Fatal double fault: eip = 0xc08118c0 esp = 0xd77ba000 ebp = 0xd77ba020 cpuid = 0; apic id = 00 panic: double fault cpuid = 0; Debugger(panic) Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x8:0xc0811a85 stack pointer = 0x10:0xc09bb2dc frame pointer = 0x10:0xc09bb2e8 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= nested task, IOPL = 0 current process = 27 (swi8: tty:sio clock) And on the next buildworld, in a different place: panic: Duplicate free of item 0xc4bc221c from zone 0xc103b6c0(MAP ENTRY) cpuid = 0; Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c0895cb8,0,c08ae388,d8a05b8c,100) at Debugger+0x55 panic(c08ae388,c4bc221c,c103b6c0,c08ac694,6d0) at panic+0x156 uma_dbg_free(c103b6c0,0,c4bc221c,6d0,0) at uma_dbg_free+0x111 uma_zfree_arg(c103b6c0,c4bc221c,0,d8a05c34,c07d9f6c) at uma_zfree_arg+0x123 vm_map_entry_dispose(c1d0d84c,c4bc221c,c08ac714,829,c08ac714) at vm_map_entry_dispose+0x3d vm_map_entry_delete(c1d0d84c,c4bc221c,c08ac714,884,c1d0d888) at vm_map_entry_delete+0x1ac vm_map_delete(c1d0d84c,0,bfc0,c1d0d84c,c48b8900) at vm_map_delete+0x228 vm_map_remove(c1d0d84c,0,bfc0,11d,c0893811) at vm_map_remove+0x58 exit1(c4704780,0,c0893811,65,d8a05d40) at exit1+0x6c6 sys_exit(c4704780,d8a05d10,c08b38d0,3ee,1) at sys_exit+0x41 syscall(2f,2f,2f,bfbfec40,0) at syscall+0x2e0 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x806427b, esp = 0xbfbfebfc, ebp = 0xbfbfec18 --- db match After 6 instructions (0 loads, 0 stores), Stopped at Debugger+0x66: ret db match Uptime: 35m13s panic: Assertion td-td_turnstile != NULL failed at /usr/src/sys/kern/subr_turnstile.c:437 cpuid = 0; Debugger(panic) [the above four lines thirteen times] Fatal double fault: eip = 0xc048a39f esp = 0xd89f8000 ebp = 0xd89f800c cpuid = 0; apic id = 00 panic: double fault cpuid = 0; Debugger(panic) Fatal trap 3: breakpoint instruction fault while in kernel mode cpuid = 0; apic
Re: Fatal double fault with 20031116-JPSNAP
Thus spake Kris Kennaway ([EMAIL PROTECTED]) [29/11/03 16:23]: over and over and over -- it makes the console essentially unusable. I think you're running into problems that have been fixed in subsequent weeks. Is there a reason you can't install the 5.2-BETA image? Well, that's good news. The only thing that's holding me back is no easy access to a CD burner -- it'll be Monday before I get to one, and I was hoping to have this done by this weekend. No matter. If the build finishes successfully, then I should be fine. If not, I'll see if I can convince sysinstall to update my system, or just download the latest 5.2 image, and start over. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal double fault with 20031116-JPSNAP
Thus spake Kris Kennaway ([EMAIL PROTECTED]) [29/11/03 17:18]: Can't you boot from the install floppy and then do a network install? Don't have any floppies handy right now. I /could/ go out and get some... But this is a little OT. I'll find some way to update my system, and respond back if the problem's fixed or not in a later -CURRENT. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tcp hostcache and ip fastforward for review
I've been thinking about this all day... Thus spake Jesper Skriver [EMAIL PROTECTED] [23:53:26 11/12/03: : + /* : +* Only unicast IP, not from loopback, no L2 or IP broadcast, : +* no multicast, no INADDR_ANY : +*/ : + if ((m-m_pkthdr.rcvif-if_flags IFF_LOOPBACK) || : + (ntohl(ip-ip_src.s_addr) == (u_long)INADDR_BROADCAST) || : : #jesper : You will never see packets with a multicast source address. Do you mean: Any packets with a multicast source address will be dropped by the kernel before this point, or that no host will ever send a packet with a multicast source address? In the former, that's fine. In the latter, how does one guarantee that there isn't a malicious host out there sending spoofed multicast-source packets? - Damian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No/weird mixer in -CURRENT
On Sun, 21 Sep 2003 23:19:12 -0400, thus spake Damian Gerow [EMAIL PROTECTED]: : This is a fairly new machine, using a DFI PS83-BL motherboard. pcm0 : is picked up as an Intel ICH5 (82801EB), and a C-Media Electronics : CMI9739 AC97 Codec. : : Does pcm not fully understand my audio device, am I lacking a mixer, : or is it something else : entirely? (Apologies for horrible wrapping the first time.) I just went through and applied a one-line patch to ich.c -- looks like it was saying to treat ICH5 like ICH4. This didn't make a difference. Does anyone have any suggestions or pointers? As much as I like listening to something at full volume, it would be nice to be able to turn it down without turning it off. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No/weird mixer in -CURRENT
On Sat, 27 Sep 2003 16:24:10 -0700, thus spake Kevin Oberman [EMAIL PROTECTED]: : Does anyone have any suggestions or pointers? As much as I like : listening to something at full volume, it would be nice to be able : to turn it down without turning it off. : : Are you seeing this with all applications? I see it with gkrellm's : volume control, but the Gnome volume control works just fine as does : the CLI mixer(1) command. I've seen it with gkrellm, aumix, opmixer, ermixer, and gmixer. Actually, to be fair, gmixer didn't do anything -- all the others will mute my audio as soon as the PCM volume hits 0. And that's all they do. : I have sent a note to the maintainer of the volume plug-in, but have : not heard anything to this point. I will probably do a PR on it soon : and I really love the gkrellm volume control. Ditto. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
No/weird mixer in -CURRENT
I just set up a new box with -CURRENT on it, using 20030918-JPSNAP (cvsup'ed the next day), and I'm having some really strange things going on with volume control. aumix won't complain, and will successfully query the mixer device. I can set the volume levels to my hearts content, but the only thing that actually works is if I set the PCM volume to 0 -- which mutes everything. Any other setting, on any other channel, leaves the volume at full. I thought this was weird, but before posting, I tested with gkrellm. Using the volume plugin for gkrellm2, it tells me that /dev/mixer0 is not a valid mixer device. So I went through /dev/audio*, /dev/dsp*, /dev/sequencer*, but none of them worked (which didn't surprise me, as they're not mixer devices). I've noticed that /dev/mixer doesn't exist, though the patterns of other devices lead me to believe that it should be a symlink to /dev/mixer0, which /does/ exist. This is a fairly new machine, using a DFI PS83-BL motherboard. pcm0 is picked up as an Intel ICH5 (82801EB), and a C-Media Electronics CMI9739 AC97 Codec. Does pcm not fully understand my audio device, am I lacking a mixer, or is it something else entirely? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT
Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 15:00]: I'm almost certain your problem is defining MAXMEM to 512 MB. Remove that from your kernel config and try again. MAXMEM causes all kinds of problems. If this doesn't solve it, start with the stock GENERIC and add back in your custom kernel options until it fails. The last option you add is the faulty one. I was wondering the same thing myself last night actually... I just pulled that line, and it now works. Which is weird -- I have two other 5.1 machines that I have specified MAXMEM in, without any troubles. It's also strange that this would only be brought out with ACPI...? Anyhow, it's working for me now. If anyone feels like further debugging, I'm all game. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT [SOLVED]
Thus spake Nate Lawson ([EMAIL PROTECTED]) [16/09/03 16:24]: I have no time to track this down but the output of acpidump -t may help someone else who might be interested. You're looking for the pointers that are stored in RSD PTR. I'm still on 5.1-R, and there's no '-t' flag to acpidump. However, I've posted the dump on the web: http://www.sentex.net/~damian/acpidump so people can browse as they wish. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT
Thus spake Nate Lawson ([EMAIL PROTECTED]) [13/09/03 14:42]: The post you reference shows the user with a kernel that has both APM and ACPI installed, apparently. This is not valid. Please report your kernel config. If GENERIC in 2003/9/6 booted fine with ACPI and then your rebuilt kernel from 2003/9/7 fails, it is almost certainly the devices you included. There were no ACPI-related commits in that timeframe. It's attached. There's no APM in there. I did some more testing -- GENERIC works for the -CURRENT date I stated before, and 5.1-R. As soon as I compile my own kernel, it breaks. I'm working on compiling this with debugging, so I can take a closer look at what's going on. ident pandora machine i386 cpu I686_CPU maxusers0 options INCLUDE_CONFIG_FILE #optionsCPU_WT_ALLOC options MAXMEM=(512*1024) options DEVICE_POLLING options HZ=1000 device isa device pci device agp device speaker device random device pty device md device npx device sio options CONSPEED=115200 options GEOM_BDE options GEOM_BSD options GEOM_VOL options SCHED_4BSD options COMPAT_43 options COMPAT_FREEBSD4 options SYSVSHM options SYSVSEM options SYSVMSG options INET options INET6 options IPSEC options IPSEC_ESP device ether device loop device bpf device disc device gif device faith device stf options IPFILTER options IPFILTER_LOG options IPFILTER_DEFAULT_BLOCK options PFIL_HOOKS options RANDOM_IP_ID options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP options TCP_DROP_SYNFIN options FFS options NFSCLIENT options NFSSERVER options PROCFS options PSEUDOFS options SOFTUPDATES options UFS_DIRHASH options UFS_EXTATTR options UFS_EXTATTR_AUTOSTART options UFS_ACL options _KPOSIX_PRIORITY_SCHEDULING options P1003_1B_SEMAPHORES #optionsMAC #optionsMAC_BSDEXTENDED #optionsMAC_SEEOTHERUIDS # These are worth looking into, but require configuration #optionsMAC_BIBA #optionsMAC_LOMAC #optionsMAC_MLS # These two are also worth looking at, and take less configuration #optionsMAC_PARTITION #optionsMAC_PORTACL device atkbdc device atkbd options KBD_INSTALL_CDEV device vga options VGA_ALT_SEQACCESS device splash device sc #device daemon_saver #device fade_saver device fire_saver #device green_saver #device logo_saver #device rain_saver #device star_saver #device warp_saver device ata device atadisk device miibus device fxp device smbus device ichsmb device smb device iicbus device iicbb device iicsmb #device crypto # core crypto support #device cryptodev # /dev/crypto for access to h/w # #device rndtest # FIPS 140-2 entropy tester # #device hifn# Hifn 7951, 7781, etc. #optionsHIFN_DEBUG # enable debugging support: hw.hifn.debug #optionsHIFN_RNDTEST# enable rndtest support # #device ubsec # Broadcom 5501, 5601, 58xx #optionsUBSEC_DEBUG # enable debugging support: hw.ubsec.debug #optionsUBSEC_RNDTEST # enable rndtest support ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems with this morning's -CURRENT
(To recap: I'm having ACPI problems on a DFI CD70-SC, with both 5.1-R and 5-CURRENT. Booting GENERIC doesn't show any problems, however, so there's a good chance it's a misconfiguration issue.) Thus spake Damian Gerow ([EMAIL PROTECTED]) [15/09/03 17:34]: It's attached. There's no APM in there. I did some more testing -- GENERIC works for the -CURRENT date I stated before, and 5.1-R. As soon as I compile my own kernel, it breaks. I'm working on compiling this with debugging, so I can take a closer look at what's going on. Okay, here's a backtrace with debugging. Unfortunately, when dropped to the debugging prompt, I don't know what to do. Attached is the kernel config I used to generate this on 5.1-R, I can re-do this on -CURRENT if need be. Here's a snippet of boot, and the stack backtrace: ... Preloaded elf kernel /boot/kernel/kernel at 0xc04b8000 Preloaded elf module /boot/kernel/acpi.ko at 0xc04b81f4 ... real memory = 536870912 (512 MB) avail memory = 516313088 (492 MB) panic: pmap_mapdev: Couldn't allocate kernel virtual memory Stack backtrace: backtrace(c035b0cc,c03baea0,c0372994,c04dabbc,100) at backtrace+0x17 panic(c0372994,c036f000,0,0,0) at panic+0x93 pmap_mapdev(1fff3000,c036ec14,c04dac48,c04dabcc,c048e880) at pmap_mapdev+0x4b AcpiOsMapMemory(1fff3000,0,c036ec14,c04dabbc,c04dabc4) at AcpiOsMapMemory+0x1e AcpiTbGetThisTable(c04dac48,c04dac00,c04dac58,c04dac48,c04dac48) at AcpiTbGetThisTable+0xf0 AcpiTbGetTableBody(c04dac48,c04dac00,c04dac58,c0387ebc,c036ec14) at AcpiTbGetTableBody+0x4c AcpiTbGetTable(c04dac48,c04dac58,9,1fff3000,0) at AcpiTbGetTable+0x38 AcpiTbGetTableRsdt(c04daca0,c04daca0,c04dacb4,1,f6010) at AcpiTbGetTableRsdt+0x23 AcpiLoadTables(c04a8bc0,c04a49ac,0,0,0) at AcpiLoadTables+0xa6 acpi_identify(c04a7528,c151cb00,c0379a14,c1506190,c151cb00) at acpi_identify+0xb4 DEVICE_IDENTIFY(c04a7528,c151cb00,c151cb00,c151cb00,c04dad18) at DEVICE_IDENTIFY+0x50 bus_generic_probe(c151cb00,c3fcc098,c04dad34,c01da1b8,c151cb00) at bus_generic_probe+0x2e nexus_attach(c151cb00,c3fcc098,c0379a1c,c151cb00,c151d000) at nexus_attach+0x14 DEVICE_ATTACH(c151cb00,c151cb00,0,c14ea5d8,1) at DEVICE_ATTACH+0x48 device_probe_and_attach(c151cb00,c14ea5d8,c04dad80,c0321635,c151d000) at device_probe_and_attach+0x7d root_bus_configure(c151d000,c0371fdc,0,c04dad98,c01960a5) at root_bus_configure+0x28 configure(0,4d7000,4d7c00,4d7000,0) at configure+0x35 mi_startup() at mi_startup+0xb5 being() at begin+0x2c Debugger(panic) Stopped atDebugger+0x54:xchgl %ebx,in_Debugger.0 db print c01c08b0 db show pcpu cpuid = 0 curthread = 0xc03b4640: pid 0 swapper curpcb = 0 fpcurthread = none idlethread = 0xc151f850: pid 11 idle currentldt = 0x28 db show map Task map 0xc01c08b0: pmap=0x4de80574, nentries=604293056, version=742228750 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4c70500 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02f3a40 stack pointer = 0x10: 0xc04da940 frame pointer = 0x10: 0xc04da960 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = 0 (swapper) kernel: type 12 trap, code=0 Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db Given that I caused a panic while in the debugger, and that I don't know what I'm looking for, I stopped here. (Further 'show map's didn't result in a panic, however.) Note that if I /don't/ boot with ACPI, I can boot just fine, with no power management. ident pandora machine i386 cpu I686_CPU maxusers0 makeoptions DEBUG=-g options DDB options DDB_TRACE options KTRACE options DIAGNOSTIC options INCLUDE_CONFIG_FILE options CPU_FASTER_5X86_FPU options CPU_UPGRADE_HW_CACHE #optionsCPU_WT_ALLOC options MAXMEM=(512*1024) options DEVICE_POLLING options HZ=1000 device isa device pci device agp device speaker device random device pty device md device npx device sio options CONSPEED=115200 options GEOM_BDE options GEOM_BSD options GEOM_VOL options SCHED_4BSD options COMPAT_43 options COMPAT_FREEBSD4 options SYSVSHM options SYSVSEM options SYSVMSG options INET options INET6 options IPSEC options IPSEC_ESP device ether device loop device bpf device disc device gif device faith device stf options IPFILTER options
ACPI problems with this morning's -CURRENT
I set up a box yesterday to play with -CURRENT on. I used the 2003-09-06 snapshot code from ftp://current.freebsd.org/. Initial setup and boot worked just fine, but when I did a rebuild/reboot last night, this is what I saw: pmap_mapdev: Couldn't alloc kernel virtual memory So thinking I missed some kernel options, I pulled a couple of things, did another cvsup/rebuild/reboot this morning, and got the same thing. I know that various people have been having ongoing issues with ACPI, but this is the first problem I've had with it (I have a couple of other boxen running 5.1-RELEASE and 5-CURRENT). I was able to fix it (and discover that it was ACPI related) by finding this post (even though it's two years old): http://www.geocrawler.com/archives/3/147/2001/8/0/6526228/ The difference is that I'm seeing the pmap_mapdev error immediately after it spits out the 'real memory' and 'avail memory' lines. This is being run on a DFI CD70-SC, 512MB DDR SDRAM, with a Via C3 Nehemiah. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
Thus spake Gerrit K?hn ([EMAIL PROTECTED]) [15/06/03 10:40]: CPU: VIA/IDT Unknown (998.70-MHz 686-class CPU) Origin = CentaurHauls Id = 0x689 Stepping = 9 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX This one doesn't seem to support SSE, though I wonder why there is this unknown. My C3 here is an Ezra and is identified as Samuel2 with id=067a. I have an Ezra or an Ezra-T core (the only difference is Tualatin sp compatibility), and it produces an Unknown. If you have a 'Samuel2' core, then you have a Samuel2 core. It's neither Ezra nor Ezra-T -- those two are the successors to Samuel2. However, if you have a C3 without SSE, it's basically a K6 with MMX and 3dNow. So I'm using CPUTYPE=k6-3 in /etc/make.conf. Up to now this has been working fine for me. I've been using CPUTYPE=i586/mmx. That's been working for me as well -- I'd be interested to see which is more optimized. Does your chip understand CMOV? GCC presumes that a 686-class processor has CMOV, and while the C3 /is/ a 686-class processor, it doesn't do CMOV. But I heard a rumor that the Samuel2 core /does/ do CMOV... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
Thus spake Gerrit K?hn ([EMAIL PROTECTED]) [18/06/03 11:00]: If you have a 'Samuel2' core, then you have a Samuel2 core. It's neither Ezra nor Ezra-T -- those two are the successors to Samuel2. Well, all I can say is, that I bought it as Ezra and there is Ezra printed on it. FreeBSD identifies it as Samuel2, though. And I bought my Ezra as a Nehemiah. Via (VIA) has no clear distinction between the cores, even though there are some pretty big differences (full speed FPU, SSE support). It would have made sense to call it C3 then C4 then C5, or some other way to distinguish between the different chips. Resellers seem to have problems figuring out which chip it is that they're selling. All I know is that the product line went: Samuel - Samuel2 - Ezra - Ezra-T - Nehemiah However, one page seems to indicate that the product line went more like: Samuel (C5A) - Samuel2 (C5B) - Ezra/Samuel3 (C5C) - Ezra-T (C5N) - Eden - Nehemiah where Eden is really just a bundled chip (with a specific VIA north/south bridge). So maybe they do have a way to distinguish the chips. Dunno -- at the very least, it's not marketed. And the Samuel2 is definitely not an Ezra. FWIW, the best way I've seen to figure out which chip you're using (at least between Ezra/Ezra-T and Nehemiah) is to look at the clocking -- Ezra/Ezra-T seems to be 100*10.0, whereas Nehemiah seems to be 133*7.5. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
This isn't really a -current issue, moving to hardware. Please strip the Cc: in your reply. Thus spake Gerrit K?hn ([EMAIL PROTECTED]) [18/06/03 11:20]: FWIW, the best way I've seen to figure out which chip you're using (at least between Ezra/Ezra-T and Nehemiah) is to look at the clocking -- Ezra/Ezra-T seems to be 100*10.0, whereas Nehemiah seems to be 133*7.5. (Note that this obviously only holds true for 1GHz rated chips.) Back to the performance-discussion between cputype 586/mmx and k6-3 optimization: do you have a suggestion how to benchmark it? Well, there's always /usr/ports/benchmarks. nbench might be what you're looking for -- compile it once using 586/mmx support, and once using k6-3 support. Other than that, time a buildworld/buildkernel. But I'm not a benchmarking person by any means, so this may or may not be accurate. Doing the buildworld/buildkernel will probably be more intensive -- compile it with k6-3 flags, reboot, then do another compile with the same flags. Time that one. Do the whole process again with 586/mmx flags, again, timing the second of the two builds. I don't have a couple of days to throw at benchmarks, so I definitely won't be doing this. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ATA mount failur (Was: Re: Panics with GnuPG)
Thus spake Doug Barton ([EMAIL PROTECTED]) [03.03.13 13:27]: Update your sources, and make sure that you have 1.202 of sys/netinet/tcp_input.c. I had a 100% reproducable panic very similar to yours, and hsu fixed it. I'd like to verify, but using updated sources as of about four hours ago, I can't boot. My system hangs on mounting root: Mar 13 18:32:12 pegmatite kernel: Copyright (c) 1992-2003 The FreeBSD Project. Mar 13 18:32:12 pegmatite kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Mar 13 18:32:12 pegmatite kernel: The Regents of the University of California. All rights reserved. Mar 13 18:32:12 pegmatite kernel: FreeBSD 5.0-CURRENT #10: Thu Mar 13 16:50:44 EST 2003 Mar 13 18:32:12 pegmatite kernel: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/pegmatite Mar 13 18:32:12 pegmatite kernel: Preloaded elf kernel /boot/kernel/kernel at 0xc053f000. Mar 13 18:32:12 pegmatite kernel: Timecounter i8254 frequency 1193182 Hz Mar 13 18:32:12 pegmatite kernel: Timecounter TSC frequency 733129806 Hz Mar 13 18:32:12 pegmatite kernel: CPU: Intel Pentium III (733.13-MHz 686-class CPU) Mar 13 18:32:12 pegmatite kernel: Origin = GenuineIntel Id = 0x686 Stepping = 6 Mar 13 18:32:12 pegmatite kernel: Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE Mar 13 18:32:12 pegmatite kernel: real memory = 1073659904 (1023 MB) Mar 13 18:32:12 pegmatite kernel: avail memory = 1037426688 (989 MB) Mar 13 18:32:12 pegmatite kernel: Allocating major#253 to net Mar 13 18:32:12 pegmatite kernel: Allocating major#252 to pci Mar 13 18:32:12 pegmatite kernel: netsmb_dev: loaded Mar 13 18:32:12 pegmatite kernel: Pentium Pro MTRR support enabled Mar 13 18:32:12 pegmatite kernel: acpi0: ASUS CUV4X_EA on motherboard Mar 13 18:32:12 pegmatite kernel: ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 Mar 13 18:32:12 pegmatite kernel: pcibios: BIOS version 2.10 Mar 13 18:32:12 pegmatite kernel: Using $PIR table, 9 entries at 0xc00f12d0 Mar 13 18:32:12 pegmatite kernel: acpi0: power button is handled as a fixed feature programming model. Mar 13 18:32:12 pegmatite kernel: Timecounter ACPI-fast frequency 3579545 Hz Mar 13 18:32:12 pegmatite kernel: acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 Mar 13 18:32:12 pegmatite kernel: acpi_cpu0: CPU port 0x530-0x537 on acpi0 Mar 13 18:32:12 pegmatite kernel: acpi_button0: Power Button on acpi0 Mar 13 18:32:12 pegmatite kernel: pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 Mar 13 18:32:12 pegmatite kernel: pci0: ACPI PCI bus on pcib0 Mar 13 18:32:12 pegmatite kernel: agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xf800-0xfbff at device 0.0 on pci0 Mar 13 18:32:12 pegmatite kernel: pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 Mar 13 18:32:12 pegmatite kernel: pcib1: could not get PCI interrupt routing table for \_SB_.PCI0.AGP_ - AE_NOT_FOUND Mar 13 18:32:12 pegmatite kernel: pci1: ACPI PCI bus on pcib1 Mar 13 18:32:12 pegmatite kernel: pci1: display, VGA at device 0.0 (no driver attached) Mar 13 18:32:12 pegmatite kernel: isab0: PCI-ISA bridge at device 4.0 on pci0 Mar 13 18:32:12 pegmatite kernel: isa0: ISA bus on isab0 Mar 13 18:32:12 pegmatite kernel: atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 4.1 on pci0 Mar 13 18:32:12 pegmatite kernel: ata0: at 0x1f0 irq 14 on atapci0 snip Mar 13 18:32:13 pegmatite kernel: vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Mar 13 18:32:13 pegmatite kernel: Timecounters tick every 1.000 msec Mar 13 18:32:13 pegmatite kernel: IP Filter: v3.4.31 initialized. Default = block all, Logging = enabled Mar 13 18:32:13 pegmatite kernel: acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% Mar 13 18:32:13 pegmatite kernel: ad0: 38166MB ST340016A [77545/16/63] at ata0-slave UDMA100 Mar 13 18:32:13 pegmatite kernel: acd0: CDROM FX4830T at ata1-slave PIO4 Mar 13 18:32:13 pegmatite kernel: Mounting root from ufs:/dev/ad0s1a And there it just hangs. I know there were some changes to the ATA code recently, I'll take a closer look at them later. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panics with GnuPG
I've been running -CURRENT on my workstation for a couple of months, and have been quite impressed. But I've started seeing pretty consistant panics when verifying PGP-signed messages. Everything was fine until I cvsup'ed about two weeks ago, and is still apparent in another cvsup as of March 10. So a rough timeline, I *wasn't* panic'ing about a month ago, and I am now. Anyone else seen something similar? I've managed to write down the actual panic twice (no panic to screen if you're in X), and they both look pretty similar. It seems to be caused directly by GnuPG trying to import a key it doesn't have from a keyserver. So it's not difficult to work around, but it'd be nice to have this working again. :) Here's the panic: Fatal trap 12: page fault in kernel mode fault virtual address = 0x20 fault code = supervisor read, page not present instruction pointer = 0x8:0xc023faf6 stack pointer = 0x10:0xdf10faa0 frame pointer = 0x10:0xdf10fac4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 11 (swi1: net) trap number = 12 panic: page fault And I just reproduced the panic, by typing: % gpg --recv-key BB6BC940 In case anyone asks, yes, it is the same version of GnuPG, and yes, I have already tried recompiling it since the new buildworld. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
