Re: What is VT_TFS?
On Fri, 31 Aug 2001, Zhihui Zhang wrote: What is the file system that uses VT_TFS in vnode.h? Is it still available on FreeBSD? Thanks. This type of filesystem was used by netcon package (http://www.netcon.com). However there is no new versions for FreeBSD above 2.x, so it probably can be safely removed. -- Boris Popov http://rbp.euro.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
.so and threads, and stereo /dev/dsp, freebsd 4.3-stable.
Hello,
I checked out quakeforge (http://www.quakeforge.net/) from their cvs
tree, and tried building it on FreeBSD yesterday. It mostly worked,
but I ran into two odd problems.
Quakeforge uses plugins to handle sound; there is an OSS plugin for
the normal system sound libs, and an SDL plugin if you have libsdl
installed. It can also build other plugins (there are ones for ALSA,
SGI, etc) depending on one's platform.
When I build sdl from ports, its configure script sees that it can use
gcc -thread, and builds libsdl with threads support. The downside is
that I need to use libc_r when I link against other apps. When
quakeforge builds a .so for its sdl sound plugin, it uses something
like gcc -thread -shared ... -o libsound_sdl.so; which all nice and
good, except it doesn't pull in libc_r. So, when quakeforge runs with
the sdl sound plugin, it complains about not being able to find the
pthread_cond_wait symbol. Is there something special I need to do to
make gcc link with -lc_r for gcc -shared -thread code?
Next: the OSS plugin builds but doesn't seem to work properly. At
some point, it tries to set /dev/dsp to stereo, and fails:
tmp = 0;
if (shm-channels == 2)
tmp = 1;
rc = ioctl (audio_fd, SNDCTL_DSP_STEREO, tmp);
if (rc 0) {
perror (snd_dev);
Con_Printf (Could not set %s to stereo=%d, snd_dev, shm-chann
els);
close (audio_fd);
return 0;
}
I have a Creative 128 card which identifies itself as
pcm0: AudioPCI ES1373-8 port 0x6800-0x683f irq 10 at device 10.0 on pci0
What can I do here to make quakeforge use the sound card?
Faried.
--
...the first are last, the blessed get wired
the best is yet to come...
self name.
superstar!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
As said below, modify usbdevs/umass.c to recognise your device and then see whether it behaves. If not, try adding the quirks to scsi_da.c (no READS_6 and no cache sync) and see whether that improves things. If it is an ATAPI based device it might be more work to get this device working. Nick On Thu, 23 Aug 2001, Jim Bryant wrote: Matthew Emmerton wrote: Hackers, The overwhelming lack of response on -questions suggests I might do better here. I though this would be an easy one. In short, I simply want to know what device to mount and what to do get that device configured. # usbdevs -v Controller /dev/usb0: addr 1: self powered, config 1, UHCI root hub(0x), Intel(0x), rev 0x0100 port 1 powered port 2 addr 2: self powered, config 1, Diamond Multimedia Digital Audio Player(0x5001), Diamond Multimedia(0x045a), rev 0x0100 /kernel: ugen0: at uhub0 port 2 (addr 2) disconnected /kernel: ugen0: detached /kernel: ugen0: Diamond Multimedia Diamond Multimedia Digital Audio Player, rev 1.00/1.00, addr 2 Since this device is recognized by the kernel as 'ugen0', it doesn't know that it's a storage unit, and explains why you can't mount it. In order to use this device, you'll have to update the USB subsystem to recognize this device as a storage unit, and perhaps do some other code hacking before you can access it as a SCSI disk. Hopefully someone else on the list can provide you with more details (as in, how do I do what I need to do to get this thing working!) For an example of how to do this, please see the changes to: /usr/src/sys/dev/usb/umass.c /usr/src/sys/dev/usb/usbdevs /usr/src/sys/dev/usb/usbdevs.h /usr/src/sys/dev/usb/usbdevs_data.h /usr/src/sys/cam/scsi/scsi_da.c These changes were just committed to solve the exact problem you are having, instead it was for the MicroTech CameraMate CompactFlash/SmardCard reader. grep -i microtech on those files and look in the vicinity of the hits for the changes. The two .h files don't have to be changed, just run the makefile in that directory after changing usbdevs. Since I don't have a Diamond MP3 player, I can't do this. Although I didn't write the changes for the MicroTech CameraMate, I did learn a bit from the experience testing them, and it really doesn't look that hard once you figure out what is going on. Oh yeah, once you have it working, come back here, and post the patches asking that they be further tested and committed! It can take a little while, but it'll be worth it for the next guy. You may also want to search the archives and see if anyone else has announced patches being available for testing, that's how I came across the CameraMate patches that were just committed as a result of my testing [and asking for them to be committed until a committer noticed I was asking]. I searched the archives, found that someone had done some patches, and advertised the fact asking for others to test them, this was from back in April. A few weeks ago, I wrote him, and asked for a copy, although they didn't go in straight from patch, they were easy enough to put in by hand, and generate -current patches. After testing them out and finding they work, it was just a matter of asking for them to be committed. Welcome to open-source, community-supported operating systems! Should you choose to take this assignment, Matt, the secretary will disavow your actions if you are caught. Good luck! ;^) jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
signal handling descrpancy (FreeBSD oaf fix/Evolution)
Hi Hackers, et.al. The PIM Evolution, http://www.ximian.com/products/ximian_evolution/, does not run on FreeBSD. The authors have made a change so that it will. However, we would like to know if FreeBSD is the odd-man-out, or if the authors were lucky Evolution ran on Solaris and Linux. - Forwarded message Subject: FreeBSD oaf fix Date: 02 Sep 2001 01:27:58 -0700 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Evolution has hung on startup on FreeBSD (all versions I've tested along the 4.x branch, and I assume the 5.x stuff as well) for some time now. This patch to OAF (the oaf-stable-0-6 branch) fixes the problem. I've run evolution on Linux with the fix and haven't noticed a change. Considering this fix isn't needed to keep things working on the other platforms evolution supports (linux, solaris) there's obviously some discrepancy in the handling of signal masks (specifically those which block SIGCHLD) between these platforms. Not sure which platform(s) are the ones with the bug, honestly, or if the correct behavior is even specified someplace. toshok Index: oaf-fork-server.c === RCS file: /cvs/gnome/oaf/liboaf/oaf-fork-server.c,v retrieving revision 1.1.2.3 diff -c -u -r1.1.2.3 oaf-fork-server.c --- oaf-fork-server.c 2001/07/22 18:14:46 1.1.2.3 +++ oaf-fork-server.c 2001/09/02 08:23:59 @@ -267,6 +267,7 @@ if (od_iorstr) oaf_setenv (OAF_OD_IOR, od_iorstr); + sigprocmask (SIG_SETMASK, omask, NULL); close (iopipes[0]); - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: :q:q![kevin.way@overtone.org: Re: import NetBSD rc system]
On Sat, Sep 01, 2001 at 03:11:46PM +, Kevin Way wrote: I don't see any reason to force the boot order to be maintained. As long as the dependancies are set correctly, i'd think the boot order would be determined solely by the output of rcorder. Correct. What am I missing? Nothing. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gzipped crashdumps
On Sat, Sep 01, 2001 at 01:16:31AM -0700, Kris Kennaway wrote: Anyone else think this patch from NetBSD is worthwhile? As JDP said, YES!. --- /dev/null Sat Sep 1 01:13:34 2001 +++ zopen.c Sat Sep 1 01:10:14 2001 @@ -0,0 +1,39 @@ +/* + * Public domain stdio wrapper for libz, written by Johan Danielsson. + */ Can we add this to libz or some other lib? These are general bits that I could see other programs wanting to use. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD and Athlon Processors
On Sun, Sep 02, 2001 at 12:11:15AM -0400, Charles Shannon Hendrix wrote: On Fri, Aug 31, 2001 at 08:33:36PM -0400, Albert D. Cahalan wrote: Well, since it didn't, I might as well explain the problem here too. There are at least two major problems with VIA chips: [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] Are you sure about that? I am. I was having data coruption in a terrable way when I added a 2nd IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD and Athlon Processors
It seems David O'Brien wrote: On Sun, Sep 02, 2001 at 12:11:15AM -0400, Charles Shannon Hendrix wrote: On Fri, Aug 31, 2001 at 08:33:36PM -0400, Albert D. Cahalan wrote: Well, since it didn't, I might as well explain the problem here too. There are at least two major problems with VIA chips: [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] Are you sure about that? I am. I was having data coruption in a terrable way when I added a 2nd IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. Hmm, dont MSI have a fixed BIOS ? I could add the code to the kernel, but do we have a placeholder for such PCI quirks ?? There is nothing new to these kind of problems, lots of chipsets has problems that are worked around in the BIOS, and frankly that is where such fixes should be IMNHO... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Patches for Conexant LANfinity support
Phil Kernick ([EMAIL PROTECTED]) has been kind enough (and brave enough) to sit down and produce patches for the dc(4) driver to add support for the Conexant LANfinity miniPCI fast ethernet controller. Those of you that have laptops with this chipset can test the patches at: http://www.freebsd.org/~wpaul/conexant.patch.gz http://www.freebsd.org/~wpaul/conexant_5.0.patch.gz The latter file is for 5.0-current, the former for -stable. Apply the patch as follows: # cd /tmp # fetch http://www.freebsd.org/~wpaul/conexant.patch.gz # gunzip conexant.patch.gz # cd /sys/pci # patch conexant.patch Then compile a new kernel and/or if_dc.ko kernel module. I intend to commit the patch for -current when I get back to work next week, however the patch for -stable will probably have to wait until the code freeze for 4.4-RELEASE is lifted (sorry guys). In the meantime, success/failure/whatever reports would be much appreciated. -Bill -- -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems I like zees guys. Zey are fonny guys. Just keel one ofzem. -- The 3 Amigos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Performance?
In article [EMAIL PROTECTED], Deepak Jain [EMAIL PROTECTED] wrote: The new P4s are shipping with 800mhz RAMBUS memory modules. Wouldn't 2GB of 800mhz RAM go a long way to evening out the performance between a PC/FreeBSD box and all but the most specialized, packet-pushing ASICs? I doubt it. My understanding is that RAMBUS memory is faster for long burst transfers, but that its random access latency is actually worse than that of conventional memory. Your routing table lookups (random accesses into a huge data structure) would be slower, not faster. There is very little bulk copying in the IP forwarding path of the kernel, so the higher bandwidth of RAMBUS would not provide much benefit. I suppose it would speed up the DMA transfers between the NICs and RAM. But I still bet overall performance wouldn't be improved by the use of RAMBUS memory. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Performance?
On Sat, 1 Sep 2001, Deepak Jain wrote: The new P4s are shipping with 800mhz RAMBUS memory modules. Wouldn't 2GB of 800mhz RAM go a long way to evening out the performance between a PC/FreeBSD box and all but the most specialized, packet-pushing ASICs? I was doing some rough figuring, and could see how a P4 with its new bus and memory path would have trouble forwarding at least 2Gb/s. Am I missing something? Hard to say without testing it, but if your estimate is reasonable (could you expand on how you arrived at it? there are interested eyes) then you max out at 5Mpps, which is not core-class routing this year, but is certainly within shooting distance of Juniper's entry level. Without any proper grounds for the notion, I also suspect the ia64 might do fairly well at fast packet classification. J To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Routing Performance?
Correcting myself ... In article [EMAIL PROTECTED], John Polstra [EMAIL PROTECTED] wrote: There is very little bulk copying in the IP forwarding path of the kernel, so the higher bandwidth of RAMBUS would not provide much benefit. I suppose it would speed up the DMA transfers between the NICs and RAM. Actually, it wouldn't help the DMA transfers either. They'd be limited by the PCI bus bandwidth, not the memory bandwidth. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD and Athlon Processors
On a related topic, I wonder whether gcc 3.0 will improve Athon compilations. I have a big number crunching program that runs just as fast on Windows2000 on my laptop(1Ghz PPro), as on my monster 1.2G Athlon DDR with FreeBSD. Rob. Søren Schmidt wrote: It seems David O'Brien wrote: On Sun, Sep 02, 2001 at 12:11:15AM -0400, Charles Shannon Hendrix wrote: On Fri, Aug 31, 2001 at 08:33:36PM -0400, Albert D. Cahalan wrote: Well, since it didn't, I might as well explain the problem here too. There are at least two major problems with VIA chips: [data curruption on VIA KT133/133A systems by pushing PCI and memory bus] Are you sure about that? I am. I was having data coruption in a terrable way when I added a 2nd IDE UDA100 drive to a very plain MSI K7T Pro2-A 1.2GHz Athlon system. Hmm, dont MSI have a fixed BIOS ? I could add the code to the kernel, but do we have a placeholder for such PCI quirks ?? There is nothing new to these kind of problems, lots of chipsets has problems that are worked around in the BIOS, and frankly that is where such fixes should be IMNHO... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- The Numeric Python EM Project www.members.home.net/europax To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
page fault unmounting FFS from NFS-located special
Hi!
Here is sequence leading to page fault:
1. Make special file on NFS
2. Mount FFS from this file
3. Read or write special file (for attributes to change)
4. Unmount this special
5. Enjoy ``Fatal trap 12: ...''
Like this:
su-2.04# mount
192.168.5.1:/home/diskless_root on / (nfs, noatime)
mfs:10 on /var (mfs, asynchronous, local)
192.168.5.1:/home on /home (nfs)
su-2.04# mount /dev/ad0s2a /mnt
su-2.04# dd if=/dev/ad0s2a of=/dev/null bs=1k count=1
1+0 records in
1+0 records out
1024 bytes transferred in 0.003526 secs (290416 bytes/sec)
su-2.04# umount /mnt
...
(gdb) where
#0 0xc01ae3a8 in nfs_request (vp=0xcec34a00, mrest=0xc07a8900, procnum=2,
procp=0xcec39560, cred=0x0, mrp=0xcf654da8, mdp=0xcf654dac,
dposp=0xcf654db0) at ../../nfs/nfs_socket.c:1006
#1 0xc01ba167 in nfs_setattrrpc (vp=0xcec34a00, vap=0xcf654e1c, cred=0x0,
procp=0xcec39560) at ../../nfs/nfs_vnops.c:792
#2 0xc01b8b50 in nfs_setattr (ap=0xcf654e08) at ../../nfs/nfs_vnops.c:740
#3 0xc01c9441 in nfsspec_close (ap=0xcf654e94) at vnode_if.h:305
#4 0xc01da96a in ffs_unmount (mp=0xc21d4600, mntflags=0, p=0xcec39560)
at vnode_if.h:218
#5 0xc0161ace in dounmount (mp=0xc21d4600, flags=0, p=0xcec39560)
at ../../kern/vfs_syscalls.c:483
#6 0xc0161a11 in unmount (p=0xcec39560, uap=0xcf654f80)
at ../../kern/vfs_syscalls.c:451
#7 0xc021f73e in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134661253, tf_esi = 134738749, tf_ebp = -1077937436,
tf_isp = -815444012, tf_ebx = 0, tf_edx = 0, tf_ecx = 3, tf_eax = 22,
tf_trapno = 12, tf_err = 2, tf_eip = 134522456, tf_cs = 31,
tf_eflags = 663, tf_esp = -1077938584, tf_ss = 47})
at ../../i386/i386/trap.c:1126
#8 0xc02120d5 in Xint0x80_syscall ()
#9 0x8048442 in ?? ()
#10 0x8048139 in ?? ()
(gdb) f 0
#0 0xc01ae3a8 in nfs_request (vp=0xcec34a00, mrest=0xc07a8900, procnum=2,
procp=0xcec39560, cred=0x0, mrp=0xcf654da8, mdp=0xcf654dac,
dposp=0xcf654db0) at ../../nfs/nfs_socket.c:1006
1006if (cred-cr_ngroups 1)
(gdb) print cred
$1 = (struct ucred *) 0x0
the cause is code in ffs_vfsops.c:ffs_unmount()
...
error = VOP_CLOSE(ump-um_devvp, fs-fs_ronly ? FREAD : FREAD|FWRITE,
NOCRED, p);
^^ == NULL
...
I have no good ideas how to fix this and if it is worth to be fixed...
(This all was tested on 4.1 system, but it seems nothing changed since
those times)
Bye!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Should URL's be pervasive.
On Fri, Aug 31, 2001 at 03:34:09PM -0700, David O'Brien wrote: On Thu, Aug 30, 2001 at 11:21:09PM +0100, Steve Roome wrote: ping http://www.myserver.wherever/ instead of telnet wherever 80, just to see if I get a connected or not ? Do you have *ANY* clue how ping works? Ping uses ICMP packets; not TCP, not UDP -- thus there is NO concept of ports. And what does instead of telnet mean?? Again, do you have any clue how ping works? I certainly understand that ping currently works on ICMP, and that a feature enhancement to allow it to use a different type of packet might be, perhaps to some, a useful addition to its capability. Considering, for example, that an ICMP packet may take a very different route to (and hence time to reach) the destination machine comparted to a TCP/IP packet containing http information it might not be such a bad idea. e.g. Transparent web proxies. Had you read the thread of course, you may have noticed that I was merely replying to someone else who has asked about this sort of functionality. But feel free to take a dig at _me_ anyway, I won't be frightened away from it all just yet. Luckily I'm not a new user who's going to take harshly and hate us bloody arrogant unix zealots though. To the person that wants to traceroute http://www.myserver.wherever/;, do you have *ANY* clue how traceroute works? You cannnot use a port that something is answering on. Again, if you've got a transparent web proxy in the way, this would be a really nice feature. I've not got a clue how to implement it though, it would probably involve changing the way rather a lot of network hardware works, I just commented on it. Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
Nick, As said below, modify usbdevs/umass.c to recognise your device and then see whether it behaves. If not, try adding the quirks to scsi_da.c (no READS_6 and no cache sync) and see whether that improves things. Since I started this, I ought to say that while I enjoy new challenges I don't think my non-existent coding skills are up to this. Given this and the fact that I am getting fed up looking at my Rio and thinking how nice it would be if I could use it thanks to some kind and talented coder who could whip up some support, I wonder if any of you fine folks would like me to send you the device to test and enjoy for a while. Would any takers please let me know if you're interested so we can work out something. -Andrew- -- __ | -Andrew J. Caines- Unix Systems Engineer [EMAIL PROTECTED] | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Mounting FAT16 on USB connected Rio 600
* Andrew J Caines [EMAIL PROTECTED] [010902 22:12] wrote: Nick, As said below, modify usbdevs/umass.c to recognise your device and then see whether it behaves. If not, try adding the quirks to scsi_da.c (no READS_6 and no cache sync) and see whether that improves things. Since I started this, I ought to say that while I enjoy new challenges I don't think my non-existent coding skills are up to this. Given this and the fact that I am getting fed up looking at my Rio and thinking how nice it would be if I could use it thanks to some kind and talented coder who could whip up some support, I wonder if any of you fine folks would like me to send you the device to test and enjoy for a while. Would any takers please let me know if you're interested so we can work out something. I can do it if you include enough packaging such that I can mail it back to you with minimal effort. I'm in the SF Bay Area. If you haven't made arrangements yet mail me priavtely and I'll give you my address. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
