Re: bin/144214: zfsboot fails on gang block after upgrade to zfs v14
On 27 May 2010 16:13, Andriy Gapon a...@icyb.net.ua 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 a...@freebsd.org 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: message 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: message 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: 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 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: Where is FreeBSD going?
On Thu, 2004-01-08 at 18:05, Munish Chopra wrote: On 2004-01-08 17:29 +, 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: 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: 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 sigh. -- 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 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: 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: 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: 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 machine/rpb.h' - 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 KR. 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: 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: 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 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: 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: 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: 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: 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: 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: 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. URL: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: 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: yamaha japan relationships anyone?
On Sun, 20 Feb 2000, Karsten W. Rohrbach wrote: hi * this might be a little offtopic... clueless mode 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... /clueless mode 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: 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: 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 Warner 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: VIA 82C586 PCI-ISA bridge).
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: 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: 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 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...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: 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 +, 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: 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: 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: 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 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: 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: 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: 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 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: 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 bsd.lib.mk. 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 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, 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: [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
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: gdb and source forking
On Fri, 3 Sep 1999, Kip Macy wrote: I have been trying to apply some modifications to gdb but have noticed that FreeBSD has basically gone off on its own path with respect to gdb. Is there any intention pf getting these changes merged back in to the original distribution? It looks like it would be a lot of work. I don't think we have gone very far from the gdb-4.18 distribution. We have made some changes to solib.c to account for some peculiarities in our ld.so and there may be some other minor changes elsewhere. It would be some work to break out all our changes so that they can be invidually submitted to FSF. Assigning all the changes to FSF is about 10x the effort and I don't have much enthusiasm for 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: gdb and source forking
On Fri, 3 Sep 1999, Kip Macy wrote: I have been trying to apply some modifications to gdb but have noticed that FreeBSD has basically gone off on its own path with respect to gdb. Is there any intention pf getting these changes merged back in to the original distribution? It looks like it would be a lot of work. I don't think we have gone very far from the gdb-4.18 distribution. We have made some changes to solib.c to account for some peculiarities in our ld.so and there may be some other minor changes elsewhere. It would be some work to break out all our changes so that they can be invidually submitted to FSF. Assigning all the changes to FSF is about 10x the effort and I don't have much enthusiasm for it. -- 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: KAME IPv6 and freebsd
On Tue, 31 Aug 1999, Mark Murray wrote: I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. I would prefer src/sys/crypto. I tend to have a lot of kernel-only trees around for my work and the more self-contained they are the better. Moving softupdates into sys/crypto was a good thing (IMHO). -- 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: [mount.c]: Option user-patch
On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a "user"-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * [EMAIL PROTECTED] * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. -- 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: More than 32 signals. Thought?
On Mon, 30 Aug 1999, Francis Jordan wrote:
Marcel Moolenaar wrote:
[cc'd to David E. Cross ([EMAIL PROTECTED]) and James Raynard
([EMAIL PROTECTED])]
I'm thinking about extending the number of signals. I like your thoughts
and opinions.
Basicly what I'm going to do is rewrite the signalling code to use a new
sigset_t and provide new syscalls to use it. The current syscalls convert
between the current and the new types for compatibility. I think I'm going
to borrow a thought or two from Linux which allows further increasing of
the number of signals without rewriting the logic, but that's basicly
undecided yet and open for discussion.
Do as NetBSD does to remain compatible? Or borrow a few thoughts from
Solaris, which also has 128 signals:
typedef struct {/* signal set type */
unsigned long __sigbits[4];
} sigset_t;
Please be careful with your datatypes when formulating this. If you are
going to pack 32 signals into one field, make it u_int32_t, not int or
long.
--
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: KAME IPv6 and freebsd
On Tue, 31 Aug 1999, Mark Murray wrote: I'll be very happy to work with you on this one. Does it make sense to make src/crypto/sys for kernel code? (for IPsec we need crypto code *in kernel*). I wonder... There was a contrib/sys (where softupdates went), and that got moved to sys/contrib. Perhaps something similar could be invented for src/crypto? We'd need to make the distibution machinery understand that, but I don't see too much a problem there. I have no strong feelings about src/crypto/sys or src/sys/crypto. I would prefer src/sys/crypto. I tend to have a lot of kernel-only trees around for my work and the more self-contained they are the better. Moving softupdates into sys/crypto was a good thing (IMHO). -- 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: Intel Merced FreeBSD???
On Sat, 28 Aug 1999, Sergey Babkin wrote:
Mark Ovens wrote:
On Fri, Aug 27, 1999 at 08:45:31PM -0400, Sergey Babkin wrote:
A funny thing is that Microsoft is porting essentially a
32-bit version of Windows to Merced. All the programs for
Windows that want to use 64-bit support will have to be
modified because the MS compiler defines both int and long
as 32-bit. On the other hand the Unix compilers (at least
UnixWare and as far as I understood that's the common Unix
convention) provide a mode with 64-bit longs that gives
certain degree of 64-bit awareness just by recompiling.
marder-1:/usr/marko{57}% cat size.c
#include stdio.h
int main (void)
{
printf(short == %d\n, sizeof(short));
printf(int == %d\n, sizeof(int));
printf(long == %d\n, sizeof(long));
printf(long long == %d\n, sizeof(long long));
return(0);
}
^D
marder-1:/usr/marko{57}% cc !$
marder-1:/usr/marko{57}% ./a.out
short == 2
int == 4
long == 4
long long == 8
marder-1:/usr/marko{57}%
And the same is true on SunOS 4.1.x as well (although not 100% sure
about long long).
I was talking about compilers for the 64-bit machines. As far
as I understood to make porting easier the major Unix vendors
have agreed on 2 64-bit modes in addition to the compatibility
32-bit mode:
- 32-bit int, 32-bit long, 64-bit long long, 64-bit pointers
- 32-bit int, 64-bit long, 64-bit long long, 64-bit pointers
While the 64-bit Windows NT has 32-bit int, 32-bit long,
64-bit long long, 32-bit pointers, 64-bit some special
kind of pointers.
Oh my god, please say it isn't true! Its the return of the Large Model...
Much of my prejudices against Wintel were formed by trying to write
programs in the large model.
Although I may be confusing something.
I sure hope so.
--
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: readdir() broken?
On Sun, 29 Aug 1999, Bjoern Fischer wrote: Hello Doug, hello Matthew, hello list members, there are some hints that readdir() in -STABLE has problems when used on NFSv3 (UDP; and TCP probably, too) mounted file systems. The reason may be the recovery code for stale READDIR cookies. The problem occurs when using GNU rm (fileutils-4.0) on our systems (NFS servers and clients -STABLE) for deleting large directory trees (e.g. egcs source tree). rm failed to delete some directories: rm: cannot remove directory `egcs-1.1.2/gcc': Directory not empty I've roughly looked through the sources and found a workaround for a readdir() bug on SunOS 4.1.4. The SunOS readdir() sometimes returned NULL although there were still entries to be read when a directory with more than 254 entries was previously modified. The workaround rewound the directory stream and read it again. Interestingly this workaround also works for FreeBSD although our readdir() passes the autoconfig tests that trigger the workaround without a hinch. Attached is a patch for GNU fileutils-4.0 that will make rm yield when the workaround code catches a bad readdir(). Are you using a FreeBSD port for GNU fileutils? If so, your patch should be directed to the port maintainer. I suggest that you also forward the patch to the GNU fileutils maintainers. -- 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: [mount.c]: Option user-patch
On Mon, 30 Aug 1999, Andrew J. Korty wrote: I suppose there already was a rather lengthy discussion about a user-option . I hope this sysctl-thing will make it into the mount-manpage, because if not, it might turn out to be a really FAQ :) -- Volker Stolz * st...@pool.informatik.rwth-aachen.de * PGP I provided a solution via send-pr (bin/11031) over four months ago, which is, in my opinion, superior in many ways to this sysctl approach. The patch contains an amendment to the mount(1) manual page. I have not reviewed this pr myself but it seems like a well thought out change to the system. Would the people who are involved with the current (more limited) proposed change like to review this and possibly use it instead. I don't want to lose anyones work here if it could be useful. -- 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: More than 32 signals. Thought?
On Mon, 30 Aug 1999, Francis Jordan wrote:
Marcel Moolenaar wrote:
[cc'd to David E. Cross (cro...@cs.rpi.edu) and James Raynard
(jrayn...@freebsd.org)]
I'm thinking about extending the number of signals. I like your thoughts
and opinions.
Basicly what I'm going to do is rewrite the signalling code to use a new
sigset_t and provide new syscalls to use it. The current syscalls convert
between the current and the new types for compatibility. I think I'm going
to borrow a thought or two from Linux which allows further increasing of
the number of signals without rewriting the logic, but that's basicly
undecided yet and open for discussion.
Do as NetBSD does to remain compatible? Or borrow a few thoughts from
Solaris, which also has 128 signals:
typedef struct {/* signal set type */
unsigned long __sigbits[4];
} sigset_t;
Please be careful with your datatypes when formulating this. If you are
going to pack 32 signals into one field, make it u_int32_t, not int or
long.
--
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: Async NFS exports?
On Fri, 20 Aug 1999, Matthew Dillon wrote: : Just to be clear... I am wondering if mounting (on the NFS _server_) a : partition (that is exportable) as async will have any performance : benefits to the NFS clients? : :As a first guess, probably not unless you have a large number of active :clients. Any modern hard disc will outperform ethernet/fast ethernet, :especially for larger read/writes. For large numbers of smaller :operations, or when there is a large number of simultaneous outstanding :requests from clients, maybe. I'd say watch the disc itself (iostat is :your friend), and if it's pegged (especially large numbers of tps) async :might buy you some increase. :-- :Matthew Fuller (MF4839) |[EMAIL PROTECTED] Not much if at all, whether you have a large number of clients or not, at least if you are using NFSv3 mounts. The reason is due to the way NFSv3 issues writes. NFSv3 issues a write but no longer assumes that the write has been synced to the server's disk as of when the reply comes back. Instead it keeps the buffer around and does a later commit rpc to do the sync, presumably long after the server has already synced the data. So, effectively, all NFSv3 writes are async insofar as the client's buffer cache is able to keep abrest of the write-rate. Hmm, interesting. I see another optimization I can do to fix the buffer cache saturation case in CURRENT on the client. The COMMIT rpc's aren't being issued async. You need to track the return value of the commit so that you can detect server reboots and sync-write the data again. If you change to async, make sure that you still keep this part - its essential to the protocol. -- 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: Async NFS exports?
On Fri, 20 Aug 1999, Matthew Dillon wrote: : Just to be clear... I am wondering if mounting (on the NFS _server_) a : partition (that is exportable) as async will have any performance : benefits to the NFS clients? : :As a first guess, probably not unless you have a large number of active :clients. Any modern hard disc will outperform ethernet/fast ethernet, :especially for larger read/writes. For large numbers of smaller :operations, or when there is a large number of simultaneous outstanding :requests from clients, maybe. I'd say watch the disc itself (iostat is :your friend), and if it's pegged (especially large numbers of tps) async :might buy you some increase. :-- :Matthew Fuller (MF4839) |fulle...@over-yonder.net Not much if at all, whether you have a large number of clients or not, at least if you are using NFSv3 mounts. The reason is due to the way NFSv3 issues writes. NFSv3 issues a write but no longer assumes that the write has been synced to the server's disk as of when the reply comes back. Instead it keeps the buffer around and does a later commit rpc to do the sync, presumably long after the server has already synced the data. So, effectively, all NFSv3 writes are async insofar as the client's buffer cache is able to keep abrest of the write-rate. Hmm, interesting. I see another optimization I can do to fix the buffer cache saturation case in CURRENT on the client. The COMMIT rpc's aren't being issued async. You need to track the return value of the commit so that you can detect server reboots and sync-write the data again. If you change to async, make sure that you still keep this part - its essential to the protocol. -- 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
