Re: Problems with pcmcia on 5.1-RELEASE
M. Warner Losh [EMAIL PROTECTED] writes: In message: [EMAIL PROTECTED] Christian Laursen [EMAIL PROTECTED] writes: : M. Warner Losh [EMAIL PROTECTED] writes: : : In message: [EMAIL PROTECTED] : Christian Laursen [EMAIL PROTECTED] writes: : : pccard0: unknown card (manufacturer=0x, product=0x) at function 0 : : pccard0:CIS info: FREECOM, PCCARD-IDE, REV836 : : Looks like we need another entry in ata-card.c for this device. : : I've added this to the kernel list. Please recvsup and make sure you : have sys/dev/pccard/pccarddevs 1.53, pccarddevs.h 1.53 and : sys/dev/ata/ata-card.c 1.14. : : Thank you very much. : : Unfortunately, like the patch Matthew N. Dodd posted, this gives me : an extra ata channel, but no devices are found on it. : : I have tried various commands to atacontrol, but nothing seems to : help. : : I'm not sure how to help debug this further. I have a stupid question: Are you sure that your cdrom is turned on? I have some that need an aux power connection before they work. Yes, I am. There is a switch that I can use to change between external power or power from the machine to which it is connected. When I insert the card, the light on the drive comes on, and if a cd is inserted, it spins up. -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: I am still not able to reproduce this. Can you update your sources? I commited some code just now that removed an external dependency from sched_nice(). This should make it more robust. With the new code, I'm also unable to reproduce the panic :) Thanks :) Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: where is rogue?
Kris Kennaway writes: I installed freebsd-games, and it has most of the games I remember, but n= ot rogue. Well, hrumph, it's supposed to be in that port. Mark, it looks like rogue wasn't added for some reason. Oops. Fix coming later today. M -- Mark Murray iumop ap!sdn w,I idlaH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Wed, 18 Jun 2003, Wiktor Niesiobedzki wrote: On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: I am still not able to reproduce this. Can you update your sources? I commited some code just now that removed an external dependency from sched_nice(). This should make it more robust. With the new code, I'm also unable to reproduce the panic :) With LAZY_SWITCH enabled? Thanks :) Cheers, Wiktor Niesiobedzki ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Novatel Merlin
I'm trying to get a Novatel Merlin for Ricochet working under -CURRENT. http://www.novatelwireless.com/support/support_ricochet.html I've been able to connect to their network via PPP and do things like ping and traceroute to the rest of the internet. However, when I try things that produce larger packets (ftp, telnet, ssh, etc), nothing works. I've noticed (in the PPP logs and when sending AT commands directly) that characters get dropped occasionally. I also found this document http://homepages.nyu.edu/~gmp216/nrm6842/bigfastuart.html which explains that the Merlin for Ricochet has a 576 byte buffer which, if full, will try and flush itself on a single interrupt. Apparently under linux this is a problem because the serial buffer is only 512 bytes and it overflows. Is this also a problem in FreeBSD? I also get a lot of messages like this in /var/log/messages and on the console: Jun 16 23:31:16 foo kernel: sio4: 137 more interrupt-level buffer overflows (total 821) That would seem to indicate that dumping 576 bytes on a single interrupt is too much. yes? no? If the serial buffer is too small, would it be difficult to increase it's size? Any help would be greatly appreciated. If I need to provide more info just let me know what to provide. Thanks! -Glenn 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.1-CURRENT #2: Tue Jun 17 01:09:59 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/foo Preloaded elf kernel /boot/kernel/kernel at 0xc04ac000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04ac21c. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1666204780 Hz CPU: AMD Athlon(TM) XP 2000+ (1666.20-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM OV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 536854528 (511 MB) avail memory = 516341760 (492 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7V333 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 11 entries at 0xc00f2050 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 32-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu: CLK_VAL field overlaps THT_EN bit acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib0: slot 5 INTA is routed to irq 10 pcib0: slot 9 INTA is routed to irq 4 pcib0: slot 9 INTB is routed to irq 11 pcib0: slot 9 INTC is routed to irq 10 pcib0: slot 13 INTA is routed to irq 11 pcib0: slot 15 INTA is routed to irq 12 pcib0: slot 15 INTB is routed to irq 4 agp0: VIA Generic host to PCI bridge mem 0xe000-0xe3ff at device 0.0 o n pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci0: multimedia, audio at device 5.0 (no driver attached) pci0: serial bus, USB at device 9.0 (no driver attached) pci0: serial bus, USB at device 9.1 (no driver attached) pci0: serial bus, USB at device 9.2 (no driver attached) xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xb800-0xb87f mem 0xd700-0xd700 007f irq 11 at device 13.0 on pci0 xl0: Ethernet address: 00:01:02:2a:53:0e miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cbb0: RF5C476 PCI-CardBus Bridge irq 12 at device 15.0 on pci0 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb1: RF5C476 PCI-CardBus Bridge irq 4 at device 15.1 on pci0 cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 8233A UDMA133 controller port 0xb400-0xb40f at device 17.1 on pci 0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 ppc0: parallel port not found. sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec pccard1: Allocation failed for cfe 32 sio4: Novatel Wireless Merlin Ricochet Modem at
ACPI errors on boot
Hi list! I have recently installed FreeBSD 5.1 on my Dell C800 laptop, and I get quite a lot (well: 48 :) of these errors on boot: ACPI-0293: *** Warning: Buffer created with zero length in AML -0166: *** Error: UtAllocate: Attempt to allocate zero bytes Are those harmfull? Is there something I can do with it? Otherwise my laptop is working perfectly... :) Thank you, Maikel Verheijen. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NVidia kernel driver support for FreeBSD-5.1
Hello: I've got a PCI-NVidia Riva TNT 64 video card at home, and I've tried to compile the drivers but it doesn't work, and after changing the source to let the compilation progress, when the module is loaded I've received a kernel panic. Im using FreeBSD-5.1 with XFree86-4.3, what can I do to solve this issue ? I can not run the X system using the nv driver, my computer hangs up. Any help will be useful, thanks! -- JFRH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
On Wed, 18 Jun 2003, 09:14+0200, Juan Rodriguez Hervella wrote: Hello: I've got a PCI-NVidia Riva TNT 64 video card at home, and I've tried to compile the drivers but it doesn't work, and after changing the source to let the compilation progress, when the module is loaded I've received a kernel panic. Im using FreeBSD-5.1 with XFree86-4.3, what can I do to solve this issue ? I can not run the X system using the nv driver, my computer hangs up. Any help will be useful, thanks! Make sure you do not have 'options INVARIANTS' in your kernel config file. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Novatel Merlin
On Wed, 18 Jun 2003, Glenn Dawson wrote: I'm trying to get a Novatel Merlin for Ricochet working under -CURRENT. http://www.novatelwireless.com/support/support_ricochet.html ... I've noticed (in the PPP logs and when sending AT commands directly) that characters get dropped occasionally. I also found this document http://homepages.nyu.edu/~gmp216/nrm6842/bigfastuart.html which explains that the Merlin for Ricochet has a 576 byte buffer which, if full, will try and flush itself on a single interrupt. Apparently under linux this is a problem because the serial buffer is only 512 bytes and it overflows. Is this also a problem in FreeBSD? I also get a lot of messages like this in /var/log/messages and on the console: Jun 16 23:31:16 foo kernel: sio4: 137 more interrupt-level buffer overflows (total 821) That would seem to indicate that dumping 576 bytes on a single interrupt is too much. yes? no? Probably. The buffer is dynamically sized depending on the line speed but is usually about 512 (min is 128). The scaling for this is easy to change (function siosetwater()). The buffer size is also a bit small given -current's broken interrupt latency, and is a lot too small if HZ is too large. This is only a problem if the modem has broken flow control to go with its wanting to dump its too-large buffer. For flow control to work, the sender has to stop sending before the reciever's buffers fill up, so it must have a granularity smaller than the receiver's buffer size (more precisely, the space above high water in the receiver's buffer). So non-broken flow control is especially important for senders with large buffers -- there are sure to be some receivers with smaller buffers. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-06-18 06:52:24 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-06-18 06:52:24 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-18 06:55:06 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] from /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/elf2aout/elf2aout.c:31: /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/sys/elf_common.h:241:33: warning: /* within comment cc -O -pipe -mcpu=pentiumpro -Wsystem-headers -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -o elf2aout elf2aout.o === usr.bin/elfdump cc -O -pipe -mcpu=pentiumpro -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/elfdump/elfdump.c In file included from /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/sys/elf32.h:32, from /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/elfdump/elfdump.c:32: /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/sys/elf_common.h:241:33: /* within comment *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin/elfdump. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-06-18 07:46:24 - /usr/bin/make returned exit code 1 TB --- 2003-06-18 07:46:24 - ERROR: failed to build world TB --- 2003-06-18 07:46:24 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems on 5.1
On Tue, Jun 17, 2003 at 04:21:41PM +0100, Antony T Curtis wrote: On a Compaq Armada V300 notebook, if I load the acpi module, boot fails after the kernel prints about half a dozen acpi_bus_number: can't get _ADR, fails to detect any of the hardware and panics because of failure to mount root. With the acpi module disabled, the machine is able to boot up. This same machine used to be able to run 5.0-CURRENT with ACPI enabled and I think the ACPICA merge at around May 2003 could be responsible. Hi, Was able to get ACPI working with FreeBSD on my Compaq Evo N800c. I have put up the stuff at my site here - http://khader.net/archives/p/319/c/1#comments Of course, now, acpi_thermal seems to be giving me problems, as it crashes every 5 minutes. Will see if I can get a trace and post the same here. Regards Sid -- Do something unusual today. Pay a bill. Sid Carter - http://khader.net ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
Wiktor Niesiobedzki wrote: On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: I am still not able to reproduce this. Can you update your sources? I commited some code just now that removed an external dependency from sched_nice(). This should make it more robust. Got it - its LAZY_SWITCH, without it - all is working fine, but when this option is set, I get panics. Good catch! -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/kern sched_ule.c (fwd)
On Tue, 17 Jun 2003 02:45:18 -0400 (EDT), Jeff Roberson [EMAIL PROTECTED] wrote: My last few commits, including this one, went a long way towards improving ULE's interactive responsiveness under heavy load. I was just able to do a make -j32 of my kernel while browsing the web with mozilla and commiting this change. Mozilla, my shell, cvs, etc. were all as responsive as they are on an unloaded system. Don't you think, the mplayer, xine and sound stuff might be better apps to test? Like, play the video and sound to see if they won't skip the frames or lag behind. Cheers, Mezz This is on a 2ghz laptop so your mileage may not be exactly the same. This is a significant improvement over the old state of things. If the interactive perf was chasing you away before, ULE should be much better now. Cheers, Jeff -- Forwarded message -- Date: Mon, 16 Jun 2003 23:39:51 -0700 (PDT) From: Jeff Roberson [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/kern sched_ule.c jeff2003/06/16 23:39:51 PDT FreeBSD src repository Modified files: sys/kern sched_ule.c Log: - Add a new function sched_interact_update() that scales back the sleep and run time. - Scale the sleep and run time back via sched_interact_update() in more places. This is to keep the statistic more accurate. - Charge a parent one tick for forking a child. - Add only the run time and not the sleep time to the parents kg when a thread exits. This allows us to give a penalty for having an expensive thread exit but does not give a bonus for having an interactive thread exit. - Change the SLP_RUN_THROTTLE to limit us to 4/5th and not 1/2. - Change the SLP_RUN_MAX to two seconds. This keeps bursty interactive applications like mozilla and openoffice in the interactive range even through expensive tasks. - Recalculate the slice after every sleep. This ensures that once a task has been marked interactive it only has a slice of 1 at the risk of giving tasks that sleep for a very brief period a longer time slice. Revision ChangesPath 1.42 +20 -23src/sys/kern/sched_ule.c -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
fun with WITNESS and pool mutex
When I was attempting to debug a system deadlock problem where the
culprit process was sleeping on a pool mutex, I noticed that show
witness in ddb doesn't report anything about this particular mutex
flavor. I discovered that witness doesn't monitor these mutexes because
mtx_pool_setup() calls mtx_init with the MTX_NOWITNESS flag.
These are a mutexes bit special, because they are supposed to be leaf
mutexes and no other mutexes should be grabbed after them. The deadlock
in question caused me to discover a violation of this restriction, so I
wondered if there were more problems of this type in the code. I
suspected there would be, since there haven't been any automatic checks
of to verify that these mutexes are being used correctly.
Just for grins, I removed the MTX_NOWITNESS flag from mtx_pool_setup()
and quickly found the first violation during the boot sequence:
Mounting root from ufs:/dev/da0s1a
acquiring duplicate lock of same type: pool mutex
1st pool mutex @ /usr/src/sys/kern/vfs_syscalls.c:736
2nd pool mutex @ /usr/src/sys/kern/kern_lock.c:598
Stack backtrace:
backtrace(c051f4df,c051c041,c051adcc,256,c05e4808) at backtrace+0x17
witness_lock(c05e0cf0,8,c051adcc,256,c05e2ae0) at witness_lock+0x697
_mtx_lock_flags(c05e0cf0,0,c051adcc,256,c641a248) at _mtx_lock_flags+0xb1
lockstatus(c641a304,0,e4b1ab24,c036f2e8,e4b1ab44) at lockstatus+0x3c
vop_stdislocked(e4b1ab44,e4b1ab30,c0464f78,e4b1ab44,e4b1ab58) at vop_stdislocked
+0x21
vop_defaultop(e4b1ab44,e4b1ab58,c0375a67,e4b1ab44,c05e4808) at vop_defaultop+0x1
8
ufs_vnoperate(e4b1ab44,c05e4808,c05740ac,c05b67e0,c641a248) at ufs_vnoperate+0x1
8
assert_vop_locked(c641a248,c05197fc,c05b74e0,c641a248,0) at assert_vop_locked+0x
47
VOP_GETVOBJECT(c641a248,0,c0524224,2e0,c05740ac) at VOP_GETVOBJECT+0x3f
kern_open(c61c64c0,bfbff6b0,0,1,0) at kern_open+0x44f
open(c61c64c0,e4b1ad10,c0537dc3,3fd,3) at open+0x30
syscall(2f,2f,2f,1,0) at syscall+0x26e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (5), eip = 0x80529ef, esp = 0xbfbff16c, ebp = 0xbfbff208 ---
The code in question:
FILEDESC_LOCK(fdp);
FILE_LOCK(fp);
if (fp-f_count == 1) {
KASSERT(fdp-fd_ofiles[indx] != fp,
(Open file descriptor lost all refs));
FILEDESC_UNLOCK(fdp);
FILE_UNLOCK(fp);
VOP_UNLOCK(vp, 0, td);
vn_close(vp, flags FMASK, fp-f_cred, td);
fdrop(fp, td);
td-td_retval[0] = indx;
return 0;
}
/* assert that vn_open created a backing object if one is needed */
KASSERT(!vn_canvmio(vp) || VOP_GETVOBJECT(vp, NULL) == 0,
(open: vmio vnode has no backing object after vn_open));
fp-f_data = vp;
fp-f_flag = flags FMASK;
fp-f_ops = vnops;
fp-f_type = (vp-v_type == VFIFO ? DTYPE_FIFO : DTYPE_VNODE);
FILEDESC_UNLOCK(fdp);
FILE_UNLOCK(fp);
This one appears to be easily fixable by moving the second KASSERT down
a few lines to below the FILE_UNLOCK() call.
Any bets on how many other potential deadlock problems there are in the
tree?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems tuning kmem_map on 5.1-REL box.
On Tue, Jun 17, 2003, Peter Losher wrote: Hi - If this sort of question is better asked on a more specialized list @freebsd.org, please let me know. (Since 5.1 is still considered a developmental release, one doesn't know if either -current or -stable would be more appropriate. So I am sending it to -current. So, I recently put a Quad-Xeon server (w/ 4GB of RAM) into production as primarily as a master FTP server for ISC as well as for FreeBSD (US/IPv6 side of ftp.freebsd.org). All has been going well for the past couple of weeks until 5.1 was released. Traffic spiked, and the server started panicking every 12 hours: panic: kmem_malloc(4096): kmem_map too small: 377487360 total allocated So after looking at the archives, I read that FreeBSD had issues with installed memory above 2GB, so I set the sysctl kern.maxvnodes=13, but to no effect: panic: kmem_malloc(16384): kmem_map too small: 293519360 total allocated I have since removed my NMBCLUSTER setting in the kernel, so it would be set automatically, I have even set VM_KMEM_SIZE_SCALE=2 (I haven't messed with the other KMEM kernel options, as I was hoping to avoid it) And a couple of hours ago I updated the kernel with the latest kern_malloc.c file in the RELENG_5_1 branch. To allow the kmem_map to exceed 200 MB, you'll also need to tweak VM_KMEM_SIZE_MAX to (for example) '(1024 * 1024 * 1024)'. BTW, the formula, which I stole from vmparam.h, is: min(max(VM_KMEM_SIZE, Physical memory/VM_KMEM_SIZE_SCALE), VM_KMEM_SIZE_MAX) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-06-18 07:46:25 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-06-18 07:46:25 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-18 07:50:34 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/elf2aout/elf2aout.c: In function `main': /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/elf2aout/elf2aout.c:130: warning: cast increases required alignment of target type cc -O -pipe-Wsystem-headers -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -o elf2aout elf2aout.o === usr.bin/elfdump cc -O -pipe-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/elfdump/elfdump.c In file included from /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/sys/elf32.h:32, from /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/elfdump/elfdump.c:32: /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include/sys/elf_common.h:241:33: /* within comment *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin/elfdump. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-06-18 08:47:03 - /usr/bin/make returned exit code 1 TB --- 2003-06-18 08:47:03 - ERROR: failed to build world TB --- 2003-06-18 08:47:03 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ULE nice bugs are fixed.
On Wed, Jun 18, 2003 at 02:43:43AM -0400, Jeff Roberson wrote: On Wed, 18 Jun 2003, Wiktor Niesiobedzki wrote: On Tue, Jun 17, 2003 at 03:51:32PM -0400, Jeff Roberson wrote: I am still not able to reproduce this. Can you update your sources? I commited some code just now that removed an external dependency from sched_nice(). This should make it more robust. With the new code, I'm also unable to reproduce the panic :) With LAZY_SWITCH enabled? Double checked - yes. No panic with LAZY_SWITCH. Wiktor ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-18 08:47:04 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-18 08:47:04 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-18 08:49:58 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/elf2aout/elf2aout.c: In function `main': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/elf2aout/elf2aout.c:130: warning: cast increases required alignment of target type cc -O -pipe-Wsystem-headers -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -o elf2aout elf2aout.o === usr.bin/elfdump cc -O -pipe-Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/elfdump/elfdump.c In file included from /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/sys/elf32.h:32, from /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/elfdump/elfdump.c:32: /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include/sys/elf_common.h:241:33: /* within comment *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin/elfdump. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/usr.bin. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-18 09:36:17 - /usr/bin/make returned exit code 1 TB --- 2003-06-18 09:36:17 - ERROR: failed to build world TB --- 2003-06-18 09:36:17 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM_FOX
I have just committed the GEOM_FOX class, see commit message below. GEOM_FOX is named after the common red fox, which amongst other traits have a liking for having multiple exits from its den. GEOM_FOX will recognize a magic label on the device, and all devices which come up with the same label will be assumed to be independent paths to the same underlying physical device. The first device found will name the created redundant device (I need to work on that aspect because it makes the name a bit unpredicatable right now). If the currently used path to the device fails, GEOM_FOX will switch to another path and retry the operation. For anyone who wants to play with this, the following shell script could be a beginning. It exploits the fact that the same file can be used to back several MD(4) devices, so you need no special hardware. This will probably be most interesting for people with FibreChannel/SAN hardware, but since the isp driver has very aggresive retrie policies as it is now, the actual usability is still somewhat below par. I'm sure both mjacob an I would appreciate any help we can get in fixing this. #!/bin/sh set -ex # cleanup mdconfig -d -u 10 /dev/null 21 || true mdconfig -d -u 20 /dev/null 21 || true kldunload geom_fox /dev/null 21 || true # Create a 4M disk image dd if=/dev/zero of=fox.img bs=1k count=4096 # create a disk on it. mdconfig -a -t vnode -f fox.img -u 10 # Put the GEOM::FOX label on it echo GEOM::FOX test-fox | dd of=/dev/md10 conv=sync # load the geom_fox module kldload geom_fox # add another path mdconfig -a -t vnode -f fox.img -u 20 # remove it again mdconfig -d -u 20 # add it again mdconfig -a -t vnode -f fox.img -u 20 # remove the original path mdconfig -d -u 10 # add it again mdconfig -a -t vnode -f fox.img -u 10 # newfs the fox newfs /dev/md10.fox # fsck it fsck_ffs /dev/md10.fox # remove the currently primary path mdconfig -d -u 20 # fsck it again fsck_ffs /dev/md10.fox # add a new secondary path mdconfig -a -t vnode -f fox.img -u 30 # remove the primary mdconfig -d -u 10 # fsck it again fsck_ffs /dev/md10.fox # Remove the primary and only path mdconfig -d -u 30 # See what's left (hopefully nothing) ls -l /dev/md* In message [EMAIL PROTECTED], Poul-Henning Kamp w rites: phk 2003/06/18 02:29:28 PDT FreeBSD src repository Modified files: sys/modules/geom Makefile sys/conf NOTES files options Added files: sys/geom geom_fox.c sys/modules/geom/geom_fox Makefile Log: Add GEOM_FOX, a class which detects and selects between multiple redundant paths to the same device. This class reacts to a label in the first sector of the device, which is created the following way: #0123456789abcdef012345... #magic--id-... echo GEOM::FOX someid | dd of=/dev/da0 conv=sync NB: Since the fact that multiple disk devices are in fact the same device is not known to GEOM, the geom taste/spoil process cannot fully catch all corner cases and this module can therefore be confused if you do the right wrong things. NB: The disk level drivers need to do the right thing for this to be useful, and that is not by definition currently the case. Revision ChangesPath 1.1153+1 -0 src/sys/conf/NOTES 1.795 +1 -0 src/sys/conf/files 1.395 +1 -0 src/sys/conf/options 1.1 +468 -0src/sys/geom/geom_fox.c (new) 1.4 +1 -0 src/sys/modules/geom/Makefile 1.1 +8 -0 src/sys/modules/geom/geom_fox/Makefile (new) -- 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]
ports problem after new world
After updating 5.1-CURRENT this morning I get the following error when trying to build any port: Your system is too old to use this bsd.port.mk. You need a fresh make world or an upgrade kit. Please go to http://www.FreeBSD.org/ports/ or a mirror site and follow the instructions. I always do my best to follow the handbook upgrade path, so I'm not sure if I've done something wrong or if there's a problem with a commit that was made within the last 24hrs. Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EHCI USB on _top_ of UHCI?
On Tue, Jun 17, 2003 at 10:46:53PM -0400, David Gilbert wrote: I'm running 5.1-RELEASE and have USB2.0 ports in my Dell D800 laptop. I also have a USB2.0 drive encloseure with a 120G drive in it... so I'm very motivated to get this to work :). To start, I posted briefly about this before... and some people suggested that this may have a bad interaction with ACPI. I have ruled that out ... disabling ACPI or fixing ACPI (by obtaining fixed ACPI code) doesn't change the EHCI behaviour. So ... some datapoints. USB 1.1 (UHCI) works. If EHCI isn't in the kernel all manner of USB devices work. I have tested the drive, an external DVD enclosure and a mouse. This is good. However, if EHCI is in the kernel, attaching the drive gives the following messages: Jun 13 22:15:46 canoe kernel: usb3: unrecoverable error, controller halted Jun 13 22:15:46 canoe kernel: usb3: blocking intrs 0x10 Jun 13 22:16:05 canoe kernel: uhub3: device problem, disabling port 3 Jun 13 22:16:48 canoe kernel: usb3: port reset timeout Jun 13 22:16:48 canoe kernel: uhub3: port 1 reset failed Please compile USB_DEBUG into your kernel and do a sysctl hw.usb.ehci.debug=2 before connecting a device. ... and then usb doesn't work thereafter. Is this something that's Yes - The ehci controller do only high speed and are sharing the physical ports with one or more USB 1.x companion controllers, which are doing full and low speed support. New devices are check for high speed first and if that controller stops... fixable? I'm willing to do some work on this, but I'm a little at a loss on where to start. I intend to track -CURRENT with this laptop, but my attempt to move from 5.1-RELEASE to -CURRENT was stymied by source that wouldn't compile. Hard to help without errors here... -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
Juan Rodriguez Hervella wrote: Hello: I've got a PCI-NVidia Riva TNT 64 video card at home, and I've tried to compile the drivers but it doesn't work, and after changing the source to let the compilation progress, when the module is loaded I've received a kernel panic. Im using FreeBSD-5.1 with XFree86-4.3, what can I do to solve this issue ? I can not run the X system using the nv driver, my computer hangs up. #pciconf -l -v [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de rev=0x15 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' This is my video card, which sounds just like yours. I have it working fine with the native XFree 'nv' module, but two caveats: First, once you have installed the driver from NVidia, your /usr/X11 tree will contain files that prevent the native 'nv' module from working. I was never able to figure out which files were responsible so I finally deleted the entire /usr/X11 tree and reinstalled everything from scratch. Second, you must be very careful which modules you load in your XF86Config. There is at least one module which will prevent everything from working-- unfortuneately I can't remember which one :0( Section Module Load extmod Load xie Load pex5 Load dbe Load record Load xtrap Load speedo # Load glx Load type1 Load freetype EndSection Notice that I have 'glx' commented out -- I think that's the reason I did that, but it was a long time ago. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
I've got a PCI-NVidia Riva TNT 64 video card at home, and I've tried to compile the drivers but it doesn't work, and after changing the source to let the compilation progress, when the module is loaded I've received a kernel panic. Im using FreeBSD-5.1 with XFree86-4.3, what can I do to solve this issue ? I can not run the X system using the nv driver, my computer hangs up. Try using the port of the driver instead of doing things manually: cd /usr/ports/x11/nvidia-driver make make install That should apply the proper patches to the kernel part of the driver. If it doesn't, it's possible your ports tree is out of date. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
#pciconf -l -v [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de rev=0x15 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' This is my video card, which sounds just like yours. I have it working fine with the native XFree 'nv' module, but two caveats: The nv module won't support 3d acceleration. IF you want 3d accel, you have to use nvidia's binary driver. First, once you have installed the driver from NVidia, your /usr/X11 tree will contain files that prevent the native 'nv' module from working. I was never able to figure out which files were responsible so I finally deleted the entire /usr/X11 tree and reinstalled everything from scratch. Second, you must be very careful which modules you load in your XF86Config. There is at least one module which will prevent everything from working-- unfortuneately I can't remember which one :0( Section Module Load extmod Load xie Load pex5 Load dbe Load record Load xtrap Load speedo # Load glx Load type1 Load freetype EndSection Notice that I have 'glx' commented out -- I think that's the reason I did that, but it was a long time ago. You did it because the nvidia binary drivers require you to. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
On Wednesday 18 June 2003 16:05, Kenneth Culver wrote: #pciconf -l -v [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de rev=0x15 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' This is my video card, which sounds just like yours. I have it working fine with the native XFree 'nv' module, but two caveats: The nv module won't support 3d acceleration. IF you want 3d accel, you have to use nvidia's binary driver. Hello! I've got exactly that video card :) So...the best way is using the ports collection, do I still have to delete options INVARIANT and recompile the kernel ? It's very painful for me to compile things because I've got an old computer (Pentium MMX 200Mhz) and it takes long time to compile the kernel, so if I can still use both the kernel with INVARIANTS and install the nvidia-port, I'd be delighted. I'm not at home yet :( Thanks! First, once you have installed the driver from NVidia, your /usr/X11 tree will contain files that prevent the native 'nv' module from working. I was never able to figure out which files were responsible so I finally deleted the entire /usr/X11 tree and reinstalled everything from scratch. Second, you must be very careful which modules you load in your XF86Config. There is at least one module which will prevent everything from working-- unfortuneately I can't remember which one :0( Section Module Load extmod Load xie Load pex5 Load dbe Load record Load xtrap Load speedo # Load glx Load type1 Load freetype EndSection Notice that I have 'glx' commented out -- I think that's the reason I did that, but it was a long time ago. You did it because the nvidia binary drivers require you to. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- JFRH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
Thus spake Gerrit K?hn ([EMAIL PROTECTED]) [15/06/03 10:40]: CPU: VIA/IDT Unknown (998.70-MHz 686-class CPU) Origin = CentaurHauls Id = 0x689 Stepping = 9 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX This one doesn't seem to support SSE, though I wonder why there is this unknown. My C3 here is an Ezra and is identified as Samuel2 with id=067a. I have an Ezra or an Ezra-T core (the only difference is Tualatin sp compatibility), and it produces an Unknown. If you have a 'Samuel2' core, then you have a Samuel2 core. It's neither Ezra nor Ezra-T -- those two are the successors to Samuel2. However, if you have a C3 without SSE, it's basically a K6 with MMX and 3dNow. So I'm using CPUTYPE=k6-3 in /etc/make.conf. Up to now this has been working fine for me. I've been using CPUTYPE=i586/mmx. That's been working for me as well -- I'd be interested to see which is more optimized. Does your chip understand CMOV? GCC presumes that a 686-class processor has CMOV, and while the C3 /is/ a 686-class processor, it doesn't do CMOV. But I heard a rumor that the Samuel2 core /does/ do CMOV... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
flock error
I'm trying to do a make release on 5.1-RELEASE to do a custom 5.1. CHROOTDIR=/home/custom and CVSROOT=/home/ncvs are both on a redhat nfs server. I had some errors related to telnet, telnetd and libtelnet. After a few makes the error went away. Now the the error is this: cd /usr/src/release/../etc make TARGET_ARCH=i386 TARGET=i386 distribution DESTDIR=/home /custom cd /usr/src/etc; install -o root -g wheel -m 644 amd.map apmd.conf auth.conf crontab cs h.cshrc csh.login csh.logout devd.conf devfs.conf dhclient.conf disktab fbtab ftpusers ge ttytab group hosts hosts.allow hosts.equiv hosts.lpd inetd.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf phones printcap profile pro tocols rc rc.firewall rc.firewall6 rc.sendmail rc.shutdown rc.subr remote rpc services shells sysctl.conf syslog.conf usbd.conf etc.i386/ttys /usr/src/etc/../gnu/usr.bin/man/m anpath/manpath.config /usr/src/etc/../usr.bin/mail/misc/mail.rc /usr/src/etc/../usr.bin/ locate/locate/locate.rc /home/custom/etc; cap_mkdb /home/custom/etc/login.conf; install -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /home/custom/etc; ins tall -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /home/custom/etc; pwd_mk db -p -d /home/custom/etc /home/custom/etc/master.passwd pwd_mkdb: flock: Operation not supported *** Error code 1 Stop in /usr/src/etc. *** Error code 1 Stop in /usr/src/release. I read somewhere weeks ago, that on -current, nfs locking and chroot stuff didn't play well together Was this corrected, or is this a user error? :) Santos ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions 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]
Why doesn't background fsck work ?
Hello!: I tried to make my Nvidia video card work yesterday, and everytime I launched the X system my computer hang up. So I had to make a hard reboot. (I think I will fix the Xs problem this night at home) But I've got another weird problem. :) The fsck of my partitions is always made on the foregroud, although I've heard about something like a delayed/background file system checker. Why is it always made on the foreground ? -- JFRH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
On Wed, Jun 18, 2003 at 10:44:17AM -0400, Damian Gerow wrote: I have an Ezra or an Ezra-T core (the only difference is Tualatin sp compatibility), and it produces an Unknown. If you have a 'Samuel2' core, then you have a Samuel2 core. It's neither Ezra nor Ezra-T -- those two are the successors to Samuel2. Well, all I can say is, that I bought it as Ezra and there is Ezra printed on it. FreeBSD identifies it as Samuel2, though. However, if you have a C3 without SSE, it's basically a K6 with MMX and 3dNow. So I'm using CPUTYPE=k6-3 in /etc/make.conf. Up to now this has been working fine for me. I've been using CPUTYPE=i586/mmx. That's been working for me as well -- I'd be interested to see which is more optimized. I don't know. But I think there are only rare cases where you will notice differences. Does your chip understand CMOV? GCC presumes that a 686-class processor has CMOV, and while the C3 /is/ a 686-class processor, it doesn't do CMOV. But I heard a rumor that the Samuel2 core /does/ do CMOV... I guess it doesn't understand CMOV. I can remember trying i686 first and having problems with several applications then... afair /usr/ports/editors/joe was among them (crashed when starting). I had already heard about that CMOV thing then and blamed the crashes on the i686-setting. Since I moved to k6-3, everything is just fine. cu Gerrit -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
On Wednesday 18 June 2003 16:05, Kenneth Culver wrote: #pciconf -l -v [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de rev=0x15 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' This is my video card, which sounds just like yours. I have it working fine with the native XFree 'nv' module, but two caveats: The nv module won't support 3d acceleration. IF you want 3d accel, you have to use nvidia's binary driver. Hello! I've got exactly that video card :) So...the best way is using the ports collection, do I still have to delete options INVARIANT and recompile the kernel ? It's very painful for me to compile things because I've got an old computer (Pentium MMX 200Mhz) and it takes long time to compile the kernel, so if I can still use both the kernel with INVARIANTS and install the nvidia-port, I'd be delighted. I'm not at home yet :( Thanks! You will most likely have to remove INVARIANT as well if you are running the GENERIC kernel. If you've never recompiled your kernel, then most likely you are running the GENERIC kernel. If you have recompiled your kernel, just make sure you've taken that option out. Ken ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
Thus spake Gerrit K?hn ([EMAIL PROTECTED]) [18/06/03 11:00]: If you have a 'Samuel2' core, then you have a Samuel2 core. It's neither Ezra nor Ezra-T -- those two are the successors to Samuel2. Well, all I can say is, that I bought it as Ezra and there is Ezra printed on it. FreeBSD identifies it as Samuel2, though. And I bought my Ezra as a Nehemiah. Via (VIA) has no clear distinction between the cores, even though there are some pretty big differences (full speed FPU, SSE support). It would have made sense to call it C3 then C4 then C5, or some other way to distinguish between the different chips. Resellers seem to have problems figuring out which chip it is that they're selling. All I know is that the product line went: Samuel - Samuel2 - Ezra - Ezra-T - Nehemiah However, one page seems to indicate that the product line went more like: Samuel (C5A) - Samuel2 (C5B) - Ezra/Samuel3 (C5C) - Ezra-T (C5N) - Eden - Nehemiah where Eden is really just a bundled chip (with a specific VIA north/south bridge). So maybe they do have a way to distinguish the chips. Dunno -- at the very least, it's not marketed. And the Samuel2 is definitely not an Ezra. FWIW, the best way I've seen to figure out which chip you're using (at least between Ezra/Ezra-T and Nehemiah) is to look at the clocking -- Ezra/Ezra-T seems to be 100*10.0, whereas Nehemiah seems to be 133*7.5. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
On Wed, Jun 18, 2003 at 11:10:49AM -0400, Damian Gerow wrote: Well, all I can say is, that I bought it as Ezra and there is Ezra printed on it. FreeBSD identifies it as Samuel2, though. And I bought my Ezra as a Nehemiah. [...] So maybe they do have a way to distinguish the chips. Dunno -- at the very least, it's not marketed. And the Samuel2 is definitely not an Ezra. Thanks for the clarification. I'm almost sure that there was something with ezra printed right on the cpu, but I can't remember for sure; so maybe you're right with the assumption that it's in fact a Samuel2. FWIW, the best way I've seen to figure out which chip you're using (at least between Ezra/Ezra-T and Nehemiah) is to look at the clocking -- Ezra/Ezra-T seems to be 100*10.0, whereas Nehemiah seems to be 133*7.5. Back to the performance-discussion between cputype 586/mmx and k6-3 optimization: do you have a suggestion how to benchmark it? cu Gerrit -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C3
This isn't really a -current issue, moving to hardware. Please strip the Cc: in your reply. Thus spake Gerrit K?hn ([EMAIL PROTECTED]) [18/06/03 11:20]: FWIW, the best way I've seen to figure out which chip you're using (at least between Ezra/Ezra-T and Nehemiah) is to look at the clocking -- Ezra/Ezra-T seems to be 100*10.0, whereas Nehemiah seems to be 133*7.5. (Note that this obviously only holds true for 1GHz rated chips.) Back to the performance-discussion between cputype 586/mmx and k6-3 optimization: do you have a suggestion how to benchmark it? Well, there's always /usr/ports/benchmarks. nbench might be what you're looking for -- compile it once using 586/mmx support, and once using k6-3 support. Other than that, time a buildworld/buildkernel. But I'm not a benchmarking person by any means, so this may or may not be accurate. Doing the buildworld/buildkernel will probably be more intensive -- compile it with k6-3 flags, reboot, then do another compile with the same flags. Time that one. Do the whole process again with 586/mmx flags, again, timing the second of the two builds. I don't have a couple of days to throw at benchmarks, so I definitely won't be doing this. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI errors on boot
On Wed, Jun 18, 2003 at 09:11:23AM +0200, Maikel Verheijen wrote: I have recently installed FreeBSD 5.1 on my Dell C800 laptop, and I get quite a lot (well: 48 :) of these errors on boot: ACPI-0293: *** Warning: Buffer created with zero length in AML -0166: *** Error: UtAllocate: Attempt to allocate zero bytes Are those harmfull? Is there something I can do with it? Otherwise my laptop is working perfectly... :) ^ I have serious doubts on that. I'm pretty sure your battery status won't be showed correctly. Fix is in the archives of this and/or acpi-jp@ list. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't background fsck work ?
On Wed, Jun 18, 2003 at 04:54:44PM +0200, Juan Rodriguez Hervella wrote: Hello!: I tried to make my Nvidia video card work yesterday, and everytime I launched the X system my computer hang up. So I had to make a hard reboot. (I think I will fix the Xs problem this night at home) But I've got another weird problem. :) The fsck of my partitions is always made on the foregroud, although I've heard about something like a delayed/background file system checker. Why is it always made on the foreground ? No softupdates enabled? -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI suspending.
On Tue, Jun 17, 2003 at 10:57:32PM -0400, David Gilbert wrote: I have a Dell D800 laptop (as I've mentioned a few times here) and I've gone so far as to upgrade the BIOS to A03 and fetch new ACPI DSDT code from the linux site. Please compare that one with the one posted on the list. I recall that one being pretty bogus. I am not totally sure though. The 'S1' suspend is where the processor clock is halted. I assume that other things turn off ... but the laptop still generates enough heat to need it's fan ... especially if I try to put it in my laptop bag. S1 is indeed not particularly useful. What I'd like to know is how much work (and possibly pointers to where I'd look) to fix the S3 level suspension. It would be nice if you actually told what is broken before we discuss the fix. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Need acpi-event-d?
On Tue, Jun 17, 2003 at 06:40:59AM -0600, M. Warner Losh wrote: : I think devd(8) should be used for this, but I havn't tried. devd does not (currently) get events for suspend/resume. Maybe it should. Either devd should or we do need an acpid. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't background fsck work ?
On Wednesday 18 June 2003 17:39, Bernd Walter wrote: On Wed, Jun 18, 2003 at 04:54:44PM +0200, Juan Rodriguez Hervella wrote: Hello!: I tried to make my Nvidia video card work yesterday, and everytime I launched the X system my computer hang up. So I had to make a hard reboot. (I think I will fix the Xs problem this night at home) But I've got another weird problem. :) The fsck of my partitions is always made on the foregroud, although I've heard about something like a delayed/background file system checker. Why is it always made on the foreground ? No softupdates enabled? yes, you've got it ! I haven't got softupdates enabled, but I didn't want to enable it, because I've heard that it isn't 100% reliable and I didn't want to lose data Do you recommend me to switch it on ? Thanks! -- JFRH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't background fsck work ?
On Wed, Jun 18, 2003 at 05:51:00PM +0200, Juan Rodriguez Hervella wrote: On Wednesday 18 June 2003 17:39, Bernd Walter wrote: On Wed, Jun 18, 2003 at 04:54:44PM +0200, Juan Rodriguez Hervella wrote: Hello!: I tried to make my Nvidia video card work yesterday, and everytime I launched the X system my computer hang up. So I had to make a hard reboot. (I think I will fix the Xs problem this night at home) But I've got another weird problem. :) The fsck of my partitions is always made on the foregroud, although I've heard about something like a delayed/background file system checker. Why is it always made on the foreground ? No softupdates enabled? yes, you've got it ! I haven't got softupdates enabled, but I didn't want to enable it, because I've heard that it isn't 100% reliable and I didn't want to lose data Softupdates works reliable from what I can tell. Snapshots might have some issues and background fsck uses snapshots. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current] Re: ACPI suspending.
Mark == Mark Santcroos [EMAIL PROTECTED] writes: Mark On Tue, Jun 17, 2003 at 10:57:32PM -0400, David Gilbert wrote: I have a Dell D800 laptop (as I've mentioned a few times here) and I've gone so far as to upgrade the BIOS to A03 and fetch new ACPI DSDT code from the linux site. Mark Please compare that one with the one posted on the list. I Mark recall that one being pretty bogus. I am not totally sure Mark though. You shouldn't happen to have a reference to the one posted to the list, would you? Sometimes the FreeBSD list search facility isn't that useful. I'll make an effort to find it. Is there any effort to centralize our knowledge of DSDT's? What I'd like to know is how much work (and possibly pointers to where I'd look) to fix the S3 level suspension. Mark It would be nice if you actually told what is broken before we Mark discuss the fix. It appears to suspend to S3, although not completely and not everytime. It appears to try to resume (ie it makes spinning up noises), but the screen never comes back and things like the pccard don't wake up. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current] Re: ACPI suspending.
On Wed, Jun 18, 2003 at 12:11:52PM -0400, David Gilbert wrote: You shouldn't happen to have a reference to the one posted to the list, would you? Sometimes the FreeBSD list search facility isn't that useful. I'll make an effort to find it. Date: Tue, 27 May 2003 22:28:32 +0200 Subject: Re: FBSD 5.1b2 Inst. Results on Dell i8500 Message-ID: [EMAIL PROTECTED] Is there any effort to centralize our knowledge of DSDT's? Yes, something like that is underway. What I'd like to know is how much work (and possibly pointers to where I'd look) to fix the S3 level suspension. Mark It would be nice if you actually told what is broken before we Mark discuss the fix. It appears to suspend to S3, although not completely and not everytime. It appears to try to resume (ie it makes spinning up noises), but the screen never comes back and things like the pccard don't wake up. Ok, it would really help if you try and document all cases until you at least exactly know the behavior. From there we can go on. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [current] Re: ACPI suspending.
Mark == Mark Santcroos [EMAIL PROTECTED] writes: Mark Ok, it would really help if you try and document all cases until Mark you at least exactly know the behavior. From there we can go on. What am I looking for? S1 appears to work. S5 appears to work (that is: shutdown -p now works). S4 shouldn't work (we don't suspend to disk AFAIk)... so what should I be looking for when I trigger S3? Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI: LCD
Hi all.. Any one know how to turn off the screen on a notebook i mean totally off, Not the dpms The problem is that when i close the lid it stays on and produces to much heat.. 5-Current on dell inspiron 8500 (with AML patch) -- /* FingerPrint: 5BF1 58B1 DE75 CBE3 6044 7098 1246 1EF6 9E78 041C @@@ @@ @@@ @@! @@@ !@@ @@! @@@ @[EMAIL PROTECTED]@!@ !@@!! @!@ [EMAIL PROTECTED] !!: !!! !:! !!: !!! :: : :: ::.: : :: : : The Power To Kill LinuX */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI: LCD
On Wednesday 18 June 2003 09:42 am, Sebastian Yepes [ESN] wrote: Any one know how to turn off the screen on a notebook i mean totally off, Not the dpms The problem is that when i close the lid it stays on and produces to much heat.. It varies from notebook to notebook. For example, on my Satellite 1605, I can find no way to do this through ACPI, DPMS, or any other means. On my Pavilion N5290 running Gentoo, there's a kernel module that handles it by twinking hardware registers. The Inspiron 8500 is a Compal machine if I remember correctly, and there's a very slight possibility that some of the utilities intended for other Compal distributors (Compaq, HP, Toshiba) might work. (The Linux omnibook kernel module works on two of my machines, both Compals, only one an HP.) You might get more information on this from the freebsd-mobile list, also. -Cliff L. Biffle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
APM problem in 5.1-RELEASE
Not sure if this is the appropriate list, but I've tried the -mobile list a few times with no response. Background: --- I have an IBM Thinkpad A30p with all the latest BIOS code and Controller code. It's running 5.1-RELEASE well. But I had to set: hw.pci.allow_unsupported_io_range=1 To get the kernel booting. I have apm enabled and loading properly in the kernel (as a module), and I have apmd running and apm enabled in user space. Problem: I can place the system into Standby mode and bring it back without problems, but when I try to suspend the system, I run into problems: The system suspends without problems. But when I try to bring it back from suspend it freezes right after the line: ata1: resetting devices .. Firewire appears to resume fine, and so does ata0, but I think it's hanging on the ATAPI devices under ata1. Help! This APM BIOS suspends fine under Linux (2.4.18 kernel)! I've tried everything I can think of to get suspend working under 5.1-RELEASE! I will happily do my best to provide any further information required! I'll even build a debug kernel if that's what it takes. I'm out of ideas here... Dmesg.boot: --- 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.1-RELEASE #7: Wed Jun 18 12:02:02 EDT 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TREVARTHAN Preloaded elf kernel /boot/kernel/kernel at 0xc04df000. Preloaded elf module /boot/kernel/snd_ich.ko at 0xc04df26c. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04df318. Preloaded elf module /boot/kernel/apm.ko at 0xc04df3c4. Timecounter i8254 frequency 1193182 Hz CPU: Intel(R) Pentium(R) III Mobile CPU 1200MHz (1198.99-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 402063360 (383 MB) avail memory = 385155072 (367 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 14 entries at 0xc00fdeb0 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 agp0: Intel 82830 host to AGP bridge mem 0xd000-0xdfff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1800-0x181f irq 9 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1820-0x183f irq 11 at device 29.1 on pci0 usb1: Intel 82801CA/CAM (ICH3) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ums0: Logitech USB Receiver, rev 1.10/16.00, addr 2, iclass 3/1 ums0: 7 buttons and Z dir. uhci2: Intel 82801CA/CAM (ICH3) USB controller USB-C port 0x1840-0x185f irq 9 at device 29.2 on pci0 usb2: Intel 82801CA/CAM (ICH3) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pcib2: PCIBIOS PCI-PCI bridge at device 30.0 on pci0 pci2: PCI bus on pcib2 cbb0: RF5C478 PCI-CardBus Bridge mem 0x5000-0x5fff irq 9 at device 0.0 on pci2 start (5000) sc-membase (c020) start (5000) sc-pmembase (e800) cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 cbb1: RF5C478 PCI-CardBus Bridge mem 0x5010-0x50100fff irq 5 at device 0.1 on pci2 start (5010) sc-membase (c020) start (5010) sc-pmembase (e800) cardbus1: CardBus bus on cbb1 pccard1: 16-bit PCCard bus on cbb1 fwohci0: vendor=1180, dev=522 fwohci0: 1394 Open Host Controller Interface mem 0xc0201000-0xc02017ff irq 9 at device 0.2 on pci2 fwohci0: OHCI version 1.0 (ROM=0) fwohci0: No. of Isochronous channel is 4. fwohci0: EUI64 00:06:1b:02:01:00:24:63 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 if_fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:06:1b:00:24:63 sbp0: SBP2/SCSI over firewire on firewire0 fwohci0: Initiate bus reset wi0: Intersil Prism2.5 mem 0xf000-0xffff irq 9 at device 2.0 on pci2 wi0: 802.11 address: 00:20:e0:8a:90:61 wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.2) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps fxp0: Intel 82801CAM (ICH3) Pro/100 VE Ethernet port 0x8000-0x803f mem
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
Don Lewis [EMAIL PROTECTED] writes: Try the very untested patch below ... RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v When I do the patch, how much of the OS do I need to rebuild, just do a make install in the .../src/sys/kern dir? Rebuild the OS from the top dir? Rebuild the kernel? I want to make sure I'm giving this a proper test. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
On 18 Jun, Chris Shenton wrote: Don Lewis [EMAIL PROTECTED] writes: Try the very untested patch below ... RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v When I do the patch, how much of the OS do I need to rebuild, just do a make install in the .../src/sys/kern dir? Rebuild the OS from the top dir? Rebuild the kernel? I want to make sure I'm giving this a proper test. If the only changes since the last buildworld have been in src/sys, then the slow but safe way is: make buildkernel make installkernel The quicker way is: cd /usr/obj/usr/src/sys/KERNELCONFNAME make make install You can do make reinstall instead of make install if you don't want /boot/kernel.old to be nuked and boot/kernel to be renamed to /boot/kernel.old before the new kernel is installed. You'll have to do it the slow way if you've changed your kernel configuration. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI: LCD
On Wed, 18 Jun 2003, Sebastian Yepes [ESN] wrote: Any one know how to turn off the screen on a notebook i mean totally off, Not the dpms The problem is that when i close the lid it stays on and produces to much heat.. 5-Current on dell inspiron 8500 (with AML patch) More sucky answers from the sucky answer brigade: if I close my notebook lid, the screen remains powered on. But if I open the lid, the screen powers off until I swap virtual consoles between X and normal consoles. So when I want the screen to turn off, I open and close my notebook twice. :-) There seems to be a message here that syscons and other bits need to learn more about dpms, and that acpi needs to provide the necessary events (and time) to the device tree to allow proper power management (and may not currently do that). This came up a number of times at the dev summit last week. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
terminfo man page
I put this on comp.unix.bsd.freebsd.misc, but I'll ask here too. Is there any reason for the terminfo man page? It's a good man page, a very stylish and well-written man page, but it's wrong. It says the terminfo files are in /usr/share/misc/terminfo (they're not there). They do get installed into /usr/local/share/misc/terminfo as part of the ncurses port. Could we just remove the man page from the base system? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problems with wi on 5.1-CURRENT
Hi, Yesterday I sent in an email to freebsd-current about the problems with wi in 5.1-Current. There haven't been any replies to suggest anyone knows why this is happening, how to fix it, or anyone looking into fixing it. Can someone please direct me as to which list (or which person) I should contact to make them aware of the problem? I've checked the cvs entries @ http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/wi/ All the recent changes were done by someone called 'imp'. Should I email this person? (if so what is there email address?) Thankyou -Rob --- http://www.robhulme.com/ http://www.woodlandschurch.org.uk/ easy as 3.1415926535897932384626433832795028841... A programmer is a device for turning coffee into code. Black holes are where God is dividing by zero. --Anonymous Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it. -- Linus Torvalds ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why doesn't background fsck work ?
From: Juan Rodriguez Hervella [EMAIL PROTECTED] Date: Wed, 18 Jun 2003 17:51:00 +0200 Sender: [EMAIL PROTECTED] On Wednesday 18 June 2003 17:39, Bernd Walter wrote: On Wed, Jun 18, 2003 at 04:54:44PM +0200, Juan Rodriguez Hervella wrote: Hello!: I tried to make my Nvidia video card work yesterday, and everytime I launched the X system my computer hang up. So I had to make a hard reboot. (I think I will fix the Xs problem this night at home) But I've got another weird problem. :) The fsck of my partitions is always made on the foregroud, although I've heard about something like a delayed/background file system checker. Why is it always made on the foreground ? No softupdates enabled? yes, you've got it ! I haven't got softupdates enabled, but I didn't want to enable it, because I've heard that it isn't 100% reliable and I didn't want to lose data Theer have been no problems with softupdates in regard to data integrity in either 5.0 or 5.1 release. I do recall a couple of glitches at various times in current, probably prior to 5.0-Release. There is an issue of combining softupdate and write cache. In the event of a power failure, this could lead to a loss of data integrity. But write-cache is dangerous even without softupdate. In addition, because of the nature of softupdate, it is possible that a file is created/updated shortly before a system failure. While data corruption should not be an issue, the file may simply not be there after the system re-boots or may be in an earlier (but still consistent) state. You should probably turn off write cache on any system that you think might lose power. (And just how reliable is that UPS? Batteries (DC) are probably much safer.) But I don't think soft updates are a significant issue. (Others can feel free to tell me I'm an idiot.) You should probably read Kirk's Usnix paper on soft updates. It's very good. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with wi on 5.1-CURRENT
From: Robert Hulme [EMAIL PROTECTED] Date: Wed, 18 Jun 2003 21:03:18 +0100 Sender: [EMAIL PROTECTED] Hi, Yesterday I sent in an email to freebsd-current about the problems with wi in 5.1-Current. There haven't been any replies to suggest anyone knows why this is happening, how to fix it, or anyone looking into fixing it. Can someone please direct me as to which list (or which person) I should contact to make them aware of the problem? I've checked the cvs entries @ http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/wi/ All the recent changes were done by someone called 'imp'. Should I email this person? (if so what is there email address?) Could you let us know EXACTLY how you are doing the configuration? rc.conf or start_if.wi0? I use start_if.wi0 and it seems to work well. With the exception of the key, could you post what you use to do the configuration? 'imp' is M. Warner Losh who posts to both this list and mobile quite often. He is the person primarily responsible for laptop work and related stuff and is also core. Unfortunately, like everyone else, his time is a bit limited. I'm not sure that this will help you, but Warner is the one with the non-disclosure specs for Prism chips, so he will almost certainly be the one to get it fixed. While I would not recommend running this way, could you try not turning on WEP and see if the problem still occurs? This would, at least, provide another data point. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Proof of concept patch for device rearrangement
I have uploaded a proof of concept patch: http://phk.freebsd.dk/patch/fd_dev.patch WARNING: It is perfectly possibly that this patch eats your machine WARNING: destroys your disk and makes your corn-flakes soggy. WARNING: RUN AT YOUR OWN RISK! This patch basically shortcuts access from userland to devices directly from the file descriptor level through DEVFS to the device driver. So far there are no indications that we will not be moving in this direction pretty soon, but it may not be this exact way we do it, this is only a proof of concept at this point. I have only tested this patch lightly on a disk-less machine, I have not tried a lot of advanced stuff with it, and I have already noticed that syslogd seems to have an issue with it during startup (I just press ctrl-C for now). The patch is controlled by the sysctl debug.phk which can take the values 0 (disabled) or 1 (enabled). But the good news is that there is a measurable performance improvement: syv# sysctl debug.phk=0 debug.phk: 1 - 0 syv# dd if=/dev/zero of=/dev/null count=10 10+0 records in 10+0 records out 5120 bytes transferred in 4.784862 secs (10700413 bytes/sec) syv# sysctl debug.phk=1 debug.phk: 0 - 1 syv# dd if=/dev/zero of=/dev/null count=10 10+0 records in 10+0 records out 5120 bytes transferred in 2.211927 secs (23147238 bytes/sec) And with this code enabled, it is possible to go from userland to device driver without touching Giant underway. Comments and test-results are most welcome! -- 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: Proof of concept patch for device rearrangement
Poul-Henning Kamp wrote: I have uploaded a proof of concept patch: http://phk.freebsd.dk/patch/fd_dev.patch ...And with this code enabled, it is possible to go from userland to device driver without touching Giant underway. I'm sorry, I can't parse that last sentence. Could you explain in 25 words or less (or 3 lines of code) what it means? 'Giant' is the lock that Alan is trying to get rid of? Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proof of concept patch for device rearrangement
walt wrote: Poul-Henning Kamp wrote: I have uploaded a proof of concept patch: http://phk.freebsd.dk/patch/fd_dev.patch ...And with this code enabled, it is possible to go from userland to device driver without touching Giant underway. I'm sorry, I can't parse that last sentence. Could you explain in 25 words or less (or 3 lines of code) what it means? 'Giant' is the lock that Alan is trying to get rid of? Giant is the big lock that protects the whole kernel that everyone is trying to get rid of :-). Maxime ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
Don Lewis [EMAIL PROTECTED] writes:
Try the very untested patch below ...
RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.150
Try the very untested patch below ...
diff -u -r1.150 uipc_syscalls.c
--- uipc_syscalls.c 12 Jun 2003 05:52:09 - 1.150
+++ uipc_syscalls.c 18 Jun 2003 03:14:42 -
@@ -1775,10 +1775,13 @@
*/
if ((error = fgetvp_read(td, uap-fd, vp)) != 0)
goto done;
+ vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (vp-v_type != VREG || VOP_GETVOBJECT(vp, obj) != 0) {
error = EINVAL;
+ VOP_UNLOCK(vp, 0, td);
goto done;
}
+ VOP_UNLOCK(vp, 0, td);
Tried it, rebuilt kernel, rebooted, no affect :-(
You were correct about apache using it. Doing a simple
fetch http://pectopah/
causes the error, dropping me into ddb if panic enabled. A tr shows
the same trace as I submitted yesterday :-(
Time to find that null modem cable.
Thanks.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APM problem in 5.1-RELEASE
Jesse Guardiani [EMAIL PROTECTED] wrote: Help! This APM BIOS suspends fine under Linux (2.4.18 kernel)! I've tried everything I can think of to get suspend working under 5.1-RELEASE! Wild-a** guess: ata1-slave: timeout waiting for interrupt ata1-slave: ATAPI identify failed I don't get this in my dmesg (and I have an A31, where apm seems to work). As you say it seems to be hanging during ATA reset, perhaps this has something to do with it? Is there any way to disable the ata1-slave? BIOS? Kernel setting??? -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA DMA broken/kernel panic with 5.1-R/5.1-C and VIA 82C586B
Soeren Schmidt writes: It seems Nicolai E M Plum wrote: I noticed some ATA problems solved in -current recently, so I tried compiling a kernel from sources about 2 days ago. Booting from that (GENERIC) kernel, I do not get Mounting root.., instead I get (approximately, can't cut/paste that console): Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code= supervisor read, page not present instruction pointer = 0x8:0xdeadcode stack pointer = 0x10:0xc736bc38 frame pointer = 0x19:0xc736bc50 current process = 21 (irc14: ata0) kernel: type 12 trap, code=0 Is this a known problem, perhaps specific to the 82C586B ATA controller? This looks strange, I dont have semilar HW here to verify the problem so I'm a bit in the dark. Is it possible you can build a kernel with ddb in it so we can get a traceback of the panic ? I get the following (copied by hand, hopefully no typos): db trace 0 mi_switch(c05bdfc0,4c,c0316220,c05bdfc0,0) at mi_switch+0x210 msleep(c0acb2c4,0,4c,c05dce9f,1) at msleep+0x484 ad_attach(c0acb2c4,1,c14d47c0,c058fef0,c06f7d80) at ad_attach+0x21b ata_boot_attach(0,6fc000,c06f7d80,c03220ba,0) at ata_boot_attach+0x186 run_interrupt_driven_config_hooks(0,6f4000,6f4c00,6f4000,0) at run_interrupt_driven_config_hooks+0x2b mi_startup() at mi_startup+0xb5 begin() at begin+0x2c db Is that any help? Nicolai ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem with USB ulpt0 and CUPS
I posted this in April and received no response. However, this has been an ongoing issue since at least 2001 (where I found the first reference to this trouble via Google). The problem seems to be that the FreeBSD USB LPT driver (even with no-reset) is somehow dropping the first bits of the data stream, causing a page full of trash to be printed prior to the actual print job. I have no verified this problem with 5.1-RELEASE as well. I have a machine that has been serving as a print server. That machine was running CUPS and SAMBA over Linux. Now, it is running FreeBSD 5.0-RELEASE-p7 with CUPS and SAMBA. I have a Lexmark Optra 312 laser printer hooked up to the usb port, ulpt0 (no reset). When it was running linux, everything ran perfectly. I allow the Windows client machines to use their print drivers and send a raw stream through samba to cups for printing. This configuration has worked fine. However, for reasons of my own, I have put FreeBSD 5.0 on this machine. The same software configuration exists for printing. Now, when I print most pages, I get an extra page prefixing the job with two or three lines of printer commands (i.e. resolution = 600, @PCL, etc). This seems to be caused by the FreeBSD usb printer driver dropping a couple of characters at the beginning of the command stream. This used to happen to me with FreeBSD 4.6 as well, which is why that machine was running Linux in the first place. Has anybody seen this strange behavior and is there a known fix for it? Thanks in advance, Tom Veldhouse ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problem with USB ulpt0 and CUPS
On Wed, Jun 18, 2003 at 08:39:12AM -0500, Thomas T. Veldhouse wrote: I posted this in April and received no response. However, this has been an ongoing issue since at least 2001 (where I found the first reference to this trouble via Google). The problem seems to be that the FreeBSD USB LPT driver (even with no-reset) is somehow dropping the first bits of the data stream, causing a page full of trash to be printed prior to the actual print job. I have no verified this problem with 5.1-RELEASE as well. I have a machine that has been serving as a print server. That machine was running CUPS and SAMBA over Linux. Now, it is running FreeBSD 5.0-RELEASE-p7 with CUPS and SAMBA. I have a Lexmark Optra 312 laser printer hooked up to the usb port, ulpt0 (no reset). When it was running linux, everything ran perfectly. I allow the Windows client machines to use their print drivers and send a raw stream through samba to cups for printing. This configuration has worked fine. However, for reasons of my own, I have put FreeBSD 5.0 on this machine. The same software configuration exists for printing. Now, when I print most pages, I get an extra page prefixing the job with two or three lines of printer commands (i.e. resolution = 600, @PCL, etc). This seems to be caused by the FreeBSD usb printer driver dropping a couple of characters at the beginning of the command stream. This used to happen to me with FreeBSD 4.6 as well, which is why that machine was running Linux in the first place. Has anybody seen this strange behavior and is there a known fix for it? I can reproduce it localy with -current, but have no fix. I thought that I had found the reason a few days ago, but murphy teached me better :( There is a bug in signal handling, but that's not our problem here. -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI problems on 5.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks! I have it working nicely now - without any problems. I decompiled, fixed and compiled... problem sorted :) On Wednesday 18 June 2003 8:58 am, Sid Carter wrote: On Tue, Jun 17, 2003 at 04:21:41PM +0100, Antony T Curtis wrote: On a Compaq Armada V300 notebook, if I load the acpi module, boot fails after the kernel prints about half a dozen acpi_bus_number: can't get _ADR, fails to detect any of the hardware and panics because of failure to mount root. With the acpi module disabled, the machine is able to boot up. This same machine used to be able to run 5.0-CURRENT with ACPI enabled and I think the ACPICA merge at around May 2003 could be responsible. Hi, Was able to get ACPI working with FreeBSD on my Compaq Evo N800c. I have put up the stuff at my site here - http://khader.net/archives/p/319/c/1#comments Of course, now, acpi_thermal seems to be giving me problems, as it crashes every 5 minutes. Will see if I can get a trace and post the same here. Regards Sid - -- Antony T Curtis BSc Unix Analyst Programmer http://homepage.ntlworld.com/antony.t.curtis/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+8Sq4ql7dp2cddmIRAjtwAJ9zAEI1jC5m7hvLjeHw7N78i1Uf5ACfW9Tf 0wkliqBvDlGpuf9Dc4s/eMo= =E2VV -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-CURRENT hangs on disk i/o? sysctl_old_user() non-sleepablelocks
On 18 Jun, Chris Shenton wrote:
Don Lewis [EMAIL PROTECTED] writes:
Try the very untested patch below ...
RCS file: /home/ncvs/src/sys/kern/uipc_syscalls.c,v
retrieving revision 1.150
Try the very untested patch below ...
diff -u -r1.150 uipc_syscalls.c
--- uipc_syscalls.c 12 Jun 2003 05:52:09 - 1.150
+++ uipc_syscalls.c 18 Jun 2003 03:14:42 -
@@ -1775,10 +1775,13 @@
*/
if ((error = fgetvp_read(td, uap-fd, vp)) != 0)
goto done;
+vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, td);
if (vp-v_type != VREG || VOP_GETVOBJECT(vp, obj) != 0) {
error = EINVAL;
+VOP_UNLOCK(vp, 0, td);
goto done;
}
+VOP_UNLOCK(vp, 0, td);
Tried it, rebuilt kernel, rebooted, no affect :-(
You were correct about apache using it. Doing a simple
fetch http://pectopah/
causes the error, dropping me into ddb if panic enabled. A tr shows
the same trace as I submitted yesterday :-(
Wierd ... I just tested the patch with ftpd which also uses sendfile()
and didn't get any complaints from DEBUG_VFS_LOCKS.
I'm going to go ahead and commit this patch.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
who has the ACPI BAD PARAMETER patch?
My Dell is exhibiting this error message all over the place.. At USENIX I was told someone had a fix.. Julian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: APM problem in 5.1-RELEASE
One thing that jumps out at me on my T30 is that when I issue the S3, the disk spins down instantly. Under APM it takes several seconds and under Windows XP it also pauses bor a few (maybe 4) seconds. I suspect it is powering down the disk as soon as the S3 is issued and the write cache is never given an opportunity to flush. This may well lead to resume getting into some really bad state regarding the disk. On my system, this has led to corruption, at least. (I, perhaps foolishly, run softupdate with write cache enebled.on my laptop. After all, it is not likely to lose power unexpectedly. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NFS weirdness...
My new web server won't mount NFS from fstab on reboot. on NFSD: (/etc/exports) /home2 -maproot=0 -alldirs httpd on HTTPD: (/etc/fstab) NFSD:/home2 /home nfs rw,bg 0 0 manually mounting works mount NFSD:/home2 /home Works fine until I reboot. Shouldn't it mount by itself? What am I missing now? Why doesn't HTTPD mount NFSD:/home2 on /home when it reboots? I see no errors in messages on either machine. Both are 5.1-CURRENT. TIA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fun with WITNESS and pool mutex
On 18 Jun, I wrote: When I was attempting to debug a system deadlock problem where the culprit process was sleeping on a pool mutex, I noticed that show witness in ddb doesn't report anything about this particular mutex flavor. I discovered that witness doesn't monitor these mutexes because mtx_pool_setup() calls mtx_init with the MTX_NOWITNESS flag. These are a mutexes bit special, because they are supposed to be leaf mutexes and no other mutexes should be grabbed after them. The deadlock in question caused me to discover a violation of this restriction, so I wondered if there were more problems of this type in the code. I suspected there would be, since there haven't been any automatic checks of to verify that these mutexes are being used correctly. Just for grins, I removed the MTX_NOWITNESS flag from mtx_pool_setup() and quickly found the first violation during the boot sequence: [ snip - I committed a patch ] Any bets on how many other potential deadlock problems there are in the tree? The only problems I've found so far are in fdrop_locked() and kern_open(), so things might not be as bleak as I initially feared. I also got this LOR message from witness about the sx lock code: lock order reversal 1st 0xc05e1020 pool mutex (pool mutex) @ /usr/src/sys/kern/kern_sx.c:111 2nd 0xc05dfa00 module subsystem sx lock (module subsystem sx lock) @ /usr/src/s ys/kern/kern_module.c:126 I *think* this is actually a safe use of pool mutex. What would be the best way to quite the complaint? The two possibilities that I can think of are to handle this as a special case in the witness code or to slightly rearrange the code in sx_lock.c to swap the order of the WITNESS_LOCK() and mtx_unlock() calls in _sx*_lock(). ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EHCI USB on _top_ of UHCI?
Bernd == Bernd Walter [EMAIL PROTECTED] writes: Bernd Please compile USB_DEBUG into your kernel and do a sysctl Bernd hw.usb.ehci.debug=2 before connecting a device. Here's the report... (I'm includin the syslog timestamps because the output happens in several spurts.) Jun 19 00:41:28 canoe su: dgilbert to root on /dev/ttyp2 Jun 19 00:42:02 canoe kernel: ehci_pcd: change=0x02 Jun 19 00:42:02 canoe kernel: ehci after reset, status=0x1005 Jun 19 00:42:02 canoe kernel: ehci port 1 reset, status = 0x1005 Jun 19 00:42:03 canoe kernel: ehci_open: pipe=0xc662d600, addr=0, endpt=0 (1) Jun 19 00:42:03 canoe kernel: ehci_alloc_sqtd_chain: start len=8 Jun 19 00:42:03 canoe kernel: usb3: unrecoverable error, controller halted Jun 19 00:42:03 canoe kernel: usb3: blocking intrs 0x10 Jun 19 00:42:08 canoe kernel: ehci_timeout: exfer=0xc6207900 Jun 19 00:42:08 canoe kernel: usbd_dump_pipe: pipe=0xc662d600 Jun 19 00:42:08 canoe kernel: usbd_dump_iface: iface=0 Jun 19 00:42:08 canoe kernel: usbd_dump_device: dev=0xc68b3e00 Jun 19 00:42:08 canoe kernel: bus=0xc61eb400 default_pipe=0xc662d600 Jun 19 00:42:08 canoe kernel: address=0 config=0 depth=1 speed=3 self_powered=0 power=0 langid=-1 Jun 19 00:42:08 canoe kernel: usbd_dump_endpoint: endp=0xc68b3e24 Jun 19 00:42:08 canoe kernel: edesc=0xc68b3e2c refcnt=1 Jun 19 00:42:08 canoe kernel: bEndpointAddress=0x00 Jun 19 00:42:08 canoe kernel: (usbd_dump_pipe:) Jun 19 00:42:08 canoe kernel: refcnt=1 running=1 aborting=0 Jun 19 00:42:08 canoe kernel: intrxfer=0, repeat=0, interval=-1 Jun 19 00:42:08 canoe kernel: ehci_timeout_task: xfer=0xc6207900 Jun 19 00:42:08 canoe kernel: ehci_abort_xfer: xfer=0xc6207900 pipe=0xc662d600 Jun 19 00:42:08 canoe kernel: ehci_sync_hc: cmd=0x00080060 sts=0xb000 Jun 19 00:42:09 canoe kernel: ehci_sync_hc: cmd=0x00080060 sts=0xb000 Jun 19 00:42:09 canoe kernel: ehci_abort_xfer: no hit Jun 19 00:42:09 canoe kernel: ehci_alloc_sqtd_chain: start len=8 Jun 19 00:42:14 canoe kernel: ehci_timeout: exfer=0xc6207900 Jun 19 00:42:14 canoe kernel: usbd_dump_pipe: pipe=0xc662d600 Jun 19 00:42:14 canoe kernel: usbd_dump_iface: iface=0 Jun 19 00:42:14 canoe kernel: usbd_dump_device: dev=0xc68b3e00 Jun 19 00:42:14 canoe kernel: bus=0xc61eb400 default_pipe=0xc662d600 Jun 19 00:42:14 canoe kernel: address=0 config=0 depth=1 speed=3 self_powered=0 power=0 langid=-1 Jun 19 00:42:14 canoe kernel: usbd_dump_endpoint: endp=0xc68b3e24 Jun 19 00:42:14 canoe kernel: edesc=0xc68b3e2c refcnt=1 Jun 19 00:42:14 canoe kernel: bEndpointAddress=0x00 Jun 19 00:42:14 canoe kernel: (usbd_dump_pipe:) Jun 19 00:42:14 canoe kernel: refcnt=1 running=1 aborting=0 Jun 19 00:42:14 canoe kernel: intrxfer=0, repeat=0, interval=-1 Jun 19 00:42:14 canoe kernel: ehci_timeout_task: xfer=0xc6207900 Jun 19 00:42:14 canoe kernel: ehci_abort_xfer: xfer=0xc6207900 pipe=0xc662d600 Jun 19 00:42:14 canoe kernel: ehci_sync_hc: cmd=0x00080060 sts=0xb000 Jun 19 00:42:15 canoe kernel: ehci_sync_hc: cmd=0x00080060 sts=0xb000 Jun 19 00:42:15 canoe kernel: ehci_abort_xfer: no hit Jun 19 00:42:15 canoe kernel: ehci_alloc_sqtd_chain: start len=8 Jun 19 00:42:20 canoe kernel: ehci_timeout: exfer=0xc6207900 Jun 19 00:42:20 canoe kernel: usbd_dump_pipe: pipe=0xc662d600 Jun 19 00:42:20 canoe kernel: usbd_dump_iface: iface=0 Jun 19 00:42:20 canoe kernel: usbd_dump_device: dev=0xc68b3e00 Jun 19 00:42:20 canoe kernel: bus=0xc61eb400 default_pipe=0xc662d600 Jun 19 00:42:20 canoe kernel: address=0 config=0 depth=1 speed=3 self_powered=0 power=0 langid=-1 Jun 19 00:42:20 canoe kernel: usbd_dump_endpoint: endp=0xc68b3e24 Jun 19 00:42:20 canoe kernel: edesc=0xc68b3e2c refcnt=1 Jun 19 00:42:20 canoe kernel: bEndpointAddress=0x00 Jun 19 00:42:20 canoe kernel: (usbd_dump_pipe:) Jun 19 00:42:20 canoe kernel: refcnt=1 running=1 aborting=0 Jun 19 00:42:20 canoe kernel: intrxfer=0, repeat=0, interval=-1 Jun 19 00:42:20 canoe kernel: ehci_timeout_task: xfer=0xc6207900 Jun 19 00:42:20 canoe kernel: ehci_abort_xfer: xfer=0xc6207900 pipe=0xc662d600 Jun 19 00:42:20 canoe kernel: ehci_sync_hc: cmd=0x00080060 sts=0xb000 Jun 19 00:42:21 canoe kernel: ehci_sync_hc: cmd=0x00080060 sts=0xb000 Jun 19 00:42:21 canoe kernel: ehci_abort_xfer: no hit Jun 19 00:42:21 canoe kernel: usbd_new_device: addr=2, getting first desc failed Jun 19 00:42:21 canoe kernel: ehci_device_ctrl_close: pipe=0xc662d600 Jun 19 00:42:21 canoe kernel: ehci_sync_hc: cmd=0x00080060 sts=0xb000 Jun 19 00:42:22 canoe kernel: ehci_sync_hc: cmd=0x00080060 sts=0xb000 Jun 19 00:42:22 canoe kernel: uhub_explore: usb_new_device failed, error=TIMEOUT Jun 19 00:42:22 canoe kernel: uhub3: device problem, disabling port 1 Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. |
