IBM-DJNA drives on FreeBSD
I'm about to install FreeBSD 3.2 on a machine with an IBM-DJNA-371350 (Deskstar 22GXP 13.5GB) drive. I see that on the -current mailing list a few weeks ago you (phk) said: >Try disabling "ultra DMA" in the BIOS, that seems to have worked for >me on my IBM-DJNA-371800 drive. Is that relevant for 3.2 as well as current? And by "disabling ultra DMA" did you mean "disabling UDMA66" or "disabling UDMA completely"? (You can permanently disable UDMA66 with a DOS utility available from IBM, and it will then act as a plain UDMA33 drive.) Thanks, -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
> Depends on your motherboard. Try to just disable UDMA66 first. Thanks, that's what I did. It works fine (I'm using a SOYO 5EHM motherboard with an AMD K6-2/200). Performance is excellent; bonnie gives: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU svax32if 100 10336 95.5 14246 57.3 5733 35.9 11372 95.4 17128 57.0 147.9 3.3 that's 17MB/s for block reads (this varies quite a bit depending on the physical position on the disk). Not bad for a disk costing £165 for 13.5GB. On the other hand the system really grinds to a halt while the benchmark is running. Incidentally, I tried bonnie on an MSDOS partition (just because it's at the outside of the disk) and the result was: svax32im 100 8940 89.2 12984 76.1 473 2.8 9108 92.1 15584 86.4 76.3 48.8 Note the abysmal rewrite speed! -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: df output ? (picobsd related)
> ufs:fd0a > set `df /` ; dev="/dev/$8" How about something like IFS=': '; set `df /`; IFS=' ' dev="/dev/$9" -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Softupdates reliability?
> > Origin = "AuthenticAMD" Id = 0x580 Stepping=0 > You have one of the first K6-2s off the line. There were definite problems > with these, and as such, they were specially distinguished by having 66 > printed on top. I have a 0x580 which has had no problems at all. I'm pretty certain it doesn't have 66 stamped on it. Are they all supposed to have this, or were they tested and the dodgy ones stamped 66? -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! ATA driver (atapi DMA)..
> lineal velocity (and hence data rate) increases from the inside
> (start) to the outside (end) of the disk.
And consequently any CD that isn't completely full will *always*
be slower than the quoted ("guaranteed not to exceed") rate.
-- Richard
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: tcsh.cat
> P>The string pointed to by path1 shall be treated only as a character > P>string and shall not be validated as a pathname. I have heard on several occasions of peope using symlink(2) to atomically store some small piece of information for locking purposes. (Symlink was more reliably atomic over NFS than other methods.) So it is possible that changing this might break something. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system and (v)fork
> vfork(2) [...] The child code > between the fork() and subsequent exec() must be carefully written > because any changes to memory (including stack) or open files will > also be reflected in the parent. Not open files: indeed, the main thing you typically want to do before the exec() is opening, closing and duping files. Stdio FILE structures on the other hand are just like any other memory, so you probably don't want to touch them (hence the warning in the man page to use _exit() rather than exit()). -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removing f2c from base distribution
> Because Berkeley Unix has /always/ included a FORTRAN compiler. Maybe we should put Franz Lisp back in. bash-2.02$ uname -sr FreeBSD 3.0-RELEASE bash-2.02$ lisp Franz Lisp, Opus 38.92 -> -- Richard To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: GEOM Gate.
> Ok, GEOM Gate is ready for testing. > For those who don't know what it is, they can read README: Aaargh! It's the return of nd(4) from SunOS. (Sorry about that.) -- Richard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GEOM Gate.
> Yeah... Think Sun2 systems > > http://www.netbsd.org/Documentation/network/netboot/nd.html Though it wasn't just for booting in the old days. On a diskless workstation, your whole filesystem would be on nd. And it was a real mistake to mount a writable partition on two machines, but nothing stopped you doing it. -- Richard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone object to the following change in libc?
> > I think ISO-C is pretty clear here. It would be wise to raise this on comp.std.c which is read by several of the ISO C standard authors. Things that seem "pretty clear" often turn out not to be... -- Richard ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: lnc0: broke for us between 3.1 and 4.0?
> > lnc0: Memory allocated above 16Mb limit > I've just committed a fix for this. It was caused by the change to the way > vm_page.c allocates memory Is this fix going into stable? (I'm a little surprised that such a change was considered appropriate for the stable branch in the first place.) -- Richard To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: solid NFS patch #6 avail for -current - need testers files)
> People desperate for current functionality can wait, back port themselves or > run current. I have taken all three options in the past :-) I agree. I have recently installed 3.1-STABLE on two machines, and in each case the ethernet drivers (xl and lnc) had been broken since 3.1 (both are now fixed). Stable is already not stable enough! -- Richard To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: _waitq_remove
> > Fatal error '_waitq_remove: Not in queue' at line 350 in file > > /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 0) > I get the same message with xine on -STABLE each time i use it. I've had this problem for months if not years, in all recent releases of FreeBSD. It's not consistent, sometimes (like right now) I can run xine dozens of times without getting an error, other times I have to run it six times before it works. I haven't been able to pin down a common factor (for example, running 4 xines at once doesn't seem to make it any more likely). -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: different packing of structs in kernel vs. userland ?
> struct foo *fee; > > It's possible that: > > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0])) > > because of end-padding, which is not accounted for in arrays, Er, no, that's not right. Otherwise fee = malloc(n * sizeof(struct foo)) wouldn't work. C89 says: There may also be unnamed padding at the end of a structure or union, as necessary to achieve the proper alignment were the structure or union to be an element of an array. And: the result [of sizeof] is the total number of bytes in such an object, including internal and trailing padding. So if a struct needs padding in an array, it has it even when it isn't in an array. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: different packing of structs in kernel vs. userland ?
> If everyone could read the text past my example of bad math, so > that they could know it was an intentional example of bad math, > live would be beautiful. 8-). I did read past it, and I just read it again, and I can't make it come out any way other than it did the first time. You said: > He's making the valid point that for: > > struct foo *fee; > > It's possible that: > > sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0])) > > because of end-padding, which is not accounted for in arrays, It is not a valid point that it's possible that sizeof(struct foo) != (((char *)&fee[1]) - ((char *)&fee[0])) because it isn't possible. It must be the case that sizeof(struct foo) == (((char *)&fee[1]) - ((char *)&fee[0])) If that's what you meant, you seem to be saying the opposite. > and that inter-structure padding depends on ordering of elements Yes, though it isn't "inter-structure" padding, it's padding that is part of the structure. > (for a good example of this, see the struct direct name element > reference macro, which is also padding independent). Not sure which macro you mean here, since there are several variants of it which work in different ways. The one in dirent.h (I'm looking at 4.6 here) subtracts from sizeof, while the one in ufs/dir.h uses &(0->d_name) which is equivalent to offsetof. > Basically, end-padding happens because arrays of structures need to > have their first element properly aligned, so there is a pad added > after each element to ensure that the following element starts on > an alignment boundary. The point is that there isn't a pad *after* each element. The pad is part of the element, and is there regardless of whether the structure is in an array. Again, if that's what you meant you seem to be saying the opposite! -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aout support broken in gcc3
> yes binary support will remain.. if you need to generate new ones (?) You say this as if no-one would want to do it, but I still use programs (lisp and prolog compilers) that need to generate and read in compiled .o files, and "undump" themselves after reading in such files, and which are never likely to be updated to know about (the much more complicated) elf format. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aout support broken in gcc3
> I think you're extremeley confused. In what way? Or are you just being rude? -- RIchard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aout support broken in gcc3
> GCC being able to produce a.out format binaries has nothing to do with > the ability of a Lisp or Prolog to compile to object files, Correct. > and read such, whether said object files be a.out or ELF or COFF or PECOFF or > Mach-O or ... False. As I said, I have systems that read a.out format object files and they would need to be ported to read ELF object files instead. Furthermore, they write themselves out (after loading object files) in a.out format, and would need to be ported to write themselves out in ELF format. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aout support broken in gcc3
> > False. As I said, I have systems that read a.out format object files > > and they would need to be ported to read ELF object files instead. > > Furthermore, they write themselves out (after loading object files) in > > a.out format, and would need to be ported to write themselves out > > in ELF format. > Where exactly does GCC fit into the mix, making this impossible? They compile Lisp (etc) to a C file, which they compile (with gcc) to a .o file, then link against the running image (with /usr/libexec/aout/ld -A) to produce a relocated .o file, then read it in and look at its symbol table to find the entry points. So they need a C compiler that can generate a.out format .o files, and a linker that can link a.out format .o files against an a.out format executable. I'm quite expecting the answer "yes, we've considered this and decided that the overhead of supporting it is to much", but I want to make sure that you realise that there are programs that will break. Long-time BSD users will not be surprised to know that Franz Lisp (the original BSD Franz Lisp, not the commercial Franz Inc product) is one of them. Incidentally, I know that the "modern" alternative to reading in .o files is to use shared libraries instead, but as far as I know there isn't any support for writing out an executable that has shared libraries mapped in (so that they don't have to be loaded, or even exist, when the program is started again). -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: aout support broken in gcc3
> You are blowing this out of proportion and not actually reading > what people are proposing. So far, the comments are about > removing a.out support from the base compiler and offering > a.out binutils and gcc _as ports_. That would be sufficient for my needs (a matching gdb would be useful too, I'm not sure if that is part of binutils). But I don't think my concern was misplaced: having gone back through the thread for the past couple of weeks, there were certainly phrases like "drop all traces of a.out support" "if you need to generate new ones (?) unpack a 2.2.6 system" with the ports solution mentioned only "if we really have to have a.out". -- Richard (running Franz Lisp since 1983) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The official "GEOM is in the tree" speech.
For those of us who scan the -current mailing list from time to time but don't actually run current, is there a description somewhere of what GEOM *is*? -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0 DP2 on Vaio Z600
I'm trying to install DP2 on a Sony Vaio Z600TEK laptop, but it hangs at "Probing devices, please wait (this can take a while)...". It's not completely hung, in that I can switch to the second console and back. The last message there is DEBUG: Add mapping for /dev/cuaa0 to sl0 and this is after a bunch of errors about da0:umass-sim0 (the memory stick slot, which doesn't have a card in it). Changing the BIOS setting for PnP OS doesn't help. I've been running 4.2 and 4.5 successfully. Any suggestions? -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
DP2 root partition size
Somewhere there should be a warning that the root partition needs to be *much* bigger in 5.0 than in 4.x. It's gone from 40-something MB to 92 MB for a default install. It's really frustrating to install a system and find that / is 104% full. It looks as if even with 128 MB you're not going to have enough room to install a custom kernel+modules without deleting the generic one. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pccardd in DP2
I now have DP2 running on my Vaio Z600 laptop, and I'm trying to get my wireless ethernet running. The cardbus is detected: kernel: cbb0: at device 12.0 on pci0 kernel: cardbus0: on cbb0 kernel: pccard0: <16-bit PCCard bus> on cbb0 But when it tries to run pccardc it reports: pccardc: /dev/card0: No such file or directory (and there is indeed no /dev/card0). pccardd exits with: fatal error: no PC-CARD slots However, if I insert the wireless card and run /etc/pccard_ether wi0 start by hand, everything works. How's this meant to work? Is there something vital I need to know about DEVFS? -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccardd in DP2
> That's because pccardc and pccardd aren't supported in NEWCARD. Ok. It might be worth noting that in /etc/defaults/rc.conf, which still has all the pccard_* variables with no suggestion that they don't work. > consider devd. It is somewhat incomplete in DP2, but complete enough > for this. Thanks, I'll try it. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pccardd in DP2
> > consider devd. It is somewhat incomplete in DP2, but complete enough > > for this. > Thanks, I'll try it. Is there any documentation for devd.conf? The man page is incomplete (it only describes the syntax of comments, though admittedly it does that in great detail) and there's no default /etc/devd.conf to start from. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Alcatel Speed Touch PC
> >I wonder if there's any planned support for Alcatel Speed Touch PC (a ADSL > >PCI card) I think there are some linuxdrivers but what could be needed for > >FreeBSD support? > Contact the guys listed on http://www.xsproject.org/speedtouch/ (bottom of > the page). That's the Speedtouch USB, not the PCI card. Given Alcatel's refusal to provide info on the Speedtouch USB, I wouldn't be too optimistic. -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
