atapicam still failing (9/8/03)
Cvsupped earlier today (9/8/03). Everything went fine with the build/install. In fact, the new kernel booted just fine in single-user mode (with the old modules, of course). However, after completing the installworld, etc. and rebooting, I got a hang after probing acd0 with the message: acd0: unknown transfer phase Rebooting the old kernel, rebuilding a new kernel without atapicam or any of the SCSI devices cured the problem. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
jdk 1.4.1 exception trying to detect network interfaces (IP address)
I've been running freenet (successfully) under jdk 1.4.1 for several weeks now. Strangely, I keep seeing the following in freenet's logs: Jun 6, 2003 8:59:31 PM (freenet.node.IPAddressDetector, FThread-22, ERROR): SocketExceptio n trying to detect NetworkInterfaces java.net.SocketException: Bad address at java.net.NetworkInterface.getAll(Native Method) at java.net.NetworkInterface.getNetworkInterfaces(NetworkInterface.java:204) at freenet.node.IPAddressDetector.checkpoint(IPAddressDetector.java:69) at freenet.node.states.maintenance.Checkpoint.checkpoint(Checkpoint.java:56) at freenet.node.states.maintenance.Checkpoint.received(Checkpoint.java:49) at freenet.node.StateChain.received(StateChain.java:161) at freenet.node.StateChain.received(StateChain.java:52) at freenet.node.StandardMessageHandler$Ticket.run(StandardMessageHandler.java:2 12) at freenet.node.StandardMessageHandler$Ticket.received(StandardMessageHandler.j ava :159) at freenet.node.StandardMessageHandler$Ticket.access$100(StandardMessageHandler .ja va:121) at freenet.node.StandardMessageHandler.handle(StandardMessageHandler.java:68) at freenet.Ticker$Event.run(Ticker.java:229) at freenet.thread.FastThreadFactory$FThread.run(FastThreadFactory.java:97) What's strange is that the interface/address are working fine in freenet. Any ideas why this error? -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas pgp0.pgp Description: PGP signature
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On 02-Jun-2003 Nicolas Souchu wrote: On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote: viapropm is seriously broken for other reasons and needs professional help. What kind of breakage? Setting resources in probe? Right. Anybody having the viapm driver loaded usually should please try the attached patch. I'm sorry to report that those patches didn't fix the problem for me. They all applied cleanly, I built a new kernel, but I still see the same messages at boot. Couldn't enable port mapping. Thanks anyway, though. :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas pgp0.pgp Description: PGP signature
viapm attach failure (was Re: loader vs PCI)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20-May-2003 Julian Elischer wrote: Is there any capability in the loader to do such things as get/set a PCI config space register? Looking at the man page I'd say not, but there is mention of some PNP capacity (though not currently working). Reason.. ASUS disable the SMBus on their new mother boards and have no BIOS entry to enable it, but it can be enabled from the PCI config regs. Without it you can not easily read the voltages, temperatures and Fan speeds. You can use pciconf to enable it but by then it's too late for the ichsmb(4) driver to find it. The only other answer is to enable it, and then kldload the ichsmb module, but the best answer would be to enable it from the loader so that it shows up on the PCI bus during normal boot. (ASUS need to get a clue on this.. a BIOS option would be real nice..) I have a related problem. I'm trying to get the viapm (viapropm0) device to attach properly at boot, but to no avail. The device is recognized, but I always get the following: smbios0: System Management BIOS at iomem 0xf7a20-0xf7a3e on motherboard smbios0: Version: 2.03, Revision: 1.08 found- vendor=0x1106, dev=0x3057, revid=0x10 bus=0, slot=7, func=4 class=06-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 4, range 32, base 1080, size 6, enabled viapropm0: SMBus I/O base at 0x4000 viapropm0: VIA VT82C686A Power Management Unit port 0x4000-0x400f at device 7.4 on pci0 viapropm0: failed to enable port mapping! viapropm0: could not allocate bus space device_probe_and_attach: viapropm0 attach returned 6 I have all the requisite devices configured into the kernel. I'm not sure what hint, if any, might help resolve this issue. Ideas? TIA - -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+2Ug5p1KR3mGnrrgRAiYGAKC+Pfw+xAMpmC1zs1IET8YDYCgV+QCgr2b/ tOCc4pN5DSmMqVxHUWjzZWM= =DNDt -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: So then, is fxp working OK again?
On 05-Apr-2003 Maxime Henrion wrote: Conrad Sabatier wrote: groan Still no go. I'm still getting a panic in bus_dmamem_alloc(). Here's the info I copied down by hand: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0301639 stack pointer = 0x10:0xc053bd34 frame pointer = 0x10: 0xc053bd48 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 0() kernel: type 12 trap, code = 0 Stopped at bus_dmamen_alloc+0x9 movl 0x24(%edx),%eax dbtrace bus_dmamem_alloc(0, c04a8aa0, 1, c04a965c, ) at bus_dmamen_alloc+0x9 acpi_alloc_wakeup_handler(0, 532000, 532020, 532000, 0) at acpi_alloc_wakeup_handler+0xa9 mi_startup() at mi_startup+0x99 begin() at begin+0x2c db Incidentally, I've been getting acpi initialization failures in the last umpteen kernels I've been through, but without panicing the machine. Could you post a complete stack trace? There's no fxp functions in this (incomplete) trace. Are you sure the problem you're having now is fxp related ? I think you're right. I built a GENERIC kernel, rebooted without the acpi module, and it's working fine. Finally, I was able to get acpidump to work properly, and created a new /boot/acpi_dsdt.aml file. About to attempt a normal boot now. Will let you know. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
So then, is fxp working OK again?
Having had the same experiences as others described here recently with the fxp stuff, I'm just wondering if it's safe now to cvsup and try it again. I only have one machine here and if my net interface fails, I'm totally screwed. :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: So then, is fxp working OK again?
On 04-Apr-2003 Wade Majors wrote: Conrad Sabatier wrote: Having had the same experiences as others described here recently with the fxp stuff, I'm just wondering if it's safe now to cvsup and try it again. I only have one machine here and if my net interface fails, I'm totally screwed. :-) You can still boot your old kernel from the loader prompt, if such a thing happens. But everything appears normal to me so far. Yes, except I ran into some problems this last time where, after successfully booting the new kernel in single-user mode, installing world, running mergemaster, rebooting and finding the new kernel didn't work, I couldn't get the old kernel to work, either. :-( Apparently, something had changed just enough somewhere to make the old kernel go kerplooey, too. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: So then, is fxp working OK again?
On 04-Apr-2003 Maxime Henrion wrote: Conrad Sabatier wrote: Having had the same experiences as others described here recently with the fxp stuff, I'm just wondering if it's safe now to cvsup and try it again. I only have one machine here and if my net interface fails, I'm totally screwed. :-) It should. If it doesn't, I'm interested in knowing it. :-) Cheers, Maxime groan Still no go. I'm still getting a panic in bus_dmamem_alloc(). Here's the info I copied down by hand: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0301639 stack pointer = 0x10:0xc053bd34 frame pointer = 0x10: 0xc053bd48 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 0() kernel: type 12 trap, code = 0 Stopped at bus_dmamen_alloc+0x9 movl 0x24(%edx),%eax dbtrace bus_dmamem_alloc(0, c04a8aa0, 1, c04a965c, ) at bus_dmamen_alloc+0x9 acpi_alloc_wakeup_handler(0, 532000, 532020, 532000, 0) at acpi_alloc_wakeup_handler+0xa9 mi_startup() at mi_startup+0x99 begin() at begin+0x2c db Incidentally, I've been getting acpi initialization failures in the last umpteen kernels I've been through, but without panicing the machine. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: playing mp3s and burning a cd
On 24-Mar-2003 The Anarcat wrote: I used to listen to MP3s (using xmms) while burning CDs (using cdrecord) and it used to work fine on -stable. Now on 5.0-release, the music gets *slw* as soon as the massive IO gets on. I presume it's related to the interrupt problems the current branch is generally having. Anyone else seeing this? Should I upgrade to -current? Yes, I'm seeing (well, actually, *hearing*) the same thing. I also get it whenever I drag a scrollbar in any gtk-based app (Mozilla, Pan). Current cvsupped 3/24, buildworld, buildkernel. And, yes, it is *very* annoying. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
options VGA_NO_MODE_CHANGE causes buildkernel failure
Building a kernel with: options VGA_NO_MODE_CHANGE # don't change video modes cc -c -O -pipe -DNO_WERROR -march=athlon -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror ../../../dev/fb/vga.c cc1: warnings being treated as errors ../../../dev/fb/vga.c:1331: warning: `filll_io' defined but not used ../../../dev/fb/vga.c:1321: warning: `fill' defined but not used *** Error code 1 Stop in /usr/src/sys/i386/compile/FOO. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 15-Mar-2003 Bryan Liesner wrote: On Fri, 14 Mar 2003, Conrad Sabatier wrote: Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. Did it panic on devfs_find()? And, if you've seen my earlier posts, have you experienced that stuff too? Yes, exactly right. In devfs_find(). And looking back at your earlier posts, it looks like my experiences pretty much correlate with yours. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 15-Mar-2003 Shizuka Kudo wrote: --- Conrad Sabatier [EMAIL PROTECTED] wrote: Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. -- I found the same problem for the last two days. However, it seems that this problem doesn't appear in the GENERIC kernel. I have tried putting the INVARIANTS stuffs back to my custom config file and it works as well. Very strange... Yes, it is very strange. Yesterday, all of the kernels I compiled were bombing in devfs_find(). Today, the kernels I've tried are now bombing in devfs_vmkdir(). I compiled today using minimal CFLAGS, just -O -pipe, no -march stuff. I may have some spare time to search for the break point later and will post if I can find any commit that causes this. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 15-Mar-2003 Shizuka Kudo wrote: I found the same problem for the last two days. However, it seems that this problem doesn't appear in the GENERIC kernel. I have tried putting the INVARIANTS stuffs back to my custom config file and it works as well. Very strange... I just built a GENERIC kernel and it booted OK. Weird. I may have some spare time to search for the break point later and will post if I can find any commit that causes this. Thanks! -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
On 14-Mar-2003 Bryan Liesner wrote: I made posts here recently describing some panics which are somehow related to disappearing/never created device nodes. I am unable to produce a core dump at all, as it panics before / is mounted. The documented kern.dumpdev (unknown oid) doesn't exist and setting dumpdev=ad0s1b in loader.conf doesn't help either. I compiled the faulty kernel with ddb and found that the failure was in devfs_find(). I'm trying to gather more information. Any tips on how to get a proper core dump would be appreciated. As described in my earlier posts, this started happening sometime shortly after commits done after 3/10/2003. Now, really, am I the only one experiencing this? No, you're not. I've been unable to get a bootable kernel running for the last few days also. Booting in verbose mode, I see the last thing that occurs just before the panic is mounting root and then starting (or trying to start) /sbin/init. After an initial hang, it drops into ddb. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bash2 or devfs problem?
On 10-Mar-2003 Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Conrad Sabatier writes:
diff (cat file1) (cat file2)
errors out with:
diff: /dev/fd/63: No such file or directory
diff: /dev/fd/62: No such file or directory
Apparently, the nodes for the named pipes are not being created as they
should.
Is this a bash problem, or something in devfs not working as expected?
That's a good question...
Has anybody found out what the standards conformant thing is for /dev/fd ?
presently we do only 0,1 2, with the std{in,out,err} symlinks.
If we are required to do all filedescriptors, we should do so with
fdescfs by default.
OK, I took this to mean use fdescfs, so I loaded the module and tried it
again. Voila, it worked!
Thanks for the clarification there.
--
Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
bash2 or devfs problem?
I've noticed that bash's process substitution fails under -CURRENT. For (an admittedly stupid, trivial) example: diff (cat file1) (cat file2) errors out with: diff: /dev/fd/63: No such file or directory diff: /dev/fd/62: No such file or directory Apparently, the nodes for the named pipes are not being created as they should. Is this a bash problem, or something in devfs not working as expected? -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On 08-Feb-2003 Ray Kohler wrote: Has anyone tried building world/kernel with high optimizations (-O2, -O3) recently? What breaks? (Booby prize to whoever says common sense ;) I last tried it quite a few months ago and the resolver died on me, don't know what else. I'm not really thinking of running like that, but I am curious about others' experiences. Call me a fool, but I've been using this for quite some time now, in both -stable (well, with slight modifications) and -current: CPUTYPE?=k7 CFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforce-addr -fstrength-reduce \ -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop \ -fexpensive-optimizations -fschedule-insns2 COPTFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforce-addr -fstrength-reduce \ -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop \ -fexpensive-optimizations -fschedule-insns2 My -current box seems to be remarkably stable (and fast!). Guess I must be living right. :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compiling with high optimization?
On 09-Feb-2003 Dan Nelson wrote: In the last episode (Feb 08), Conrad Sabatier said: Call me a fool, but I've been using this for quite some time now, in both -stable (well, with slight modifications) and -current: CPUTYPE?=k7 CFLAGS= -O2 -pipe -mmmx -m3dnow -fforce-mem -fforce-addr -fstrength-reduce \ -fthread-jumps -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop \ -fexpensive-optimizations -fschedule-insns2 Have you actually tested the benefits of these switches? If you had, you would have discovered that -fforce-mem, -fstrength-reduce, -fthread-jumps, -fcse-follow-jumps, -fcse-skip-blocks, -frerun-cse-after-loop, -fexpensive-optimizations, and -fschedule-insns2 do absolutely nothing, since -O2 enables them anyway. -fforce-addr is the only non-redundant -f flag in that whole list. Yes, I figured some of them were redundant, but it was kind of hard to figure out which ones, so I just went ahead and used them. :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: First time CURRENT user having problems with new boot loader install
On 02-Feb-2003 Taylor Dondich wrote: After reading src/UPDATING and attempting to follow the directions to upgrade from 4.7-RELEASE to -CURRENT, I'm having some difficulty, after successfully building world and building and installing the kernel, I attempted to make install in src/sys/boot. I'm getting the following error: ((inappropriate text taken out)) i386/mbr install -o root -g wheel -m 444 mbr /boot install: mbr: No such file or directory *** Error code 71 Do a simple make first, then a make install. Sadly, I'm not experienced, this is my first CURRENT build, and I'm hoping I researched enough of it, but if I'm missing something that's documented, I'd love if someone pointed it out so I can further educate myself. The source tree doesn't work like ports, where make install will do all the prerequisite steps first. If you say make install in /usr/src/*, you'd better have already built something! :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tunefs using libufs.
On 28-Jan-2003 Juli Mallett wrote: * De: Conrad Sabatier [EMAIL PROTECTED] [ Data: 2003-01-27 ] [ Subjecte: Re: tunefs using libufs. ] I'm getting some odd behavior with tunefs (5.0-CURRENT cvsupped and built Sunday, Jan 26). If a filesystem, rather than an actual device, is specified, it spits out a weird error message regarding my linproc mount: # tunefs -p /tmp tunefs: linproc: could not find special device Is anyone else seeing this? Could it just be the result of the gcc optimizations I'm using (an admittedly heavy set of flags)? Or might it be related to the recent changes the OP mentioned? Now that libufs will hunt for the disk, tunefs shouldn't, that's all. Doing it both shouldn't have caused a problem, I don't think, but it does for me, too. This is caused by more-recent changes to libufs. I'll commit a fix shortly, once I verify the behaviour is correct. Yep, that seems to have fixed it. Thanks! -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tunefs using libufs.
I'm getting some odd behavior with tunefs (5.0-CURRENT cvsupped and built Sunday, Jan 26). If a filesystem, rather than an actual device, is specified, it spits out a weird error message regarding my linproc mount: # tunefs -p /tmp tunefs: linproc: could not find special device My /etc/fstab: # DeviceMountpoint FStype Options DumpPass# /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ad0s1f /tmpufs rw 2 2 /dev/ad0s1g /usrufs rw 2 2 /dev/ad0s1e /varufs rw 2 2 /dev/acd0c /cdrom cd9660 ro,noauto 0 0 /dev/acd1c /cdrom1 cd9660 ro,noauto 0 0 proc/proc procfs rw 0 0 /dev/ad1s1e /mm ufs rw 2 2 linproc /compat/linux/proc linprocfs rw 0 0 Is anyone else seeing this? Could it just be the result of the gcc optimizations I'm using (an admittedly heavy set of flags)? Or might it be related to the recent changes the OP mentioned? On 18-Jan-2003 Juli Mallett wrote: Can I get some tests of these changes to make tunefs use libufs? Thanx, juli. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VM_METER no longer defined?
Pardon me if I missed something, but what's become of the definition of VM_METER? It is nowhere to be found under /usr/include. This breaks a few ports, kdebase3 being one of the most notable. -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sbin/sysctl sysctl.8 src/sys/kern init_main.c
On 14-Nov-2002 Dag-Erling Smorgrav wrote: Conrad Sabatier [EMAIL PROTECTED] writes: Was the following just swallowed up into the bowels of the CVS beast or something? :-) I've tried updating my sources several times, and still not retrieving it. Hook, line and sinker, eh? You know, I did suspect that maybe it was a prank. Thought it seemed a little too good to be true. :-) -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
/dev/acd*t* no longer available in -current?
I've been using a homemade CD ripping script under -stable that uses dd with the acd0t* devices. Unfortunately, these seem no longer to exist in -current, or am I mistaken? I'm still a bit perplexed by devfs, to be honest. Is there any way to create these devices (if they are still supported, that is)? Any info/help much appreciated. -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /dev/acd*t* no longer available in -current?
Please disregard. I discovered it was just that I was using single-digit track numbers (e.g., acd0t1), whereas leading-zero numbers were expected (e.g., acd0t01). Sorry 'bout that. :\ On 13-Nov-2002 Conrad Sabatier wrote: I've been using a homemade CD ripping script under -stable that uses dd with the acd0t* devices. Unfortunately, these seem no longer to exist in -current, or am I mistaken? I'm still a bit perplexed by devfs, to be honest. Is there any way to create these devices (if they are still supported, that is)? Any info/help much appreciated. -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-multimedia in the body of the message -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/sbin/sysctl sysctl.8 src/sys/kern init_main.c
Urgh, nevermind. I just noticed (in another of my mail folders) that the committer got jumped on over this one and, presumably, has already backed it out. Sorry, that makes two neverminds in one day. Shame on me. :-) On 14-Nov-2002 Conrad Sabatier wrote: Was the following just swallowed up into the bowels of the CVS beast or something? :-) I've tried updating my sources several times, and still not retrieving it. On 12-Nov-2002 Dag-Erling Smorgrav wrote: des 2002/11/12 02:69:42 PST Modified files: sbin/sysctl sysctl.8 sys/kern init_main.c Log: Add the kern.turbo sysctl, which makes the system run twice as fast. Default to 0 (off) for backward compatibility. Revision ChangesPath 1.48 +1 -0 src/sbin/sysctl/sysctl.8 1.215 +3 -0 src/sys/kern/init_main.c -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: speed of -CURRENT [was: questions about the state of current
On 30-Oct-2002 Stijn Hoop wrote: On Wed, Oct 30, 2002 at 07:48:14AM -0500, Alexander Kabaev wrote: I am experiencing a really noticable slower startup time on my very recent-CURRENT laptop for almost all programs. The problem seems to be in getting info in the cache, because it disappears when I start the same program again. This almost certainly is caused by the 'ioslow' addition to specfs_vnops.c. Find a block in specfs_strategy function which goes into tsleep for niced processes and comment it out. Let us know if that helps :) Yes, that's it. -CURRENT actually feels snappier than -STABLE now :) I have to agree. Until I did this, MP3 playback (using mpg123) was horribly choppy at times. Now it's running *much* smoother. -- Conrad Sabatier [EMAIL PROTECTED] I get up each morning, gather my wits. Pick up the paper, read the obits. If I'm not there I know I'm not dead. So I eat a good breakfast and go back to bed. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrading 4.7-stable to -current question
On 02-Nov-2002 Ned Wolpert wrote: Folks- I've ran into problem upgrading to -current from RELENG_4 after the 'make installkernel' process. One the kernel was installed, I rebooted. However, the old 4.7 kernel was loaded instead of the new -current kernel. I read from the archive about how the old /modules directory can cause problems, when loading the 5.x kernel, but that's not the issue since the wrong kernel was loaded in the first place. Now, when I forced /boot/kernel/kernel, the system failed completely. (No error message, the loading never occurred as the whole system froze.) Could that have been from the old /modules directory? Anyways, the question is when doing an upgrade, what's the best method to update the loader? It isn't installed by default. (From what I could tell) Read the UPDATING file very carefully. You'll see that one of the steps in upgrading from 4.x to 5.0 is updating the boot blocks. -- Conrad Sabatier [EMAIL PROTECTED] Given the choice between accomplishing something and just lying around, I'd rather lie around. No contest. -- Eric Clapton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Upgrading 4.7-stable to -current question
On 03-Nov-2002 Ned Wolpert wrote: On Sat, 2002-11-02 at 17:20, Conrad Sabatier wrote: Read the UPDATING file very carefully. You'll see that one of the steps in upgrading from 4.x to 5.0 is updating the boot blocks. Yes, there are several entries. 2615 is the most interesting: In addition, you'll need to update your boot blocks to a more modern version, if you haven't already done so. Modern here means 4.0 release or newer (although older releases may work). Now, my system was installed around 4.4, so I should not need to update my boot blocks. Correct? Mmm, perhaps not. :-) Getting back to my original question, the problem I was having was with the loader itself. Now, do I have to execute this step (from the UPDATING document) cd src/sys/boot ; make install Yes, that's the one I was thinking of, actually. Had a little slip of the brain there. :-) Reason why I ask is because my loader is from 4.4, so it should work. (Provided I do a ok unload ok boot /boot/kernel/kernel manually) As the UPDATING doc mentions, upgrading from 4.x to 5.x needs that step to avoid those extra steps, yes? But it should still boot if I unload and load manually, correct? I guess the real question was that if this is the case, it didn't boot into /boot/kernel/kernel at that point either... after the unload and boot steps above. Could that have occurred because I still had the old /modules directory? I do think this last step (make install in sys/boot) is an absolute must to boot the new kernel. Someone may correct me, but that's the impression I got from reading the docs. Myself, I played it ultra-safe and followed the upgrade instructions to the letter, including moving the 4.x modules to a different directory. The upgrade went off without a single gotcha. -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A few questions
On 01-Nov-2002 Conrad Sabatier wrote: I just upgraded a 4.7-STABLE box to current over the weekend. Went off very well, thanks to the great documentation in UPDATING. It's odd, though, that after upgrading again just a few days later, suddenly X (or perhaps just xdm) failed to start due to an unresolved symbol. I had already upgraded X, as well as many other ports, after upgrading to -current, btw. It seems very peculiar that a cvsup just a few days apart from the previous one would require X to be rebuilt. OK, turned out it was a mismatched gtk/glib combination. On another note, can someone clue me in as to why I'm getting all these duplicate script errors when building both ports and world? I've looked high and low and can't find the reason for this. Seems harmless enough, but it *is* just slightly annoying. And these seem to have pretty much disappeared as well. Still no idea what was causing them. And finally, is there a simple way to ensure that none of the debugging code (including INVARIANTS stuff) is included during a buildworld? It would be nice if there were a simple switch or environment variable to control this. Now *this* I would still be interested to know about. -- Conrad Sabatier [EMAIL PROTECTED] Liar, n.: A lawyer with a roving commission. -- Ambrose Bierce, The Devil's Dictionary To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A few questions
On 01-Nov-2002 Kris Kennaway wrote: On Thu, Oct 31, 2002 at 06:39:00PM -0600, Conrad Sabatier wrote: I just upgraded a 4.7-STABLE box to current over the weekend. Went off very well, thanks to the great documentation in UPDATING. It's odd, though, that after upgrading again just a few days later, suddenly X (or perhaps just xdm) failed to start due to an unresolved symbol. I had already upgraded X, as well as many other ports, after upgrading to -current, btw. What symbol? The symbol was __sF, if I remember correctly. Turned out to be ports-related (out of sync port upgrades). It seems very peculiar that a cvsup just a few days apart from the previous one would require X to be rebuilt. What dates? OK, OK, I know. I could have provided more details. :-) Sorry for the noise. -- Conrad Sabatier [EMAIL PROTECTED] At least they're __EXPERIENCED incompetents To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: A few questions
On 01-Nov-2002 Giorgos Keramidas wrote: On 2002-10-31 18:39, Conrad Sabatier [EMAIL PROTECTED] wrote: [...] And finally, is there a simple way to ensure that none of the debugging code (including INVARIANTS stuff) is included during a buildworld? INVARIANTS and WITNESS are kernel-only stuff. They shouldn't affect your userland programs. If they do, it's probably a bug. I just happened to notice this: $ grep -r 'CFLAGS.*INVARIANTS' /usr/src /usr/src/gnu/usr.bin/cc/Makefile.inc:#CFLAGS+= -DWANT_COMPILER_INVARIANTS /usr/src/lib/libc_r/Makefile:CFLAGS+=-D_PTHREADS_INVARIANTS /usr/src/lib/libpthread/Makefile:CFLAGS+=-D_PTHREADS_INVARIANTS Granted, the first one is commented out (and I've already built world after commenting the other two with no ill effects). -- Conrad Sabatier [EMAIL PROTECTED] He played the king as if afraid someone else would play the ace. -- John Mason Brown, drama critic To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
A few questions
I just upgraded a 4.7-STABLE box to current over the weekend. Went off very well, thanks to the great documentation in UPDATING. It's odd, though, that after upgrading again just a few days later, suddenly X (or perhaps just xdm) failed to start due to an unresolved symbol. I had already upgraded X, as well as many other ports, after upgrading to -current, btw. It seems very peculiar that a cvsup just a few days apart from the previous one would require X to be rebuilt. On another note, can someone clue me in as to why I'm getting all these duplicate script errors when building both ports and world? I've looked high and low and can't find the reason for this. Seems harmless enough, but it *is* just slightly annoying. And finally, is there a simple way to ensure that none of the debugging code (including INVARIANTS stuff) is included during a buildworld? It would be nice if there were a simple switch or environment variable to control this. Please forgive if this is all old stuff; I'm new with -current, and I have made a real effort to find the answers to this stuff myself. Thanks. -- Conrad Sabatier [EMAIL PROTECTED] One Page Principle: A specification that will not fit on one page of 8.5x11 inch paper cannot be understood. -- Mark Ardis To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Building aout ports in -current
I've been notified that one of the ports I'm responsible for, xswallow, will no longer build under -current. Here's a snip from the build log: === Building for xswallow-1.0.18 cd /tmp/a/ports/www/xswallow/work/xswallow/xswallow cc -O -pipe -o xswallow.so -aout -shared -nostdlib -DXP_UNIX -I../include -I/usr/X11R6/include -L/usr/lib/compat/aout -lgcc UnixShell.c stubs.c as: could not exec aout/as in /usr/libexec: No such file or directory UnixShell.c: In function `readEntries2': UnixShell.c:498: output pipe has been closed cpp0: output pipe has been closed as: could not exec aout/as in /usr/libexec: No such file or directory stubs.c:15: output pipe has been closed *** Error code 1 Stop in /a/ports/www/xswallow. *** Error code 1 Is it no longer possible to build aout binaries in -current, or am I simply using the wrong approach here? Admittedly, I did employ a rather "ad hoc" method to get this package to compile, and up until now it's worked just fine. Any info that might help will be greatly appreciated. -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Building aout ports in -current
On 29-Mar-2001 Kris Kennaway wrote: On Wed, Mar 28, 2001 at 10:20:33PM -0600, Conrad Sabatier wrote: I've been notified that one of the ports I'm responsible for, xswallow, will no longer build under -current. Here's a snip from the build log: a.out support is entirely optional these days for ports, so it's up to you whether or not you care about fixing your port to build that way. Well, this is a plugin for Netscape, and (unless I'm mistaken) *must* be in aout format, or will ELF plugins work with Netscape??? -- Conrad Sabatier [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Nevermind! (Re: Info needed re: new userconfig scripting and PnP)
OK, I've gotten a few private replies (thanks!), and have also read through several threads in the -current archives. I think I've got the picture now. Can't say I'm all that happy about what I've read (I mean, having to add to my web pages something to the effect of "you can disregard all of this information if you're running -current"), but who am I to stand in the way of progress, eh? :-) BTW, speaking of device IDs, if anyone needs the info for the AWE 64 "value" card, I'll be happy to provide whatever I can. -- Conrad Sabatier http://members.home.net/conrads/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Info needed re: new userconfig scripting and PnP
Someone just mailed me this heads up about my AWE soundcard setup tutorial at http://members.home.net/conrads/awepnp-freebsd.html. As this is the first I've heard about this, I'd greatly appreciate it if someone could fill me in on the details, so I can update the info on my web site. Thanks! BTW, I'm subscribed to -current now, so you can reply to the list. -FW: [EMAIL PROTECTED]- Date: Sun, 24 Oct 1999 14:50:46 -0400 (EDT) From: Matt Dibb [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: http://members.home.net/conrads/awepnp-freebsd.html Your SB AWE-card how-to is quite helpful, but slightly flawed. You indicate that the procedures listed apply to FreeBSD 3.x and -CURRENT, but this is not so. While the kernel config lines compile fine under 3.x and 4.0, the userconfig script employs the "pnp" keyword to explicitly define which slots/irqs/dmas to probe, but, much to my dismay, this command was eliminated when the userconfig program was reworked for FreeBSD-Current this summer. I am writing to you to inquire as to whether another method (even if less conventional) exists for instructing the kernel to probe all these slots. The kernel syntax doesn't accomodate multiple ports for devices [that I know of], so I've had no luck getting AWE64 support with VoxWare drvs. If you could advise me on a way to get the slots probed right without the "pnp" keyword in userconfig, I'd be most grateful. --End of forwarded message--------- -- Conrad Sabatier http://members.home.net/conrads/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sound etc,
On 30-Sep-99 Rick Yip wrote: Hi! I have bought the official version of FreeBSD 3.2 and tried to get the sound to work but it doesn't. I tried 4Front's software but that doesn't work either. I get messages that I can't configure /dev/dsp: device is busy all of the time. Somtimes I can't "allocate 32768 M " problems. After reading a how-to on AWE (I have a SoundBlaster AWE64 PnP) sound cards http://members.home.net/conrads/awepnp-freebsd.html, it still doesn't work. The information on my site was slightly inaccurate/out of date until recently. You may want to have another look and try it again, since I just updated it and (I think) the information there is now good (at least for less-than-current versions). -- Conrad Sabatier http://members.home.net/conrads/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ifq_maxlen problem...
On 04-Feb-99 Jaroslaw Bazydlo wrote: After yesterdays 'make world' I am having such warnings: FreeBSD 4.0-CURRENT #0: Thu Feb 4 17:19:09 GMT 1999 jar...@ent.freebsd.org.pl:/usr/src/sys/compile/ENT [...] ep0 at 0x300-0x30f irq 10 on isa ep0: utp/bnc[*UTP*] address 00:60:08:65:d6:8d [...] ep0 XXX: driver didn't set ifq_maxlen lo0 XXX: driver didn't set ifq_maxlen ^ The system itself seems to work fine (for last 24 hrs). What do those messages mean??? Does anyone of you noticed similar messages??? The NIC is 3com 3c509B. Just cvsup'ed, made world and kernel today (Thursday, 2/4), and am seeing the same thing at bootup (on lo0; I have no network interfaces installed). No idea what it means or what's causing it, but it seems pretty harmless. -- Conrad Sabatier conr...@neosoft.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
