Re: -current lockup (how to diagnose?)
At Tue, 2 Dec 2003 01:45:43 -0500 (EST), Robert Watson wrote: Could you try compiling in DEBUG_LOCKS into your kernel and doing show lockedvnods with that? Okay. I'll use new kernel with DEBUG_LOCKS. Unfortunately, someone removed the pid from the output of that command, but didn't add the thread pointer to the DDB ps output, so you'll probably need to modify the lockmgr_printinfo() function in vfs_subr.c to print out lkp-lk_lockholder-td_proc-p_pid as well for exclusive locks. I don't understand what it means, but I'll try with this modification. Index: kern_lock.c === RCS file: /home/ncvs/src/sys/kern/kern_lock.c,v retrieving revision 1.70 diff -u -r1.70 kern_lock.c --- kern_lock.c 16 Jul 2003 01:00:38 - 1.70 +++ kern_lock.c 2 Dec 2003 07:04:49 - @@ -611,8 +611,8 @@ printf( lock type %s: SHARED (count %d), lkp-lk_wmesg, lkp-lk_sharecount); else if (lkp-lk_flags LK_HAVE_EXCL) - printf( lock type %s: EXCL (count %d) by thread %p, - lkp-lk_wmesg, lkp-lk_exclusivecount, lkp-lk_lockholder); + printf( lock type %s: EXCL (count %d) by thread %p (pid:%d), + lkp-lk_wmesg, lkp-lk_exclusivecount, lkp-lk_lockholder, lkp-lk_lockholder-td_proc-p_pid); if (lkp-lk_waitcount 0) printf( with %d pending, lkp-lk_waitcount); } It looks like maybe something isn't releasing a vnode lock before returning to userspace. I have some patches to assert that no lockmgr locks are held on the return to userspace, but I'll have to dig them up tomorrow and send them to you. Basically, it adds a per-thread lockmgr lock count in a thread-local variable, incrementing for each lock, and decrementing for each release, and then KASSERT()'s in userret that the variable is 0. Thanks! I'm waiting for your patch. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
/dev/fd0 not working with ACPI
In may 2003 there was a version of /usr/src/sys/contrib/dev/acpica/nsalloc.c in the tree so that the floppy disk interface was detected properly on my cheap and already a little old k7s5a motherboard at home. Currently there is the old io range problem as before. Are all others happy now with floppy support and acpi? (There are no newer bios updates for the board around AFAIK) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATAPI CD still not detected, verbose boot logs available
It seems Christoph Sold wrote: FreeBSD 5.2-B still does not detect my ATAPI DVD-ROM drive. This used to work until Søren's ATAng commits. Other OSes (Win, Linux, Solaris) detect the drive appropriately. Hmm from the bootlogs it seems that your drive does not set the proper ATAPI signature, thats why detection fails: atapci0: VIA 82C686A UDMA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata0-slave: stat=0x00 err=0x01 lsb=0x14 msb=0x80 should be 0xeb ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 mask=03 stat0=50 stat1=00 devices=0x1ATA_MASTER ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] There isn't much I can do about that one except you experimenting with the device and finding out why it fails setting the right signature -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA boot failure
On Sun, 2003-11-30 at 22:49, [EMAIL PROTECTED] wrote: Quoting Jerry Keefe [EMAIL PROTECTED]: I tried upgrading a Dell Optiplex GXa from Release 5.1p10 to the 5.2 Beta using the mini-install CD. The system hangs in the boot loader. This problem doesn't happen with the Release 5.1 CDs. try disabling acpi when you boot from cd via boot menu. -nth I disabled acpi. It didn't help. Still hangs on ata3, which is the CD-ROM. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
Daniel Eischen wrote: licq 1.2.7 installed from ports does not works on 5.2-BETA with mapping libc_r to libkse: %licq -d0 -p qt-gui -- -noxim Fatal error 'No current thread. ' at line 318 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno = 2) I just built and installed this under -current and it seems to work fine. I invoke it as you describe above. Are you using an nvidia driver or openGL? I am using nvidia driver installed from ports. But how it related? -- Alexander Motin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Daily lockups on 5.2-BETA (maybe pst driver bug?)
Hello, I'm seeing daily lockups on an up to date -CURRENT machine. I've had the debugger already compiled in, but it didn't save a crashdump. The machine is mostly idle, it has only some IMAP mailboxes under cyrus. All I could save from the console is the following: pst: timeout mfa=0x002a5850 cmd=0x02 pst: timeout mfa=0x002a38d0 cmd=0x02 pst: timeout mfa=0x002a5af0 cmd=0x02 interrupt total irq1: atkbd0 246 irq8: rtc7800771 irq13: npx01 stray irq131 irq14: ata0 144893 irq15: ata1 30 irq48: pstpci0345956 irq54: em0304160 irq0: clk6093522 Total 14689580 watchdog_fire(e65e4b08,c7dfeb00,e65e4a98,c05df35c) at watchdog_fire+0xab hardlock(e65e4b08,c3f08a00,e65e4ab8,c05df2e4,c7eb0800) at hardlock+0x147 clkintr(e65e4b08,e65e4ac8,46,0,cad91c80) at clkintr+0xef intr_execute_handlers(c0645d20,e65e4b08,e65e4b04,c05da5d6,80012) at intr_execute_handlers+0x8a atpic_handle_intr(0) at atpic_handle_intr+0xef Xatpic_intr0() at Xatpic_intr0+0x1e --- interrupt, eip = 0xc04bb328, esp = 0xe65e4b4c, ebp = 0xe65e4b70 --- lockmgr(d464ab34,80012,0,cad91c80,c0650010) at lockmgr+0x5ee getdirtybuf(e65e4bb4,0,1,d464aa68,1) at getdirtybuf+0xb7 flush_deplist(c8f86d44,1,e65e4bdc,e65e4be0,0) at flush_deplist+0x40 flush_inodedep_deps(c813c800,3219373,246,e65e4c38,c04cfbf7) at flush_inodedep_deps+0x83 softdep_sync_metadata(e65e4ca8,ce873000,50,c06176c6,0) at softdep_sync_metadata+0x7e ffs_fsync(e65e4ca8,0,0,0,0) at ffs_fsync+0x44f fsync(cad91c80,e65e4d14,4,29739000,1) at fsync+0x188 syscall(2f,2f,2f,bfbf6c24,0) at syscall+0x2ed Xint0x80_syscall() at Xint0x80_syscall+0x1d -- syscall (95), eip = 0x28385053, esp = 0xbfbf4b9c, ebp = 0xbfbfc68 --- Debugger(watchdog timeout) Stopped atDebugger+0x4f: xchgl %ebx,in_Debugger.0 db panic panic: from debugger cpuid = 0; boot() called on cpu#0 syncing disks, buffers remaining... panic: softdep_lock: locking against myself cpuid = 0; boot() called on cpu#0 Uptime: 16h55m37s dmesg: 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 5.2-BETA #6: Mon Dec 1 11:04:55 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IMAP Preloaded elf kernel /boot/kernel/kernel at 0xc06eb000. ACPI APIC Table: PTLTD APIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SS E2,SS,HTT,TM,PBE real memory = 2146893824 (2047 MB) avail memory = 2084335616 (1987 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard Pentium Pro MTRR support enabled acpi0: PTLTDRSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 21 entries at 0xc00fde70 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_cpu2: CPU on acpi0 device_probe_and_attach: acpi_cpu2 attach returned 6 acpi_cpu2: CPU on acpi0 device_probe_and_attach: acpi_cpu2 attach returned 6 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge mem 0xf800-0xfbff at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 2.0 on pci0 pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND pci2: ACPI PCI bus on pcib2 pci2: base peripheral, interrupt controller at device 28.0 (no driver attached) pcib3: ACPI PCI-PCI bridge at device 29.0 on pci2 pci3: ACPI PCI bus on pcib3 pcib4: PCI-PCI bridge at device 1.0 on pci3 pci4: PCI bus on pcib4 pstpci0: Promise SuperTrak SX6000 ATA RAID controller mem 0xf240-0xf27f irq 48 at device 1.1 on pci3 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.19 port 0x3000-0x303f mem 0xf210-0xf211 irq 54 at device 3. 0 on pci3 em0: Speed:N/A Duplex:N/A pci2: base peripheral, interrupt controller at device 30.0 (no driver attached) pcib5: ACPI PCI-PCI bridge at device 31.0 on pci2 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 30.0 on pci0 pci6: ACPI PCI bus on pcib6 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 UDMA100 controller port 0x2440-0x244f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 mem 0xf000-0xf 3ff
[current tinderbox] failure on i386/i386
TB --- 2003-12-02 07:43:21 - tinderbox 2.2 running on cueball.rtp.FreeBSD.org TB --- 2003-12-02 07:43:21 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-12-02 07:43:21 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-12-02 07:45:17 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything.. TB --- 2003-12-02 08:47:10 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue Dec 2 08:47:10 GMT 2003 Kernel build for GENERIC completed on Tue Dec 2 09:02:12 GMT 2003 TB --- 2003-12-02 09:02:12 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-12-02 09:02:12 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Dec 2 09:02:12 GMT 2003 -- === LINT mkdir -p /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys cd /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf; PATH=/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/sbin:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/bin:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/games:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/sbin:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/bin:/home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf/LINT WARNING: unknown option `ELAN_XTAL' removed from /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/opt_cpu.h WARNING: unknown option `ELAN_PPS' removed from /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/LINT/opt_cpu.h /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf/LINT: unknown option ELAN_PPS *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-12-02 09:02:13 - TB --- /usr/bin/make returned exit code 1 TB --- 2003-12-02 09:02:13 - TB --- ERROR: failed to build lint kernel TB --- 2003-12-02 09:02:13 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bash2 linked dynamically
On Mon, 1 Dec 2003, Leo Bicknell wrote: In a message written on Sun, Nov 30, 2003 at 09:48:45PM -0800, David O'Brien wrote: Lucky for me (who wants a static Bash), I don't have to make the decission -- ports are frozen and have been for a while. This line of thinking seems a bit silly to me. We have a long discussion documenting the dynamic root concept, and how it was deemed important that /bin/sh be dynamic to support NSS and other reasons. Now someone wants the same thing in bash, and commit-freeze is going to stop it from happening? Sounds like the core team, or re, or someone needs to decide which is more important. If NSS is so important redoing the whole root is important, then I sure think any and all shells installed by ports should support the same features. If, on the other hand it's not important for Bash then why in the heck are we doing it for the root? I'm done arguing for either side of this issue, but I will argue for consistency until I'm blue in the face. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org Don't bother about it. There was a discussion, and some people thinks that if something isn't broken (static linking), thne no one should fix it (dynamic linking). Perhaps they thinks that Billy will test dynamic linking in CURRENT and the performance will be OK... Maybe he will... But OS will became Microsoft (R) FreeBSD (TM) then... IMHO... If we want to reduce dynamic linking penalty - we MUST to do it... Go forward, testing and fixing things, that gives us performance loss... But static is a cure for these penalties... Sincerely, Maxim M. Kazachek mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
How to disable devices in -current / 5.2-BETA?
Hello, I'm trying to boot 5.2-BETA with aac, which panics as has been reported here and I can confirm panics too. I would like to try boot with aac disabled for now, but it does not work for me. There is suggested in device.hints(5), that I can do set hint.driver.unit.disabled=1 however it does not work for me - neither in loader prompt, nor in /boot/device.hints. Exactly, I'm trying hint.aac.0.disabled=1 in /boot/device.hints or set hint.aac.0.disabled=1 in loader prompt. I have tried hint.lpt.0.disabled, hint.sio.0.disabled, hint.ppi.0.disabled and hint.orm.0.disabled too, but I would not be able to disable any device and still all devices are detected during boot and 5.2-BETA panics with aac in all cases. Please, does anybody know, what I'm doing wrong and how to exactly disable any device from GENERIC kernel, atleast aac? Does really work disabling of devices through hint.driver.unit.disabled? Thanks. -- Rudolf Cejka cejkar at fit.vutbr.cz http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
System hangs solid with ATAPICAM
Hello, I've tried over several weeks to get ATAPICAM to work for me. I've tried with and without acpi (compiled in or disabled via. boot). I've tried turning on all debug. I've tried a few misc. thigs. All leave my system hanging after the GEOM initialization without any indication of debug output. The only clue I have is that it sounds like my zip-100 was accessed right before the hang. I've looked and there appear to be some other reports of ATAPICAM problems, but I didn't see this one (possibly related to zip drive). Are ATAPICAM issues to be resolved before 5.2? Cheers, Sean ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI results Inspiron 8000
On Tuesday 02 December 2003 00:47, Daniel O'Connor wrote: On Tuesday 02 December 2003 08:46, Ryan wrote: Are you able to suspend to disk? So far I haven't been able to suspend to disk on my Inspiron 8200. I'm using the fixed DSDT table from the URL you posted as well. The fixed DSDT only fixes the battery issue (which is cosmetic IMO). S1 state still does not power-off the display, and S3/S4 states still reboot. I see now that the attachment with the IASL dump was stripped by the mailing list. Is there anybody who still wants that? I used to suspend to disk in 4.x after creating the S2D partition with the floppy image from Dell, however I don't any more.. I kept the Dell partition intact. Or does it need special formatting? Basically it takes so long to suspend and resume with a decent amount of memory (256Mb+) that it's not worth it - most of my applications are smart enough to save state when they quit :) Hmm, since I have 512 and might upgrade to 1G of memory, I guess I don't need it either :). But it should error out and resume normal powerstate if for whatever reason suspension does not work. It should not reboot. -- Melvyn === FreeBSD sarevok.idg.nl 5.2-BETA FreeBSD 5.2-BETA #2: Mon Dec 1 17:58:47 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAREVOK_NOFW_DBG i386 === pgp0.pgp Description: signature
Re: [PATCH] fixes of tcp_hostcache.c
Greetings, I found two calls of bcopy() in tcp_hostcache.c got the source and the destination pointer wrongly. # Perhaps the author got confused with memcpy(), I guess. Indeed. Originally these were memcpy calls and I've been asked to change them to bcopy calls. Which I did. It didn't occur to me that bcopy would change the destination from left-hand to right-hand argument... But that seems to be a common pitfall. :/ The fix is attached as a patch against tcp_hostcache.c as of revision 1.2. Please review and incorporate the patch to the tree because the bug makes hostcache useless with TCPv6 and/or brings TTCP (RFC1644) meaningless. Especially the bug renders it unusable to use TCPv6 and TTCP together. # To confirm this: sysctl net.inet.tcp.rfc1644=1; telnet ::1 This also fixes the problem Hajimu-san is seeing with pathmtu discovery which I thought to reside in ip6_getpmtu(). Thank you for catching the bug! -- Andre ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System hangs solid with ATAPICAM
On Tue, 2 Dec 2003, Sean McNeil wrote: I've tried over several weeks to get ATAPICAM to work for me. I've tried with and without acpi (compiled in or disabled via. boot). I've tried turning on all debug. I've tried a few misc. thigs. All leave my Did you try backing out rev.1.23 of ata_lowlevel.c? system hanging after the GEOM initialization without any indication of debug output. The only clue I have is that it sounds like my zip-100 was accessed right before the hang. That's interesting. The bug avoided by backing out rev.1.23 of ata-lowlevel.c is obviously system dependent. I only see it on a system that has a zip100. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PLEASE TEST: FreeBSD-current if_sis patch
Please test this patch, hopefully it improves the short cable
situation on FreeBSD-current.
Poul-Henning
Index: if_sis.c
===
RCS file: /home/ncvs/src/sys/pci/if_sis.c,v
retrieving revision 1.90
diff -u -r1.90 if_sis.c
--- if_sis.c14 Nov 2003 19:00:31 - 1.90
+++ if_sis.c2 Dec 2003 11:27:10 -
@@ -2095,6 +2095,28 @@
sis_list_tx_init(sc);
/*
+* Page 78 of the DP83815 data sheet (september 2002 version)
+* recommends the following register settings for optimum
+* performance. for rev 15C. The driver from NS also sets
+* the PHY_CR register for later versions.
+*/
+ if (sc-sis_type == SIS_TYPE_83815) {
+ CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);
+ /* DC speed = 01 */
+ CSR_WRITE_4(sc, NS_PHY_CR, 0x189C);
+ if (sc-sis_srr == NS_SRR_15C) {
+ /* set val for c2 */
+ CSR_WRITE_4(sc, NS_PHY_TDATA, 0x);
+ /* load/kill c2 */
+ CSR_WRITE_4(sc, NS_PHY_DSPCFG, 0x5040);
+ /* rais SD off, from 4 to c */
+ CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C);
+ }
+ CSR_WRITE_4(sc, NS_PHY_PAGE, 0);
+ }
+
+
+ /*
* For the NatSemi chip, we have to explicitly enable the
* reception of ARP frames, as well as turn on the 'perfect
* match' filter where we store the station address, otherwise
@@ -2148,7 +2170,6 @@
CSR_WRITE_4(sc, SIS_RX_CFG, SIS_RXCFG256);
}
-
/* Accept Long Packets for VLAN support */
SIS_SETBIT(sc, SIS_RX_CFG, SIS_RXCFG_RX_JABBER);
@@ -2183,12 +2204,15 @@
CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);
reg = CSR_READ_4(sc, NS_PHY_DSPCFG);
+ /* Allow coefficient to be read */
CSR_WRITE_4(sc, NS_PHY_DSPCFG, (reg 0xfff) | 0x1000);
DELAY(100);
reg = CSR_READ_4(sc, NS_PHY_TDATA);
- if ((reg 0x0080) == 0 || (reg 0xff) = 0xd8) {
+ if ((reg 0x0080) == 0 ||
+(reg 0xd8 reg = 0xff)) {
device_printf(sc-sis_self, Applying short cable fix
(reg=%x)\n, reg);
CSR_WRITE_4(sc, NS_PHY_TDATA, 0x00e8);
+ /* Adjust coefficient and prevent change */
SIS_SETBIT(sc, NS_PHY_DSPCFG, 0x20);
}
CSR_WRITE_4(sc, NS_PHY_PAGE, 0);
@@ -2216,21 +2240,6 @@
#ifdef notdef
mii_mediachg(mii);
#endif
-
- /*
-* Page 75 of the DP83815 manual recommends the
-* following register settings for optimum
-* performance. Note however that at least three
-* of the registers are listed as reserved in
-* the register map, so who knows what they do.
-*/
- if (sc-sis_type == SIS_TYPE_83815) {
- CSR_WRITE_4(sc, NS_PHY_PAGE, 0x0001);
- CSR_WRITE_4(sc, NS_PHY_CR, 0x189C);
- CSR_WRITE_4(sc, NS_PHY_TDATA, 0x);
- CSR_WRITE_4(sc, NS_PHY_DSPCFG, 0x5040);
- CSR_WRITE_4(sc, NS_PHY_SDCFG, 0x008C);
- }
ifp-if_flags |= IFF_RUNNING;
ifp-if_flags = ~IFF_OACTIVE;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA dsp.c duplicate lock
Maxime Henrion wrote: Mathew Kanner wrote: [patch ripped] Maxime, I think it would be better to isolate the changes (DUP_OK flag and lock creation) to just the channel code, no need to touch every driver. Yes, but to do this I'd need either to make the channel code use mtx_init() directly, which would defeat the purpose of the USING_MUTEX define, or to completely unifdef -U it. Since I had no idea if this code was actually used or not, I went the safe way and just changed the snd_mtxcreate() wrapper interface to accept mutex options. For what it's worth, there is at least one direct invokation of mtx_init() in the sound drivers, so it seems this define is actually already broken. This needs to be sorted out before committing this patch if we need to, but for now, I just wanted to see if using MTX_DUPOK solved the problem or not. I'll try to test later today. Thanks! -- Jesse Guardiani, Systems Administrator WingNET Internet Services, P.O. Box 2605 // Cleveland, TN 37320-2605 423-559-LINK (v) 423-559-5145 (f) http://www.wingnet.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
On Tue, 2 Dec 2003, Alexander Motin wrote: Daniel Eischen wrote: licq 1.2.7 installed from ports does not works on 5.2-BETA with mapping libc_r to libkse: %licq -d0 -p qt-gui -- -noxim Fatal error 'No current thread. ' at line 318 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno = 2) I just built and installed this under -current and it seems to work fine. I invoke it as you describe above. Are you using an nvidia driver or openGL? I am using nvidia driver installed from ports. But how it related? You haven't told me if you are getting static LDT warnings out of the kernel (check /var/log/messages). libthr, libkse, and nvidia drivers/OpenGL use LDTs and %gs. nvidia drivers (and/or their version of OpenGL) stomp on the LDTs/%gs that both libthr and libkse use. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System hangs solid with ATAPICAM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 02 Dec 2003 11:48, Sean McNeil wrote: Hello, I've tried over several weeks to get ATAPICAM to work for me. I've tried with and without acpi (compiled in or disabled via. boot). I've tried turning on all debug. I've tried a few misc. thigs. All leave my system hanging after the GEOM initialization without any indication of debug output. The only clue I have is that it sounds like my zip-100 was accessed right before the hang. I had (last time I checked) the same problem with my LS-120 (a 120Mb ATAPI floppy drive). Putting a disk in it during boot worked as a workaround and that allowed me to boot. I've since taken out atapicam because this got old fairly quickly. I think this goes back to when ATAng came in. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/zJ7TLqgJ90OcaiARAqE3AJ9CK/HHogf8CfwQkPr4ZR7xnxIGSgCgqc0n atSsfkWW/3SuKcY1IE5g5Fk= =abdJ -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
Alexander Motin wrote: licq 1.2.7 installed from ports does not works on 5.2-BETA with mapping libc_r to libkse: %licq -d0 -p qt-gui -- -noxim Fatal error 'No current thread. ' at line 318 in file /usr/src/lib/libpthread/thread/thr_sig.c (errno = 2) I just built and installed this under -current and it seems to work fine. I invoke it as you describe above. Are you using an nvidia driver or openGL? I am using nvidia driver installed from ports. But how it related? You haven't told me if you are getting static LDT warnings out of the kernel (check /var/log/messages). If I use libkse I get: kernel: Warning: pid 25341 used static ldt allocation. kernel: See the i386_set_ldt man page for more info in my messages. When I use libc_r I do not get this messages. I'm sorry. Messages seems to be independent from library. I get messages with both libraries but not every time. Some times I get two messages on one licq launching. But with libc_r it works and with libkse is not. libthr, libkse, and nvidia drivers/OpenGL use LDTs and %gs. nvidia drivers (and/or their version of OpenGL) stomp on the LDTs/%gs that both libthr and libkse use. I test this on other PC with ATI video without loading nvidia module. Situation is the same. -- Alexander Motin [EMAIL PROTECTED] ISP Alkar-Teleport ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
On Tue, 2 Dec 2003, Alexander Motin wrote: Daniel Eischen wrote: You haven't told me if you are getting static LDT warnings out of the kernel (check /var/log/messages). If I use libkse I get: kernel: Warning: pid 25341 used static ldt allocation. kernel: See the i386_set_ldt man page for more info in my messages. When I use libc_r I do not get this messages. This is why libkse doesn't work (nor is libthr likely to work). libthr, libkse, and nvidia drivers/OpenGL use LDTs and %gs. nvidia drivers (and/or their version of OpenGL) stomp on the LDTs/%gs that both libthr and libkse use. I test this on other PC with ATI video without loading nvidia module. Situation is the same. Do you still get static ldt warnings on this system? If so, then some library or module is causing the same problem. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 02 Dec 2003 14:05, Daniel Eischen wrote: libthr, libkse, and nvidia drivers/OpenGL use LDTs and %gs. nvidia drivers (and/or their version of OpenGL) stomp on the LDTs/%gs that both libthr and libkse use. Have nvidia indicated if / when they are are likely to fix this? Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/zKmKLqgJ90OcaiARArf9AJ0Vuqitpir6dtftyPUuzHcmb2RJlgCgzkK6 zItLBnfZMTXaM4Gfvm76XOs= =ajNz -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
On Tue, 2 Dec 2003, Alexander Motin wrote: Alexander Motin wrote: If I use libkse I get: kernel: Warning: pid 25341 used static ldt allocation. kernel: See the i386_set_ldt man page for more info in my messages. When I use libc_r I do not get this messages. I'm sorry. Messages seems to be independent from library. I get messages with both libraries but not every time. Some times I get two messages on one licq launching. But with libc_r it works and with libkse is not. It is not libkse that is causing the messages. It is some library or driver that licq is using. The kernel spews these messages whenever something uses static LDT allocation. We know that nvidia drivers and/or their OpenGL library do this, and they have been notified of it (by me). If there is another library or application that is also using static LDT allocation, please help us find it so it can be fixed also. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
On Tue, 2 Dec 2003, Mark Dixon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 02 Dec 2003 14:05, Daniel Eischen wrote: libthr, libkse, and nvidia drivers/OpenGL use LDTs and %gs. nvidia drivers (and/or their version of OpenGL) stomp on the LDTs/%gs that both libthr and libkse use. Have nvidia indicated if / when they are are likely to fix this? I sent them an email a couple of days ago and received a response saying they would investigate it for the next release of their software. I do not know anything more than that. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 4 - 5 Problem
I've just tried this again, and noticed an error message that I'd missed: [EMAIL PROTECTED]:/usr/src# make installkernel make: no target to make. /usr/src/Makefile.inc1, line 157: warning: make -f /dev/null -m /usr/src/share/mk CPUTYPE=i686 -V CPUTYPE returned non-zero status cd /usr/obj/usr/src/sys/P6MPFW; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i686 GROFF_BIN_PATH=/usr/obj/usr/src/i386/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/legacy/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/legacy/usr/share/tmac PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/ bin:/usr/obj/usr/src/i386/legacy/usr/games:/usr/obj/usr/src/i386/usr/sbin:/u sr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/ sbin:/usr/bin make KERNEL=kernel install thiskernel=`sysctl -n kern.bootfile` ; if [ `dirname $thiskernel` != /boot/kernel ] ; then chflags -R noschg /boot/kernel ; rm -rf /boot/kernel ; else if [ -d /boot/kernel.old ] ; then chflags -R noschg /boot/kernel.old ; rm -rf /boot/kernel.old ; fi ; mv /boot/kernel /boot/kernel.old ; sysctl kern.bootfile=/boot/kernel.old/`basename $thiskernel` ; fi mkdir -p /boot/kernel install -p -m 555 -o root -g wheel kernel /boot/kernel *** Signal 12 I also tried un-setting CPUTYPE, but got the same error. This gives you a zero sized kernel in /boot/kernel. Running install -p -m 555 -o root -g wheel kernel /boot/kernel from within the correct /obj directory works though. Lawrence Farr EPC Direct Limited -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence Farr Sent: 26 November 2003 19:32 To: [EMAIL PROTECTED] Subject: RE: 4 - 5 Problem I'm still getting this with fresh sources. Has anyone else done 4-5 in the last few days? Is it worth filing a PR? Lawrence Farr EPC Direct Limited -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lawrence Farr Sent: 25 November 2003 16:27 To: 'Clement Laforet' Cc: [EMAIL PROTECTED] Subject: RE: 4 - 5 Problem Err yes I did. Im trying to install a kernel. Lawrence Farr EPC Direct Limited -Original Message- From: Clement Laforet [mailto:[EMAIL PROTECTED] Sent: 25 November 2003 16:26 To: Lawrence Farr Cc: [EMAIL PROTECTED] Subject: Re: 4 - 5 Problem On Tue, 25 Nov 2003 16:18:26 - Lawrence Farr [EMAIL PROTECTED] wrote: the Current target machine is from Thu Sep 25 14:32:19 GMT 2003, the stable one from Mon Mar 24 16:30:45 GMT 2003, and the src and obj are fresh from last night. did you read /usr/src/UPDATING ? 20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a `installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. clem ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Periodic Scripts - Configuration problem?
[EMAIL PROTECTED] wrote: I recently change the hostname of my FreeBSD host to remove a hyphen from the name (i.e. skrap-node to skrapnode) Since then, all of the periodic output scripts send their mail output to [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Only the mail delivery failures make it to my inbox. Mail works fine for all users, this just affects the periodic scripts. I have tried grep'ing for the incorrect hostname in the /etc/periodic/blah... But haven't found anything. the easiest thing to check right now is the output of hostname. also, i *think* that the periodic scripts send mail to root (i.e., they don't add the domain), so perhaps sendmail is adding this? try: # sendmail -bv root if that is the case, check /etc/mail/sendmail.cf for the hardcoded hostname, or give sendmail a bit of -HUP (make restart in /etc/mail) hope this helps ~jon - Yesterday upon the stair I saw a man who wasn't there, he wasn't there again today, oh how i wish he'd go away Rev. Jonathan T. Sage Lighting / Set Designer Professional Web Design [HTTP://thr.msu.edu] [EMAIL PROTECTED] [PGP: www.keyserver.net] -- Yesterday upon the stair I saw a man who wasn't there, he wasn't there again today, oh how i wish he'd go away Rev. Jonathan T. Sage Lighting / Set Designer Professional Web Design [HTTP://thr.msu.edu] [EMAIL PROTECTED] [PGP: www.keyserver.net] pgp0.pgp Description: PGP signature
User mounts could not use character conversions (libkiconv is just for roots)
Hello, I have found, that user mounts using libkiconv.so (msdosfs, cd9660, ...) could not use character code conversions, beause writing to sysctl kern.iconv.add is allowed just for root. Personally, I have created small patch, which allows to change kern.iconv.add to anybody, so it does work for me. Does anybody know, if there are security drawbacks and if it can or can not be commited? Thanks. --- sys/libkern/iconv.c.origTue Dec 2 16:58:05 2003 +++ sys/libkern/iconv.c Tue Dec 2 16:59:57 2003 @@ -401,7 +401,8 @@ return error; } -SYSCTL_PROC(_kern_iconv, OID_AUTO, add, CTLFLAG_RW | CTLTYPE_OPAQUE, +SYSCTL_PROC(_kern_iconv, OID_AUTO, add, CTLFLAG_RW | CTLFLAG_ANYBODY + | CTLTYPE_OPAQUE, NULL, 0, iconv_sysctl_add, S,xlat, register charset pair); /* -- Rudolf Cejka cejkar at fit.vutbr.cz http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
Daniel Eischen wrote: On Tue, 2 Dec 2003, Alexander Motin wrote: Alexander Motin wrote: If I use libkse I get: kernel: Warning: pid 25341 used static ldt allocation. kernel: See the i386_set_ldt man page for more info in my messages. When I use libc_r I do not get this messages. I'm sorry. Messages seems to be independent from library. I get messages with both libraries but not every time. Some times I get two messages on one licq launching. But with libc_r it works and with libkse is not. It is not libkse that is causing the messages. It is some library or driver that licq is using. The kernel spews these messages whenever something uses static LDT allocation. We know that nvidia drivers and/or their OpenGL library do this, and they have been notified of it (by me). If there is another library or application that is also using static LDT allocation, please help us find it so it can be fixed also. $ ldd /usr/local/bin/licq /usr/local/bin/licq: libssl.so.3 = /usr/lib/libssl.so.3 (0x28102000) libcrypto.so.3 = /lib/libcrypto.so.3 (0x28134000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x28242000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x28266000) libm.so.2 = /lib/libm.so.2 (0x28322000) libc.so.5 = /lib/libc.so.5 (0x2833b000) $ ldd ./licq_qt-gui.so ./licq_qt-gui.so: libqt-mt.so.3 = /usr/X11R6/lib/libqt-mt.so.3 (0x2828e000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x288d) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x288d9000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x288f) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x289b8000) libjpeg.so.9 = /usr/local/lib/libjpeg.so.9 (0x289c7000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x289e5000) libm.so.2 = /lib/libm.so.2 (0x28aa1000) libmng.so.1 = /usr/local/lib/libmng.so.1 (0x28aba000) libpng.so.5 = /usr/local/lib/libpng.so.5 (0x28b18000) libz.so.2 = /lib/libz.so.2 (0x28b3d000) libGL.so.1 = /usr/X11R6/lib/libGL.so.1 (0x28b4b000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x28bb2000) libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0x28bc8000) libXft.so.2 = /usr/X11R6/lib/libXft.so.2 (0x28bd) libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x28be2000) libfontconfig.so.1 = /usr/X11R6/lib/libfontconfig.so.1 (0x28c4c000) liblcms.so.1 = /usr/local/lib/liblcms.so.1 (0x28c74000) libGLcore.so.1 = /usr/X11R6/lib/libGLcore.so.1 (0x28c8f000) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x2912b000) libexpat.so.4 = /usr/local/lib/libexpat.so.4 (0x2917c000) -- Alexander Motin [EMAIL PROTECTED] ISP Alkar-Teleport ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Periodic Scripts - Configuration problem?
Jonathan T. Sage wrote: [EMAIL PROTECTED] wrote: I recently change the hostname of my FreeBSD host to remove a hyphen from the name (i.e. skrap-node to skrapnode) Since then, all of the periodic output scripts send their mail output to [EMAIL PROTECTED] instead of [EMAIL PROTECTED] Only the mail delivery failures make it to my inbox. Mail works fine for all users, this just affects the periodic scripts. I have tried grep'ing for the incorrect hostname in the /etc/periodic/blah... But haven't found anything. the easiest thing to check right now is the output of hostname. also, i *think* that the periodic scripts send mail to root (i.e., they don't add the domain), so perhaps sendmail is adding this? try: # sendmail -bv root if that is the case, check /etc/mail/sendmail.cf for the hardcoded hostname, or give sendmail a bit of -HUP (make restart in /etc/mail) Also, check /etc/mail/aliases, and /etc/hosts Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Periodic Scripts - Configuration problem?
Eric - this should have been sent to -questions, but i'm getting used to a new mailer (thunderbird), and i'm an idiot. Eric Anderson wrote: **big snip** **/me hides in shame for being stupid again** pgp0.pgp Description: PGP signature
Re: 4 - 5 Problem
On Tue, Dec 02, 2003 at 04:33:42PM -, Lawrence Farr wrote: I've just tried this again, and noticed an error message that I'd missed: install -p -m 555 -o root -g wheel kernel /boot/kernel *** Signal 12 This usually means you've tried to update something out of the correct order. Kris pgp0.pgp Description: PGP signature
Re: Daily lockups on 5.2-BETA (maybe pst driver bug?)
On Tue, 2 Dec 2003, Attila Nagy wrote: I'm seeing daily lockups on an up to date -CURRENT machine. I've had the debugger already compiled in, but it didn't save a crashdump. The machine is mostly idle, it has only some IMAP mailboxes under cyrus. It appears you have the hardware watchdog enabled. Any reason you need that? It might be malfunctioning on your system. Also the pst driver might be grabbing interrupts for too long. You might check your RAID status. All I could save from the console is the following: pst: timeout mfa=0x002a5850 cmd=0x02 pst: timeout mfa=0x002a38d0 cmd=0x02 pst: timeout mfa=0x002a5af0 cmd=0x02 interrupt total irq1: atkbd0 246 irq8: rtc7800771 irq13: npx01 stray irq131 irq14: ata0 144893 irq15: ata1 30 irq48: pstpci0345956 irq54: em0304160 irq0: clk6093522 Total 14689580 watchdog_fire(e65e4b08,c7dfeb00,e65e4a98,c05df35c) at watchdog_fire+0xab hardlock(e65e4b08,c3f08a00,e65e4ab8,c05df2e4,c7eb0800) at hardlock+0x147 clkintr(e65e4b08,e65e4ac8,46,0,cad91c80) at clkintr+0xef intr_execute_handlers(c0645d20,e65e4b08,e65e4b04,c05da5d6,80012) at intr_execute_handlers+0x8a atpic_handle_intr(0) at atpic_handle_intr+0xef Xatpic_intr0() at Xatpic_intr0+0x1e --- interrupt, eip = 0xc04bb328, esp = 0xe65e4b4c, ebp = 0xe65e4b70 --- lockmgr(d464ab34,80012,0,cad91c80,c0650010) at lockmgr+0x5ee getdirtybuf(e65e4bb4,0,1,d464aa68,1) at getdirtybuf+0xb7 flush_deplist(c8f86d44,1,e65e4bdc,e65e4be0,0) at flush_deplist+0x40 flush_inodedep_deps(c813c800,3219373,246,e65e4c38,c04cfbf7) at flush_inodedep_deps+0x83 softdep_sync_metadata(e65e4ca8,ce873000,50,c06176c6,0) at softdep_sync_metadata+0x7e ffs_fsync(e65e4ca8,0,0,0,0) at ffs_fsync+0x44f fsync(cad91c80,e65e4d14,4,29739000,1) at fsync+0x188 syscall(2f,2f,2f,bfbf6c24,0) at syscall+0x2ed Xint0x80_syscall() at Xint0x80_syscall+0x1d -- syscall (95), eip = 0x28385053, esp = 0xbfbf4b9c, ebp = 0xbfbfc68 --- Debugger(watchdog timeout) Stopped atDebugger+0x4f: xchgl %ebx,in_Debugger.0 db panic panic: from debugger cpuid = 0; boot() called on cpu#0 syncing disks, buffers remaining... panic: softdep_lock: locking against myself cpuid = 0; boot() called on cpu#0 Uptime: 16h55m37s dmesg: 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 5.2-BETA #6: Mon Dec 1 11:04:55 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/IMAP Preloaded elf kernel /boot/kernel/kernel at 0xc06eb000. ACPI APIC Table: PTLTD APIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf27 Stepping = 7 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SS E2,SS,HTT,TM,PBE real memory = 2146893824 (2047 MB) avail memory = 2084335616 (1987 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard Pentium Pro MTRR support enabled acpi0: PTLTDRSDT on motherboard pcibios: BIOS version 2.10 Using $PIR table, 21 entries at 0xc00fde70 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_cpu2: CPU on acpi0 device_probe_and_attach: acpi_cpu2 attach returned 6 acpi_cpu2: CPU on acpi0 device_probe_and_attach: acpi_cpu2 attach returned 6 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge mem 0xf800-0xfbff at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 2.0 on pci0 pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.HLB_ - AE_NOT_FOUND pci2: ACPI PCI bus on pcib2 pci2: base peripheral, interrupt controller at device 28.0 (no driver attached) pcib3: ACPI PCI-PCI bridge at device 29.0 on pci2 pci3: ACPI PCI bus on pcib3 pcib4: PCI-PCI bridge at device 1.0 on pci3 pci4: PCI bus on pcib4 pstpci0: Promise SuperTrak SX6000 ATA RAID controller mem 0xf240-0xf27f irq 48 at device 1.1 on pci3 em0: Intel(R) PRO/1000 Network Connection, Version - 1.7.19 port 0x3000-0x303f mem 0xf210-0xf211 irq 54 at device 3. 0 on pci3 em0: Speed:N/A Duplex:N/A pci2: base peripheral, interrupt controller at device 30.0 (no driver attached)
BTX halts installing 5.x
I'm trying to install FreeBSD on a Dual Pentium Pro 200mhz 512K cache system and I am getting the following error: CD Loader 1.01 Building the boot loader arguements Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.01 int=0005 err= efl=00019286 eip=0001c8a4 eax=00a3 ebx= ecx= edx= esi=cce65d00 edi= ebp= esp=0009407c cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=62 6f 6f 74 2e 6e 65 74-69 66 2e 69 70 00 62 6f 6f 74 2e 6e 65 74 69 66-2e 6e 65 74 6d 61 73 6b ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted I've tried warm booting after this and I get the same results. I've tried 5.0-RELEASE, 5.0-DP1, 5.1-RELEASE, and three different snapshots, all of which work fine on my other machines, including one other SMP box. It's also worth noting that 4.8-RELEASE and 4.9-RELEASE install fine on this box. I can boot 4.9 and post a dmesg if that would help, but to briefly describe the hardware: Intel PR440FX Mainboard Dual Pentium Pro 200mhz 512K Cache CPUs Adaptec 7880 SCSI controller 4.3 gig IBM Wide SCSI-2 Disks Intel EtherExpress Pro LAN adapter I've tried a couple different video cards, Cirrus Logis and SIS PCI 320 Megs of Registered ECC SDRAM I've tried googling for a solution for this as well as perused the -CURRENT archives and haven't seen anything relevent to this issue. Thanks in Advance, Josh Paetzel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable devices in -current / 5.2-BETA?
In message: [EMAIL PROTECTED] Rudolf Cejka [EMAIL PROTECTED] writes: : : Hello, : I'm trying to boot 5.2-BETA with aac, which panics as has been : reported here and I can confirm panics too. I would like to try : boot with aac disabled for now, but it does not work for me. : There is suggested in device.hints(5), that I can do : set hint.driver.unit.disabled=1 : however it does not work for me - neither in loader prompt, nor : in /boot/device.hints. : : Exactly, I'm trying : hint.aac.0.disabled=1 : in /boot/device.hints or : set hint.aac.0.disabled=1 : in loader prompt. You can't disable pci devices. You lose. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4 - 5 Problem
In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : On Tue, Dec 02, 2003 at 04:33:42PM -, Lawrence Farr wrote: : : I've just tried this again, and noticed an error message that I'd : missed: : : install -p -m 555 -o root -g wheel kernel /boot/kernel : *** Signal 12 : : This usually means you've tried to update something out of the correct : order. Signal 12 means thaqt you didn't upgrade your kernel first. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable devices in -current / 5.2-BETA?
On Tue, 2 Dec 2003, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Rudolf Cejka [EMAIL PROTECTED] writes: : : Hello, : I'm trying to boot 5.2-BETA with aac, which panics as has been : reported here and I can confirm panics too. I would like to try : boot with aac disabled for now, but it does not work for me. : There is suggested in device.hints(5), that I can do : set hint.driver.unit.disabled=1 : however it does not work for me - neither in loader prompt, nor : in /boot/device.hints. : : Exactly, I'm trying : hint.aac.0.disabled=1 : in /boot/device.hints or : set hint.aac.0.disabled=1 : in loader prompt. You can't disable pci devices. You lose. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] The aac problem will be fixed soon, I'm just reviewing it for any other hidden problems. However, having a general mechanism for disabling newbus devices would be really nice. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 4 - 5 Problem
I get this error when trying to install the kernel, the same kernel installs fine on the box that made it. [EMAIL PROTECTED]:/usr/src# make installkernel Lawrence Farr EPC Direct Limited -Original Message- From: M. Warner Losh [mailto:[EMAIL PROTECTED] Sent: 02 December 2003 17:16 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: 4 - 5 Problem In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : On Tue, Dec 02, 2003 at 04:33:42PM -, Lawrence Farr wrote: : : I've just tried this again, and noticed an error message that I'd : missed: : : install -p -m 555 -o root -g wheel kernel /boot/kernel : *** Signal 12 : : This usually means you've tried to update something out of the correct : order. Signal 12 means thaqt you didn't upgrade your kernel first. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX halts installing 5.x
Hi, On Tuesday 02 December 2003 19:11, Josh Paetzel wrote: I'm trying to install FreeBSD on a Dual Pentium Pro 200mhz 512K cache system and I am getting the following error: I just tried installing the same versions as you (only one recent snapshot though) on my VS440FX based box, with the same results except for the value of efl: int=0005 err= efl=00019286 eip=0001c8a4 mine: 00010286 I've tried warm booting after this and I get the same results. I've tried 5.0-RELEASE, 5.0-DP1, 5.1-RELEASE, and three different snapshots, all of which work fine on my other machines, including one other SMP box. It's also worth noting that 4.8-RELEASE and 4.9-RELEASE install fine on this box. This one is happily running 4.9, and has run everything from 4.3 upwards. From 4.9: CPU: Pentium Pro (199.43-MHz 686-class CPU) Origin = GenuineIntel Id = 0x619 Stepping = 9 Features=0xf9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV I've tried googling for a solution for this as well as perused the -CURRENT archives and haven't seen anything relevent to this issue. Same here. I've put the dmesg from 4.9 at http://hex.athame.co.uk/FreeBSD/dmesg.txt It's not essential this box runs 5.x (it's my fileserver so I like some stability), but I thought I would add something to show you aren't the only one affected by this. Cheers, Andy -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates. -- anon | [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI problem, my VAIO won't come back from suspension
Hello, I have a Sony VAIO PCG-GRX626P, and I'm using a two days old FreeBSD current, and pretty much everything works, except that when I move into sleep mode 3 (acpiconf -s 3) I cannot bring my lap back. :-( The fan starts again, but nothing else happens, after a while I just power off the machine. I might be missing something, please point me to the right docs. TIA, --Francisco ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable devices in -current / 5.2-BETA?
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : However, having a general mechanism for disabling newbus devices would be : really nice. Agreed. But today and 5.2 you lose. However, it isn't easy. What does disabled mean? Don't attach? Don't even probe? If you don't probe, then how do you know that the device is aac.0? If you do probe, then you get ISA probe routines called that can be 'destructive'. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Daily lockups on 5.2-BETA (maybe pst driver bug?)
Doug White wrote: It appears you have the hardware watchdog enabled. Any reason you need that? It might be malfunctioning on your system. It's FreeBSD's WATCHDOG, and all I compiled that in is why I needed the machine to go. But it doesn't :-O It freezes without the watchdog completely. Also the pst driver might be grabbing interrupts for too long. You might check your RAID status. Is it normal that a RAID driver crashes the kernel when a RAID array is down? BTW, the card's bios doesn't show any problems (it's dumb as the earth), but I will check it with its Windows stuff, but first I need to install a Windows somewhere... Thanks. -- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU) phone @work: +361 210 1415/127 ISOs: http://www.fsn.hu/?f=downloadcell.: +3630 306 6758 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX halts installing 5.x
On Tue, Dec 02, 2003 at 11:11:18AM -0600, Josh Paetzel wrote: I'm trying to install FreeBSD on a Dual Pentium Pro 200mhz 512K cache system and I am getting the following error: CD Loader 1.01 SNIP BTX halted SNIP booting 4.9 cd works 5.anything doesn't Intel PR440FX Mainboard Dual Pentium Pro 200mhz 512K Cache CPUs Intel EtherExpress Pro LAN adapter Adaptec 7880 SCSI controller I have the above running 5.1-CURRENT, but I got there with a source upgrade from 4.8. Works fine. 4.3 gig IBM Wide SCSI-2 Disks I'm not actually using the SCSI controller. I, instead, have a Promise IDE RAID controller. The disks are fast enough for the CPU. I've tried a couple different video cards, Cirrus Logis and SIS PCI 320 Megs of Registered ECC SDRAM ATI Rage video and I'm currently down to 128MB 50ns ECC EDO (SDRAM)? RAM. I was getting random failures and the BIOS had logged some ECC evevents on the 64MB stick. I also have a : bt0: BT-948 FW Rev. 5.06I Ultra Narrow SCSI Host Adapter to run the : sa0: HP C1533A A612 Removable Sequential Access SCSI-2 device My Adaptec controller is completely idle. I've tried googling for a solution for this as well as perused the -CURRENT archives and haven't seen anything relevent to this issue. If you don't get it resolved, I can try booting a 5.x install cd on it's twin brother, 1 CPU, no Promise, no BT-948, which is sitting unpowered at the house, before I scavenge the RAM for this box. -- Scott LambertKC5MLE Unix SysAdmin [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable devices in -current / 5.2-BETA?
On Tue, Dec 02, 2003 at 11:11:48AM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : However, having a general mechanism for disabling newbus devices would be : really nice. Agreed. But today and 5.2 you lose. However, it isn't easy. What does disabled mean? Don't attach? Don't even probe? If you don't You could disable the driver altogether. Assuming that is what is desired. -- | / o / /_ _ |/|/ / / /( (_) Bulte [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
On 02-Dec-2003 Scott Long wrote: On Tue, 2 Dec 2003, Greg 'groggy' Lehey wrote: On Monday, 1 December 2003 at 10:01:23 -0500, Robert Watson wrote: This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. Show stopper defects for 5.2-RELEASE ++ | Issue | Status |Responsible |Description| |---+---++---| | | ||The new i386 interrupt code| |ACPI kernel| ||requires that ACPI be compiled into| |module |In progress|John Baldwin|the kernel if it to be used. Work | | | ||is underway to restore the ability | | | ||to load it as a module.| |---+---++---| I'm currently investigating ACPI problems on a dual processor Intel motherboard (re@ knows about this). It looks as if the new code is much fussier than the old code about the quality of the motherboard BIOS: this machine runs fine on 5.1, but won't finish booting on 5.2-BETA. Yes, this is probably an ACPI bug, but users aren't going to see it that way: if we release a 5.2 which won't boot on a lot of machines, people are going to blame 5.2, not the machine. I think we should ensure that there's at least a fallback for machines with broken ACPI. This argument is exactly why I added the 'disable acpi' option in the boot loader menu. Of course, we STILL need to get good debugging information from you as to why you get a Trap 9 when ACPI is disabled. This is the more important issue. This is actually a known issue on Intel motherboards. Somehow we broke something in our bios32 code. 4.x works fine using the BIOS to enumerate PNP BIOS devices, but 5.x (including 5.0 and 5.1) get a GPF (Trap 9) with the code segment set to 0x58 trying to enumerate the last PNPBIOS device. Somehow the BIOS routine jumps off into lala land where it eventually traps. I dumped the BIOS and dissassembled and tried to walk it to figure out how it was breaking but couldn't see anything obvious. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 4 - 5 Problem
On Tue, Dec 02, 2003 at 05:27:12PM -, Lawrence Farr wrote: I get this error when trying to install the kernel, the same kernel installs fine on the box that made it. [EMAIL PROTECTED]:/usr/src# make installkernel -Original Message- From: M. Warner Losh [mailto:[EMAIL PROTECTED] Sent: 02 December 2003 17:16 : : install -p -m 555 -o root -g wheel kernel /boot/kernel : *** Signal 12 : : This usually means you've tried to update something out of the correct : order. Signal 12 means thaqt you didn't upgrade your kernel first. I've observed this when installing on a different system than the build system. I got it after building/installing several times on the build system before trying to installkernel on another system with /usr/src and /usr/obj nfs-mounted. The problem appeared to be that the stuff in the legacy directory under /usr/obj is built assuming that what's on the build system will work under the prior kernel - which is true on the build system but not necessarily on the target system. My solution was to edit (temporarily) /usr/src/Makefile.inc1 to put /usr/bin first in the PATH set up for the reinstallkernel target. That allowed make installkernel to succeed on the target system. Then I rebooted the target and backed out the change to /usr/src/Makefile.inc1, and after that make installworld and mergemaster went fine as usual. I didn't delve deeply enough to figure out what a cleaner fix would be, but this should probably be a PR as otherwise the 5.2 upgrade may be difficult for people who build and install on separate boxes. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
On Mon, 1 Dec 2003, Scott Long wrote: On Tue, 2 Dec 2003, Greg 'groggy' Lehey wrote: On Monday, 1 December 2003 at 10:01:23 -0500, Robert Watson wrote: ... I'm currently investigating ACPI problems on a dual processor Intel motherboard (re@ knows about this). It looks as if the new code is much fussier than the old code about the quality of the motherboard BIOS: this machine runs fine on 5.1, but won't finish booting on 5.2-BETA. Yes, this is probably an ACPI bug, but users aren't going to see it that way: if we release a 5.2 which won't boot on a lot of machines, people are going to blame 5.2, not the machine. I think we should ensure that there's at least a fallback for machines with broken ACPI. This argument is exactly why I added the 'disable acpi' option in the boot loader menu. Of course, we STILL need to get good debugging information from you as to why you get a Trap 9 when ACPI is disabled. This is the more important issue. Just to be complete, there are already a whole bunch of machines that will not boot 5.x, irregardless of the ACPI issues. I've never been able to boot 5.x with ACPI on or off, on any of the 5 Dell PowerEdge 6350 servers I have here, even though they run 4.9 perfectly. I have a PR open on it. So even without the ACPI issues on some hardware, there are still other reasons why 5.x is going to fail to boot. Tom ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to disable devices in -current / 5.2-BETA?
In message: [EMAIL PROTECTED] Wilko Bulte [EMAIL PROTECTED] writes: : On Tue, Dec 02, 2003 at 11:11:48AM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Scott Long [EMAIL PROTECTED] writes: : : However, having a general mechanism for disabling newbus devices would be : : really nice. : : Agreed. But today and 5.2 you lose. However, it isn't easy. What : does disabled mean? Don't attach? Don't even probe? If you don't : : You could disable the driver altogether. Assuming that is what : is desired. That would be the next best thing. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
awk versus gawk
So it appears current has switched 'gawk' to 'awk'. These
aren't 100% compatible, here's a little gotcha in case
someone else runs into it:
awk '{print var}' var='a
b'
works on 'gawk' (e.g. RELENG_4), but on current, will
awk '{print var}' var='a
b'
awk: newline in string a
b... at source line 1
FYI, in case anyone else runs into it. Not sure if this
is just gawk being more expressive.
--don
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System hangs solid with ATAPICAM
I saw that message about rev.1.23 of ata_lowlevel.c. I had this problem prior to that change. On Tue, 2003-12-02 at 05:12, Bruce Evans wrote: On Tue, 2 Dec 2003, Sean McNeil wrote: I've tried over several weeks to get ATAPICAM to work for me. I've tried with and without acpi (compiled in or disabled via. boot). I've tried turning on all debug. I've tried a few misc. thigs. All leave my Did you try backing out rev.1.23 of ata_lowlevel.c? system hanging after the GEOM initialization without any indication of debug output. The only clue I have is that it sounds like my zip-100 was accessed right before the hang. That's interesting. The bug avoided by backing out rev.1.23 of ata-lowlevel.c is obviously system dependent. I only see it on a system that has a zip100. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System hangs solid with ATAPICAM
I always have media in that drive, but I could try without media. I've had to disable atapicam too. Only thing is, I have a CD-RW and a DVD-RW that I can't use very well without atapicam. On Tue, 2003-12-02 at 06:16, Mark Dixon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 02 Dec 2003 11:48, Sean McNeil wrote: Hello, I've tried over several weeks to get ATAPICAM to work for me. I've tried with and without acpi (compiled in or disabled via. boot). I've tried turning on all debug. I've tried a few misc. thigs. All leave my system hanging after the GEOM initialization without any indication of debug output. The only clue I have is that it sounds like my zip-100 was accessed right before the hang. I had (last time I checked) the same problem with my LS-120 (a 120Mb ATAPI floppy drive). Putting a disk in it during boot worked as a workaround and that allowed me to boot. I've since taken out atapicam because this got old fairly quickly. I think this goes back to when ATAng came in. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/zJ7TLqgJ90OcaiARAqE3AJ9CK/HHogf8CfwQkPr4ZR7xnxIGSgCgqc0n atSsfkWW/3SuKcY1IE5g5Fk= =abdJ -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 4 - 5 Problem
Does this need a note in UPDATING then? 4- 5 over NFS, and Older 5- Newer 5 over NFS no longer work as previous? Lawrence Farr EPC Direct Limited -Original Message- From: Barney Wolff [mailto:[EMAIL PROTECTED] Sent: 02 December 2003 18:32 To: Lawrence Farr Cc: 'M. Warner Losh'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: 4 - 5 Problem On Tue, Dec 02, 2003 at 05:27:12PM -, Lawrence Farr wrote: I get this error when trying to install the kernel, the same kernel installs fine on the box that made it. [EMAIL PROTECTED]:/usr/src# make installkernel -Original Message- From: M. Warner Losh [mailto:[EMAIL PROTECTED] Sent: 02 December 2003 17:16 : : install -p -m 555 -o root -g wheel kernel /boot/kernel : *** Signal 12 : : This usually means you've tried to update something out of the correct : order. Signal 12 means thaqt you didn't upgrade your kernel first. I've observed this when installing on a different system than the build system. I got it after building/installing several times on the build system before trying to installkernel on another system with /usr/src and /usr/obj nfs-mounted. The problem appeared to be that the stuff in the legacy directory under /usr/obj is built assuming that what's on the build system will work under the prior kernel - which is true on the build system but not necessarily on the target system. My solution was to edit (temporarily) /usr/src/Makefile.inc1 to put /usr/bin first in the PATH set up for the reinstallkernel target. That allowed make installkernel to succeed on the target system. Then I rebooted the target and backed out the change to /usr/src/Makefile.inc1, and after that make installworld and mergemaster went fine as usual. I didn't delve deeply enough to figure out what a cleaner fix would be, but this should probably be a PR as otherwise the 5.2 upgrade may be difficult for people who build and install on separate boxes. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Current, keep your inbox clean!
Automatically Blocking s@ [EMAIL PROTECTED] automatically checks your mail boxes and filters unwanted, dangerous, or offensive mail messages to save your time from manually detecting and organizing mail messages. Effectively s@ Detecting A complex Aritificial Intelligence algorithm has been used in [EMAIL PROTECTED] product to detecting legitimate mail messages and s@ messages,the technique has more precision than other filter-based and keyword-based anti-s@ technologies. Be Sure You Get Your Right Mail Messages [EMAIL PROTECTED] doesn't confirm a s@ message by a single keyword in mail content. It examines the entire message - source, headers and mail content to confirm whether it is a s@ message. Supports Multiple Email Types and Almost All Email Clients [EMAIL PROTECTED] supports POP3, Hotmail/MSN, IMAP4 and MAPI email accounts,Directly works with almost all email clients(Outlook Express, Becky Mail,Foxmail,Outlook, The bat!, Eudora etc.), espacially includes support for web-based Hotmail/MSN email clients. Nothing you need to change to your email clients! Friends List and Rejecting List With Friends List and Rejecting List,you have the chance to decide who are never blocked or directly treat their mail messages as [EMAIL PROTECTED] Keep your inbox clean [EMAIL PROTECTED] places all intercepted s@ messages to its interval mail database so that your inbox remains uncluttered and free of [EMAIL PROTECTED] for some reason a legitimate email is flagged as s@, you can easily recover in multiple ways. Main View Setting up [screen01.gif] [screen02.gif] Log File Good Help [screen03.gif] [screen04.gif] Easy to use You don't need to set any complex filter rules, just add your email accounts to [EMAIL PROTECTED] and then it works. References Visible links Hidden links: 1. http://wana-soft.biz/cgi-bin/order.pl?idp=110ida=193 2. http://wana-soft.biz/cgi-bin/order.pl?idp=110ida=193 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic with ugen
Martin wrote:
Could you try the attached patch (rm -f sys/dev/usb/ugen.c, cvs up
sys/dev/usb/ugen.c, patch ...) to see if it alleviates the panic? It
should at least give a more specific panic, if it doesn't fix the problem.
Sorry for the delay, I got a busy weekend.
And sorry for the delay here too. Had a busy start-of-week. :\
I still got a panic after starting the small piece of code, but it looks
like this now:
fatal trap 12
fault virtual address = 0x5
supervisor read, page not present
[...]
trace shows me ugen_set_config() at top of the stack.
Hmm. I'm afraid I'm not really sure why my patch doesn't fix the problem.
Unfortunately, to fix this I think I'd need to be able to reproduce the panic
locally and do some debugging. Otherwise, I'd just be guessing at what's
causing the problem.
If you could provide a full backtrace with a debug-enabled kernel
('makeoptions DEBUG=-g' in your kernel configuration file, with GDB using
kernel.debug to obtain symbols - I think onlamp.com had a tutorial on doing
this) I may be able to locate where things are going wrong. But if it's too
much hassle for you, I think it'd be best to pass this on to a developer with
a machine to test the panic on.
Thanks for trying the patches, though. :)
--
Cheers,
Jay
http://www.evilrealms.net/ - Systems Administrator Developer
http://www.imperial.ac.uk/ - 3rd year CS student
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
Tom wrote: Just to be complete, there are already a whole bunch of machines that will not boot 5.x, irregardless of the ACPI issues. I've never been able to boot 5.x with ACPI on or off, on any of the 5 Dell PowerEdge 6350 servers I have here, even though they run 4.9 perfectly. I have a PR open on it. So even without the ACPI issues on some hardware, there are still other reasons why 5.x is going to fail to boot. Are you using a PERC in those boxes? I've seen issues with PERC controllers on 5.1, but 4.8 worked fine. I received a patch, which fixed it, but it's a bit hard to install the os, and then rebuild world without rebooting the machine. :) Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
: This argument is exactly why I added the 'disable acpi' option in the boot : loader menu. Of course, we STILL need to get good debugging information : from you as to why you get a Trap 9 when ACPI is disabled. This is the : more important issue. : :This is actually a known issue on Intel motherboards. Somehow we broke :something in our bios32 code. 4.x works fine using the BIOS to enumerate :PNP BIOS devices, but 5.x (including 5.0 and 5.1) get a GPF (Trap 9) :with the code segment set to 0x58 trying to enumerate the last PNPBIOS :device. Somehow the BIOS routine jumps off into lala land where it :eventually traps. I dumped the BIOS and dissassembled and tried to walk :it to figure out how it was breaking but couldn't see anything obvious. : :-- : :John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ I have a motherboard that even 4.x doesn't work on... same deal, GPF while enumerating PNP devices. It died on the 6th device or something like that. I went so far as to 'fix' DDB's disassembler (in DFly) to properly decode the code segment (instead of double faulting on a 'bad' EIP in DDB) and properly show 16 bit instructions, and I set break points and single-stepped through. It died in the same place every time, during an attempt to issue a write to a CS: prefixed memory address. But I suspect a bad branch or indirect-jump table lookup. I finally gave up but if I were to do it again I would attach a serial console and record the single-step session all the way through two device number iterations... the one prior to the one that failed, and the one that failed, then I'd compare the output for the successful device iteration verses the failure to figure out where they diverge. That's what I suggest... don't play around, just connect the serial console, fix DDB's disassembler (you can pop the changes that I made in DFly, they should be the same), single step through two iterations, and compare. If you figure out what is causing the problem I'd love an email. I suspect it is a mapping overlap somewhere due to the page 0 map. I just can't think of anything else it might be. -Matt Matthew Dillon [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX halts installing 5.x
On 2 Dec, Josh Paetzel wrote: I'm trying to install FreeBSD on a Dual Pentium Pro 200mhz 512K cache system and I am getting the following error: CD Loader 1.01 Building the boot loader arguements Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.01 int=0005 err= efl=00019286 eip=0001c8a4 eax=00a3 ebx= ecx= edx= esi=cce65d00 edi= ebp= esp=0009407c cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=62 6f 6f 74 2e 6e 65 74-69 66 2e 69 70 00 62 6f 6f 74 2e 6e 65 74 69 66-2e 6e 65 74 6d 61 73 6b ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted I've tried warm booting after this and I get the same results. I've tried 5.0-RELEASE, 5.0-DP1, 5.1-RELEASE, and three different snapshots, all of which work fine on my other machines, including one other SMP box. It's also worth noting that 4.8-RELEASE and 4.9-RELEASE install fine on this box. I can boot 4.9 and post a dmesg if that would help, but to briefly describe the hardware: Intel PR440FX Mainboard Dual Pentium Pro 200mhz 512K Cache CPUs Adaptec 7880 SCSI controller 4.3 gig IBM Wide SCSI-2 Disks Intel EtherExpress Pro LAN adapter I've tried a couple different video cards, Cirrus Logis and SIS PCI 320 Megs of Registered ECC SDRAM Could this be a result of the switch from emulated floppy bootable CDs to 'no emulation' bootable CDs that happened with between the 4.x and 5.x branches? If you can do a make release to create you own .iso images, try doing it with the EMUL_BOOT variable defined, which will generate the .iso images with the emulated-floppy boot code. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.2-BETA: Instant crash (GPF) on Primergy RX300
Hi, just for the fun of it, I booted 5.2-BETA kern.flp/mfsroot.flp on a FSC Primergy RX300 (1 Xeon, 512 MB RAM) with ServerWorks Chipset, onboard Dual Adaptec 79XX (unused, disabled in BIOS), 2 * Broadcom 5704 and LSI MegaRAID 320-1 (69 GB net RAID5 FWIW). It instantly died with a GPF after having read the mfsroot.flp. Is there BTW an installation kernel/mfsroot/whatever stuff that can be PXE booted or can I generate one from an existing installation? I find floppy images (or D/L-ing like 200 MB install ISO) ever so inconvenient. The same hardware is fine under SuSE Linux 9.0, here is the lspci (think pciconf): 00:00.0 Class 0600: 1166:0014 (rev 33) 00:00.1 Class 0600: 1166:0014 00:00.2 Class 0600: 1166:0014 00:04.0 Class 0300: 1002:4752 (rev 27) 00:0f.0 Class 0600: 1166:0203 (rev a0) 00:0f.1 Class 0101: 1166:0213 (rev a0) 00:0f.2 Class 0c03: 1166:0221 (rev 05) 00:0f.3 Class 0601: 1166:0227 00:10.0 Class 0600: 1166:0110 (rev 12) 00:10.2 Class 0600: 1166:0110 (rev 12) 00:11.0 Class 0600: 1166:0101 (rev 05) 00:11.2 Class 0600: 1166:0101 (rev 05) 02:00.0 Class 0200: 14e4:1648 (rev 02) 02:00.1 Class 0200: 14e4:1648 (rev 02) 04:08.0 Class 0104: 1000:1960 (rev 01) I may be able to capture the boot logging by booting headless tomorrow. We'll see. -- Matthias Andree Encrypt your mail: my GnuPG key ID is 0x052E7D95 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PII SMP system hangs during boot with ACPI enabled
On Tue, 25 Nov 2003, John Polstra wrote: On 24-Nov-2003 Nate Lawson wrote: Please also send the output of acpidump -t -d jdp-P2.asl I booted the 5.1R live CD in an attempt to get this output. I discovered that the machine hangs the same way with 5.1R as it does with -current. (When I originally installed 5.1R, the machine had an older, non-ACPI BIOS.) I've attached the verbose boot messages from 5.1R, in case that's worth anything. Such a shame -- it gets within a hair's breadth of running init, but it just can't quite make it all the way there. Would you try this patch? http://people.freebsd.org/~jhb/patches/acpi_sci.patch -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA dsp.c duplicate lock
On Dec 01, Maxime Henrion wrote: Mathew Kanner wrote: [patch ripped] Maxime, I think it would be better to isolate the changes (DUP_OK flag and lock creation) to just the channel code, no need to touch every driver. Yes, but to do this I'd need either to make the channel code use mtx_init() directly, which would defeat the purpose of the USING_MUTEX define, or to completely unifdef -U it. Since I had no idea if this code was actually used or not, I went the safe way and just changed the snd_mtxcreate() wrapper interface to accept mutex options. For what it's worth, there is at least one direct invokation of mtx_init() in the sound drivers, so it seems this define is actually already broken. Funny, I was thinking the exact same thing the other day. I'm %100 for this idea. This needs to be sorted out before committing this patch if we need to, but for now, I just wanted to see if using MTX_DUPOK solved the problem or not. I believe that your patch should fix the problem. In general I see one of three strategies, 1) Your patch, 2) create a new snd_mtxcreate_chan for channels that sets the flags DUP_OK. 3) Fix locking to never hold duplicates. First glance suggests that would be contained in dsp.c, the ioctl handler is the real problem and seems inconsistent with itself in regards to locking. Ugh. Also, if this is the right direction, we should back out the commit I did that re-ordered code that prevented duplicate channel locks (obviously it wasn't completen) channel. If the code is not supposed to acquire several channel locks at once, then yes, it's not the right direction to go.As I said in my previous mail, and that's why I wanted the advice of you sound guys, in that case it's just a workaround. :-) I hear you. The fact is, currently there are no experienced sound people. Anyway, my order of preference is #2, #3, #1. Since #1 exists, I don't mind it being committed until we really understand what's going on. I will work on #3 tonight and maybe fallback to #2. Cheers, --Mat -- Applicants must also have extensive knowledge of UNIX, although they should have sufficiently good programming taste to not consider this an achievement. - MIT AI Lab job ad in the /Boston Globe/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX halts installing 5.x
On Tue, Dec 02, 2003 at 11:31:12AM -0800, Don Lewis wrote: On 2 Dec, Josh Paetzel wrote: I'm trying to install FreeBSD on a Dual Pentium Pro 200mhz 512K cache system and I am getting the following error: CD Loader 1.01 Building the boot loader arguements Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.01 int=0005 err= efl=00019286 eip=0001c8a4 eax=00a3 ebx= ecx= edx= esi=cce65d00 edi= ebp= esp=0009407c cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=62 6f 6f 74 2e 6e 65 74-69 66 2e 69 70 00 62 6f 6f 74 2e 6e 65 74 69 66-2e 6e 65 74 6d 61 73 6b ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted I've tried warm booting after this and I get the same results. I've tried 5.0-RELEASE, 5.0-DP1, 5.1-RELEASE, and three different snapshots, all of which work fine on my other machines, including one other SMP box. It's also worth noting that 4.8-RELEASE and 4.9-RELEASE install fine on this box. I can boot 4.9 and post a dmesg if that would help, but to briefly describe the hardware: Intel PR440FX Mainboard Dual Pentium Pro 200mhz 512K Cache CPUs Adaptec 7880 SCSI controller 4.3 gig IBM Wide SCSI-2 Disks Intel EtherExpress Pro LAN adapter I've tried a couple different video cards, Cirrus Logis and SIS PCI 320 Megs of Registered ECC SDRAM Could this be a result of the switch from emulated floppy bootable CDs to 'no emulation' bootable CDs that happened with between the 4.x and 5.x branches? If you can do a make release to create you own .iso images, try doing it with the EMUL_BOOT variable defined, which will generate the .iso images with the emulated-floppy boot code. Booting the install floppies worked fine. Thanks for the tip. :) Josh ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
On Tue, 2 Dec 2003, Alexander Motin wrote: Daniel Eischen wrote: On Tue, 2 Dec 2003, Alexander Motin wrote: Alexander Motin wrote: If I use libkse I get: kernel: Warning: pid 25341 used static ldt allocation. kernel: See the i386_set_ldt man page for more info in my messages. When I use libc_r I do not get this messages. I'm sorry. Messages seems to be independent from library. I get messages with both libraries but not every time. Some times I get two messages on one licq launching. But with libc_r it works and with libkse is not. It is not libkse that is causing the messages. It is some library or driver that licq is using. The kernel spews these messages whenever something uses static LDT allocation. We know that nvidia drivers and/or their OpenGL library do this, and they have been notified of it (by me). If there is another library or application that is also using static LDT allocation, please help us find it so it can be fixed also. $ ldd /usr/local/bin/licq From which system is this? The nvidia or the ATI? We know nvidia has a problem with ldt/%gs usage. You still haven't told me if you are getting the same static LDT warnings from the ATI system. /usr/local/bin/licq: libssl.so.3 = /usr/lib/libssl.so.3 (0x28102000) libcrypto.so.3 = /lib/libcrypto.so.3 (0x28134000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x28242000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x28266000) libm.so.2 = /lib/libm.so.2 (0x28322000) libc.so.5 = /lib/libc.so.5 (0x2833b000) $ ldd ./licq_qt-gui.so ./licq_qt-gui.so: libqt-mt.so.3 = /usr/X11R6/lib/libqt-mt.so.3 (0x2828e000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x288d) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x288d9000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x288f) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x289b8000) libjpeg.so.9 = /usr/local/lib/libjpeg.so.9 (0x289c7000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x289e5000) libm.so.2 = /lib/libm.so.2 (0x28aa1000) libmng.so.1 = /usr/local/lib/libmng.so.1 (0x28aba000) libpng.so.5 = /usr/local/lib/libpng.so.5 (0x28b18000) libz.so.2 = /lib/libz.so.2 (0x28b3d000) libGL.so.1 = /usr/X11R6/lib/libGL.so.1 (0x28b4b000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x28bb2000) libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0x28bc8000) libXft.so.2 = /usr/X11R6/lib/libXft.so.2 (0x28bd) libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x28be2000) libfontconfig.so.1 = /usr/X11R6/lib/libfontconfig.so.1 (0x28c4c000) liblcms.so.1 = /usr/local/lib/liblcms.so.1 (0x28c74000) libGLcore.so.1 = /usr/X11R6/lib/libGLcore.so.1 (0x28c8f000) ^^ What is this? libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x2912b000) libexpat.so.4 = /usr/local/lib/libexpat.so.4 (0x2917c000) This doesn't match mine: /usr/local/lib/licq/licq_qt-gui.so: . libqt-mt.so.3 = /usr/X11R6/lib/libqt-mt.so.3 (0x2828e000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x2894c000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x28955000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x2896c000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x28a34000) libjpeg.so.9 = /usr/local/lib/libjpeg.so.9 (0x28a43000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x28a61000) libm.so.2 = /lib/libm.so.2 (0x28b1d000) libc_r.so.5 = /usr/lib/libkse.so.1 (0x28b36000) libmng.so.1 = /usr/local/lib/libmng.so.1 (0x28b5b000) libpng.so.5 = /usr/local/lib/libpng.so.5 (0x28bb9000) libz.so.2 = /lib/libz.so.2 (0x28bde000) libGL.so.1 = /usr/X11R6/lib/libGL.so.1 (0x28bec000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x28c59000) libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0x28c6f000) libXrandr.so.2 = /usr/X11R6/lib/libXrandr.so.2 (0x28c77000) libXcursor.so.1 = /usr/X11R6/lib/libXcursor.so.1 (0x28c7b000) libXft.so.2 = /usr/X11R6/lib/libXft.so.2 (0x28c84000) libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x28c96000) libfontconfig.so.1 = /usr/X11R6/lib/libfontconfig.so.1 (0x28d0) liblcms.so.1 = /usr/local/lib/liblcms.so.1 (0x28d28000) libc.so.5 = /lib/libc.so.5 (0x2808) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x28d43000) libexpat.so.4 = /usr/local/lib/libexpat.so.4 (0x28d94000) -- Dan Eischen ___
Re: BTX halts installing 5.x
Hi, I have this same machine setup, and although I haven't tried running/ booting 5.x lately, I had the same symptoms -- cold boot works, warm boots, BTX halted. I suspect that this may be the critical fix: http://article.gmane.org/gmane.os.freebsd.devel.cvs.src/15784/match=btx Josh Paetzel wrote: I'm trying to install FreeBSD on a Dual Pentium Pro 200mhz 512K cache system and I am getting the following error: CD Loader 1.01 Building the boot loader arguements Looking up /BOOT/LOADER... Found Relocating the loader and the BTX Starting the BTX loader BTX loader 1.00 BTX version is 1.01 int=0005 err= efl=00019286 eip=0001c8a4 eax=00a3 ebx= ecx= edx= esi=cce65d00 edi= ebp= esp=0009407c cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=62 6f 6f 74 2e 6e 65 74-69 66 2e 69 70 00 62 6f 6f 74 2e 6e 65 74 69 66-2e 6e 65 74 6d 61 73 6b ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted I've tried warm booting after this and I get the same results. I've tried 5.0-RELEASE, 5.0-DP1, 5.1-RELEASE, and three different snapshots, all of which work fine on my other machines, including one other SMP box. It's also worth noting that 4.8-RELEASE and 4.9-RELEASE install fine on this box. I can boot 4.9 and post a dmesg if that would help, but to briefly describe the hardware: Intel PR440FX Mainboard Dual Pentium Pro 200mhz 512K Cache CPUs Adaptec 7880 SCSI controller 4.3 gig IBM Wide SCSI-2 Disks Intel EtherExpress Pro LAN adapter I've tried a couple different video cards, Cirrus Logis and SIS PCI 320 Megs of Registered ECC SDRAM I've tried googling for a solution for this as well as perused the -CURRENT archives and haven't seen anything relevent to this issue. Thanks in Advance, Josh Paetzel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- othermark atkin901 at nospam dot yahoo dot com (!wired)?(coffee++):(wired); ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-BETA dsp.c duplicate lock
On Dec 02, Mathew Kanner wrote: On Dec 01, Maxime Henrion wrote: [snip] I believe that your patch should fix the problem. In general I see one of three strategies, 1)Your patch, 2)create a new snd_mtxcreate_chan for channels that sets the flags DUP_OK. 3)Fix locking to never hold duplicates. First glance suggests that would be contained in dsp.c, the ioctl handler is the real problem and seems inconsistent with itself in regards to locking. Ugh. Why do the best ideas happen after you send? 4) Make read and write channel locks of a different class. --Mat -- In general, a standard is very useful, whether it's de facto or du jour. - Microsoft's Greg Sullivan as misquoted by News.Com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 4 - 5 Problem
I've just completed my 3rd 5.0 - 5-current upgrade over nfs, and it always
sig 12's on me. however, if I cd /usr/obj/usr/src/sys/KERNEL and 'make
install' from there it works fine. Good workaround for this particular
problem.
I have also gotten an error regarding this line in Makefile.inc1 for early
versions of 5.x
743 .if (!defined(NO_RESCUE) || \
744 defined(RELEASEDIR)) \
745 (${TARGET_ARCH} != ${MACHINE_ARCH} || ${BOOTSTRAPPING} 501101)
746 _crunchide= usr.sbin/crunch/crunchide
747 .endif
where make complains that ${BOOTSTRAPPING} 501101 is invalid, because it
thinks it's a string comparison..
Changing it to != for a quick hack works for upgrading 5.0.
Lawrence Farr wrote:
Does this need a note in UPDATING then? 4- 5 over NFS, and Older
5- Newer 5 over NFS no longer work as previous?
Lawrence Farr
EPC Direct Limited
-Original Message-
From: M. Warner Losh [mailto:[EMAIL PROTECTED]
Sent: 02 December 2003 17:16
:
: install -p -m 555 -o root -g wheel kernel /boot/kernel
: *** Signal 12
:
: This usually means you've tried to update something out of
the correct
: order.
Signal 12 means thaqt you didn't upgrade your kernel first.
this cracked me up.
--
othermark
atkin901 at nospam dot yahoo dot com
(!wired)?(coffee++):(wired);
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
mp_maxid madness
The patch at http://www.FreeBSD.org/~jhb/patches/mp_maxid.patch should fix all users of mp_maxid to use the same semantics. Namely: 1) mp_maxid is a valid FreeBSD CPU ID in the range 0 to MAXCPU - 1. 2) For every CPU in the system, PCPU_GET(cpuid) = mp_maxid -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
On Tue, 2 Dec 2003 15:58:07 -0500 (EST), Daniel Eischen [EMAIL PROTECTED] wrote: On Tue, 2 Dec 2003, Alexander Motin wrote: Daniel Eischen wrote: On Tue, 2 Dec 2003, Alexander Motin wrote: Alexander Motin wrote: If I use libkse I get: kernel: Warning: pid 25341 used static ldt allocation. kernel: See the i386_set_ldt man page for more info in my messages. When I use libc_r I do not get this messages. I'm sorry. Messages seems to be independent from library. I get messages with both libraries but not every time. Some times I get two messages on one licq launching. But with libc_r it works and with libkse is not. It is not libkse that is causing the messages. It is some library or driver that licq is using. The kernel spews these messages whenever something uses static LDT allocation. We know that nvidia drivers and/or their OpenGL library do this, and they have been notified of it (by me). If there is another library or application that is also using static LDT allocation, please help us find it so it can be fixed also. $ ldd /usr/local/bin/licq From which system is this? The nvidia or the ATI? We know nvidia has a problem with ldt/%gs usage. You still haven't told me if you are getting the same static LDT warnings from the ATI system. /usr/local/bin/licq: libssl.so.3 = /usr/lib/libssl.so.3 (0x28102000) libcrypto.so.3 = /lib/libcrypto.so.3 (0x28134000) libc_r.so.5 = /usr/lib/libc_r.so.5 (0x28242000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x28266000) libm.so.2 = /lib/libm.so.2 (0x28322000) libc.so.5 = /lib/libc.so.5 (0x2833b000) $ ldd ./licq_qt-gui.so ./licq_qt-gui.so: libqt-mt.so.3 = /usr/X11R6/lib/libqt-mt.so.3 (0x2828e000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x288d) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x288d9000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x288f) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x289b8000) libjpeg.so.9 = /usr/local/lib/libjpeg.so.9 (0x289c7000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x289e5000) libm.so.2 = /lib/libm.so.2 (0x28aa1000) libmng.so.1 = /usr/local/lib/libmng.so.1 (0x28aba000) libpng.so.5 = /usr/local/lib/libpng.so.5 (0x28b18000) libz.so.2 = /lib/libz.so.2 (0x28b3d000) libGL.so.1 = /usr/X11R6/lib/libGL.so.1 (0x28b4b000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x28bb2000) libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0x28bc8000) libXft.so.2 = /usr/X11R6/lib/libXft.so.2 (0x28bd) libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x28be2000) libfontconfig.so.1 = /usr/X11R6/lib/libfontconfig.so.1 (0x28c4c000) liblcms.so.1 = /usr/local/lib/liblcms.so.1 (0x28c74000) libGLcore.so.1 = /usr/X11R6/lib/libGLcore.so.1 (0x28c8f000) ^^ What is this? It's more like Nvidia driver issue as you have said previous. There has an option to build QT3 with OpenGL. Alexander, Nvidia driver and libkse don't play together very well; it's recommend to stick with libc_r if you want to use Nvidia driver. Cheers, Mezz libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x2912b000) libexpat.so.4 = /usr/local/lib/libexpat.so.4 (0x2917c000) This doesn't match mine: /usr/local/lib/licq/licq_qt-gui.so: . libqt-mt.so.3 = /usr/X11R6/lib/libqt-mt.so.3 (0x2828e000) libSM.so.6 = /usr/X11R6/lib/libSM.so.6 (0x2894c000) libICE.so.6 = /usr/X11R6/lib/libICE.so.6 (0x28955000) libX11.so.6 = /usr/X11R6/lib/libX11.so.6 (0x2896c000) libXext.so.6 = /usr/X11R6/lib/libXext.so.6 (0x28a34000) libjpeg.so.9 = /usr/local/lib/libjpeg.so.9 (0x28a43000) libstdc++.so.4 = /usr/lib/libstdc++.so.4 (0x28a61000) libm.so.2 = /lib/libm.so.2 (0x28b1d000) libc_r.so.5 = /usr/lib/libkse.so.1 (0x28b36000) libmng.so.1 = /usr/local/lib/libmng.so.1 (0x28b5b000) libpng.so.5 = /usr/local/lib/libpng.so.5 (0x28bb9000) libz.so.2 = /lib/libz.so.2 (0x28bde000) libGL.so.1 = /usr/X11R6/lib/libGL.so.1 (0x28bec000) libXmu.so.6 = /usr/X11R6/lib/libXmu.so.6 (0x28c59000) libXrender.so.1 = /usr/X11R6/lib/libXrender.so.1 (0x28c6f000) libXrandr.so.2 = /usr/X11R6/lib/libXrandr.so.2 (0x28c77000) libXcursor.so.1 = /usr/X11R6/lib/libXcursor.so.1 (0x28c7b000) libXft.so.2 = /usr/X11R6/lib/libXft.so.2 (0x28c84000) libfreetype.so.9 = /usr/local/lib/libfreetype.so.9 (0x28c96000) libfontconfig.so.1 = /usr/X11R6/lib/libfontconfig.so.1 (0x28d0) liblcms.so.1 = /usr/local/lib/liblcms.so.1 (0x28d28000) libc.so.5 = /lib/libc.so.5 (0x2808) libXt.so.6 = /usr/X11R6/lib/libXt.so.6 (0x28d43000) libexpat.so.4 = /usr/local/lib/libexpat.so.4 (0x28d94000) -- bsdforums.org 's moderator, mezz.
Re: 40% slowdown with dynamic /bin/sh
Daniel C. Sobral wrote: Now, my machines usually get by themselves, but all *I* do on them is sh(1) intensive, so I'll probably be using the static root option when it comes time to upgrade them to 5.x. The static root option exists for people with special requirements: * Use a lot of shell scripts * Have very high performance requirements for those scripts * Does not use LDAP, NIS, or other networked directory services (I want to move NIS out of libc. Its privileged position relative to LDAP and other services is rather dated.) E.g., someone with a standalone server that's using /bin/sh to run CGIs would be well advised to compile a static /bin/sh. Fortunately, that's easy to do. And if you are using FreeBSD on desktop you should use bash or some other ports-shell, instead of slowing down _the_ shell for shell scripts. User shell scripts do rely on tilde expansion. Having that break in any environment relying on networked directory services is a pretty serious loss of functionality. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Wed, 26 Nov 2003, Lukas Ertl wrote: On Wed, 26 Nov 2003, Nate Lawson wrote: I need the output of sysctl hw.acpi.thermal to see your _ACx values. hw.acpi.thermal.tz0.temperature: 3072 hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 3627 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 3662 hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 Um, you have no _ACx values so the fan will be controlled by the BIOS. We should probably provide a way for users to supply their own _ACx values if they're not happy with the BIOS's but I'm not sure your ASL exports a power resource for the fan object. Do you have an object with id PNP0C0B? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: if_xname changes incoming
On Fri, Nov 14, 2003 at 02:27:26PM -0800, Brooks Davis wrote: On Fri, Nov 14, 2003 at 02:38:34PM -0700, Janet Sullivan wrote: Brooks Davis wrote: On Fri, Oct 31, 2003 at 10:27:35AM -0800, Brooks Davis wrote: I will be commiting the if_xname changes momentairly. If you experience any problems with this commit, please let me know ASAP. I'll send an all clear once I've sucessfully built a world/kernel from CVS. Ok, we're mostly clear. World builds, but I've had to disconnect ipfstat, ipnat, and ipftest from the build because they need modifications and are on vendor branch. Will this be fixed before 5.2-REL? Yes. I don't know if it will make the codefreeze. It took longer then it should have, but I've reenabled ipfstat, ipnat, and ipftest so they will make it into the release. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
Re: Updated acpi_cpu patch
On Tue, 2 Dec 2003, Nate Lawson wrote: Um, you have no _ACx values so the fan will be controlled by the BIOS. We should probably provide a way for users to supply their own _ACx values if they're not happy with the BIOS's but I'm not sure your ASL exports a power resource for the fan object. Do you have an object with id PNP0C0B? No, there's no PNP0C0B device. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 2 Dec 2003, Lukas Ertl wrote: On Tue, 2 Dec 2003, Nate Lawson wrote: Um, you have no _ACx values so the fan will be controlled by the BIOS. We should probably provide a way for users to supply their own _ACx values if they're not happy with the BIOS's but I'm not sure your ASL exports a power resource for the fan object. Do you have an object with id PNP0C0B? No, there's no PNP0C0B device. Build with options ACPI_DEBUG and boot with this in loader.conf: debug.acpi.layer=ACPI_POWER debug.acpi.level=ACPI_LV_OBJECTS It will print any power resources you have. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Thinkpad T40p and panic during boot...;O
Hi there! ;) I´ve been trying to install FreeBSD-CURRENT and FreeBSD 5.2-BETA on my Thinkpad for awile The problem is this: When i try to boot 5.1-Current (first cd i tried was from 5 Oct 2003 and the latest one was 5.2-BETA) i get this error: ---CUT--- Memory modified after free 0x20e1800(2044) val=c4c24510 @ 0xc20e1ac4 panic: Most recently used by bus Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 ---CUT--- I have the newest bios for this puter, and have tried without acpi, safe mode, and defaultnothing seems to boot this baby! ;) It boots 5.1-Release, but then i cant use the network card, it says something about bad eprom (its intel 10/100/1000 cardem0 WellIf anyone gets idea or if you guys need more info, just ask ..didnt thing of anything you guys wanted more. - Finnzi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
On Tue, Dec 02, 2003 at 01:43:16PM -0800, Tim Kientzle wrote: Daniel C. Sobral wrote: Now, my machines usually get by themselves, but all *I* do on them is sh(1) intensive, so I'll probably be using the static root option when it comes time to upgrade them to 5.x. The static root option exists for people with special requirements: * Use a lot of shell scripts * Have very high performance requirements for those scripts * Does not use LDAP, NIS, or other networked directory services (I want to move NIS out of libc. Its privileged position relative to LDAP and other services is rather dated.) What impact, if any, will this have on those of us that use NIS and still want a statically linked root? I have been using NIS for years and see no compelling reason to switch to LDAP (i.e., NIS satisfies my needs, is configured, and working). Bob -- Bob Willcox First Law of Procrastination: [EMAIL PROTECTED] Procrastination shortens the job and places the Austin, TX responsibility for its termination on someone else (i.e., the authority who imposed the deadline). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated acpi_cpu patch
On Tue, 2 Dec 2003, Nate Lawson wrote: Build with options ACPI_DEBUG and boot with this in loader.conf: debug.acpi.layer=ACPI_POWER debug.acpi.level=ACPI_LV_OBJECTS It will print any power resources you have. Unfortunately, there's no power resource listed. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/fd0 not working with ACPI
dmesg, please, including error. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problem, my VAIO won't come back from suspension
Try other states (acpiconf -s 1, 2, 4). If one works, use it. If not, try disabling acpi and using apm(4) to suspend and resume. Suspend/resume is far down my list of things to troubleshoot and most of the problems are very hw-specific. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: PII SMP system hangs during boot with ACPI enabled
On 23-Nov-2003 John Polstra wrote: I have an old dual PII/400 system that I'm trying to set up as a -current scratchbox. The motherboard is a Tyan S1836DLUAN with the Intel 440BX chipset. I upgraded the BIOS to the latest from Tyan's web site. It is supposed to support ACPI. I'm using -current from around noon Pacific time, November 23 (today). The system boots and runs fine if I disable ACPI either in loader.conf or in the BIOS, but if ACPI is enabled it hangs fairly late in the boot, right after these messages: lo0: bpf attached acpi_cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% It's not a totally solid hang. For instance, the scroll lock key works and allows me to scroll forward and backward through the syscons output. I've attached the verbose boot messages. Is this system Just Too Old? Try http://www.FreeBSD.org/~jhb/patches/acpi_irq.patch -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ problem with VAIO laptop again
On 24-Nov-2003 Pete Carah wrote: I had noted a problem with choppy audio after the pci.c update of a week ago; this turns out to be more general. I've also lost firewire and the memory-stick slot (3rd usb controller) completely: --- Following up to my own note: With no visible change to dmesg, the audio now appears to work at least pretty well, maybe a little chop but acceptable with no changes to pci.c; maybe some acpi change fixed it? Music plays at least fairly well now, but the X-windows beep function (using kde + artsd) still seems rather delayed but now completely non-choppy. However, the firewire and memory-stick are still listed as missing in action... I can't burn a cd using my usb drive since this laptop doesn't support ehci (can send the files to another computer with an internal drive). I will check this again, but I am pretty sure that I have plug-and-play OS turned ON in my bios since last summer when the acpi started working fairly well. How is this supposed to be set now on non-acpi motherboards (I have several such that run current; one Aladdin-5 K6-2 (ASUS has acpi, but at least one of my cheap ones doesn't), and an embedded-controller (Cyrix GX) mini-system)? PNP OS should still be OFF. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IRQ problem with VAIO laptop again
On 24-Nov-2003 Nate Lawson wrote: uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f at device 29.2 on pci0 pcib0: _PRS resource entry has unsupported type 0 uhci2: Could not allocate irq device_probe_and_attach: uhci2 attach returned 6 This one loses the memory-stick slot pcib1: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib1 pcib1: _PRS resource entry has unsupported type 0 pcib1: slot 8 INTA is routed to irq 9 fwohci0: Texas Instruments TSB43AB22/A mem 0xe020-0xe0203fff,0xe0205000-0xe02057ff at device 2.0 on pci2 pcib1: _PRS resource entry has unsupported type 0 fwohci0: Could not allocate irq device_probe_and_attach: fwohci0 attach returned 6 This one loses firewire The problem is that your _PRS values are incorrect. Actually, I think jhb committed some code to deal with extended irq resources. Send me the output of acpidump -t -d pete-SonyVaio.asl Also, does booting without ACPI fix things? I fixed this bug a while ago. Messed up a test for the type of _PRS. (Used || instead of ) -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Intel SE7500WV2 not working with ACPI
On 25-Nov-2003 Brooks Davis wrote: Since the interrupt changes, my dual Xeons based on the SE7500WV2 board don't work with ACPI. Specificly, the onboard nics (em0 and em1) appear to not be recieving interupts. Instead, they continiously get watchdog timeouts. In a stock current, this is an instant panic. With a minor fix to the watchdog function, the system sees to be more or less funcitonal other then not having a network. Disabling ACPI makes the nics work. I have updated the BIOS to the latest version[0]. I've included ACPI and non-ACPI dmesg output below. What else is needed to diagnose this problem? Any patches I should try? Since acpi0 failed to probe, ACPI isn't used to route interrupts. However, the apic code expects ACPI to do that since it enumerated CPUs and I/O APICs. You are just going to have to disable ACPI for now. acpi0: INTEL SWV20on motherboard ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] (Node 0xc29b4660), AE_NOT_EXIST acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST device_probe_and_attach: acpi0 attach returned 6 If you can get this fixed, then you can re-enable ACPI again. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel SE7500WV2 not working with ACPI
On Tue, Dec 02, 2003 at 05:50:27PM -0500, John Baldwin wrote: On 25-Nov-2003 Brooks Davis wrote: Since the interrupt changes, my dual Xeons based on the SE7500WV2 board don't work with ACPI. Specificly, the onboard nics (em0 and em1) appear to not be recieving interupts. Instead, they continiously get watchdog timeouts. In a stock current, this is an instant panic. With a minor fix to the watchdog function, the system sees to be more or less funcitonal other then not having a network. Disabling ACPI makes the nics work. I have updated the BIOS to the latest version[0]. I've included ACPI and non-ACPI dmesg output below. What else is needed to diagnose this problem? Any patches I should try? Since acpi0 failed to probe, ACPI isn't used to route interrupts. However, the apic code expects ACPI to do that since it enumerated CPUs and I/O APICs. You are just going to have to disable ACPI for now. acpi0: INTEL SWV20on motherboard ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.SBRG.EC0_._REG] (Node 0xc29b4660), AE_NOT_EXIST acpi0: Could not initialise SystemIO handler: AE_NOT_EXIST device_probe_and_attach: acpi0 attach returned 6 If you can get this fixed, then you can re-enable ACPI again. What I can't figure out is why this is failing since acpi was at least partialy working before. For instance, soft power was definalty working. Doesn't that depend on acpi attaching? -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
EHCI problems - Revisited
Just curious who is working on the EHCI stuff? I am running -current as of today, and playing with EHCI support. I have a Sandisk 256mb USB 2.0 Cruzer memory stick, that doesn't quite work right with EHCI enabled. Here's my dmesg fragment: Dec 2 16:47:28 neutrino kernel: ehci0: EHCI (generic) USB 2.0 controller mem 0xf4fffc00-0xf4ff irq 11 at device 29.7 on pci0 Dec 2 16:47:28 neutrino kernel: ehci0: (New EHCI DeviceId=0x24cd8086) Dec 2 16:47:28 neutrino kernel: ehci_pci_attach: companion usb0 Dec 2 16:47:28 neutrino kernel: ehci_pci_attach: companion usb1 Dec 2 16:47:28 neutrino kernel: ehci_pci_attach: companion usb2 Dec 2 16:47:28 neutrino kernel: usb3: EHCI version 1.0 Dec 2 16:47:28 neutrino kernel: usb3: companion controllers, 2 ports each: usb0 usb1 usb2 Dec 2 16:47:28 neutrino kernel: usb3: EHCI (generic) USB 2.0 controller on ehci0 Dec 2 16:47:28 neutrino kernel: usb3: USB revision 2.0 Dec 2 16:47:28 neutrino kernel: uhub3: (0x8086) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 Dec 2 16:47:28 neutrino kernel: uhub3: 6 ports with 6 removable, self powered and here's what happens when I plug in the memory stick: Dec 2 16:48:43 neutrino kernel: usb3: unrecoverable error, controller halted Dec 2 16:48:43 neutrino kernel: usb3: blocking intrs 0x10 Dec 2 16:49:08 neutrino kernel: usb3: port reset timeout Here are some lines from pciconf -l: [EMAIL PROTECTED]:29:0:class=0x0c0300 card=0x45418086 chip=0x24c28086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:29:1:class=0x0c0300 card=0x45418086 chip=0x24c48086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:29:2:class=0x0c0300 card=0x45418086 chip=0x24c78086 rev=0x01 hdr=0x00 [EMAIL PROTECTED]:29:7:class=0x0c0320 card=0x011d1028 chip=0x24cd8086 rev=0x01 hdr=0x00 I saw some threads from August or so, saying that Intel EHCI controllers are not supported yet, but not much else. Just wondering if there are some patches for me to try, or any testing I can help with. Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
Daniel Eischen wrote: It is not libkse that is causing the messages. It is some library or driver that licq is using. The kernel spews these messages whenever something uses static LDT allocation. We know that nvidia drivers and/or their OpenGL library do this, and they have been notified of it (by me). If there is another library or application that is also using static LDT allocation, please help us find it so it can be fixed also. Some multimedia player using Win32 codecs will encounter same problem if these Win32 codec are activated during media playing. They use WINE's some core components, one of is libw32dll, which uses static LDT allocation too. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
On Wed, 3 Dec 2003, David Xu wrote: Daniel Eischen wrote: It is not libkse that is causing the messages. It is some library or driver that licq is using. The kernel spews these messages whenever something uses static LDT allocation. We know that nvidia drivers and/or their OpenGL library do this, and they have been notified of it (by me). If there is another library or application that is also using static LDT allocation, please help us find it so it can be fixed also. Some multimedia player using Win32 codecs will encounter same problem if these Win32 codec are activated during media playing. They use WINE's some core components, one of is libw32dll, which uses static LDT allocation too. Do you know what port this belongs to and if it is built from source? mplayer also used static ldt allocations, but I fixed that port. Hmm, I found multimedia/libxine that might be the culprit. I'll look into submitting a patch for that. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
Bob Willcox wrote: What impact, if any, will this have on those of us that use NIS and still want a statically linked root? I have been using NIS for years ... First, let me clarify that I'm advocating moving NIS out of libc in the 6.0 timeframe. Also, I'm not suggesting anyone replace NIS with LDAP. FreeBSD currently has a strong bias for NIS over LDAP; I just think we should support both equally. How would this affect a static root? Make it a lot smaller and faster, for starters. NIS adds as much as 400k each to many programs in /bin and /sbin. Over a quarter of a static /bin/sh is from NIS support. Does that rule out NIS with a static root? Yes, with the current NSS/PAM implementation, although a variety of suggestions have been floated around that would make NSS/PAM compatible with static binaries. My personal favorite is to implement NSS/PAM daemons to satisfy such requests. Such daemons are surprisingly simple to implement, in my experience. I'm skeptical of efforts to use dlopen() with static binaries; static binaries don't have symbol tables, so there's no way to resolve references from the dlopen()-ed library back into the executable. I'm curious, though. The single most convincing argument so far in favor of a static root has been performance. Doesn't the NIS network overhead swamp any performance gains from static linking? I suspect you have other reasons for wanting a static root. (Or do you only require certain executables to be static, such as /bin/sh?) Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: licq KSE
Daniel Eischen wrote: Do you know what port this belongs to and if it is built from source? mplayer also used static ldt allocations, but I fixed that port. Hmm, I found multimedia/libxine that might be the culprit. I'll look into submitting a patch for that. Search word win32 in page http://www.freebsd.org/ports/multimedia.html if you hit anyone, it is very doubtful. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PCMCIA CDROM drives
Does the generic kernel have drivers for these. I got such a cdrom drive for my Portege 3500 tablet PC and it appeared to be able to boot the 5.2 beta mini-install CD. I wasn't ready to proceed with a complete install, so I shut it off at this point. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] fixes of tcp_hostcache.c
On Tue, Dec 02, 2003 at 11:56:30AM +0900, Taku YAMAMOTO wrote: The fix is attached as a patch against tcp_hostcache.c as of revision 1.2. Looks good to me. I haven't been able to test this thoroughly, netperf/netserver don't seem to want to listen on a TCP6 port for the TCPIPV6_STREAM test. Our port appears to incorporate the necessary patches. BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PANIC: PAGE FAULT
Hi all, I'm trying to install FreeBSD-5.1 on the PC with PIII,512MB SDRAM, 30GB Barracuda II Model ST330630A. But following error has occured. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc035eb26 stack pointer = 0x10:0xdba72bb8 frame pointer = 0x10:0xdba72c2c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 80 (sh) trap number = 12 panic: page fault syncing disks, buffers remaining... 184 184 184 184 184 184 184 184 184 184 184 184 184 184 giving up on 148 buffers Uptime: 16s Terminate ACPI PLEASE HELP ME!!! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 40% slowdown with dynamic /bin/sh
In the last episode (Dec 02), Tim Kientzle said:
Does that rule out NIS with a static root?
Yes, with the current NSS/PAM implementation, although a variety of
suggestions have been floated around that would make NSS/PAM
compatible with static binaries. My personal favorite is to
implement NSS/PAM daemons to satisfy such requests. Such daemons are
surprisingly simple to implement, in my experience. I'm skeptical of
efforts to use dlopen() with static binaries; static binaries don't
have symbol tables, so there's no way to resolve references from the
dlopen()-ed library back into the executable.
I'm curious, though. The single most convincing argument so far in
favor of a static root has been performance. Doesn't the NIS network
overhead swamp any performance gains from static linking? I suspect
you have other reasons for wanting a static root. (Or do you only
require certain executables to be static, such as /bin/sh?)
The programs in /bin or /sbin that link the NIS stuff in don't use it
all that often (rm, for example, will only do a user_from_uid call in
the -i case for a file not owned by the deleter), and unaccessed pages
in a static executable cause no performance hit. I'm not sure that any
program in /bin or /sbin really does enough lookups for it to be a
speed factor. Quite a few of the ones that pull in the NIS code really
do it for resolving hostnames. /bin/sh is the best argument for an
external NSS lookup agent, since it should be fast but occasionally may
want to do NSS calls.
To list programs that pull in NIS:
ident /bin/* /sbin/* | awk '/^[^ ]/ { cmd=$1 } /nsdispatch/ { print cmd }'
--
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI results Inspiron 8000
On Tuesday 02 December 2003 21:50, Melvyn Sopacua wrote: I used to suspend to disk in 4.x after creating the S2D partition with the floppy image from Dell, however I don't any more.. I kept the Dell partition intact. Or does it need special formatting? If it's a newish laptop then that partition has diag tools on it, not a suspend to disk partition. My laptop didn't come with a S2D partition because WinME does it itself - ie I'd say the S2D method is deprecated. Basically it takes so long to suspend and resume with a decent amount of memory (256Mb+) that it's not worth it - most of my applications are smart enough to save state when they quit :) Hmm, since I have 512 and might upgrade to 1G of memory, I guess I don't need it either :). But it should error out and resume normal powerstate if for whatever reason suspension does not work. It should not reboot. Sure thing.. Got patches? :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PCMCIA CDROM drives
In message: [EMAIL PROTECTED] Justin Smith [EMAIL PROTECTED] writes: : Does the generic kernel have drivers for these. I got such a cdrom drive : for my Portege 3500 tablet PC and it appeared to be able to boot the 5.2 : beta mini-install CD. I wasn't ready to proceed with a complete : install, so I shut it off at this point. Yes and no. 5.2 current likely will work. 5.2-beta won't because there were some issues with ata's pccard attachment. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Thinkpad T40p and panic during boot...;O
and i am waiting for you guys to tell me the tp40 works with -current before i upgrade from a limping -stable. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /dev/fd0 not working with ACPI
Am Di, den 02.12.2003 schrieb Nate Lawson um 23:32: dmesg, please, including error. -Nate Ok, here is a text attachment: fdc0: cannot reserve I/O port range (6 ports), this was reported by some others too within this year. 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 5.2-BETA #3: Tue Dec 2 22:27:21 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRITZ Preloaded elf kernel /boot/kernel/kernel at 0xc0945000. Preloaded elf module /boot/kernel/if_sis.ko at 0xc094526c. Preloaded elf module /boot/kernel/miibus.ko at 0xc0945318. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc09453c4. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc0945470. Preloaded elf module /boot/kernel/usb.ko at 0xc094551c. Preloaded elf module /boot/kernel/uhid.ko at 0xc09455c4. Preloaded elf module /boot/kernel/ums.ko at 0xc0945670. Preloaded elf module /boot/kernel/umass.ko at 0xc0945718. Preloaded elf module /boot/kernel/nvidia.ko at 0xc09457c4. Preloaded elf module /boot/kernel/linux.ko at 0xc0945870. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (896.19-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 268369920 (255 MB) avail memory = 251052032 (239 MB) Pentium Pro MTRR support enabled acpi0: AMIINT SiS735XX on motherboard pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00f7950 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 2 INTD is routed to irq 5 pcib0: slot 2 INTA is routed to irq 12 pcib0: slot 2 INTC is routed to irq 11 pcib0: slot 3 INTA is routed to irq 11 agp0: SIS Generic host to PCI bridge mem 0xd000-0xd3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pcib0: slot 1 INTA is routed to irq 5 pcib1: slot 0 INTA is routed to irq 5 nvidia0: GeForce2 MX/MX 400 mem 0xc000-0xc7ff,0xce00-0xceff irq 5 at device 0.0 on pci1 isab0: PCI-ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 ohci0: SiS 5571 USB controller mem 0xcfffe000-0xcfffefff irq 5 at device 2.2 on pci0 usb0: OHCI version 1.0, legacy support usb0: SiS 5571 USB controller on ohci0 usb0: USB revision 1.0 uhub0: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: SiS 5571 USB controller mem 0xc000-0xcfff irq 12 at device 2.3 on pci0 usb1: OHCI version 1.0, legacy support usb1: SiS 5571 USB controller on ohci1 usb1: USB revision 1.0 uhub1: SiS OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ums0: Logitech Inc. iFeel Mouse, rev 1.00/1.01, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. atapci0: SiS 735 UDMA100 controller port 0xff00-0xff0f at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] pcm0: SiS 7012 port 0xd800-0xd83f,0xdc00-0xdcff irq 11 at device 2.7 on pci0 pcm0: Realtek ALC100 AC97 Codec sis0: SiS 900 10/100BaseTX port 0xd400-0xd4ff mem 0xcfffd000-0xcfffdfff irq 11 at device 3.0 on pci0 sis0: Ethernet address: 00:07:95:b5:dc:e2 miibus0: MII bus on sis0 rlphy0: RTL8201L 10/100 media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto acpi_button0: Sleep Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: cmd 3 failed at out byte 1 of 3 npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface orm0: Option ROMs at iomem 0xcc800-0xd47ff,0xc-0xcc7ff on isa0 pmtimer0 on isa0 fdc0: cannot reserve I/O port range (6 ports) sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 896191702 Hz quality 800 Timecounters tick every 10.000 msec GEOM: create disk ad0 dp=0xc2d78e60 ad0: 57277MB SAMSUNG SV0602H [116374/16/63] at ata0-master UDMA100 GEOM: create disk ad1 dp=0xc2d99660 ad1: 16446MB ST317221A [33416/16/63] at ata0-slave UDMA66 acd0: CDRW R/RW 4x4x32 at ata1-master WDMA2 acd1: DVDROM HL-DT-STDVD-ROM GDR8161B at ata1-slave UDMA33 Mounting root from ufs:/dev/ad0s2a Warning: pid 522 used static ldt allocation. See the i386_set_ldt man page for more info ___ [EMAIL
Re: User mounts could not use character conversions (libkiconv is just for roots)
On Tue, Dec 02, 2003 at 05:38:05PM +0100, Rudolf Cejka wrote: I have found, that user mounts using libkiconv.so (msdosfs, cd9660, ...) could not use character code conversions, beause writing to sysctl kern.iconv.add is allowed just for root. Personally, I have created small patch, which allows to change kern.iconv.add to anybody, so it does work for me. Does anybody know, if there are security drawbacks and if it can or can not be commited? Probably it is not a good idea to allow users to load kernel iconv tables because one can waste a lot of memory by loading of all possible conversion schemes. The better solution is to add some kind of preload ability which could be used on startup. -- Boris Popov http://rbp.euro.ru ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
please test pcm channel patch
Hello All,
Please test this PCM patch. It creates seperate locking
classes for PCM channels and should prevent the warning where multiple
mutexes from the same class are held (as reported recently). I
believe this to be a good strategy as it masks fewer errors.
Thanks,
--mat
--
The state has no business in the bedrooms of the
nation.
- Pierre Elliott Trudeau
Index: channel.c
===
RCS file: /home/ncvs/src/sys/dev/sound/pcm/channel.c,v
retrieving revision 1.92
diff -u -r1.92 channel.c
--- channel.c 27 Nov 2003 19:51:44 - 1.92
+++ channel.c 3 Dec 2003 05:59:56 -
@@ -69,7 +69,10 @@
static void
chn_lockinit(struct pcm_channel *c)
{
- c-lock = snd_mtxcreate(c-name, pcm channel);
+ if (c-direction == PCMDIR_PLAY)
+ c-lock = snd_mtxcreate(c-name, pcm play channel);
+ else
+ c-lock = snd_mtxcreate(c-name, pcm record channel);
}
static void
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
