Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14
On 27 May 2010 16:13, Andriy Gapon wrote: > on 27/05/2010 17:40 Doug Rabson said the following: > > > > Excellent work - thanks for looking into this. I still think its easier > > to debug this code in userland using a shim that redirects the zfsboot > > i/o calls to simple read system calls... > > Absolutely! That should much easier. > Do you have such a shim that you could share? > I'd be much obliged for it. And not only I, I think. > Thanks! > Attached. I thought I sent it to the list before but perhaps I only sent to one of the participants in the last gang block thread. zfstest.c Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14
On 27 May 2010 09:35, Andriy Gapon wrote:
>
>
> I think I nailed this problem now.
> What was additionally needed was the following change:
>if (!vdev || !vdev->v_read)
>return (EIO);
> - if (vdev->v_read(vdev, bp, &zio_gb, offset, SPA_GANGBLOCKSIZE))
> + if (vdev->v_read(vdev, NULL, &zio_gb, offset, SPA_GANGBLOCKSIZE))
>return (EIO);
>
> Full patch is here:
> http://people.freebsd.org/~avg/boot-zfs-gang.diff
>
> Apparently I am not as smart as Roman :) because I couldn't find the bug by
> just
> starring at this rather small function (for couple of hours), so I had to
> reproduce the problem to catch it. Hence I am copying hackers@ to share
> couple
> of tricks that were new to me. Perhaps, they could help someone else some
> other
> day.
>
> First, after very helpful hints that I received in parallel from pjd and
> two
> Oracle/Sun developers it became very easy to reproduce a pool with files
> with
> gang blocks in them.
> One can set metaslab_gang_bang variable in metaslab.c to some value < 128K
> and
> then blocks with size greater than metaslab_gang_bang will be allocated as
> gang
> blocks with 25% chance. I personally did something similar but slightly
> more
> deterministic:
> --- a/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c
> +++ b/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c
> @@ -1572,6 +1572,12 @@ zio_dva_allocate(zio_t *zio)
>ASSERT3U(zio->io_prop.zp_ndvas, <=, spa_max_replication(spa));
>ASSERT3U(zio->io_size, ==, BP_GET_PSIZE(bp));
>
> + /*XXX XXX XXX XXX*/
> + if (zio->io_size > 8 * 1024) {
> + return (zio_write_gang_block(zio));
> + }
> + /*XXX XXX XXX XXX*/
> +
>error = metaslab_alloc(spa, mc, zio->io_size, bp,
>zio->io_prop.zp_ndvas, zio->io_txg, NULL, 0);
>
> This ensured that any block > 8K would be a gang block.
> Then I compiled zfs.ko with this change and put it into a virtual machine
> where
> I created a pool and populated its root/boot filesystem with /boot
> directory.
> Booted in virtual machine from the new virtual disk and immediately hit the
> problem.
>
> So far, so good, but still no clue why zfsboot crashes upon encountering a
> gang
> block.
>
> So I decided to debug the crash with gdb.
> Standard steps:
> $ qemu ... -S -s
> $ gdb
> ...
> (gdb) target remote localhost:1234
>
> Now I didn't want to single-step through the whole boot process, so I
> decided to
> get some help from gdb. Here's a trick:
> (gdb) add-symbol-file
> /usr/obj/usr/src/sys/boot/i386/gptzfsboot/gptzfsboot.out
> 0xa000
>
> gptzfsboot.out is an ELF image produced by GCC, which then gets transformed
> into
> a raw binary and then into final BTX binary (gptzfsboot).
> gptzfsboot.out is built without much debugging data but at least it
> contains
> information about function names. Perhaps it's even possible to compile
> gptzfsboot.out with higher debug level, then debugging would be much more
> pleasant.
>
> 0xA000 is where _code_ from gptzfsboot.out ends up being loaded in memory.
> BTW, having only shallow knowledge about boot chain and BTX I didn't know
> this
> address. Another GDB trick helped me:
> (gdb) append memory boot.memdump 0x0 0x1
>
> This command dumps memory content in range 0x0-0x1 to a file named
> boot.memdump. Then I produced a hex dump and searched for byte sequence
> with
> which gptzfsboot.bin starts (raw binary produced produced from
> gptzfsboot.out).
>
> Of course, memory dump should be taken after gptzfsboot is loaded into
> memory :)
> Catching the right moment requires a little bit of boot process knowledge.
> I caught it with:
> (gdb) b *0xC000
>
> That is, memory dump was taken after gdb stopped at the above break point.
>
> After that it was a piece of cake. I set break point on zio_read_gang
> function
> (after add-symbol-file command) and the stepi-ed through the code (that is,
> instruction by instruction). The following command made it easier to see
> what's
> getting executed:
> (gdb) display/i 0xA000 + $eip
>
> I quickly stepped though the code and saw that a large value was passed to
> vdev_read as 'bytes' parameter. But this should have been 512. The
> oversized
> read into a buffer allocated on stack smashed the stack and that was the
> end.
>
> Backtracking the call chain in source code I immediately noticed the bp
> condition in vdev_read_phys and realized what the problem was.
>
> Hope this would be a useful reading.
>
Excellent work - thanks for looking into this. I still think its easier to
debug this code in userland using a shim that redirects the zfsboot i/o
calls to simple read system calls...
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Problems with zfsboot loader if raidz present on any drive
On 9 Dec 2008, at 23:54, Paul Wootton wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pegasus Mc Cleaft Sent: 07 December 2008 12:17 To: Doug Rabson Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Problems with zfsboot loader if raidz present on any drive On Sunday 07 December 2008 09:22:16 Doug Rabson wrote: On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: Hello Hackers, Recently and friend and I have been trying to get the new gptzfsboot working on our machines and ran into a interesting problem. Initially I was building the world without the environment variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt work very well. Every time the machine booted, it would throw 2 lines after the pin-wheel and then reboot. I couldent read what the lines were it went so fast. My friend had a bit more luck and got his machine working OK with a single drive and later a mirror drive added. I added the environment variable and rebuilt everything and installed. This time, I could see the bios drives and a further 2 lines of ZFS something and a reboot... No matter what I tried, I couldent get the machine to boot up to a point where I could try and fix the problem, so I started pulling devices out and found the following: If there is a raidz pool on any drive (not necessarily the one that you are trying to boot from) the loader dies and reboots the machine. My friend, as an experiment created 3 gpt partitions (in addition to the single partition that he had been previously booted from) on his single drive and made a raidz pool for testing. His machine showed the same condition as mine, however he was able to capture the message before the machine rebooted: ZFS: can only boot from disk or mirror vdevs ZFS: inconsistent nvlist contents The zfsboot code in current doesn't support raidz or raidz2. I have been working on adding that support but its not ready yet. The code works in my test harness but crashes instantly when I put it in the boot code :(. I should have time to finish debugging it soon. Hi Doug, In my haste to put a message to the group, I didnt do a very good job of explaining or give what platform I was working with. I set up a single disk pool with the gptzfsboot code on it as a boot drive. My idea was to have a single disk boot (and after it boots and I can kill the UFS drive I am currently booting from) convert it to a mirror. But I have 6 other drives in the machine that I have as a raidz for my /usr/home, et al. If the 6 raidz drives are present at boot time, the machine starts to cyclic reboot just after the pin-wheel. The machine I am working on is running FBSD8.0-Current as of midnight 7/12/2008 and the platform is AMD64. If I can help test in any way I would be more than happy to try, or provide any information necessary.. ~Peg Hi Doug, I was working with Peg on this over the weekend. I think I have a patch for this - see http://www.freebsd.org/cgi/query-pr.cgi?pr=129539 The problem was that we were not checking the return code from vdev_init_from_nvlist() on line 726 in /usr/src/sys/boot/zfs/zfsimpl.c Joao, Do you want to try the attached patch? It seems to have fixed the problem, at least on mine and Peg's machine. This looks like the right fix. I will commit something similar to this today. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with zfsboot loader if raidz present on any drive
On 7 Dec 2008, at 03:19, Pegasus Mc Cleaft wrote: Hello Hackers, Recently and friend and I have been trying to get the new gptzfsboot working on our machines and ran into a interesting problem. Initially I was building the world without the environment variable LOADER_ZFS_SUPPORT=YES in the /etc/make.conf and this, of course, didnt work very well. Every time the machine booted, it would throw 2 lines after the pin-wheel and then reboot. I couldent read what the lines were it went so fast. My friend had a bit more luck and got his machine working OK with a single drive and later a mirror drive added. I added the environment variable and rebuilt everything and installed. This time, I could see the bios drives and a further 2 lines of ZFS something and a reboot... No matter what I tried, I couldent get the machine to boot up to a point where I could try and fix the problem, so I started pulling devices out and found the following: If there is a raidz pool on any drive (not necessarily the one that you are trying to boot from) the loader dies and reboots the machine. My friend, as an experiment created 3 gpt partitions (in addition to the single partition that he had been previously booted from) on his single drive and made a raidz pool for testing. His machine showed the same condition as mine, however he was able to capture the message before the machine rebooted: ZFS: can only boot from disk or mirror vdevs ZFS: inconsistent nvlist contents The zfsboot code in current doesn't support raidz or raidz2. I have been working on adding that support but its not ready yet. The code works in my test harness but crashes instantly when I put it in the boot code :(. I should have time to finish debugging it soon. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: build problems with gptzfsboot (AMD64) 8.0-CURRENT
On 20 Nov 2008, at 19:41, Olivier SMEDTS wrote:
2008/11/20 Olivier SMEDTS <[EMAIL PROTECTED]>:
2008/11/20 Olivier SMEDTS <[EMAIL PROTECTED]>:
2008/11/20 Pascal Hofstee <[EMAIL PROTECTED]>:
On Thu, 20 Nov 2008 01:46:31 -
"Pegasus Mc Cleaft" <[EMAIL PROTECTED]> wrote:
Hi everyone,
I am having difficulties rebuilding the world after some
patches
were made today. I was wondering if anyone else is experiencing
the
same troubles?
ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext
0x0 -o
gptzfsboot.out /usr/obj/usr/src/sys/boot/i386/gptzfsboot/../btx/
lib/crt0.o
zfsboot.o sio.o gptzfsboot.o ld: gptzfsboot.o: No such file: No
such
file or directory *** Error code 1
Stop in /usr/src/sys/boot/i386/gptzfsboot.
*** Error code 1
I am experiencing the exact same problem with a fresh svn checkout
Just my "me too".
I did not experience the problem 24 hours ago (after ZFS version 13
update and zfsboot import).
That's it. Seems to work with the following patch :
--- sys/boot/i386/gptzfsboot/Makefile.orig 2008-11-20
19:58:45.0 +0100
+++ sys/boot/i386/gptzfsboot/Makefile 2008-11-20
20:01:53.0 +0100
@@ -65,7 +65,7 @@
zfsboot.o: ${.CURDIR}/../../zfs/zfsimpl.c
.if ${MACHINE_ARCH} == "amd64"
-beforedepend gptzfsboot.o: machine
+beforedepend gptzfsboot.bin: machine
CLEANFILES+= machine
machine:
ln -sf ${.CURDIR}/../../../i386/include machine
Sorry for replying again to my own post :)
The patch is crap, in fact it just breaks the already broken
conditional. At least I can buildworld on amd64 now (I don't use the
recently introduced gptzfsboot).
Makefile experts ?
I think I fixed this in r185175. Sorry for the inconvenience.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ZFS boot
On 11 Oct 2008, at 14:28, Danny Braniss wrote: To Doug: > ZFS boot is coming. great! any time estimate?, just curious, no preasure :-) Its part of pjd's current big ZFS patch which brings us more or less up-to-date with Solaris. I'm not the best person to ask when that will be ready but I would expect to see it in current later this year. I hope to have some time soon to work on some outstanding issues with the boot code, so I may be able to add raidz and raidz2 support before its committed to current. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: continuous backup solution for FreeBSD
On 11 Oct 2008, at 12:07, Danny Braniss wrote: On Sat, Oct 11, 2008 at 12:35:16PM +0200, Danny Braniss wrote: On Fri, 10 Oct 2008 08:42:49 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: On Fri, Oct 10, 2008 at 11:29:52AM -0400, Mike Meyer wrote: On Fri, 10 Oct 2008 07:41:11 -0700 Jeremy Chadwick <[EMAIL PROTECTED]> wrote: On Fri, Oct 10, 2008 at 03:53:38PM +0300, Evren Yurtesen wrote: Mike Meyer wrote: On Fri, 10 Oct 2008 02:34:28 +0300 [EMAIL PROTECTED] wrote: Quoting "Oliver Fromme" <[EMAIL PROTECTED]>: These features are readily available right now on FreeBSD. You don't have to code anything. Well with 2 downsides, Once you actually try and implement these solutions, you'll see that your "downsides" are largely figments of your imagination. So if it is my imagination, how can I actually convert UFS to ZFS easily? Everybody seems to say that this is easy and that is easy. It's not that easy. I really don't know why people are telling you it is. Maybe because it is? Of course, it *does* require a little prior planning, but anyone with more than a few months experience as a sysadmin should be able to deal with it without to much hassle. Converting some filesystems are easier than others; /home (if you create one) for example is generally easy: 1) ZFS fs is called foo/home, mounted as /mnt 2) fstat, ensure nothing is using /home -- if something is, shut it down or kill it 3) rsync or cpdup /home files to /mnt 4) umount /home 5) zfs set mountpoint=/home foo/home 6) Restart said processes or daemons "See! It's like I said! EASY!" You can do this with /var as well. Yup. Of course, if you've done it that way, you're not thinking ahead, because: Now try /usr. Hope you've got /rescue available, because once /usr/lib and /usr/libexec disappear, you're in trouble. Good luck doing this in multi-user, too. Oops. You F'ed up. If you'd done a little planning, you would have realized that / and /usr would be a bit of extra trouble, and planned accordingly. And finally, the root fs. Whoever says "this is easy" is kidding themselves; it's a pain. Um, no, it wasn't. Of course, I've been doing this long enough to have a system set up to make this kind of thing easy. My system disk is on a mirror, and I do system upgrades by breaking the mirror and upgrading one disk, making everything work, then putting the mirror back together. And moving to zfs on root is a lot like a system upgrade: 1) Break the mirror (mirrors actually, as I mirrored file systems). 2) Repartition the unused drive into /boot, swap & data 3) Build zfs & /boot according to the instructions on ZFSOnRoot wiki, just copying /boot and / at this point. 4) Boot the zfs disk in single user mode. 5) If 4 fails, boot back to the ufs disk so you're operational while you contemplate what went wrong, then repeat step 3. Otherwise, go on to step 6. 6) Create zfs file systems as appropriate (given that zfs file systems are cheap, and have lots of cool features that ufs file systems don't have, you probably want to create more than you had before, doing thing like putting SQL serves on their own file system with appropriate blocking, etc, but you'll want to have figured all this out before starting step 1). 7) Copy data from the ufs file systems to their new homes, not forgetting to take them out of /etc/fstab. 8) Reboot on the zfs disk. 9) Test until you're happy that everything is working properly, and be prepared to reboot on the ufs disk if something is broken. 10) Reformat the ufs disk to match the zfs one. Gmirror /boot, add the data partition to the zfs pool so it's mirrored, and you should have already been using swap. This is 10 steps to your "easy" 6, but two of the extra steps are testing you didn't include, and 1 of the steps is a failure recovery step that shouldn't be necessary. So - one more step than your easy process. Of course, the part you seem to be (intentionally?) forgetting: most people are not using gmirror. There is no 2nd disk. They have one disk with a series of UFS2 filesystems, and they want to upgrade. That's how I read Evren's "how do I do this? You say it's easy..." comment, and I think his viewpoint is very reasonable. Granted, most people don't think about system upgrades when they build a system, so they wind up having to do extra work. In particular, Evren is talking about spending thousands of dollars on proprietary software, not to mention the cost of the server that all this data is going to flow to, for a backup solution. Compared to that, the cost of a few spare disks and the work to install them are trivial. Yeah, this isn't something you do on a whim. On the other hand, it's not something that any competent sysadmin would consider a pain. For a good senior admin, it's a lot easier than doing an OS upgrade from source, which should be the next step up from trivial.
Re: How TLS is used in Kernel thread
On Thu, 2007-08-30 at 14:20 -0700, Jin Guojun wrote: > By looking through _pthread_create() code and find it uses a magic > cookie -- TLS -- created > by rtld_allocate_tls(), and passed into kernel by sysarch() via > _tcb_set() / _kcb_set(). > > The information seems to be set by rtld (ld-elf.so.1) in digest_phdr() > under tag PT_TLS. > But it is very magic for where the TLS object is created and how it is > passed to digest_phdr(). > > The whole object passed into kernel (as sd.gsbase) looks like this: > > TCB: __ > | TLS | TCB | > |__|___| > > Can someone give some basic exaplain on following questions? > > 1) What TLS stand for? Its used to implement Thread-Local-Storage variables. These are global variables declared with the '__thread' keyword. Each variable declared in this way has a per-thread value (i.e. each thread has a private copy of the variable). > 2) Where TLS object is created? (below is the tls assigned, but I couls > not find where ph is from) > case PT_TLS: > obj->tlsindex = 1; > obj->tlssize = ph->p_memsz; > obj->tlsalign = ph->p_align; > obj->tlsinitsize = ph->p_filesz; > obj->tlsinit = (void*) ph->p_vaddr; Most of the work of dealing with TLS happens in the runtime linker /libexec/ld-elf.so.1. The runtime linker calculates the TLS size based on the TLS usage of all loaded libraries. The thread library uses an internal interface to rtld (_rtld_allocate_tls and _rtld_free_tls) during thread creation and destruction to allocate and free the TLS blocks. As you have seen, the memory allocated also includes the thread-library's control structures (which includes the saved register set etc.). Static programs have a slightly simpler mechanism (simpler because there is only the main program and no dynamic libraries). This is handled in src/lib/libc/gen/tls.c. > > 3) Where in kernel the TLS is used for thread operation? The kernel doesn't use this information at all. It simply provides support for the thread libraries needs. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A question about /sys/kern/link_elf.c
On Monday 02 May 2005 13:35, [EMAIL PROTECTED] wrote: > >There is a "#ifdef SPARSE_MAPPING" at line 701,and again a "#ifdef > >SPARSE_MAPPING" at line 713.I just can't understand the second > >one.Does it have any special mean ? > > > >thanks . > > It's just conditional compiling construct...however as you can see in > the tag "For whatever reason, SPARSE_MAPPING is not even a config > option, so this is dead code." It dates back to a tools problem that I had on the alpha where the linker would round up the size of the text segment to the next megabyte boundary. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: EFI network boot loader for ia32?
On 27 Apr 2005, at 20:10, Fred Clift wrote: This might better belong on -questions, this isn't the most technical question, but it is obscure... I've recently been loaned an eval server indirectly from intel. It is an SR-2400. We've been using SR-2300s for a while now and have been doing custom network installs via PXE. I note that these new servers have ia32 EFI support and that the only net-booting they support is via EFI. I can DHCP boot the box via the EFI boot manager menu that comes up, I get an address and it tftp's a file from the right server but of course the pxeboot bootfile doesn't work. I downloaded the indel EFI SDK and it has some sample EFI binaries (a test binary, one that draws some cute little boxes on the screen etc) and I can boot and run those just fine... I understand that EFI netbooting works fine on (was designed to work on?) ia64 boxes - is there support for netbooting via EFI on ia32? I see /usr/src/sys/boot/EFI - can I somehow build a loader.efi that would work via netboot for ia32? Thanks in advance for any help... The EFI boot loader does not support ia32 in its current state. It would be possible to port it to an ia32 EFI environment with some effort. It would be quite an advanced level project though. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: The continued remote debugging saga...
On Wednesday 01 September 2004 18:15, John-Mark Gurney wrote: > Rob Deker wrote this message on Wed, Sep 01, 2004 at 11:38 -0400: > > So, after a lot of work and help from folks here, I've gotten > > remote gdb functioning (thanks again to those who helped. In the > > end there was a bad cable in the mix that was the final screw-up). > > Now I have one other question/problem. I've got cuaa0 on the target > > machine as the console, and cuaa1 as the gdb port. In the docs it > > says that to switch to gdb mode I enter 'gdb' at the ddb prompt. > > No problem. It also says that typing 'gdb' again will take me back > > to ddb. What it doesn't say is where to enter it. I've tried in gdb > > (no success) and on the console (also no success). What am I > > missing on how to switch back to ddb mode? Alternately, if I can > > just cause the machine to reset from gdb, that would work. I've > > tried the following from gdb: > > If you are able to be at a command line, you could try: > sysctl debug.kdb.current=ddb You used to be able to use GDB's detach command to switch back. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting MAC address?
On Saturday 26 June 2004 10:15, Ivan Voras wrote:
> Dmitry Morozovsky wrote:
> > On Sat, 26 Jun 2004, Ivan Voras wrote:
> >
> > IV> How to get the MAC address for an (ethernet) interface? The
> > linux code IV> does this:
> > IV> retval = ioctl(thisint->sockInt, SIOCGIFHWADDR, &ifr);
> > IV>
> > IV> After some searching, I found SIOCSIFLLADDR ioctl, but it
> > appears there IV> isn't a "GET" counterpart.
> > IV>
> > IV> (I've got interface name & index available...)
> >
> > Take a look at ifconfig(8) source.
> >
> > getifaddrs(3), case when sa_family == AF_LINK
>
> I was looking at it and came across getifaddrs(). This function does
> not depend on a open socket (yes, mine is AF_LINK, sockaddr_dl), and
> apparently returns a list of all interfaces. Is there really no other
> way than to traverse this list?
Its really not that hard:
static void
getNodeID(uint8_t node[6])
{
struct ifaddrs *ifap;
if (getifaddrs(&ifap) == 0) {
struct ifaddrs *p;
for (p = ifap; p; p = p->ifa_next) {
if (p->ifa_addr->sa_family == AF_LINK) {
struct sockaddr_dl* sdp = (struct sockaddr_dl*) p->ifa_addr;
memcpy(node, sdp->sdl_data + sdp->sdl_nlen, 6);
freeifaddrs(ifap);
return;
}
}
freeifaddrs(ifap);
}
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: quiet ATX mid-Towers
On Friday 18 June 2004 15:39, zera holladay wrote: > Under a kind suggestion, I am re-submitting this > e-mail with a different subject. The old message was: > > Hello, I am looking for a very quiet ATX mid-tower and > I was wondering if anybody has a suggestion or > recommendation. My hard disks produce the most > decibels at the most annoying frequency -- itÂ’s not a > bad fan. I am an EE student using FreeBSD, so a quiet > computer is very important to me. I like the Antec Sonata cases. They have special drive trays which mean that your drives are mounted on rubber grommets to reduce noise. Plus they have a decent quiet PSU, a large low-speed case fan at the back and a cute blue LED on the front :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD and Debugging?
On Saturday 10 April 2004 06:17, Lev Walkin wrote: > Brandon Erhart wrote: > > For Linux, I've seen valgrind (probably one of the best) as well as > > several others. In the commercial arena, Rational's PURIFY and > > Parasoft's INSURE++ work on every OS *but* BSD. Any particular > > reason for this? > > > > Are there any debuggers out there for BSD that will detect the > > heap/stack corruption!? > > Valgrind is available for FreeBSD. > > http://eirikn.kerneled.com/valgrind/ Or alternatively, a more up-to-date version (which the above is a snapshot of) at http://www.rabson.org/#valgrind. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SCM options (was Re: Where is FreeBSD going?)
On Sun, 2004-01-11 at 00:05, Peter Jeremy wrote: > On Sat, Jan 10, 2004 at 05:01:13PM -0500, Garance A Drosihn wrote: > >At 9:35 PM + 1/10/04, Andrew Boothman wrote: > >>Peter Schuller wrote: > >> > >>>Most of the noteworthy features of subversion are listed > >>>on the project front page: > >>> > >>> http://subversion.tigris.org/ > >> > >>A significant one of which is the fact that it's available > >>under a BSD-style license. Meaning that the project wouldn't > >>have to rely on more GPLed code. > >> > >>I wonder if our SCM would be brought into the base system or > >>whether it would just be left in ports? > > > >We haven't even started to *test* subversion yet, so I think > >it's a bit early to worry about this question! > > I disagree. Andrew raised two issues (type of license and port vs > base location). The type of license is an input to the decision as > to which SCM to choose - BSD would be preferable but GPL is probably > acceptable (given two potential SCMs with similar features, the BSD > licensed one would be selected in preference to the GPL one). Subversion has a friendly BSD-ish license but it depends heavily on Sleepycat DB which doesn't. I imagine that if we do end up using it one day, it would be best managed as a port rather than part of the base system. I just don't see many people agreeing on importing subversion+db-4.2+apache2 into src/contrib... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where is FreeBSD going?
On Thu, 2004-01-08 at 18:05, Munish Chopra wrote: > On 2004-01-08 17:29 +0000, Doug Rabson wrote: > > [...] > > > > > The three main showstoppers for moving FreeBSD to subversion would be: > > > > 1. A replacement for cvsup. Probably quite doable using svnadmin > >dump and load. > > 2. Support for $FreeBSD$ - user-specified keywords are not supported > >and won't be until after svn-1.0 by the looks of things. > > 3. Converting the repository. This is a tricky one - I tried the > >current version of the migration scripts and they barfed and died > >pretty quickly. Still, I'm pretty sure that the svn developers > >are planning to fix most of those problems. From mailing-list > >archives, it appears that they are using our cvs tree as test > >material for the migration scripts. > > Perfection (or as close as possible) of cvs2svn.py is scheduled for > 1.0. They've entered beta now, but without scanning the lists I suppose > that's "sometime 2004". > > I've noticed some other projects having problems with repository > conversion, but at least things seem to be getting better. There seems to be a reasonably common problem where a single branch point ends up with more than one branch name. This certainly happens in the FreeBSD cvs. If you ignore that error, it gets about 1000 commits into the conversion but then dies with an error in the branch handling code (probably caused by the first problem). There are outstanding problems with vendor branches which it looks like they will fix before 1.0. I've been using the scripts to convert another large repository and they are not quick - my current test has been going for 2.5 days now and it still has about six months worth of repository to convert (the cvs history goes back about seven years in total). I estimate that the complete conversion will take about 3 days and will contain about 15000 commits... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where is FreeBSD going?
On Wed, 2004-01-07 at 20:19, Robert Watson wrote: > On Wed, 7 Jan 2004, Roman Neuhauser wrote: > > > [1] has core@ considered subversion (devel/subversion)? > > Everyone has their eyes wide open looking for a revision control > alternative, but last time it was discussed in detail (a few months ago?) > it seemed there still wasn't a viable alternative. On the src tree side, > FreeBSD committers are making extensive use of a Perforce repository > (which supports lightweight branching, etc, etc), but there's a strong > desire to maintain the base system on a purely open source revision > control system, and migrating your data is no lightweight proposition. > Likewise, you really want to trust your data only to tried and true > solutions, I think -- we want to build an OS, not a version control > system, if at all possible :-). Subversion seems to be the current > "favorite" to keep an eye on, but the public release seemed not to have > realized the promise of the design (i.e., no three-way merges, etc). You > can peruse the FreeBSD Perforce repository via the web using > http://perforce.FreeBSD.org/ -- it contains a lot of personal and small > project sandboxes that might be of interest. For example, we do all the > primary TrustedBSD development in Perforce before merging it to the main > CVS repository. I've been re-evaluating the current subversion over the last couple of weeks and its holding up pretty well so far. It still misses the repeated merge thing that p4 does so well but in practice, merging does seem to be a lot easier than with CVS due to the repository-wide revision numbering system - that makes it easy to remember when your last merge happened so that you don't merge a change twice. The three main showstoppers for moving FreeBSD to subversion would be: 1. A replacement for cvsup. Probably quite doable using svnadmin dump and load. 2. Support for $FreeBSD$ - user-specified keywords are not supported and won't be until after svn-1.0 by the looks of things. 3. Converting the repository. This is a tricky one - I tried the current version of the migration scripts and they barfed and died pretty quickly. Still, I'm pretty sure that the svn developers are planning to fix most of those problems. From mailing-list archives, it appears that they are using our cvs tree as test material for the migration scripts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Shrinking /(s)bin: A Proposal
On Thursday 14 November 2002 6:45 am, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > > Nate Lawson <[EMAIL PROTECTED]> writes: > : On Mon, 11 Nov 2002, Tim Kientzle wrote: > : > The possibility of dynamically linking /(s)bin seems > : > to recur pretty regularly. As libc continues to grow, > : > this idea seems worth revisiting. However, I've come up > : > with an alternative that might be worth considering. > : > : I'm open to patches for building /[s]bin as dynamic. If you have > : time and can coordinate with [EMAIL PROTECTED] to build the patch, I > : would appreciate it. > > % make NOSHARED=NO buildworld > > No patches necessary. We do this all the time at work, and it works > fabulously. I do this for disk based systems that have / and /usr on > the same file system too. To do it right for split root/usr installations requires a few patches though. The rtld and the libs required for /[s]bin need to move to / and compat symlinks created from /usr. A suitable crunchgen'ed binary for /recover would be useful too. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Soft interrupts
On Thu, 9 May 2002, Josef Karthauser wrote:
> Do we have soft interrupts?
>
> Here's a bit of code from the NetBSD usb stack, and I'm trying to work
> out what it would be in FreeBSDland.
>
> sc->sc_bus->soft = softintr_establish(IPL_SOFTNET,
> sc->sc_bus->methods->soft_intr, sc->sc_bus);
> if (sc->sc_bus->soft == NULL) {
> printf("%s: can't register softintr\n", USBDEVNAME(sc->sc_dev));
> sc->sc_dying = 1;
> USB_ATTACH_ERROR_RETURN;
> }
>
> Can someone point me to a man page please?
Try using taskqueue.9. You don't need to create a new queue - just use the
system queue 'taskqueue_swi' which executes tasks on a SWI thread (on
current).
--
Doug Rabson Mail: [EMAIL PROTECTED]
Phone: +44 20 8348 6160
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
On Thu, 14 Mar 2002, Michael Smith wrote: > > hw.busfrequency = 133326902 > > Not typically obtainable. And which bus? This is available for ia64. I think the speed returned by ia64 firmware for this is the FSB speed. > > > hw.cpufrequency = 66700 > > Should be obtainable on Alpha and Sparc, and calculable on x86 (though it > will probably have to be calculated at the time the sysctl is read, since > it's variable). Certainly also available for ia64. > > > hw.cachelinesize = 32 > > hw.l1icachesize = 32768 > > hw.l1dcachesize = 32768 > > hw.l2cachesize = 262144 > > Most of these can be obtained, one way or another. I can get this too. Also sizes of various levels of TLB too for fun... -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: to users of threads (GDB support)
On Mon, 11 Feb 2002, Kip Macy wrote: > > > > There's no reason freebsd-uthread.c has to be included in gdb. > > I think that there are instances when an individual wants to use the latest and > greatest version of GDB and still have thread support. Even if the threads > library does change, the objfile function should be able to take that into > account. > > > > That said, I think dfr and I are the only ones that have > > done anything with freebsd-uthread.c, aside from obrien. > > My papers are on file with FSF. I don't know about dfr. > > dfr is your paperwork on file? I don't have any up-to-date paperwork on file right now (I did once a long time ago but that was several companies ago...) I'm quite willing to relinquish all ownership that I may have to this code. If it helps, I can claim that David O'Brien wrote it all :-) -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Oh my god, Google has a USENET archive going back to 1981!
On Tue, 8 Jan 2002, Matthew Dillon wrote: > : > :That brings back memories. We wrote our own firmware for the 1541 since > :the commodore DOS was so slow. I forget what transfer rate we managed but > :it was much better than the standard code. Bit of a sod to debug though. > : > :-- > :Doug Rabson Mail: [EMAIL PROTECTED] > : Phone: +44 20 8348 6160 > > Yup. Remember Bryce's 1541 Flash? He was working on beefing up > the C64 serial link while I was working on beefing up the PET's > (software driven) IEEE-488 link. We both managed to increase disk > bandwidth by an order of magnitude, mainly by synchronizing the > computer's 6502 with the peripheral's 65xx and then just stuffing > data into the ports without bothering with any handshakes until the > very end. That old usenet posting I posted has some references to it. I wasn't really into the C64 scene (it cost significant money just to get Usenet access in the UK in those days). I was working on a C64 game at the time and I remember spending many unhappy hours trying to fix some problems with the drive firmware. That was a pretty cool project actually. The game was a text adventure originally written in 68k assembler and we wrote a 68k emulator and VM system which paged the game's 128k address space from the floppy into the C64's teaspoonful of memory. All the development was done on a Microvax running 4.2BSD. The vax generated C64 disk images which we downloaded via the C64's serial port. Those were the days . -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Oh my god, Google has a USENET archive going back to 1981!
On Mon, 7 Jan 2002, Matthew Dillon wrote: > Oh my god. I don't even *remember* writing this one! This was when > I was 18. Google's archive isn't complete but they've done an incredible > job getting as much as they have. > > Pet, C64, DMail, Shell (for the amiga), backup/restore utilities, > dme, dterm, AmigaUUCP, DICE, etc. It's all there in bits and pieces, > complete with my trademark spelling errors. That brings back memories. We wrote our own firmware for the 1541 since the commodore DOS was so slow. I forget what transfer rate we managed but it was much better than the standard code. Bit of a sod to debug though. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linus Torvalds and urgent message about your future!
On Wed, 5 Dec 2001, Miss Cleo wrote: > [top_urgent.gif] > > Linus Torvalds, you must have friends in high places. I've been > authorized to issue you a Special Tarot Reading! You can learn about > important events concerning your future. It is vital that you call > immediately! > So, make this FREE CALL to 1-800-311-1736 ROFLMAO. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: ACPI CA updated
On Wed, 31 Oct 2001, Grover, Andrew wrote: > > From: Doug Rabson [mailto:[EMAIL PROTECTED]] > > This doesn't appear to fix the 64bit alignment problems which > > we had while > > trying to use the code on ia64. Any news on when/whether > > Intel will accept > > our 64bit patches? > > Our next release will include a fix for this. Good news, thanks! -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ACPI CA updated
On Tue, 30 Oct 2001, Mike Smith wrote: > > I've just updated the ACPI CA subsystem to the Intel 20011018 snapshot. > > This primarily fixes a couple of bugs in the ACPI interpreter; see the > changelog at > > http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt > > for full details. This doesn't appear to fix the 64bit alignment problems which we had while trying to use the code on ia64. Any news on when/whether Intel will accept our 64bit patches? -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New rc.d init script roadmap
On 18 Oct 2001, Dag-Erling Smorgrav wrote: > John Baldwin <[EMAIL PROTECTED]> writes: > > Huh? Int on alpha is 32, and pointer is 64. > > I thought we were ILP64 on 64-bit archs, but you're right. And I > ought to know better... Fortunately (?) it doesn't matter in this case. Function arguments which are passed in registers are all promoted to 64bits. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Newbus
On Wed, 8 Aug 2001 [EMAIL PROTECTED] wrote: > I would very much like to know, exaclty which files comprise the code for > NEWBUS, excluding the drivers themselves.Can anyone help The external API is in sys/bus.h. The internal implementation is in sys/bus_private.h and kern/subr_bus.c. Interface definitions are scattered around the tree - the core interfaces DEVICE and BUS are in kern/device_if.m and kern/bus_if.m respectively. The 5.x version of newbus is based on the kobj system with api in sys/kobj.h and implementation in kern/subr_kobj.c. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: processes private data
On Fri, 29 Jun 2001, Nicolas Souchu wrote: > On Thu, Jun 28, 2001 at 07:48:21PM +0100, Doug Rabson wrote: > > On Thu, 28 Jun 2001, Nicolas Souchu wrote: > > > > > Hi folks, > > > > > > I have a char driver that must be opened by more than one process. The minor > > > index is not sufficient for this. Is there any process private data (void *) > > > in the devfs structure (or the opposite) I could point to with the minor index > > > of my device? > > > > The only way I know of to do this is to get a new struct file with > > falloc() and install your own fileops. You can then set p->p_dupfd to the > > new file descriptor and return ENXIO. The caller will magically use the > > new struct file. For an example, see streamsopen() in > > sys/dev/streams/streams.c. > > Ok, it seems to do part of the job. But this won't change the content of the > file struct. Does anything ensure that the f_data of the freshly allocated > struct file won't be used by vfs? Is the new struct file only local to my > device driver? > > Otherwise, I could write my own falloc() which would allocate a struct file > compatible with the original one like this: When you get a new struct file from falloc(), VFS has nothing to do with it. As you can see from the streamsopen() code, you can change f_ops (which by default points at &badfileops) and f_data (defaults to zero) to point at your own functions and data. The point is that you are creating a new file. The VFS-owned file which ended up calling the open driver entrypoint will be discarded in favour of your new one. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: processes private data
On Thu, 28 Jun 2001, Nicolas Souchu wrote: > Hi folks, > > I have a char driver that must be opened by more than one process. The minor > index is not sufficient for this. Is there any process private data (void *) > in the devfs structure (or the opposite) I could point to with the minor index > of my device? The only way I know of to do this is to get a new struct file with falloc() and install your own fileops. You can then set p->p_dupfd to the new file descriptor and return ENXIO. The caller will magically use the new struct file. For an example, see streamsopen() in sys/dev/streams/streams.c. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libwi and KWireless
On Mon, 25 Jun 2001, Arun Sharma wrote: > KWireless is a KDE kicker applet to display the signal qualtiy of a IEEE > 802.11b wireless network. > > http://www.sharma-home.net/~adsharma/projects/KWireless/ > > It depends on libwi, a library version of wicontrol(8). > > http://www.sharma-home.net/~adsharma/projects/libwi/ > > I know this is not in a commitable state and would appreciate some > feedback on what I need to do, before it can be commited. I can't configure it. It doesn't contain a configure script and autoconf doesn't seem to like the (possible misnamed?) configure.in.in file. This is from 4.3-stable with autoconf-2.13_1. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newbussifying drivers
On Fri, 8 Jun 2001, Sergey Babkin wrote: > j mckitrick wrote: > > > > Okay, there is something i'm not understanding here. In the ed driver, > > there are many possible cards, which each have different i/o ports, correct? > > The driver has a lot of probe routines, and it looks like they are just > > using different macros with hard-coded (#defined) port addresses. > > > > So, how do you CORRECTLY use the newbus calls to probe these ports? I am > > not running -current, so i do not have 'hints'. > > As Doug Rabson said, write an 'identify' routine. Look at the > ep driver for an example. And my artile in DaemonNews > (www.daemonnews.org) from I think August 2000 or somewhere around > that time gives some description of the newbussified ISA drivers. > It should also be included into the Handbook by now. Actually, the ex driver does have an identify method. The issue is that the identify method uses 'unallocated' ports to do its search. It ought to allocate them, do its tests and release them for the real probe but it gets messy due to the fact that a device instance doesn't exist yet. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: newbussifying drivers
On Thu, 7 Jun 2001, Matthew N. Dodd wrote: > On Wed, 6 Jun 2001, Warner Losh wrote: > > In message <[EMAIL PROTECTED]> j mckitrick writes: > > : How would you recommending fixing this, taken from the ex driver? > > > > By deleting it. > > Uh, what? > > Non PnP devices that can be autodetected should be autodetected. > > Relying on the user to wire down hints is silly. Probably they should provide an identify method to look for and create the non-PnP devices. The actual probe method should be dumb and just use the resources given to it (IMHO). -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD/powerpc work to date
On Mon, 21 May 2001, Benno Rice wrote: > Please feel free to review, comment, etc. > > The snapshot is in the form of a diff against -CURRENT and a tar.gz file > containing new files that would need to be committed. Both of these > files are rooted in src/sys. Nice! Reading through the changes, I have a couple of comments. In mp_machdep.c, you should remove the 'include ' - that is only ever likely to exist on alpha. You can alsp delete ipl.h since that has been removed for the other arches. In swtch.s, you are correct in thinking that Idle is unneeded. A generic assembler question - why the use of _C_LABEL(xx)? Surely since we are only ever going to be using ELF here, we can assume the format of C names? Its difficult to see what is happening since I'm not familiar with powerpc assembler but it appears that you are saving the process state on the stack (using a 'struct switchframe'). The other architectures save this information in the PCB - I'm not sure which is the best place. I notice that pmap.c contains a mix of programming styles with some of the code using ANSI and some K&R. The trend seems to be to move to ANSI for all new code so its probably worth converting the rest of the file. How far does the beast get when booting? -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kobj, makedevops.pl etc.
On Mon, 8 Jan 2001, Vijo Cherian wrote: > hi, > > I have some questions... but most of them may be prerry lame because I am new > to FreeBSD. > > I am running 5.0 and I have a driver for a card which was written for 4.1. > The driver uses bus_if.h, device_if.h and pci_if.h and these files are generated > by makedevops.pl. The driver is written as a module and is loaded using kldload. > But loading fails because BUS_READ_IVAR and friends are not available. > Using makeobjops.pl works. My questions are >1. Is this the right way? >2. When did kobj find place in the kernel? (which release) > (that is what makeobjops.pl does,right?) >3. If all that I did is wrong, what is the right way? >4. Can you point me to a driver that can be loaded as kld? > > waiting to see how the community treats a new convert ;-) Unfortunately, the device driver ABIs (and many others) are different between 4.1 and 5.0-current so you cannot load a binary driver intended for 4.1 on a 5.0-current system. For newbus at least, the programming API is the same, although in 5.0 it uses kobj for its object model instead of the slightly less flexible system used in 4.x. You need to rebuild the driver, using makeobjops.pl instead of makedevops.pl. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken-by-design USB device?
On Sun, 7 Jan 2001, Nick Hibma wrote: > > There is, I think, at least a bug in subr_bus.c that might cause this, > although, this is just a hunch. I've not been able to explain what's > happening yet. > > What is happening is that device_probe_child sets the device class, and > in case of an error unsets it. But in this case attach (instead of > probe) returns an error and hence the devclass _should_ be unset for > that device (it didn't have a devclass to start with) to force it back > to its virgin state, but isn't. > > If you could review his patch dfr, that would be appreciated. > > This is an issue in current as well. The patch looks good to me. -- Doug Rabson Mail: [EMAIL PROTECTED] Technical Director, Qube Software Ltd. Phone: +44 20 7431 9995 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel debugging suggestion needed
On Tue, 2 Jan 2001, Doug White wrote: > On Tue, 2 Jan 2001, Zhiui Zhang wrote: > > > > > I have written a KLD and am debugging it. The program often hangs after > > runs for a while (I guess it enters into some dead loop). Is there a way > > to attach to the process and somehow find out which code it is executing > > (with remote debugging or ddb)? > > kld debugging is a bit tricky. Take a look at the debugging macros and > bits that Greg Lehey put together for vinum for a starting point. You have > to calculate the appropriate offset to get to the KLD code in gdb. Not anymore. You can use GDB's "sharelibrary" command to read the symbols of all loaded KLDs. You only need to ensure that the exact same pathname works for both loading the KLD on the target machine and for loading the symbols on the machine running GDB. -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: uidinfo has many race conditions.
On Sat, 10 Jun 2000, Alfred Perlstein wrote: > * Brian Fundakowski Feldman <[EMAIL PROTECTED]> [000610 09:13] wrote: > > On Fri, 9 Jun 2000, Alfred Perlstein wrote: > > > > > * Alfred Perlstein <[EMAIL PROTECTED]> [000609 16:45] wrote: > > > > hi, > > > > > > > > Is it just me or does the fact that uidinfo structures (see > > > > kern/kern_proc.c) are allocated with M_WAITOK after finding them > > > > fails and then inserted into the uidhash structure a race condition? > > > > > > > > Index: kern_proc.c > > > > === > > > > > > Yes, I know i forgot to put the created ones back into the list, I was > > > just a bit flusteres after reading over the code. I'll have some more > > > later. > > > > With regard to sbsize itself, the test-and-branch conditions do not have > > to be atomic. It really isn't that important. The incrementing does, > > though, and to fix that a very lightweight mutex should be used. How > > about a simplelock? That should work perfectly. > > Well if we get an atomic_t it could be done that way, even if we > fail the race for updating and go beyond our rlimit slightly it's > much cheaper than a spinlock from my PoV. The only problem is > that afaik on some archs atomic_t can be quite small, we'd have > to watch for overflow, perhaps a spinlock is a better idea however > only if the next thing I mention here is realized: You can use atomic_add_*() to do safe arithmetic on memory locations. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
On Fri, 9 Jun 2000, Wilko Bulte wrote: > On Fri, Jun 09, 2000 at 09:39:53AM +0100, Doug Rabson wrote: > > On Thu, 8 Jun 2000, Wilko Bulte wrote: > > > > > I'm considering buying an Athlon based machine. Before shelling out the > > > $ (well, fl ) I'd like to know what experiences have with Athlon and > > > FreeBSD. And obviously which mom boards to prefer or keep away from. > > > > We have one at work and it works fine. We had to put some extra cooling on > > the motherboard chipset though. > > What motherboard are you using? I'm not sure - Nick Hibma might know since its his desktop machine. I could probably open it up and check. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Comments on Athlon [motherboards] sought..
On Thu, 8 Jun 2000, Wilko Bulte wrote: > I'm considering buying an Athlon based machine. Before shelling out the > $ (well, fl ) I'd like to know what experiences have with Athlon and > FreeBSD. And obviously which mom boards to prefer or keep away from. We have one at work and it works fine. We had to put some extra cooling on the motherboard chipset though. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: I will be in Japan and Korea from June 7th through June 15th
On Thu, 1 Jun 2000, Jordan K. Hubbard wrote: > > Does this mean we won't get the SMP stuff done next week? > > I'm back on the 15th (you gain 10 hours coming back) and the SMP > meeting isn't until the 16th and 17th. Of course it will. :) So you are running this right before Usenix? Thats annoying - I've already booked a flight to San Diego on the 17th. Meeting *at* Usenix would be good though. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: subr_bus.c | kldload | kldunload
On Mon, 29 May 2000, Bob Kot wrote: > > > I am in the process of upgrading my Turtle Beach MultiSound Monterey > soundcard device driver (msm) from the 3.x version available from > http://www.treefort.org/~bobkat/msm_main.shtml > to 4.0-RELEASE. While crawling over the learning curve of the new-bus > system I've been bit by the following. > > In FreeBSD: src/sys/kern/subr_bus.c,v 1.54 2000/02/29 09:36:25 dfr > line 312 devclass_find_internal(driver->name, TRUE); > calls that function ignoring the return value but with arg2=TRUE > If the classname is not found in the for loop at line 255 and > create = TRUE, which it is by call value then a malloc is performed. > The malloc is assigned to dc and dc is returned, but the calling > function has summarily ignored the return value. How is this malloc'd > memory ever freed? I looked at the head of the CVS tree and this > same scenario still looks like it can happen. Please confirm > or refute. > > -=-=-=-=-=-=-=-= > > What led me to uncover this is trying to get my driver which is > compiled as a module to kldload / kldunload from a shell prompt > as root with the system fully up running multi-user. The behavior > under 3.x is that a kldload will attach my (msm) module to the kernel > and execute my msm_probe() and msm_attach() functions. A subsequent > kldunload will delete the module and free all resources allocated > leaving no leaks or indications that it had ever been attached. I am > attempting to accomplish the same behavior on 4.0-RELEASE. Also my > 4.0 kernel will have no prior knowledge of this device meaning > /sys/compile/SOMEKERNEL/ioconf.c will know nothing about this device. The devclass will live forever. This is not a problem since the second time the driver is loaded, it will use the devclass which was created the first time. > > This souncard is a totally brain dead ISA board not PnP. So in > modifications for newbus of 4.0 I used the joy driver as an example. > It's source being at /sys/isa/joy.c. It has a module Makefile at > /sys/modules/joy and also there is a joy.sh file that would indicate > that this module can be kldload'd into a running kernel. Well I > tried that and kldstat -v indeed showed the joy module was loaded > but the joy_probe() function never got executed. I edited the > /sys/isa/joy.c file and added a printf() as the 1st line of the > joy_probe() function, recompiled the module and kldloaded it again, > after first kldunload'ing it of course, and that printf() output was > nowhere to be found (not in /var/log/messages or on any system > console). Someone please confirm or refute this behavior. > > I went thru the execise of adding a joy option to a kernel config > file and built a new kernel. Booting it caused the joy_probe() > function to execute and the printf() output was in /var/log/messages > as anticipated. > > My driver, patterned after the joy driver module, was exhibiting the > same behavior my msm_probe() was not being executed on kldload. > I did some things to surmount that hurdle and am at a point where > my driver kldload's, executes my msm_probe() and msm_attach() > functions and kldunload's, but that leak in subr_bus.c is leaving > an instance of my msm_devclass behind when I kldunload and on > each subsequent kldload I add another msm unit to the kernel. > That is not an acceptable situation. Without seeing the code, it appears that you are creating a new device instance each time the module is loaded. Probably you should try to only do this the first time (e.g. by looking to see if device msm0 exists). This part of the interface could use some improvement. > > Knowing that my in-experienced approach at getting my msm_probe() > and msm_attach() to execute may not be the right way to do things, > I will start by just asking for a referral to some other driver > that is implemented as a module with the newbus architecture, that > will kldload / kldunload with no side effects and that preferably is > an ISA device. If no one responds to this request I will repost with > actual code and a laundry list of observed symptoms. Warner Losh might be able to help you out here. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0 - Isa devices not being probed
On Mon, 29 May 2000, Dennis wrote: > At 06:36 PM 5/27/00 -0700, Mike Smith wrote: > >> Existing bus abstractions tend to let think that the same software driver > >> can deal with different buses, bridges or IO methods without having to > >> care about how these things actually behave, notably regarding buffering > >> and ordering rules. This is untrue. > > > >A good bus abstraction lets you care as much or as little as necessary. > >The NetBSD framework (which we use) allows you to do this. > > The best "portable" coding method is with memory-mapped registers, which > seems to have been omitted from this "implementation", which is the gripe > here. Perhaps "portable" within the OS was your goal, but in the mean time > "portable" between very different OSs has been tainted. After an OS > specific initialization, the driver can be completely OS independent (as > are our LINUX and FreeBSD drivers) using memory-mapped registers. Using normal C pointers to memory-mapped registers is not portable. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.0 - Isa devices not being probed
On Sat, 27 May 2000, Dennis wrote: > At 09:54 AM 5/27/00 +0200, John Hay wrote: > >> In message <[EMAIL PROTECTED]> Dennis writes: > >> : My 4.0 system doesnt probe ISA devices on my system. > >> : > >> : Whats the trick? Is there a config requirement with old-style drivers? > >> > >> They probe great for me. what, specifically, isn't probing? > > > >He is probably talking about their own driver. In that case you have to > >add it to /sys/i386/isa/isa_compat.* or bite the bullet and new-busify > >it. > > YesWhose brainstorm was it to use the new convoluted bus nonsense in > FreeBSD 4.0? Clearly someone who never wrote a driver with a complex > controller with indexed memory mapped registers.Whats next, assembler drivers? Mine. > > isa_compat.h? LOL...what college freshman thought of that? Is it really > that difficult to have the prefix_probe() function called based on the > config file? This is just a list of drivers using the legacy apis. Since no new drivers will be using those apis, this file will gradualy disappear and certainly no new drivers will be added to it. > > Its seems rather humorous that the "generic" bus implementation requires > that isa drivers be hacked into the kernel with a build-time include. Very > humorous indeed. Is this a temporary condition as was the deboggle in v3.0? Whatever. > > any docs on this junk? RTFM. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: S5933 PCI Adapter..??
On Fri, 26 May 2000, Joy Ganguly wrote: > hi all, > > i have a atm oc3 care which uses the amcc S5933 PCI adapter. however the > driver reports "unable to map mem" at boot time. i used pciconf to read > the configuration space base address registers and all of them showed > 0x. however when i write all 1's t the base registers they give > me the proper mask. the device and vendor id configuration registers > show the right values. i think the bios is unable to assign physical > addresses. > > how can i solve this problem?? one way out is to have the driver assign > physical addresses to map the pci space. however for that i need the > physical map...what data structure holds that?? Can you check your BIOS and make sure it does *not* think you have a Plug-n-Play OS. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: further question to bus_alloc_resource
On Sat, 20 May 2000, Alexander Langer wrote: > Thus spake Doug Rabson ([EMAIL PROTECTED]): > > > There is really no need. The mcclock driver can't be detached since its > > required for normal system functioning (its the main clock source). > > OK. I agree. > It was just the first driver I got, so far only an example (bad one). > What about aha? It would be nice to be able te detach most drivers. I think that when aha was converted originally, cam didn't support detach but I'm pretty sure it does now. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: further question to bus_alloc_resource
On Sat, 20 May 2000, Alexander Langer wrote: > Hello! > > See sys/alpha/isa/mcclock_isa.c: > It has attach (which allocs resource), but not detach. > Also, it doesn't save the rid in the softc. > > I wonder, if the generic detach function is capable to clean up the > resource without knowing the rid, or if this is a bug. > > If so, I'm going to write patches. There is really no need. The mcclock driver can't be detached since its required for normal system functioning (its the main clock source). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Netfinity 5600 patches
On Tue, 9 May 2000 [EMAIL PROTECTED] wrote: > > I still have uncommitted patches that add support for the Netfinity > > 5600's host-to-PCI bridge. They're not perfect, but they work fine. > > > > http://www.freebsd.org/~des/software/> > > As far as I can see, these patches aren't needed for 4.0-STABLE. I > have a 4.0-STABLE system here with no kernel patches, and it seems > to be working fine. Note that there is already support for the RCC > chipsets in /sys/i386/isa/pcibus.c. See attached boot messages. > > For 3.x, isn't Andrew Gallatin's patch more general? See > >http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=60828+0+archive/2000/freebsd-smp/2423.freebsd-smp > > However, if anybody can tell me why there seems to be quite a bit > of overlap between nexus_pcib_is_host_bridge (/sys/i386/isa/pcibus.c) > and chip_match (/sys/pci/pcisupport.c), I'd be happy. Examples of > overlap are: 0x00011039 (SiS 5591 host to AGP bridge) and 0x00051004 > (VLSI 82C592 Host to PCI bridge). The code in sys/i386/pcibus.c is used to search for all the host-pci bridges so that nexus can grow toplevel pcib instances for each one. The stuff in pcisupport is just informational. In fact, I'm planning to chop it out soon since I want to be able to attach an AGP driver to some of those devices. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What do people think of maybe using the sourceforge software?
On Mon, 8 May 2000, Jordan K. Hubbard wrote: > http://sourceforge.net/project/filelist.php?group_id=1 > > Contains the software used by source forge to implement the > project/help desk/download tracker thingie which they themselves use > to manage the various projects registered with source forge. > > I think it's also reasonable to say that FreeBSD itself is a bit too > large to register and run as a sourceforge project, but why not use > the same software to offer a higher level of "polish" to the existing > project infrastructure? Comments? I'm just playing with this stuff a > bit myself right now and will say more once I actually know more about > it. > I've been using it to work on the DRI project recently and I like it. The web-based frontend for creating accounts and managing SSH keys is pretty useful. I'm not quite sure how well the patch manager scales - it barfed when I uploaded a patch containing a large uuencoded file. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel 810/BookPC
On Tue, 7 Mar 2000, FreeBSD MAIL wrote: > Sorry if this is a repost but I didnt see it come throug yet and my mail was > screwed up. > > I am working with a BookPC whith an intel 810 all in one chipset. > > I was wondering if there was planned support for the sound and if someone > has heard anyting about the Xfree86 (linux) LKM being ported to FreeBSD. I have been working on something which should be adequate for the purposes of XFree86-4.0. I've been distracted by having to ship some software at work but I hope to get back to this soon, probably next week. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: yamaha japan relationships anyone?
On Mon, 21 Feb 2000, Daniel C. Sobral wrote: > Jeroen Ruigrok/Asmodai wrote: > > > > Well Doug, > > > > you're in the UK, so part of the European Community. > > > > And since you requested information from Yamaha and got none, you are > > now legally clean of action due to the law that you may > > disassemble/reverse engineer their drivers to obtain the information you > > need to program the driver. > > > > For once, a cool law in Europe. > > The U.S. Supreme Court made this exactly ruling one or two weeks ago. Unfortunately (fortunately?) I'm not intending to spend the time necessary to reverse-engineer specs for this thing. Besides I swapped the card with a colleague for one which works... -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: yamaha japan relationships anyone?
On Sun, 20 Feb 2000, Karsten W. Rohrbach wrote: > hi * > this might be a little offtopic... > > > i just messaged the guys from yamaha japan for specs on their pci audio > chipsets to get some decent documentation to start torturing those ymf744 > soundcards. no response. i mailed again. same result. do they actually > read their mail or is this an uncommon thing in .jp? > if there's anyone out there who can tell me how to talk with these guys > please hit me with your suggestions, since i am starting to get very > very pissed about this whole yamaha clan and people from several > continents telling me to ask someone else in another division of their > rotten company... > also if you know who to talk to on these issues, i'd appreciate any > information about contacts there... > I have had more-or-less the same experience. I did get a response which completely misunderstood what I was asking and assumed I wanted the source code to their windows driver. My reply explaining that I really just wanted documentation went unanswered. Sigh. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 64bit OS?
On Sun, 20 Feb 2000, Patryk Zadarnowski wrote: > > On Sun, Feb 20, 2000 at 12:42:14PM +1100, Patryk Zadarnowski wrote: > > > One more thing about GPTs (I thought I'll leave that till last. ;) > > > Jochen Liedtke holds a German patent on them, although he will > > > probably be fairly easily convinced to give FreeBSD rights to use > > > them. I'll be happy to ask (if we're interested.) > > > > It looks like the hardware has to implement GPTs and know how to > > walk them. How can FreeBSD use them without hardware support ? > > No it doesn't. We've got software GPT implementations for both MIPS64 and > Alpha, and they're both peform very well in our somewhat hostile SASOS > conditions. So you have custom PALcode for Alpha on SASOS? We have been able to use OSF1 PALcode up to now which makes life a lot easier for supporting new hardware. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Detecting PnP devices upon module load
On Fri, 11 Feb 2000, Steve Hocking wrote: > > Are there any existing examples of this happening? I'm doing a version of the > Linux joystick driver ported to FreeBSD and of course some of the devices are > PnP. You need to dike out the unknown driver (near the end of sys/isa/isa_common.c). I'll fix this properly after 4.0 if Matt Dodd doesn't beat me to it. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: elf
On Fri, 4 Feb 2000, John Baldwin wrote: > > On 04-Feb-00 Marco van de Voort wrote: > > > > > > How can I disassemble ELF programs? > > > > I need to create my own startup code for FPC programs. > > (copying some variables before pascal code startup) > > Try 'objdump -d'. It's more readable if you don't strip the program. > You can also use this to disassemble object files as well, so you > could just 'objdump -d /usr/lib/crt0.o'. My favourite is 'objdump -dS' to include source code. This obviously requires debugging information in the disassembled thing. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to allocate an alined address for a device?
On Fri, 28 Jan 2000, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Doug >Rabson writes: > : I'm uneasy about using the flags for this since I'm vaguely reserving the > : upper 16 bits of flags for bus-specific purposes (although I haven't > : formalised this). > : > : For allocating aligned regions with pnp, I simply looped in the caller > : trying each specific range until one was free (see isa_find_port() in > : isa_common.c). This is ugly but it does work. > : > : In the long run, I think we need either an extra parameter to > : rman_reserve_resource() or a new api rman_reserve_resource_aligned(). > : This also implies changing the method BUS_ALLOC_RESOURCE() or adding > : BUS_ALLOC_RESOURCE_ALIGNED(). > > Well, with just 6 bits one could handle any alignment requirement up > to 2^(2^6). > > We have 6 bits left. If this were the alignment requirement, a value > of 0 would mean 2^0 or 1, which is the current behavior. More > restrictive alignment requirements could be encoded easily. No ABI or > API change needed. > > #define RF_ALIGNMENT_MASK 0xfc00 > #define RF_ALIGNMENT_SHIFT10 > #define RF_ALIGNMENT_LOG2(x) (x << RF_ALIGNMENT_SHIFT) That seems reasonable. We should implement this right after 4.0 is done. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to allocate an alined address for a device?
On Fri, 28 Jan 2000, YAMAMOTO Shigeru wrote: > > >>>>> "Warner" == Warner Losh writes: > Warner> In a cardbus system, one would force the alignment in the card bus > Warner> bridge. It would reject those things that aren't aligned in a sane > Warner> manner for cardbus. It would try again to get a different range, if > Warner> possible, or would reject the attempt. > > I think it is no good to try again to get a different range. > Because, a different system has a different free address range and a device > dirver can not know where is a free address range. > > So I change rman_reserve_resource() in @src/sys/kern/subr_rman.c for we can > allocate an aligned address. > > My idea is using high bits of flags. > RF_ALIGN_XXX in aflags specifies an alignment request and an alignment > size. > Bad point of my idea is that we need to use a different bit for each an > alignment size. > > This is a patch for @src/sys/kern/subr_rman.c (rev. 1.10) and > @src/sys/sys/rman.h (rev. 1.5) > > Is my idea good or not? I'm uneasy about using the flags for this since I'm vaguely reserving the upper 16 bits of flags for bus-specific purposes (although I haven't formalised this). For allocating aligned regions with pnp, I simply looped in the caller trying each specific range until one was free (see isa_find_port() in isa_common.c). This is ugly but it does work. In the long run, I think we need either an extra parameter to rman_reserve_resource() or a new api rman_reserve_resource_aligned(). This also implies changing the method BUS_ALLOC_RESOURCE() or adding BUS_ALLOC_RESOURCE_ALIGNED(). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Use of newbus in sys/pci/pci.c
On Sat, 15 Jan 2000, Michael Kennett wrote:
> Hello All,
>
> I have a question on the sys/pci/pci.c code, and its use of the
> newbus architecture. An example of the code in question is:
>
> static struct resource *
> pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
> u_long start, u_long end, u_long count, u_int flags)
> {
> struct pci_devinfo *dinfo = device_get_ivars(child);
> ^ Looks wrong
> struct resource_list *rl = &dinfo->resources;
>
> return resource_list_alloc(rl, dev, child, type, rid,
> start, end, count, flags);
> }
>
> I don't understand the line that extracts the ivars from the child
> device. Isn't it the case that the ivars are a property of the bus
> device (dev)? In any case, the child device might not be directly
> descended from the pci bus (e.g. it could be attached thru' the
> bridge isab0: ).
The ivars are for bus-specific per-child information. The resource
locations for pci devices fall into this category and the information is
stored in a pci-private structure in the child device's ivars field.
This code is slightly dubious for the case when child isn't a direct
descendant of dev (i.e. a grandchild etc). In this case, the ivars pointer
would be read but not indirected through since the first thing
resource_list_alloc() does is check for this and pass the allocation up
the tree. It should be safe but its certainly dubious.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: GLIDE for FreeBSD
On Fri, 24 Dec 1999, Theo van Klaveren wrote: > > Whew. After two late nights of furious hacking, you > can now download the modified source for Glide 2.46 > (the Voodoo Graphics version) at > > ftp://phoenix.student.utwente.nl/pub/glide > > Note: I have completely hacked the source to bits > to achieve this. The source has been autoconf'ed > (scary, but at least it works, which cannot be said > of the build system 3DFX provided). All source files > needed for FreeBSD compilation have been included, > but Windows-compilation etc. have been dropped. > > I'd be more than happy to accept patches which'll > make it compile on other platforms again, but chances > are you'll have to get the neccesary files from the > original source file. > > Also, binaries of GLIDE and Mesa+glide > are available for FreeBSD-CURRENT. > > The GLIDE library has one bug, though: When quitting > an application, it won't restore the normal display. > If anyone can help me with this, that'd be GREAT! > > One last question: What are the chances of incorporating > the sources for Voodoo2/3 into one source tree? They > all have the swlibs/ directory (almost unchanged)... The cvs repository at sourceforge already has both the V2 and V3 sources in it. That is just the Glide 3 sources though. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about GLIDE...u
On Thu, 23 Dec 1999, Andrew Kenneth Milton wrote: > +----[ Doug Rabson ]- > | On Wed, 22 Dec 1999, Theo van Klaveren wrote: > | > | I already ported the voodoo2 sources for Glide 2.x and Glide 3.x. You can > | find patches at: > | > | http://www.freebsd.org/~dfr/Glide-V2-2.53.diff > | http://www.freebsd.org/~dfr/Glide-V2-3.01.diff > > I have an old Voodo Graphics card, I've seen people talking about > V2 and V3, is that because the Voodoo 1 is not going to work, or > because noone else has crappy hardware like me? d8) > > If it's not going to work, I guess I can bite the bullet and get a V3. I don't have a v1. I'm sure it would work pretty easily though. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about GLIDE...
On Thu, 23 Dec 1999, Theo van Klaveren wrote: > On Thu, 23 Dec 1999, Doug Rabson wrote: > > > On Thu, 23 Dec 1999, Julian Elischer wrote: > > > > Thats right. Another gotcha with the Glide code is that it uses the Linux > > convention for outx(), i.e. outb(val, port) where we use outb(port, val). > > That had me going for an hour or two.. > > Ah-ha, thanks for mentioning that! What had me going for an hour or so > was not noticing that they didn't supply the '-c' to install, which caused > the header files to be moved OUT of the source tree on the first build > pass :) Hehe. I had that too :-) > > > > > Seriously, look at my diffs. I ran all the tests and they produced the > > same results as for Linux. I was planning to work with the folks at > > glide.sourceforge.net next year to get the FreeBSD bits integrated with > > their source base. > > That'd be a Good Thing. Seriously though, the patchwork I'm creating here > is NOT meant to be integrated in the source tree (it's _UGLY_)... I'd be > glad to help in any such porting work though. > > B.t.w. I noticed the assembly files are preprocessed with gasp piped > through to as, which generates an empty object file because gasp isn't > on my system. It also isn't in the ports. Anyone know where to get it? I added it to the -current build a couple of weeks ago when I was working on Glide. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about GLIDE...
On Thu, 23 Dec 1999, Julian Elischer wrote:
> Theo,
>
> Though doug didn't say so, I think the equivalent code in freeBSD is
>
> if ((fd = open("/dev/io",O_RDWR,0)) == -1) {
> ERROR...
> }
>
> you are asking for permission to do direct IO to IO ports from userland.
>
> man 4 io
Thats right. Another gotcha with the Glide code is that it uses the Linux
convention for outx(), i.e. outb(val, port) where we use outb(port, val).
That had me going for an hour or two..
Seriously, look at my diffs. I ran all the tests and they produced the
same results as for Linux. I was planning to work with the folks at
glide.sourceforge.net next year to get the FreeBSD bits integrated with
their source base.
In the mean time, I'm looking for someone to generate a port or two for
glide..
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Question about GLIDE...
On Wed, 22 Dec 1999, Theo van Klaveren wrote:
> Hello,
>
> I am in the process of porting the GLIDE library to FreeBSD/i386
> which is making good progress so far. My worst enemy has been the
> build system itself and the huge amount if `#ifdef __linux__' in
> the code.
>
> I am doing this in the light of the Quake source code
> release, which I'd like to play natively with 3dFX hardware... :)
> (for the interested: I have already gotten the server and X11
> client to build, but I haven't tested them yet.)
>
> My question is about this particular piece of code in
> swlibs/fxpci/pcilib/fxlinux.c, around line 70:
>
> if (iopl(3)<0) {
> pciErrorCode = PCI_ERR_NO_IO_PERM;
> return FXFALSE;
> }
>
> Does anyone know what 'iopl(3)' is supposed to do,
> and what it's equivalent on FreeBSD is (if at
> all available)?
>
> The code this is in is about opening the /dev/3dfx device
> (which is not available for FreeBSD so it'll fail anyway),
> so I _could_ just remove it, but I'm not so certain...
>
> Also, IANAL, so could anyone tell me if the 3DFX license
> permits me to publish my patches under a BSD-style license?
I already ported the voodoo2 sources for Glide 2.x and Glide 3.x. You can
find patches at:
http://www.freebsd.org/~dfr/Glide-V2-2.53.diff
http://www.freebsd.org/~dfr/Glide-V2-3.01.diff
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Cool little 100BaseTX switch - they're coming down in price
On Sat, 18 Dec 1999, Tim Tsai wrote: > > hub. It works fine except that it hangs occasionally (can be > > reset by power-cycling). > > Most of these can be attributed to the crappy wall wart they call a > power supply. If it's plugged into an UPS or replace it with your own DC > power supply they generally hold up a lot better. > > I have a Netgear FS108 at home (8 port 10/100 switch) and I've found > Netgear stuff to be as cheap as I would go and still be reasonably > reliable. That rings a bell. I had a D-Link 4 port hub and I went through about 4 power supplies before I gave up, binned it and bought a Netgear. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aout gdb in 3.x
On Sun, 19 Dec 1999, Greg Lehey wrote: > On Saturday, 18 December 1999 at 14:51:59 +0000, Doug Rabson wrote: > > On Fri, 17 Dec 1999, Julian Elischer wrote: > > > >> > >> How does one compile a version of GDB that can read a.out files? > >> I know there is a way of doing it but I have totoally failed to work > >> out how to do so. > > > > I think you can do this by changing src/gnu/usr.bin/binutils/gdb/Makefile. > > Change: > > > > CFLAGS += -DFREEBSD_ELF > > > > to set FREEBSD_AOUT instead. > > I thought it used to be possible for gdb to recognize multiple > formats. Is this no longer the case? I think that most of gdb can cope with both a.out and elf. The main problem is the shared library support which has ifdefs all over it to cope with the differences between SunOS and SVR4 shared libs. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dynamic sysctls (Re: Per CPU timekeeping for SMP)
On Fri, 17 Dec 1999, Zhihui Zhang wrote: > > On Fri, 17 Dec 1999, Andrzej Bialecki wrote: > > > On Fri, 17 Dec 1999, Arun Sharma wrote: > > > > > I have also figured out how to dynamically register sysctl nodes. > > > The trick is to basically malloc a sysctl_oid and fill in the right > > > fields and calling sysctl_register_oid. The code is in a kernel > > > module available from: > > > > > > http://sharmas.dhs.org/~adsharma/projects/freebsd/sysctl.tar.gz > > > > > > It really needs to go into the base kernel. Also, I think > > > sysctl_register_long and its yet to be written friends (register_int) > > > etc, need to go into kern_sysctl - so that others can reuse the code > > > to dynamically create sysctl nodes. > > > > Can this patch be applied to FreeBSD 3.3-Release? If so, is it difficult > to do so? You would need to port the dynamic sysctl work first. In principle it isn't difficult but it affects quite a few files other than the core sysctl code itself. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aout gdb in 3.x
On Fri, 17 Dec 1999, Julian Elischer wrote: > > How does one compile a version of GDB that can read a.out files? > I know there is a way of doing it but I have totoally failed to work > out how to do so. I think you can do this by changing src/gnu/usr.bin/binutils/gdb/Makefile. Change: CFLAGS += -DFREEBSD_ELF to set FREEBSD_AOUT instead. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Glide source available
On Tue, 7 Dec 1999, Doug Rabson wrote: > On Tue, 7 Dec 1999, Stephen Hocking-Senior Programmer PGS Perth wrote: > > > > > Go look at http://linux.3dfx.com/open_source > > It's availabe for Voodoo 1, 2, & 3 cards. Register level specs too! I'm > > utterly freaked out. > > Its pretty cool. I spent some time hacking the Voodoo2 sources today and I > ported both the glide2x and glide3x libraries. I managed to run all the > tests but haven't run anything substantial. Patches at: > > http://www.freebsd.org/~dfr/Glide-V2-2.53.diff > http://www.freebsd.org/~dfr/Glide-V2-3.01.diff > > If someone can take these and maybe roll them into a couple of ports, I > would be grateful. I just remembered that a couple of files are missing from the 3.01 diff. I'll regenerate that today. To build 2.53, you will need gasp. I added gasp to the build yesterday but I mucked it up. I'll fix that too shortly and you will be able to install gasp by 'make all install' in src/gnu/usr.bin/binutils followed by src/usr.bin/objformat (which I also forgot to commit). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI DMA lockups in 3.2 (3.3 maybe?)
On Tue, 7 Dec 1999, Peter Wemm wrote: > Ed Hall wrote: > > : you wrote: > > : : I wrote: > > : :4) Using a different SCSI driver (Peter managed to get a driver from 4.0 > > : : hooked up under 3.3, and it survived two days of torture that would > > : : have toasted things within an hour using the stock driver; you'll have > > : : to ask him for details). > > : > > : Ed, this is great stuff! > > : > > : Are you sure about #4? Is that the same ncr.c driver or something > > : else? There are only a few differences between the 3.x and 4.x > > : /usr/src/sys/pci/ncr.c drivers. Which Peter, Peter Wemm? > > > > It was Peter Wemm. I may be misunderstanding just what he did--trying > > the 4.0 driver was just one several experiments he proposed and > > performed. And saying that it "worked" is provisional; two days of > > testing strongly suggests that it reduced the problem with 3.3 to > > acceptible levels for my application. Is it truly a "fix?" I don't > > know. > > > > -Ed > > I might add that others have found that using sym + fxp on the N440BX > motherboards didn't solve their problems, or moved the problem elsewhere, > eg: to the sbdrop() etc routines. One other interesting variable.. an ahc > + pn driver combination on a 440BX motherboard under -current in late may > 99 had the exact same problems we saw a number of times with ncr + fxp (ie: > sbdrop, sbflush, m_copym etc panics). The same motherboard with ahc + de or > fxp did not have the problems. > > In all cases the panics were extremely "strange". The original fxp+ncr > combination changed it's crash pattern when we put extra debugging in it to > sanity check and check conditions. The results varied from registers getting > clobbered (as though an interrupt happened and the trapframe on the stack got > changed by the interrupt handler and then returned with garbage contents in > some registers.. this is what seems to be happening in the fxp_add_rfabuf() > panics - %esi was getting loaded earlier on and when it got to do the > vtophys() it was zero. People have printed the contents of "rfa" on the stack > and seen garbage - in fact it's a register variable under normal circumstances. > Adding debugging caused it to be stored in the local variable rather than > being left in %esi, and then the panics moved elsewhere (!).) > > It had the markings of "something trashing something somewhere and then crashing > quite a bit later". :-( Has anyone tried fiddling with the latency timer on either fxp or ncr (or both)? -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Glide source available
On Tue, 7 Dec 1999, Stephen Hocking-Senior Programmer PGS Perth wrote: > > Go look at http://linux.3dfx.com/open_source > It's availabe for Voodoo 1, 2, & 3 cards. Register level specs too! I'm > utterly freaked out. Its pretty cool. I spent some time hacking the Voodoo2 sources today and I ported both the glide2x and glide3x libraries. I managed to run all the tests but haven't run anything substantial. Patches at: http://www.freebsd.org/~dfr/Glide-V2-2.53.diff http://www.freebsd.org/~dfr/Glide-V2-3.01.diff If someone can take these and maybe roll them into a couple of ports, I would be grateful. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: question on lkm / kld in 3.3-RELEASE or later
On Fri, 3 Dec 1999 [EMAIL PROTECTED] wrote:
> It seems that lkm is no longer working after 3.3, it complains regardless
> the mod is compiled in aout or elf (setenv OBJFORMAT before doing compiling):
>
> # modload -ezatm_mod /lkm/znatmdrv.o
> ld: /kernel: malformed input file (not rel or archive)
> modload: /usr/bin/ld: return code 1
>
> So, it looks like that kld is the way to go. However, there is no
> miscellaneous module under kld (/usr/share/examples/kld/{cdev, syscall}).
> Below is some comment in kld/cdev/module/cdevmod.c, It says that cdev
> module is "a miscellaneous module".
>
> Will kld provide a miscellaneous module in the future? or miscellaneous
> module is merged with cdev module?
>
> Thanks for any information,
There aren't any specific module types for KLD. Basically, we just run all
the SYSINITs in the code which is loaded. Virtually anything can be built
from that and we have provided hooks for registering filesystems, devices,
syscalls, etc. To do something else, just use a SYSINIT to call a custom
initialisation function of your own.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
On Tue, 30 Nov 1999, Dan Moschuk wrote: > > | I reviewed the NFSv4 specs recently and came to the same conclusion. To do > | it right will be quite a bit of work and would include a decent kernel > | side implementation of rpc and gssapi. > > Cool! I can take that "I volunteer" ? :-) Not with my current workload :-(. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Ok, that's it, enough is enough! (rpc.lockd)
On Mon, 29 Nov 1999, Dan Moschuk wrote: > > | >I'm fairly certain that rpc.lockd is included with Darwin from Apple, > | >I've not closely compared it to what we have in -STABLE or -CURRENT > | >to see if it actually works. > | > | It doesn't, sorry... if someone gets a *BSD version of NFS locking operating > | I'd help see it into Darwin. > | > | BTW, is anyone working on NFS Version 4 for BSD? Rick? > > A few of us talked about this on IRC a few weeks ago and it was decided that > when/if we implement NFSv4 it would have to be from scratch. A pretty big > task. I reviewed the NFSv4 specs recently and came to the same conclusion. To do it right will be quite a bit of work and would include a decent kernel side implementation of rpc and gssapi. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ANNOUNCE: VMware 1.1 for Linux on the FreeBSD
On Sat, 27 Nov 1999, Vladimir N. Silyaev wrote: > Hi, > > At this time I can successful run the VMware 1.1 for Linux on the FreeBSD. > It could be used to run Linux on the FreeBSD box, or to run another FreeBSD > on the same box. Of course you can run some piece of Microsoft products: > MS DOS, Windows 9X, Windows NT and etc. You can download the port > (NOTE: -current only) from: > > http://www.mindspring.com/~vsilyaev/vmware/vmware.tar.gz > > > Some more information about this port available at: > http://www.mindspring.com/~vsilyaev/vmware/ > > General information about VMware available at: > http://www.vmware.com > > > Vladimir N. Silyaev Well done indeed! This is excellent work! -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Set the baud rate on remote debugging
On Tue, 16 Nov 1999, Greg Lehey wrote: > On Monday, 15 November 1999 at 16:46:50 -0500, Zhihui Zhang wrote: > > > > On Mon, 15 Nov 1999, Greg Lehey wrote: > > > >> On Monday, 15 November 1999 at 15:13:53 -0700, Kenneth D. Merry wrote: > >>> Zhihui Zhang wrote... > >>>> > >>>> I have set up a remote debugging environment. But I think default 9600 > >>>> bps is slow. I can use "set remotebaud 19200" on the debugging machine > >>>> side. How can I set the baud rate on the target machine that is running > >>>> the debugged kernel? (I press CTRL+ESC+ALT to drop to DDB mode and find > >>>> no command to set the baud rate). > >>>> > >>>> Any help is appreciated. > >>> > >>> Use the CONSPEED option in the kernel config file on the target machine. > >>> e.g.: > >>> > >>> options CONSPEED=115200 > >> > >> I'm planning to modify ddb to specify the bit rate as a parameter to > >> the gdb command: > >> > >> db> gdb 19200 > >> Next trap will enter GDB remote protocol mode at 19200 bps > >> > >> Comments? > >> > > > > That will be useful. I have just found out that I can use sysctl -w > > machdep.conspeed=19200 to achieve this. But I can not go higher than > > 19200. > > I set 38400 today, but it ran very badly. I think 19200 is probably > as high as you want to go, at least until somebody fixes the buffering > in the UARTs. I've always used 57600 and it seems to work fine... -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Using non-PIC code in shared libraries?
On 9 Nov 1999, Assar Westerlund wrote:
> Nate Williams <[EMAIL PROTECTED]> writes:
> > How about the reverse, where you link in PIC compiled libraries into
> > static (.a) libraries? Does this work?
>
> Sure. Look at how lib${LIB}_pic.a is done i . PIC-code
> is less efficient than non-PIC code.
True for x86. For alpha, all code is PIC but the extra registers available
reduce the overhead considerably.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ARM support
On Mon, 8 Nov 1999, Daniel C. Sobral wrote: > "Stephane E. Potvin" wrote: > > > > Unfortunately no. It uses a stripped down linux kernel as firmware. > > In that case the source code is available, yes? > > M... have you tried ext2fs? Doesn't the netwinder support netbooting? If so, that is certainly the best environment for kernel porting. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Limitations in FreeBSD
On Mon, 8 Nov 1999, Mike Smith wrote: > > * Matthew Dillon > > | FreeBSD boxes can handle up to 4 Gigabytes of main memory. > > > > Is this true for the Alpha kernels too? > > There are issues with > 1GB of RAM on Alphas at the moment, which may > be easier to resolve soon. We have a 4100 with 1GB, which should be > upgraded to 1.5 shortly and which will be available for various people > to beat on at that point. As a special case, we support xp1000 and ds20 class alphas with upto 2G of memory (not actually tested). The real fix which will allow essentially unbounded memory size (dependant on hardware limits) will happen on the 4100. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ARM support
On Sun, 7 Nov 1999, Stephane E. Potvin wrote: > To whoever that may interest, I've now got a nearly working freebsd > loader for the NetWinder. It currently only uses the serial console and > miss internal hard driver support but work is underway for both these > issues. > > I'm making some progress too in getting world to compile but work in > this area is more slower as I've got no way to test what I compile and > I'm not that at ease with most of the code. Hey, good work! If you have any questions on porting the kernel, don't hesitate to contact me. I also have a fair knowledge of ARM too, although its a bit dated (the last ARM machine I owned was an ARM3). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip forwarding broken on alpha
On Thu, 28 Oct 1999, Jason Thorpe wrote: > On Thu, 28 Oct 1999 21:32:51 -0400 (EDT) > Andrew Gallatin <[EMAIL PROTECTED]> wrote: > > > exception_return & skipped the ipl lowering & the check for an ast > > since I don't think you're ever going to need to check for an ast > > after an interrupt. > > Nonsense. ASTs are a key part of process scheduling, and I'd bet that > you run into strange scheduling behaviour if you don't deal with ASTs > after e.g. clock interrupts. Thats correct. The problem is that we are calling the AST with interrupts enabled which allows unbounded interrupt recursion. This is true in NetBSD (at least in version 1.60 of locore.s) as well. The whole idea of ASTs and SWIs is an awful hangover from the VAX; there must be a better way. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ip forwarding broken on alpha
On Thu, 28 Oct 1999, Andrew Gallatin wrote:
>
> Andrew Gallatin writes:
> >
> > I have an older AlphaStation 600 5/266 running -current (cvsupped
> > last week) which is setup as a router between 2 100mb networks. When
> > the machine is pushed fairly hard (like running a netperf -tUDP_STREAM
> > -- -m 100 across the router, eg about 10-20k 100byte packets/sec ) the
> > alpha falls over almost instantly. I have not enabled any NAT or
> > firewall functionality, just ip forwarding.
>
> <...>
>
> >
> > This might be a red herring, but I've found that if I run the entire
> > ip_input path under splnet() (added splnet() around the call to
> > ip_input() in ipintr().), things get a hell of a lot more stable.
> > Rather than crashing in a few seconds, it sometimes takes minutes.
> > And rather than an illegal access, I tend to run out of kernel stack
> > space ( either a panic("possible stack overflow\n"); in
> > alpha/alpha/interrupt.c, or I end up in the SRM console after calling
> > halt from a PC which isn't in the kernel, which smells like an overrun
> > stack to me). I'm not sure if this is related, or if it is a separate
> > problem entirely.
>
> That was it.
>
> The problem is that the interrupt handler returns through
> exception_return, like the trap handler does. Exception_return checks
> to see if the last ipl the system was at was 0. If it was, it
> eventually lowers the ipl to zero and checks for a pending ast. This
> was the problem. If you're getting interrupts quickly enough, there's
> large window when you're still running on the interrupt stack where
> you're sitting at ipl0 and you can get another interrupt & build onto
> that stack. If you're getting 40,000 interrupts per second
> (forwarding 20,000 packets/sec), this can build up & rapidly run you
> out of stack space.
>
> I've found the system can forward 70,000 packets per second & remain
> perfectly stable with the appended patch. I'm not terribly good at
> assembler, so rather than try to be tricky & check to see if the
> current ipl is >= 4 (handling a device interrupt), I simply copied
> exception_return & skipped the ipl lowering & the check for an ast
> since I don't think you're ever going to need to check for an ast
> after an interrupt.
>
> I have NFC why mclfree was getting trashed, but it must have been
> caused by running out of stack space as the appended patch seems to
> take care of everything.
>
> Doug -- should I commit this as-is, or do you want to take a more
> refined approach?
I think the intention of ASTs is that they are generated whenever you are
returning to user mode. This patch will essentially defer the AST until
the next system call which might be unacceptable.
I can see the window and its a serious problem but I'm worried about
fixing it in this way. What I really want is some way to generate a 'real'
AST after the PALcode has dropped the exception frame for the interrupt.
Without changing to use the VMS palcode, we aren't going to get that
though :-). (ASTs and SWIs are derived from the way VAXen work and the VMS
palcode emulates the old vax behaviour).
The main problem as I see it is that we are dropping the IPL to zero
before calling the ast. I don't see why we are doing this at all. We
should be able to just call the ast without changing the ipl at all. This
still leaves a window in do_sir (which lowers the IPL to 1) though.
Perhaps, SWIs should be handled by using another kernel thread which can
be switched to instead of calling do_sir. I have to think about that some
more. Could you test just removing the swpipl(0) code and see if it
improves things, thanks.
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ISA Plug 'n Play support / kernel -c bug / IETF
On Fri, 15 Oct 1999, Graham Wheeler wrote: > Hi all > > While PCI plug 'n play devices seem to work nicely with FreeBSD, we find > that ISA ones are not detected and that we have to configure them as though > they are not plug 'n play. Is the pnp0 controller in the kernel config for PCI > only? Or is there a way to get the ISA ones to be automagically detected > upon bootup? Maybe with some BIOS tweak? 4.0 will have a complete PnP system, including automagic detection and configuration, support for pnpbios (and probably acpi). The code is in -current now and being tested. By the time 4.0 ships we should have enough drivers so that you can have a kernel config with *no* custom settings at all and it will detect all your hardware magically. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Symbols and klds
On Tue, 12 Oct 1999, Warner Losh wrote: > > How does one tell ddb about dynamic modules? I've had a couple of > crashes in my code where I've needed symbols from things dynamically > loaded... Does gdb grok them any better? > I thought ddb was supposed to know about them already but perhaps that only works for pre-loaded modules. GDB can be forced to see them but its tricky - Greg Lehey has some gdb macros to help him get vinum into GDB. One thing I would like to do with GDB (if I ever get to it) is to fake up the data structures which it expects to see from ld.so so that it can walk our module list directly. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Netscape Bus Error
On Tue, 28 Sep 1999, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Darren R. Davis <[EMAIL PROTECTED]> wrote: > > > I believe that a Bus Error is specifically referencing miss aligned > > data vs segmentation violation (SIGSEGV) which is accessing data > > that is either free'd or not yours, etc. > > That was the traditional distinction, but it's different on > FreeBSD/i386. SIGSEGV means you accessed memory that is unmapped. > SIGBUS means you accessed memory that is mapped, but protected > (unwritable and/or unreadable). To further confuse matters, > FreeBSD/alpha generates SIGSEGV for both cases. And it generates SIGBUS for unaligned accesses (when traps for that are enabled). -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 2.88Mb floppies
On Mon, 27 Sep 1999, Wilko Bulte wrote:
> Hi there,
>
> Just having installed a 2.88Mb floppy drive in one of my axp boxes
> I wonder if FreeBSD can do 2.88Mb floppy disks. From the looks
> of the contents of /sys/i386/isa/fd.c:
>
> static struct fd_type fd_types[NUMTYPES] =
> {
> { 21,2,0xFF,0x04,82,3444,1,FDC_500KBPS,2,0x0C,2 }, /* 1.72M in HD 3.5in */
> { 18,2,0xFF,0x1B,82,2952,1,FDC_500KBPS,2,0x6C,1 }, /* 1.48M in HD 3.5in */
> { 18,2,0xFF,0x1B,80,2880,1,FDC_500KBPS,2,0x6C,1 }, /* 1.44M in HD 3.5in */
>
> it appears it cannot.
>
> Is this true? Is there anything that stops one from adding an appropriate
> line to this struct? And to dev/MAKEDEV of course?
I have no idea whether that driver can cope with 2.88mb floppies to be
honest. There is only one way to find out...
--
Doug Rabson Mail: [EMAIL PROTECTED]
Nonlinear Systems Ltd. Phone: +44 181 442 9037
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: TLB miss handler for alpha running FreeBSD-4.0
On Thu, 16 Sep 1999, Mohit Aron wrote: > Hi, > as I understand it, TLB misses on the alpha are handled by the > software (as opposed to x86 where they are handled in hardware). Can someone > help me with the FreeBSD code. I'm trying to locate the kernel code that > implements the TLB handler. I'd appreciate if someone can tell me how the > control is given to the software (i.e. what trap is generated), how the > handler is called and finally how does the control return back. Thanks, TLB misses are handled by the PALcode on the alpha (which is often part of the firmware). There is no trap handler in the FreeBSD code which needs to handle TLB misses as the PALcode deals with it transparently. PALcode is 'special' software which runs at a higher privilege level than the kernel and handles low-level traps, interrupts, etc., translating them into a standard form for the kernel's consumption. If a later processor revision needs different handling for low-level issues, it will use a different PALcode but will generally present the same interface to the kernel. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: TLB miss handler for alpha running FreeBSD-4.0
On Thu, 16 Sep 1999, Mohit Aron wrote: > Hi, > as I understand it, TLB misses on the alpha are handled by the > software (as opposed to x86 where they are handled in hardware). Can someone > help me with the FreeBSD code. I'm trying to locate the kernel code that > implements the TLB handler. I'd appreciate if someone can tell me how the > control is given to the software (i.e. what trap is generated), how the > handler is called and finally how does the control return back. Thanks, TLB misses are handled by the PALcode on the alpha (which is often part of the firmware). There is no trap handler in the FreeBSD code which needs to handle TLB misses as the PALcode deals with it transparently. PALcode is 'special' software which runs at a higher privilege level than the kernel and handles low-level traps, interrupts, etc., translating them into a standard form for the kernel's consumption. If a later processor revision needs different handling for low-level issues, it will use a different PALcode but will generally present the same interface to the kernel. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: does gdb on 3.3RC have thread support? (fwd)
On Wed, 15 Sep 1999, Daniel Eischen wrote: > > Thanks, I figured as much. I just thought I remember being told at one > > point that gdb's thread support on FreeBSD had improved. Given a choice > > between adding thread support to GDB myself and developing my application > > on NT, which by the way has very good thread debugging support on MSVC6.0. > > I think I would rather just spend a weekend adding support to GDB. > > Search the mailing list archives. Doug Rabson had already done most > of the work to make FreeBSDs gdb thread-aware. It hasn't been committed, > but diffs were submitted to one of the mailing lists (probably -hackers > or -current). Unfortunately, I had to drop this for a while to fight fires in other places. There is a small amount of work to do to make the gdb interface more robust in the face of changes to the uthread structures but even without that, my current set of patches seem to work fairly well. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: does gdb on 3.3RC have thread support? (fwd)
On Wed, 15 Sep 1999, Daniel Eischen wrote: > > Thanks, I figured as much. I just thought I remember being told at one > > point that gdb's thread support on FreeBSD had improved. Given a choice > > between adding thread support to GDB myself and developing my application > > on NT, which by the way has very good thread debugging support on MSVC6.0. > > I think I would rather just spend a weekend adding support to GDB. > > Search the mailing list archives. Doug Rabson had already done most > of the work to make FreeBSDs gdb thread-aware. It hasn't been committed, > but diffs were submitted to one of the mailing lists (probably -hackers > or -current). Unfortunately, I had to drop this for a while to fight fires in other places. There is a small amount of work to do to make the gdb interface more robust in the face of changes to the uthread structures but even without that, my current set of patches seem to work fairly well. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS authentication
On Tue, 14 Sep 1999, Alfred Perlstein wrote: > > On Tue, 14 Sep 1999, Doug Rabson wrote: > > > On Mon, 13 Sep 1999, Zhihui Zhang wrote: > > > > > > > > I am wondering where the NFS authentication is done in FreeBSD. Is it done > > > by the NFS daemon mountd (or other daemon) or within the kernel? Can > > > anyone give me a pointer? Thanks a lot. > > > > Kerberos authentication is done by nfsd. The kernel returns ENEEDAUTH from > > the nfssvc() call and nfsd does the authentication, passing the results > > back via nfssvc(). I don't think this code is actually used by anyone so > > there is a strong possibility that it doesn't work at all. > > nfs_socket.c:#ifdef NFSKERB > nfs_socket.c- XXX > nfs_socket.c-#endif > > There is some work already there, it's just incomplete. I have a feeling that it was once complete but was ripped out for crypto-export reasons. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS authentication
On Tue, 14 Sep 1999, Alfred Perlstein wrote: > > On Tue, 14 Sep 1999, Doug Rabson wrote: > > > On Mon, 13 Sep 1999, Zhihui Zhang wrote: > > > > > > > > I am wondering where the NFS authentication is done in FreeBSD. Is it done > > > by the NFS daemon mountd (or other daemon) or within the kernel? Can > > > anyone give me a pointer? Thanks a lot. > > > > Kerberos authentication is done by nfsd. The kernel returns ENEEDAUTH from > > the nfssvc() call and nfsd does the authentication, passing the results > > back via nfssvc(). I don't think this code is actually used by anyone so > > there is a strong possibility that it doesn't work at all. > > nfs_socket.c:#ifdef NFSKERB > nfs_socket.c- XXX > nfs_socket.c-#endif > > There is some work already there, it's just incomplete. I have a feeling that it was once complete but was ripped out for crypto-export reasons. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS authentication
On Mon, 13 Sep 1999, Zhihui Zhang wrote: > > I am wondering where the NFS authentication is done in FreeBSD. Is it done > by the NFS daemon mountd (or other daemon) or within the kernel? Can > anyone give me a pointer? Thanks a lot. Kerberos authentication is done by nfsd. The kernel returns ENEEDAUTH from the nfssvc() call and nfsd does the authentication, passing the results back via nfssvc(). I don't think this code is actually used by anyone so there is a strong possibility that it doesn't work at all. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NFS authentication
On Mon, 13 Sep 1999, Zhihui Zhang wrote: > > I am wondering where the NFS authentication is done in FreeBSD. Is it done > by the NFS daemon mountd (or other daemon) or within the kernel? Can > anyone give me a pointer? Thanks a lot. Kerberos authentication is done by nfsd. The kernel returns ENEEDAUTH from the nfssvc() call and nfsd does the authentication, passing the results back via nfssvc(). I don't think this code is actually used by anyone so there is a strong possibility that it doesn't work at all. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Warner Losh wrote: > In message <199909051942.oaa42...@celery.dragondata.com> Kevin Day writes: > : No, I'm working on adding support for PCI based non-winmodems. Modems that > : still have a 16550 based uart interface to them, but just happen to sit on > : the PCI bus. I'm not at all planning on writing support for winmodems, just > : making sio.c understand UARTs on the PCI bus. > : > : There *are* PCI modems out there that aren't winmodems, they're just hard to > : find. 3Com makes one, as well as a few other companies. > > SIO doesn't support anything but isa attachments right now. Its probe > and attach routines need to be corrected to not be ISA specific. I think I will tackle that soon. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Matthew N. Dodd wrote: > On Sun, 5 Sep 1999, Kevin Day wrote: > > I'm actually going to look at doing this tommorow, but I have to admit > > the sio driver isn't really going to like doing this. Has anyone > > looked at this before and could possibly give any suggestions as to > > how I should begin this? > > It looks really ugly. > > The real problem is the 'isa_get_foo()' calls that are used. I've got a > small start of splitting out the ISA bits from the probe/attach routines > but I'm really not sure what the best way to solve these issues is. > (They're the same issues I'm dealing with on the if_ed driver...) I have a plan for this. The isa_get_flags() stuff is going to change to device_get_flags() and the rest can use the ISA_GET/SET_RESOURCE methods which could be implemented by pccard as well. For PCI, we need to change the probe slightly to pass the RID for the port resource (always zero for isa but normally nonzero for pci). In this case, the GET/SET_RESOURCE methods probably won't be needed since they are just used for the multiport kluge. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Kevin Day writes: > : No, I'm working on adding support for PCI based non-winmodems. Modems that > : still have a 16550 based uart interface to them, but just happen to sit on > : the PCI bus. I'm not at all planning on writing support for winmodems, just > : making sio.c understand UARTs on the PCI bus. > : > : There *are* PCI modems out there that aren't winmodems, they're just hard to > : find. 3Com makes one, as well as a few other companies. > > SIO doesn't support anything but isa attachments right now. Its probe > and attach routines need to be corrected to not be ISA specific. I think I will tackle that soon. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI modems do not work???
On Sun, 5 Sep 1999, Matthew N. Dodd wrote: > On Sun, 5 Sep 1999, Kevin Day wrote: > > I'm actually going to look at doing this tommorow, but I have to admit > > the sio driver isn't really going to like doing this. Has anyone > > looked at this before and could possibly give any suggestions as to > > how I should begin this? > > It looks really ugly. > > The real problem is the 'isa_get_foo()' calls that are used. I've got a > small start of splitting out the ISA bits from the probe/attach routines > but I'm really not sure what the best way to solve these issues is. > (They're the same issues I'm dealing with on the if_ed driver...) I have a plan for this. The isa_get_flags() stuff is going to change to device_get_flags() and the rest can use the ISA_GET/SET_RESOURCE methods which could be implemented by pccard as well. For PCI, we need to change the probe slightly to pass the RID for the port resource (always zero for isa but normally nonzero for pci). In this case, the GET/SET_RESOURCE methods probably won't be needed since they are just used for the multiport kluge. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UHCI / OHCI controller with no interrupt configured
On Sat, 4 Sep 1999, Nick Hibma wrote: > > In many BIOS's today you will have to switch on USB support. The > problem is to figure out whether or not this has been done. > > The irq in any case is something like 0 or 255 / -1. Is this a valid > testing method or is there a better way to see whether a PCI card has > been configured? The value 255 for intline represents "not configured" or "no interrupt". -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: UHCI / OHCI controller with no interrupt configured
On Sat, 4 Sep 1999, Nick Hibma wrote: > > In many BIOS's today you will have to switch on USB support. The > problem is to figure out whether or not this has been done. > > The irq in any case is something like 0 or 255 / -1. Is this a valid > testing method or is there a better way to see whether a PCI card has > been configured? The value 255 for intline represents "not configured" or "no interrupt". -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb and source forking
On Fri, 3 Sep 1999, Kip Macy wrote: > I have not looked closely, but it appears that the changes to bfd to > support the solib.c changes have been quite extensive. The diff of the > .c files in bfd/ is 7000 lines long. > > I know that interacting with the FSF can be unenjoyable but gdb compiles > and runs fine on all other OSs I have used. So if the solaris and linux > crowds can keep the modifications consistent why can't we? > Thanks for any insight. We have have not made any significant changes to bfd. We are using binutils-2.9.1 in our tree since 2.9.2 has not been released (gdb-4.18 was based on a snapshot of 2.9.2). The linux folks often just bundle patches with the gdb sources which is not much different from us importing FSF sources into our CVS tree. We can generate diffs from the virgin FSF sources very easily. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
