Re: NFS: likely problem is vfs_bio.c rev 1.188
:On the server I downgraded vfs_bio.c to rev 1.187 & rebooted; no luck. I :then installed the same kernel (with the downgraded vfs_bio.c) to the :client. Bingo. With both NFS client & server machine running rev 1.187, :the problem so far as building XFree86-contrib from an NFS mounted :/usr/ports disappears. : :As Chuck Robey noted, it seems like the client's writes are not completely :being committed to the server, which results in partially baked files :which are truncated. : :Unfortunately -r1.188 -r1.187 doesn't apply cleanly, so there's some work :to be done by Eivind to adapt his subsequent commits if we were to say, :back out 1.188 prior to the branch. : :-Chris Hmm. r1.88 are Luoqi's fixes to the handling of misaligned buffers. It is quite possible that there is a bug in there or with assumptions made in the NFS code in regards to how buffers are handled, but most of those changes are theoretically critical to the proper operation of the VFS code on other platforms (aka alpha, with its larger page size), and pretty important to the msdos code too under certain circumstances. And it was reviewed pretty well, too. I'd rather we not lose the work. I think it is important that we find the bug and fix it without having to back-out that entire patch! I was hoping to avoid updating my codebase until after the split, but I'll go ahead and try to sync it up tonight and see if I can reproduce the NFS problem. If I can do that, I should be able to locate the bug and fix it. So, nobody backout 1.188 yet, please. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
make world error upto src-cur.3710
Hello, I tried to make world (src-cur.3710) todya and found the following error. Can anyone tell me how to solve it. thanks. Clarence === Error === In file included from /usr/obj/usr/src/gnu/usr.bin/perl/perl/perl.h:2081, from DynaLoader.xs:107: /usr/obj/usr/src/gnu/usr.bin/perl/perl/thrdvar.h:73: parse error before `PL_ofslen' /usr/obj/usr/src/gnu/usr.bin/perl/perl/thrdvar.h:73: warning: data definition has no type or storage class In file included from DynaLoader.xs:130: dlutils.c:10: `NULL' undeclared here (not in a function) dlutils.c: In function `dl_generic_private_init': dlutils.c:35: `NULL' undeclared (first use this function) dlutils.c:35: (Each undeclared identifier is reported only once dlutils.c:35: for each function it appears in.) dlutils.c: In function `SaveError': dlutils.c:50: `va_list' undeclared (first use this function) dlutils.c:50: parse error before `args' dlutils.c:56: `args' undeclared (first use this function) DynaLoader.c: In function `XS_DynaLoader_dl_load_file': DynaLoader.c:155: dereferencing pointer to incomplete type DynaLoader.c:155: dereferencing pointer to incomplete type DynaLoader.c:165: dereferencing pointer to incomplete type DynaLoader.xs:163: warning: assignment makes pointer from integer without a cast DynaLoader.xs:166: `NULL' undeclared (first use this function) DynaLoader.c: In function `XS_DynaLoader_dl_find_symbol': DynaLoader.c:197: dereferencing pointer to incomplete type DynaLoader.c:198: dereferencing pointer to incomplete type DynaLoader.c:198: dereferencing pointer to incomplete type DynaLoader.xs:183: warning: assignment makes pointer from integer without a cast DynaLoader.xs:187: `NULL' undeclared (first use this function) DynaLoader.c: In function `XS_DynaLoader_dl_install_xsub': DynaLoader.c:240: dereferencing pointer to incomplete type DynaLoader.c:240: dereferencing pointer to incomplete type DynaLoader.c:241: dereferencing pointer to incomplete type DynaLoader.c:247: dereferencing pointer to incomplete type DynaLoader.c:247: dereferencing pointer to incomplete type DynaLoader.c: In function `boot_DynaLoader': DynaLoader.c:282: `NULL' undeclared (first use this function) DynaLoader.c:282: dereferencing pointer to incomplete type DynaLoader.c:282: dereferencing pointer to incomplete type DynaLoader.c:282: dereferencing pointer to incomplete type DynaLoader.c:282: dereferencing pointer to incomplete type *** Error code 1 Stop. === Error === To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
how to update the system from the master machine
Hello, I have two system. One is P233 (master) and the other is a dual P90. How can I update the dual P90 system from the P233 (master) system. Is there anyone can share your experience with me. Thanks. clarence To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: how to update the system from the master machine
At 16.22 18/01/99 +0800, you wrote:
>Hello,
>
>I have two system. One is P233 (master) and the other is a dual P90.
>How can I update the dual P90 system from the P233 (master) system.
>Is there anyone can share your experience with me. Thanks.
>
>clarence
I usually have a box ("server") which make the make world process, the
others ("clients") only install what the server did :-)
Let's say in advance that I do it _only_ if server and clients run the same
version of FreeBSD.
If yes :
(server) cd /sys/i386/conf
(server) cp GENERIC CLIENT_NAME
(server) edit CLIENT_NAME to suit your needs
(server) config -r CLIENT_NAME (if 3.0) else config CLIENT_NAME
(server) cd ../../compile/CLIENT_NAME
(server) make all
When it is finished :
(client) mount /usr/src and /usr/obj of the server in /usr/src and /usr/obj
(client) cd /sys/compile/CLIENT_NAME
(client) make install
(client) cd /usr/src
(client) make installworld (or make reinstall if both are release prior 3.0)
(client) compare /etc/* with /usr/src/etc/* to see if it is changed
something in the scripts
(client) restart
Please check that both systems have the same /etc/make.conf or at least
compatible each other.
Also it could not work if the clients are too much older from the server.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Build Errors in -current
With sources as of about 10 p.m. PST, I got an error in /usr/src/usr.bin/netstat/mbuf.c:71, which was easy to fix. But I still got an error much later with texinfo, so apparently this is only partly fixed. Annelise To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: how to update the system from the master machine
At 09.44 18/01/99 +0100, Gianmarco Giovannelli wrote:
>At 16.22 18/01/99 +0800, you wrote:
>I usually have a box ("server") which make the make world process, the
>others ("clients") only install what the server did :-)
>
>Let's say in advance that I do it _only_ if server and clients run the same
>version of FreeBSD.
>If yes :
Ehm, obviusly you need a built /usr/obj tree so you need also to do :
(server) cd /usr/src
(server) make world
>(server) cd /sys/i386/conf
>(server) cp GENERIC CLIENT_NAME
>(server) edit CLIENT_NAME to suit your needs
>(server) config -r CLIENT_NAME (if 3.0) else config CLIENT_NAME
>(server) cd ../../compile/CLIENT_NAME
>(server) make all
>
>When it is finished :
>
>(client) mount /usr/src and /usr/obj of the server in /usr/src and /usr/obj
>(client) cd /sys/compile/CLIENT_NAME
>(client) make install
>(client) cd /usr/src
>(client) make installworld (or make reinstall if both are release prior 3.0)
>(client) compare /etc/* with /usr/src/etc/* to see if it is changed
>something in the scripts
>(client) restart
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Problems with new IDE's & -current
Andrew Atrens wrote: > > On Sun, 17 Jan 1999, Karl Pielorz wrote: > > Karl, > > Let's see your (dmesg) probe messages ... :) they may shed some light on > what's happening. I don't claim to be an expert on wd.c but from what I > can tell it seems that controller and drive capabilities are probed > separately, its conceivable you've hit upon an untested code path. > > ide_pci.c has been changing a lot lately (probably four times in the last > seven days) - after capturing your dmesg output, try a fresh kernel and > look for differences in probed controller/drive capabilities... > > Andrew. OK, I didn't want to post the dmesg as it's quite long, and I couldn't see anything relevant in it - but here goes... :) The machines running fairly recent -current from ~7th Jan... I've been trying to update recently but run into the same problems everyone else has... I'm hoping to get another build done today/tomorrow... re: Probed controller/drive capabilities - from the look of it (and assuming the Neptune is as old as it is) - it seems to be finding no g'o faster stripes', multiblock, DMA or anything (which is what I'd expect) - so I don't think it's getting the 'wrong mode' for the drives... -Kp --- Copyright (c) 1992-1998 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.0-RELEASE #1: Thu Jan 14 12:49:14 GMT 1999 r...@magpie.dmpriest.com:/usr/src/sys/compile/SMP-MAGPIE Timecounter "i8254" frequency 1193182 Hz cost 4354 ns CPU: Pentium/P54C (586-class CPU) Origin = "GenuineIntel" Id = 0x521 Stepping=1 Features=0x7bf real memory = 16777216 (16384K bytes) avail memory = 14397440 (14060K bytes) Programming 16 pins in IOAPIC #0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 eisa0: Probing for devices on the EISA bus Probing for devices on PCI bus 0: chip0: rev 0x11 on pci0.0.0 ncr0: rev 0x01 int a irq 15 on pci0.1.0 chip1: rev 0x04 on pci0.2.0 vga0: rev 0x00 int a irq 10 on pci0.4.0 Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A lpt0 at 0x278-0x27f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 on isa wdc0: unit 0 (wd0): wd0: 16124MB (33022080 sectors), 32760 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): wd1: 16124MB (33022080 sectors), 32760 cyls, 16 heads, 63 S/T, 512 B/S lnc0 at 0x340-0x357 irq 9 drq 7 on isa lnc0: PCnet-ISA address 00:40:1c:60:36:ab npx0 on motherboard npx0: INT 16 interface Intel Pentium F00F detected, installing workaround APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via pin 2 ccd0-1: Concatenated disk drivers SMP: AP CPU #1 Launched! changing root device to da0s1a da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI2 device da0: 10.0MB/s transfers (10.0MHz, offset 8), Tagged Queueing Enabled da0: 2049MB (4197405 512 byte sectors: 255H 63S/T 261C) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
netstat prints shifted if_obytes values?
Hi folks, Is the following behaviour from netstat expected under CURRENT? input (xl0) output packets errs bytespackets errs bytes colls 2 0390 0 0 0 0 4 0264 0 0 90 0 3 0 1469 1 0 0 0 18 0 1581 0 0 0 0 21 0 15621 0 0 90 0 6 0312 1 0 0 0 4 0760 0 0 90 0 9 0785 1 0 0 0 36 0 8085 0 0 0 0 7 0 1084 0 0 0 0 21 0 13615 0 0 0 0 7 0616 0 0 0 0 4 0249 0 0 0 0 1 0440 0 0 0 0 5 0312 0 0 0 0 5 0528 0 0 0 0 18 0 13971 1 0 82 0 4 0678 0 0 0 0 7 0390 0 0 0 0 3 0364 0 0 0 0 7 0400 0 0 0 0 Specifically, I'm interested in the fact that it _looks_ like if_obytes is sometimes being printed for each ``loop''. At the time, the only expected network traffic was generated by NFSv3. I have no idea whether this might be significant. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
SurfChina.com - Search Engine for China
Dear friend, Do you ever wonder where to find information about China? Well, wonder no more. Come check out SurfChina.com (http://www.surfchina.com), the BEST SEARCH ENGINE for China. SurfChina.com's database consists of thousands of China, Chinese related web sites, all sites are carefully categorized into over 300 categories, which makes search very easy. New sites and categories are added everyday. You can find Chinese companies, Chinese culture sites, travel agencies, employment opportunities, Chinese newspapers, and much, much more. Take a look for yourself, and tell a friend about SurfChina.com, so everyone can take advantage of this wonderful resource. SurfChina.com also provides China statistical information service. We work directly with the State Statistical Bureau of China to provide the latest, the most accurate, and most authritative China statistical data for our clients. To find out more about this service, please visit http://www.surfchina.com/stats/ Sincerely yours, SurfChina.com team To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RE: SurfChina.com - Search Engine for China
[snip] > Dear friend, > > Do you ever wonder where to find information about China? > Well, wonder no > more. Come check out SurfChina.com [snap] just wondering if anyone else receives this post about 10 times...? -- Markus Doehr IT Admin AUBI Baubeschläge GmbH Tel.: +49 6503 917 152 Fax : +49 6503 917 119 e-Mail: doe...@aubi.de MD1139-RIPE * To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
The removal of MT_RTABLE
The removal of MT_RTABLE by fenner in rev 1.32 of /sys/sys/mbuf.h has broken the build of the tree in netstat. It may have broken other net apps that I haven't hit yet. There's also a new coding style that I've not come across before being used in this file, it's based on commenting out lines by clobbering the first two chars, e.g. /*efine MT_RTABLE 5*/ /* routing tables */ It looks like it was invented by Garret and fenner followed his good example :-) Paul. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
NFS problem found - pleaes try this patch.
::On the server I downgraded vfs_bio.c to rev 1.187 & rebooted; no luck. I
::then installed the same kernel (with the downgraded vfs_bio.c) to the
::client. Bingo. With both NFS client & server machine running rev 1.187,
::...
::-Chris
:
:Hmm. r1.88 are Luoqi's fixes to the handling of misaligned buffers. It is
:quite possible that there is a bug in there or with assumptions made in
:the NFS code in regards to how buffers are handled, but most of those
:...
: -Matt
Ok, I believe I have found the bug. Please test the patch included below.
I was able to make /usr/ports/x11/XFree86-contrib after applying this
patch ( and it was screwing up prior to that ).
The problem is in getblk() - code was added to validate the buffer and
to clear B_CACHE if the bp was not entirely valid. The problem is
that NFS uses B_CACHE to flag a dirty buffer that needs to be written out!
Additionally, a write() to an NFS based file may write data that is not
on a DEV_BSIZE'd boundry which causes a subsequent read() to improperly
clear B_CACHE.
There are almost certainly more problems like this -- using B_CACHE to
mark a buffer dirty is just plain dumb, it's no wonder NFS is so screwed
up!
-Matt
Matthew Dillon
Index: kern/vfs_bio.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
retrieving revision 1.192
diff -u -r1.192 vfs_bio.c
--- vfs_bio.c 1999/01/12 11:59:34 1.192
+++ vfs_bio.c 1999/01/18 13:25:27
@@ -1364,6 +1364,7 @@
break;
}
}
+
boffset = (i << PAGE_SHIFT) - (bp->b_offset & PAGE_MASK);
if (boffset < bp->b_dirtyoff) {
bp->b_dirtyoff = max(boffset, 0);
@@ -1457,7 +1458,14 @@
}
KASSERT(bp->b_offset != NOOFFSET,
("getblk: no buffer offset"));
+#if 0
/*
+* XXX REMOVED XXX - this is bogus. It will cause the
+* B_CACHE flag to be cleared for a partially constituted
+* dirty buffer (NFS) that happens to have a write that is
+* not on a DEV_BSIZE boundry!! XXX REMOVED
+*/
+ /*
* Check that the constituted buffer really deserves for the
* B_CACHE bit to be set. B_VMIO type buffers might not
* contain fully valid pages. Normal (old-style) buffers
@@ -1478,6 +1486,7 @@
poffset = 0;
}
}
+#endif
if (bp->b_usecount < BUF_MAXUSE)
++bp->b_usecount;
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Broken make world
I got the following when trying a new make world (1-17-99): cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/netstat/if.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/netstat/inet.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/netstat/main.c cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/netstat/mbuf.c /usr/src/usr.bin/netstat/mbuf.c:71: `MT_RTABLE' undeclared here (not in a function) /usr/src/usr.bin/netstat/mbuf.c:71: initializer element for `mbtypes[4].mt_type' is not constant *** Error code 1 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS problem found - pleaes try this patch.
Good work! I have to run at the moment but it looks like you nailed this
one. Your explanation coincides perfectly with the symptoms.
Thanks!
-Chris
On Mon, 18 Jan 1999, Matthew Dillon wrote:
> Ok, I believe I have found the bug. Please test the patch included below.
> I was able to make /usr/ports/x11/XFree86-contrib after applying this
> patch ( and it was screwing up prior to that ).
>
> The problem is in getblk() - code was added to validate the buffer and
> to clear B_CACHE if the bp was not entirely valid. The problem is
> that NFS uses B_CACHE to flag a dirty buffer that needs to be written out!
> Additionally, a write() to an NFS based file may write data that is not
> on a DEV_BSIZE'd boundry which causes a subsequent read() to improperly
> clear B_CACHE.
>
> There are almost certainly more problems like this -- using B_CACHE to
> mark a buffer dirty is just plain dumb, it's no wonder NFS is so screwed
> up!
>
> -Matt
>
> Matthew Dillon
>
>
> Index: kern/vfs_bio.c
> ===
> RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v
> retrieving revision 1.192
> diff -u -r1.192 vfs_bio.c
> --- vfs_bio.c 1999/01/12 11:59:34 1.192
> +++ vfs_bio.c 1999/01/18 13:25:27
> @@ -1364,6 +1364,7 @@
> break;
> }
> }
> +
> boffset = (i << PAGE_SHIFT) - (bp->b_offset & PAGE_MASK);
> if (boffset < bp->b_dirtyoff) {
> bp->b_dirtyoff = max(boffset, 0);
> @@ -1457,7 +1458,14 @@
> }
> KASSERT(bp->b_offset != NOOFFSET,
> ("getblk: no buffer offset"));
> +#if 0
> /*
> + * XXX REMOVED XXX - this is bogus. It will cause the
> + * B_CACHE flag to be cleared for a partially constituted
> + * dirty buffer (NFS) that happens to have a write that is
> + * not on a DEV_BSIZE boundry!! XXX REMOVED
> + */
> + /*
>* Check that the constituted buffer really deserves for the
>* B_CACHE bit to be set. B_VMIO type buffers might not
>* contain fully valid pages. Normal (old-style) buffers
> @@ -1478,6 +1486,7 @@
> poffset = 0;
> }
> }
> +#endif
>
> if (bp->b_usecount < BUF_MAXUSE)
> ++bp->b_usecount;
>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: NFS problem found - pleaes try this patch.
The check is correct and should be there, the B_CACHE bit was cleared because I made a mistake when setting the valid bit in the vm page. Index: vfs_bio.c === RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v retrieving revision 1.192 diff -u -r1.192 vfs_bio.c --- vfs_bio.c 1999/01/12 11:59:34 1.192 +++ vfs_bio.c 1999/01/18 14:45:33 @@ -2171,7 +2171,7 @@ (vm_offset_t) (soff & PAGE_MASK), (vm_offset_t) (eoff - soff)); sv = (bp->b_offset + bp->b_validoff + DEV_BSIZE - 1) & ~(DEV_BSIZE - 1); - ev = (bp->b_offset + bp->b_validend) & ~(DEV_BSIZE - 1); + ev = (bp->b_offset + bp->b_validend + DEV_BSIZE - 1) & ~(DEV_BSIZE - 1); soff = qmax(sv, soff); eoff = qmin(ev, eoff); } Note the calculation of ev, the original code was a round-up and I changed it to round-down in my -r1.188 commit (I thought it was a bug in the original code, but it was actually me who didn't understand the nfs code well enough). -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
New boot blocks + serial hardware handshaking?
We're having trouble using the new boot loader code and '-h' in boot.config. It appears that unless the terminal is connected to the serial port a machine doesn't reboot properly. My guess is that the new boot serial code is defaulting to hardware handshaking on the serial terminal line, whereas the original boot code didn't. A quick glance at the code didn't confirm this, but does anyone know the answer to this off the top of their heads? Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: ATM LANE support
Unfortunately in practice at the desktop level there are a mix of hosts that run on ATM or ethernet. As is the case here where we use LANE to integrate both in to a single network. Chris >ATM LANE is evil. Why do you want it? > >On Sun, Jan 17, 1999 at 06:58:24PM -0500, Chris Steva wrote: >> I was pleasantly surprised to find that FreeBSD 3.0 supported my FORE >> PCA-200e ATM card, but I wasn't able to get it up and running becuase there >> is no support for ethernet LANE (LAN emulation). Instead I found HARP, >> which appears to be some kind of substitue to LANE for running IP over ATM. >> Will there be support for LANE in the future? >> >> I havn't been able to find any information about what's is going on in >> FreeBSD ATM land. The Linux ATM world doesn't seem to be any further along, >> but I saw that they do have LANE support in their alpha release of ATM >> drivers. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: New boot blocks + serial hardware handshaking?
Josef Karthauser wrote: > We're having trouble using the new boot loader code and '-h' in > boot.config. It appears that unless the terminal is connected to > the serial port a machine doesn't reboot properly. My guess is > that the new boot serial code is defaulting to hardware handshaking > on the serial terminal line, whereas the original boot code didn't. > > A quick glance at the code didn't confirm this, but does anyone > know the answer to this off the top of their heads? As the one who did the actual coding, I can confirm that the approach adopted in both the new bootblocks and the boot loader is virtually identical to that used in the older (biosboot) bootblocks. In all cases, the simplest approach giving the smallest code sizes was used, so there's very little difference between the three sets of routines. The above applies to 3.0-current. In 3.0-release, the boot loader was still using BIOS routines (with hardware handshaking), but this was changed around late November 1998. -- Robert Nordier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: NFS problem found - pleaes try this patch.
A. Yes, I see. I will unapply my patch and apply this one and test it. I'm not sure what the use of having m->valid and m->clean bits are at all if we have to munge them like this. Perhaps we should change these vm_page_t to a byte range in -4.0. I think we also need to redefine the way dirty bp's are handled, though, and at least panic if it tries to clear B_CACHE on something that B_CACHE should not be cleared on. -Matt Matthew Dillon :The check is correct and should be there, the B_CACHE bit was cleared because :I made a mistake when setting the valid bit in the vm page. : :Index: vfs_bio.c :=== :RCS file: /home/ncvs/src/sys/kern/vfs_bio.c,v :retrieving revision 1.192 :diff -u -r1.192 vfs_bio.c :--- vfs_bio.c 1999/01/12 11:59:34 1.192 :+++ vfs_bio.c 1999/01/18 14:45:33 :@@ -2171,7 +2171,7 @@ : (vm_offset_t) (soff & PAGE_MASK), : (vm_offset_t) (eoff - soff)); : sv = (bp->b_offset + bp->b_validoff + DEV_BSIZE - 1) & ~(DEV_BSIZE - 1); :- ev = (bp->b_offset + bp->b_validend) & ~(DEV_BSIZE - 1); :+ ev = (bp->b_offset + bp->b_validend + DEV_BSIZE - 1) & ~(DEV_BSIZE - 1); : soff = qmax(sv, soff); : eoff = qmin(ev, eoff); : } : :Note the calculation of ev, the original code was a round-up and I changed it :to round-down in my -r1.188 commit (I thought it was a bug in the original :code, but it was actually me who didn't understand the nfs code well enough). : :-lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
build failure on dec axp
cc -O -pipe -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.bin/netstat/uni x.c /usr/src/usr.bin/netstat/mbuf.c:71: `MT_RTABLE' undeclared here (not in a functi on) /usr/src/usr.bin/netstat/mbuf.c:71: initializer element for `mbtypes[4].mt_type' is not constant Gary -- Gary Palmer FreeBSD Core Team Member FreeBSD: Turning PC's into workstations. See http://www.FreeBSD.ORG/ for info To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
make release & vn
Hey gang: Should I worry about these messages on the console when doing a make release? vn0: raw partition size != slice size vn0: start 0, end 2879, size 2880 vn0: start 0, end 5759, size 5760 vn0: truncating raw partition vn0: rejecting partition in BSD label: it isn't entirely within the slice vn0: start 0, end 2879, size 2880 vn0: start 0, end 5759, size 5760 Eventually (later in the build) the make release fails because /mnt is full. I'm running a CVSup mirror locally, which sync'ed every hour with cvsup.freebsd.org. The make release failed just a few minutes ago, and was started a couple of hours ago. Cheers, Chris -- "We are not bound by any concept, we are just bound to make any concept work better than others." -- Dr. Ferry Porsche [Disclaimer: I speak for myself and my views are my own and not in any way to be construed as the views of BellSouth Corporation. ] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
aic (adaptec 152x) still not supported in -current?
Hello, When CAM was integrated someone reported that the aic driver was not ready yet for CAM, but that "Brian Beattie is working on it". At the moment, looking in LINT, it looks like aic still isn't supported. Is that true? Does anyone know whether it will be? Thanks, -- Peter Mutsaers | Abcoude (Utrecht), | Trust me, I know p...@xs4all.nl | the Netherlands| what I'm doing. ---+-+- Running FreeBSD-3.0 UNIX. See http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
kernel malloc and M_CANWAIT
Here at whistle we are trying to remember about a conversation regarding malloc that occured recently. Maybe others can help. There was some talk about the fact that malloc(..M_CANWAIT) can now return with a failure. Is that true? who has their finger on that particular button? julian (p.s. still searching the archives but not having much success) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
oops on last mail..(malloc)
Of course I meant M_WAITOK not M_CANWAIT julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
RELNOTES.TXT
In /usr/src/release/texts/RELNOTES.TXT it lists the following for supported adaptec controllers: Adaptec 1535 ISA SCSI controllers Adaptec 154x series ISA SCSI controllers Adaptec 174x series EISA SCSI controller in standard and enhanced mode. Adaptec 274X/284X/2920/2940/2950/3940/3950 (Narrow/Wide/Twin) series EISA/VLB/PCI SCSI controllers. Adaptec AIC7850, AIC7880, AIC789x, on-board SCSI controllers. As far as I know, I don't think the 2920 is supported since it's not a standard adaptec card (it was bought from another company) If I'm wrong, I'd be really pleased since we've been trying to get one of these cards to be supported in FreeBSD 3.0-current. But if I'm right, it should be removed because it's sure to piss people off :) The last known source for the old patches to get this card working are at the following URL: http://www.sbox.tu-graz.ac.at/home/r/rmike/freebsd/welcome.html They, of course, don't work with CAM. IRC: SchradeE-Mail: schr...@schrade.com http://www.schrade.com/> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
> > Here at whistle we are trying to remember about a conversation > regarding malloc that occured recently. Maybe others can help. > > There was some talk about the fact that malloc(..M_CANWAIT) > can now return with a failure. Is that true? Yes; it's necessary to do this to allow some chance of avoiding deadlock. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote: > > > > Here at whistle we are trying to remember about a conversation > > regarding malloc that occured recently. Maybe others can help. > > > > There was some talk about the fact that malloc(..M_CANWAIT) > > can now return with a failure. Is that true? > > Yes; it's necessary to do this to allow some chance of avoiding > deadlock. Ouch! Is everything in src-sys already checking the return value of an M_WAITOK? > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ m...@smith.net.au > \\ The race is long, and in the \\ msm...@freebsd.org > \\ end it's only with yourself. \\ msm...@cdrom.com > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
> On Mon, 18 Jan 1999, Mike Smith wrote: > > > > > > > Here at whistle we are trying to remember about a conversation > > > regarding malloc that occured recently. Maybe others can help. > > > > > > There was some talk about the fact that malloc(..M_CANWAIT) > > > can now return with a failure. Is that true? > > > > Yes; it's necessary to do this to allow some chance of avoiding > > deadlock. > > Ouch! Is everything in src-sys already checking the return value of an > M_WAITOK? Probably not, no. I had some patches from Andrzej who was trying to do it just for the mbuf allocator case; there's definitely a call for someone to take the time to clean things up. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote: > > On Mon, 18 Jan 1999, Mike Smith wrote: > > > > > > > > > > Here at whistle we are trying to remember about a conversation > > > > regarding malloc that occured recently. Maybe others can help. > > > > > > > > There was some talk about the fact that malloc(..M_CANWAIT) > > > > can now return with a failure. Is that true? > > > > > > Yes; it's necessary to do this to allow some chance of avoiding > > > deadlock. > > > > Ouch! Is everything in src-sys already checking the return value of an > > M_WAITOK? > > Probably not, no. I had some patches from Andrzej who was trying to do > it just for the mbuf allocator case; there's definitely a call for > someone to take the time to clean things up. Well, it'll be hard to determine (for me, not knowing any of the kernel well) whether it's proper for: a. return EAGAIN b. return ENOMEN c. try again, then return EAGAIN/ENOMEM? But I'm going to start fixing what I can. It would have been nice for a HEADS UP! or somesuch. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ m...@smith.net.au > \\ The race is long, and in the \\ msm...@freebsd.org > \\ end it's only with yourself. \\ msm...@cdrom.com > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
:> > There was some talk about the fact that malloc(..M_CANWAIT) :> > can now return with a failure. Is that true? :> :> Yes; it's necessary to do this to allow some chance of avoiding :> deadlock. : :Ouch! Is everything in src-sys already checking the return value of an M_WAITOK? : : Brian Feldman _ __ ___ ___ ___ It looks like malloc() can return NULL if the kmem_malloc() fails. kmem_malloc() can only fail in the M_WAITOK case if the KVM map is full. If the system is simply low on memory, kmem_malloc() will block. So malloc() will generally not return NULL even in low memory situations unless the KVM map fills up, which isn't supposed to happen but can in certain severe circumstances. Callers should therefore check for NULL. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote: > > > > Here at whistle we are trying to remember about a conversation > > regarding malloc that occured recently. Maybe others can help. > > > > There was some talk about the fact that malloc(..M_CANWAIT) oops M_WAITOK.. > > can now return with a failure. Is that true? > > Yes; it's necessary to do this to allow some chance of avoiding > deadlock. I can't find this in the archives.. can you remember a keyword that would pull it up? I've looked in.. The archives freebsd-current and freebsd-hackers contain the following items relevant to `malloc AND M_WAITOK AND 1998' (and similar) It seems to me that there must be a lot of places where the return value of MALLOC is not tested when M_WAITOK is set. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ m...@smith.net.au > \\ The race is long, and in the \\ msm...@freebsd.org > \\ end it's only with yourself. \\ msm...@cdrom.com > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Matthew Dillon wrote: > :> > There was some talk about the fact that malloc(..M_CANWAIT) > :> > can now return with a failure. Is that true? > :> > :> Yes; it's necessary to do this to allow some chance of avoiding > :> deadlock. > : > :Ouch! Is everything in src-sys already checking the return value of an > M_WAITOK? > : > : Brian Feldman _ __ ___ ___ ___ > > It looks like malloc() can return NULL if the kmem_malloc() fails. > > kmem_malloc() can only fail in the M_WAITOK case if the KVM map is full. > If the system is simply low on memory, kmem_malloc() will block. > > So malloc() will generally not return NULL even in low memory situations > unless the KVM map fills up, which isn't supposed to happen but can in > certain severe circumstances. Callers should therefore check for NULL. why not just put it in a loop and block on lbolt? (or call panic) the trouble is that this is a major change in semantics and will affect code flow all over the place. julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
> > > There was some talk about the fact that malloc(..M_CANWAIT) > oops M_WAITOK.. > > > > can now return with a failure. Is that true? > > > > Yes; it's necessary to do this to allow some chance of avoiding > > deadlock. > > I can't find this in the archives.. can you remember > a keyword that would pull it up? No; Matt's on the spot with his comment though, and it's trivial to understand why it needs to be able to fail to avoid deadlock. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
> > So malloc() will generally not return NULL even in low memory situations > > unless the KVM map fills up, which isn't supposed to happen but can in > > certain severe circumstances. Callers should therefore check for NULL. > > why not just put it in a loop and block on lbolt? > (or call panic) Because you shouldn't panic unless there's no alternative. Panicking on resource starvation is just totally lame. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote:
> > > So malloc() will generally not return NULL even in low memory
> > > situations
> > > unless the KVM map fills up, which isn't supposed to happen but can in
> > > certain severe circumstances. Callers should therefore check for
> > > NULL.
> >
> > why not just put it in a loop and block on lbolt?
> > (or call panic)
>
> Because you shouldn't panic unless there's no alternative. Panicking
> on resource starvation is just totally lame.
And what's wrong with spinning inside malloc until the resources are free?
There are places that architecturally require M_WAITOK to not return NULL.
Look at the void () functions that call malloc/MALLOC. Also, commit the
attached patch; it was OKed by Bruce to disallow this, but he seems to forget
to commit it.
>
> --
> \\ Sometimes you're ahead, \\ Mike Smith
> \\ sometimes you're behind. \\ m...@smith.net.au
> \\ The race is long, and in the \\ msm...@freebsd.org
> \\ end it's only with yourself. \\ msm...@cdrom.com
>
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
--- src/sys/kern/vfs_syscalls.c.origFri Dec 25 22:27:21 1998
+++ src/sys/kern/vfs_syscalls.c Fri Dec 25 22:28:12 1998
@@ -2909,6 +2909,10 @@
if (error = namei(&nd))
return (error);
vp = nd.ni_vp;
+ if (vp->v_type == VFIFO) {
+ error = EINVAL;
+ goto out;
+ }
if (error = VOP_GETATTR(vp, &vattr, p->p_ucred, p))
goto out;
if (p->p_ucred->cr_uid != vattr.va_uid &&
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
>There was some talk about the fact that malloc(..M_CANWAIT) >can now return with a failure. You mean M_WAITOK. >Is that true? Of course not. It is fundamental that malloc(..., M_WAITOK) either succeeds or panics. Most callers depend on this and don't check for success. The others are bogus. You may be thinking of the documented but unimplemented new flag M_ASLEEP. It's hard to see what this does (since it is unimplemented), but the docs say to only use it with M_NOWAIT. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re2: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote:
> > > So malloc() will generally not return NULL even in low memory
> > > situations
> > > unless the KVM map fills up, which isn't supposed to happen but can in
> > > certain severe circumstances. Callers should therefore check for
> > > NULL.
> >
> > why not just put it in a loop and block on lbolt?
> > (or call panic)
>
> Because you shouldn't panic unless there's no alternative. Panicking
> on resource starvation is just totally lame.
Ahem:
uipc_mbuf.c: unmodified, readonly: line 268 of 945 [28%]
panic("Out of mbuf clusters");
uipc_mbuf.c: unmodified, readonly: line 296 of 945 [31%]
panic("Out of mbuf clusters");
And if the max number of mbuf clusters is{, to become} a sysctl, shouldn't
these just be informative printf()s or something?
>
> --
> \\ Sometimes you're ahead, \\ Mike Smith
> \\ sometimes you're behind. \\ m...@smith.net.au
> \\ The race is long, and in the \\ msm...@freebsd.org
> \\ end it's only with yourself. \\ msm...@cdrom.com
>
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Sync card users. need testers..
Whistle is preparing to submit it's synchronous protocols suppoort framework, but to make it usable we'd like to be able to release it with support for the sr and ar sync cards (and maybe even the third (cx) if I can get to it). However as we have NONE of those cards I'll need people to help test the driver mods. We can presently run sync cards in, raw hdlc, cisco-hdlc, raw framerelay, rfc1490 over framerelay, and, with userland help, ppp over all the above. Anyone who is running a recent -current and who would be able to help with any of the 3 sync cards mantionned above is invited to contact me for information on how we can test these. The new code is non invasive, (i.e it doesn't edit other kernel files) except for the additions to the 3 sync driver files. julian To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
> > why not just put it in a loop and block on lbolt? > > (or call panic) > > Because you shouldn't panic unless there's no alternative. Panicking > on resource starvation is just totally lame. We haven't used up the kernel name space yet. This sort of fundamental change should be enabled by a new flag and then added when handled. Changing things to return NULL pointers in the kernel where they never were before is equally lame. Without the appropriate work you're just pushing the panic off to a hard to find location. Peter -- Peter Dufault (dufa...@hda.com) Realtime development, Machine control, HD Associates, Inc. Safety critical systems, Agency approval To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
On Tue, 19 Jan 1999, Bruce Evans wrote: > >There was some talk about the fact that malloc(..M_CANWAIT) > >can now return with a failure. > > You mean M_WAITOK. yes.. a braino.. (I corrected in later mail) > > >Is that true? > > Of course not. It is fundamental that malloc(..., M_WAITOK) either > succeeds or panics. Most callers depend on this and don't check for > success. The others are bogus. actually it turns out to be true.. see other email from matt. > > You may be thinking of the documented but unimplemented new flag > M_ASLEEP. It's hard to see what this does (since it is > unimplemented), but the docs say to only use it with M_NOWAIT. Unrelated > > Bruce > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
>It looks like malloc() can return NULL if the kmem_malloc() fails. Not for the M_WAITOK case. >kmem_malloc() can only fail in the M_WAITOK case if the KVM map is full. kmem_malloc() panics in this case (except for map == mb_map; the mbuf allocator has special handling for this problem). >If the system is simply low on memory, kmem_malloc() will block. > >So malloc() will generally not return NULL even in low memory situations >unless the KVM map fills up, which isn't supposed to happen but can in >certain severe circumstances. Callers should therefore check for NULL. Callers that check for NULL are bogus. Callers that can actually handle low memory conditions should use M_NOWAIT. There should probably be a flag that says to wait for everything except the map to unfill, and this flag should have been used instead of the `map == mb_map' hack, but no callers actually handle filling of their map (the mbuf allocator doesn't -- it tends to panic a little later because m_retry[hdr]() is not prepared to pass failures back to callers in the can-wait case). Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
>> Of course not. It is fundamental that malloc(..., M_WAITOK) either >> succeeds or panics. Most callers depend on this and don't check for >> success. The others are bogus. > >actually it turns out to be true.. Actually not. >see other email from matt. See my corrections to that mail. Bruce To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
> On Mon, 18 Jan 1999, Mike Smith wrote: > > > > > So malloc() will generally not return NULL even in low memory > > > > situations > > > > unless the KVM map fills up, which isn't supposed to happen but can > > > > in > > > > certain severe circumstances. Callers should therefore check for > > > > NULL. > > > > > > why not just put it in a loop and block on lbolt? > > > (or call panic) > > > > Because you shouldn't panic unless there's no alternative. Panicking > > on resource starvation is just totally lame. > > And what's wrong with spinning inside malloc until the resources are free? If you have to ask this, you have a lot of reading to do before you're going to be able to understand any of the deadlock issues. Just as a hint for this one though - if you're spinning inside malloc() waiting for the resources to be freed, who is going to free them? > There are places that architecturally require M_WAITOK to not return NULL. > Look at the void () functions that call malloc/MALLOC. These are (obviously) bogus code. So they need to be fixed... > Also, commit the > attached patch; it was OKed by Bruce to disallow this, but he seems to forget > to commit it. I'm not going to second-guess Bruce on this one. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
>Look at the void () functions that call malloc/MALLOC. Also, commit the
>attached patch; it was OKed by Bruce to disallow this, but he seems to forget
>to commit it.
It is queued behind 10-100 other patches.
>--- src/sys/kern/vfs_syscalls.c.orig Fri Dec 25 22:27:21 1998
>+++ src/sys/kern/vfs_syscalls.cFri Dec 25 22:28:12 1998
>@@ -2909,6 +2909,10 @@
> if (error = namei(&nd))
> return (error);
> vp = nd.ni_vp;
>+ if (vp->v_type == VFIFO) {
>+ error = EINVAL;
>+ goto out;
>+ }
> if (error = VOP_GETATTR(vp, &vattr, p->p_ucred, p))
> goto out;
> if (p->p_ucred->cr_uid != vattr.va_uid &&
Actually, the patch from Lite1 is queued. It also backs out support
for revoke of everything except cdevs and bdevs. I don't have time to
check what happens for regular files, pipes and sockets...
Bruce
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: Re2: kernel malloc and M_CANWAIT
> > Because you shouldn't panic unless there's no alternative. Panicking
> > on resource starvation is just totally lame.
>
> Ahem:
> uipc_mbuf.c: unmodified, readonly: line 268 of 945 [28%]
> panic("Out of mbuf clusters");
> uipc_mbuf.c: unmodified, readonly: line 296 of 945 [31%]
> panic("Out of mbuf clusters");
> And if the max number of mbuf clusters is{, to become} a sysctl, shouldn't
> these just be informative printf()s or something?
See my earlier comment about work in progress on just exactly this.
Pay attention. 8)
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ m...@smith.net.au
\\ The race is long, and in the \\ msm...@freebsd.org
\\ end it's only with yourself. \\ msm...@cdrom.com
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
> >If the system is simply low on memory, kmem_malloc() will block. > > > >So malloc() will generally not return NULL even in low memory situations > >unless the KVM map fills up, which isn't supposed to happen but can in > >certain severe circumstances. Callers should therefore check for NULL. > > Callers that check for NULL are bogus. If it can truly never return NULL, that's true. But it would also be true to say that callers that can't deal with a veto return and that can't guarantee deadlock avoidance are also bogus. I got the impression that my understanding of M_WAITOK's behaviour came from a discussion with you about it, but it looks like I was mistaken. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
19990112-SNAP: no /usr/libexec/ld.so
Making use of a hint from Mike Smith (re: "two-floppy boot"), I tried upgrading a box here that had been running an older level of -CURRENT to the 19990112-SNAP. Died while copying data (I think it was ports) with a SIGSEGV; no recent corefiles were on the system, and I didn't think it was worthwhile to try to reproduce the failure. Since my basic task was to get the machine running that SNAP, and since there wasn't much critical on the system, I elected to just re-install. That worked, and I booted (in single-user mode) to edit /etc/rc.conf (to add in the name of the NIS domain, as well as a couple of other tweaks). I then created a new kernel config file, and config CLEAR cd ../../compile/CLEAR make depend && make && make install && reboot which worked OK, but toward the tail end of the boot process, 6 occurrences of Couldn't open /usr/libexec/ld.so. were issued. Sure enough, ls -l /usr/libexec/ld* yields: -r-xr-xr-x 1 root wheel 62872 Jan 13 03:37 /usr/libexec/ld-elf.so.1 On a colleague's 3.0 system, the same command yields: -r-xr-xr-x 1 root wheel 62900 Jan 8 19:31 /usr/libexec/ld-elf.so.1 -r-xr-xr-x 1 root wheel 77824 Nov 11 08:16 /usr/libexec/ld.so It appears that /usr/libexec/ld.so is found, OK... but this colleague re-builds thinsg fairly often, and that file seems to have merely been left there, rather than having been built any time in the recent past. Further, I tried an exhaustive "find" looking for ld.so on the new system; no such file found anywhere. As for why the start-up was looking for the file, I suspect that it's an issue with the contents of /usr/local/etc/rc.d -- which (in the environment that I inherited here) is mounted from an NFS export from a (now) FreeBSD-2.2.6-R system. (Actually, all of /usr/local is thus mounted.) And sure enough, if I try to telnet to the system, I get: pau-amma[37]% telnet clear Trying 207.76.205.132... Connected to clear.whistle.com. Escape character is '^]'. FreeBSD/i386 (clear.whistle.com) (ttyp0) login: dhw Password: Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 3.0.0-19990112-SNAP (CLEAR) #0: Mon Jan 18 16:09:57 PST 1999 Welcome to FreeBSD! If the doc distribution has been loaded on this machine, the FreeBSD Handbook will be in file:/usr/share/doc/handbook and the FAQ in file:/usr/share/doc/FAQ Type /stand/sysinstall to re-enter the installation and configuration utility. No ld.so Connection closed by foreign host. pau-amma[38]% (A telnet as root goes OK (since I whacked /etc/ttys to permit this, though I realize it's dangerous), so it's likely that my attempted use of a.out-flavored stuff is a problem.) I suppose I could copy /usr/libexec/ld.so from a random machine, but that approach seems to be, at best, inelegant. Also, I don't look forward to doing the same to each machine on our (engineering) net. I welcome suggestions for making this work better (for some arguably reasonable definition of the term "better"). Thankas, david -- David Wolfskill UNIX System Administrator d...@whistle.comvoice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
On Tue, 19 Jan 1999, Bruce Evans wrote:
> >Look at the void () functions that call malloc/MALLOC. Also, commit the
> >attached patch; it was OKed by Bruce to disallow this, but he seems to forget
> >to commit it.
>
> It is queued behind 10-100 other patches.
>
> >--- src/sys/kern/vfs_syscalls.c.orig Fri Dec 25 22:27:21 1998
> >+++ src/sys/kern/vfs_syscalls.c Fri Dec 25 22:28:12 1998
> >@@ -2909,6 +2909,10 @@
> > if (error = namei(&nd))
> > return (error);
> > vp = nd.ni_vp;
> >+if (vp->v_type == VFIFO) {
> >+error = EINVAL;
> >+goto out;
> >+}
> > if (error = VOP_GETATTR(vp, &vattr, p->p_ucred, p))
> > goto out;
> > if (p->p_ucred->cr_uid != vattr.va_uid &&
>
> Actually, the patch from Lite1 is queued. It also backs out support
> for revoke of everything except cdevs and bdevs. I don't have time to
> check what happens for regular files, pipes and sockets...
Hmm... that may be a good idea, although for it seems to work on all of them,
I haven't checked for any kind of leak in the others, nor would truly expect
one. And pipes ARE fifo's aren't they?
>
> Bruce
>
Brian Feldman_ __ ___ ___ ___
gr...@unixhelp.org _ __ ___ | _ ) __| \
http://www.freebsd.org/ _ __ ___ | _ \__ \ |) |
FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
Re: kernel malloc and M_CANWAIT
On Mon, 18 Jan 1999, Mike Smith wrote: > > >If the system is simply low on memory, kmem_malloc() will block. > > > > > >So malloc() will generally not return NULL even in low memory > > > situations > > >unless the KVM map fills up, which isn't supposed to happen but can in > > >certain severe circumstances. Callers should therefore check for NULL. > > > > Callers that check for NULL are bogus. > > If it can truly never return NULL, that's true. But it would also be > true to say that callers that can't deal with a veto return and that > can't guarantee deadlock avoidance are also bogus. > > I got the impression that my understanding of M_WAITOK's behaviour > came from a discussion with you about it, but it looks like I was > mistaken. Everyone else's impression of malloc M_WAITOK's behavior has always been that it could never return NULL, at least without (say) trying to allocate all available kernel memory. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ m...@smith.net.au > \\ The race is long, and in the \\ msm...@freebsd.org > \\ end it's only with yourself. \\ msm...@cdrom.com > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: how to update the system from the master machine
On Mon, 18 Jan 1999, Chan Yiu Wah wrote: > Hello, > > I have two system. One is P233 (master) and the other is a dual P90. > How can I update the dual P90 system from the P233 (master) system. > Is there anyone can share your experience with me. Thanks. > > clarence I have used dump and restore to "clone" a running system, but you want to be careful about what you don't want to be identical on the two systems, or, in my case, the two drives. I use rsync to keep it up to date, so the second disk is a backup for the first. This can be used from one host to another. Again, you might not want everything the same. But rsync is quite fast since it only transfers differences. Annelise To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
linuxthreads, gimp 1.1+, dies
I running gimp -unstable (CVS 1/17/1998) and FreeBSD -current (1/17/1998) with CFLAGS= -O2 -m486 -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK COPTFLAGS= -O -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK and linuxthreads port from http://lt.tar.com. recompiled glib, gtk+ and gimp which works fine reasonably well without threads. with threads CFLAGS="-D_THREAD_SAFE -I/usr/local/include -L/usr/local/lib -O2 -m486 -pipe -lpthread" Everything compiles and it runs. However, various operations crash for example: starting tile preswapper /usr/local/bin/gimp fatal error: sigsegv caught /usr/local/bin/gimp (pid:15557): [E]xit, [H]alt, show [S]tack trace or [P]roceed: S #0 0x282a0326 in g_on_error_stack_trace ( #1 0x282a0254 in g_on_error_query (prg_name=0xefbfdb40 "/usr/local/bin/gimp") #2 0x808b867 in fatal_error () #3 0x80cef0a in on_signal () #4 #5 0x8100a33 in tile_idle_thread () #6 0x28155ea1 in pthread_start_thread (arg=0xeb7ffd08) #7 0x2815650d in _clone () at clone.S:1 #8 0x7202c in ?? () #9 0x1 in ?? () -- Brian Litzinger To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: linuxthreads, gimp 1.1+, dies
On Mon, 18 Jan 1999 br...@worldcontrol.com wrote: > I running gimp -unstable (CVS 1/17/1998) and FreeBSD -current > (1/17/1998) with > > CFLAGS= -O2 -m486 -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK > COPTFLAGS= -O -pipe -DCOMPAT_LINUX_THREADS -DVM_STACK > > and linuxthreads port from http://lt.tar.com. > > recompiled glib, gtk+ and gimp which works fine reasonably > well without threads. > > with threads > CFLAGS="-D_THREAD_SAFE -I/usr/local/include -L/usr/local/lib -O2 -m486 -pipe > -lpthread" Where's -g? > > Everything compiles and it runs. However, various operations crash > for example: > > starting tile preswapper > /usr/local/bin/gimp fatal error: sigsegv caught > /usr/local/bin/gimp (pid:15557): [E]xit, [H]alt, show [S]tack trace or > [P]roceed: > S > #0 0x282a0326 in g_on_error_stack_trace ( > #1 0x282a0254 in g_on_error_query (prg_name=0xefbfdb40 "/usr/local/bin/gimp") > #2 0x808b867 in fatal_error () > #3 0x80cef0a in on_signal () > #4 > #5 0x8100a33 in tile_idle_thread () > #6 0x28155ea1 in pthread_start_thread (arg=0xeb7ffd08) > #7 0x2815650d in _clone () at clone.S:1 > #8 0x7202c in ?? () > #9 0x1 in ?? () > Try compiling with debugging info, get a coredump, and debug with the binary that has the full debugging symbols. > > -- > Brian Litzinger > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: The removal of MT_RTABLE
According to p...@originative.co.uk: > The removal of MT_RTABLE by fenner in rev 1.32 of /sys/sys/mbuf.h has > broken the build of the tree in netstat. It may have broken other net > apps that I haven't hit yet. Already fixed. If you're not subscribed to cvs-all, please do... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #69: Mon Jan 18 02:02:12 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Build Errors in -current
According to Annelise Anderson: > But I still got an error much later with texinfo, so apparently > this is only partly fixed. Weird. After fixing netstat, my "make buildworld" succeeded w/o any problem... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #69: Mon Jan 18 02:02:12 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: FrontPage Extensions
For what it's worth, the FP security issues are very well documented by ReadyToRun Software's site (these are the folks who do the UNIX ports for Microsoft). They also keep both BSDI 2.1 and 3.0 binaries available, and they know about FreeBSD (it's mentioned in the FAQ as an unsupported platform; apparently someone was having problems with the MD5 password hashing. Someone who cares should send them mail on how to update their FAQ to be more correct, and to raise FreeBSD's visibility as a platform -- e.g. what versions to us4e for what, install instructions for FreeBSD, etc.). Here is the source code to mod_frontpage and fpexe: http://www.rtr.com/fpsupport/SERK/a_modfp.htm http://www.rtr.com/fpsupport/SERK/a_fpexe.htm Here's Microsoft's take on the security issues: http://www.rtr.com/fpsupport/SERK/security.htm Pretty much, using the source code provided, you could add FP extensions to any web server for which you had source. One caveat is that the FrontPage client (stupidly) will refuse to create "sub webs" unless the server type is "netscape" or "apache-fp", so I guess it's back to lying about what your server is if it isn't one of those; sorry, JAVA-teers... Terry Lambert te...@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: aic (adaptec 152x) still not supported in -current?
Peter Mutsaers wrote... > Hello, > > When CAM was integrated someone reported that the aic driver was not > ready yet for CAM, but that "Brian Beattie is > working on it". Right. > At the moment, looking in LINT, it looks like aic still isn't > supported. Is that true? Does anyone know whether it will be? It's true that it isn't supported yet. We are planning on supporting it. Brian Beattie is the one working on it, you should probably ask him how it is coming along. I have no idea when support will appear. If you want SCSI support any time soon, I would suggest getting a supported card. An ISA Advansys card might be a good, cheap substitute for your 6360/6260 board. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: RELNOTES.TXT
> As far as I know, I don't think the 2920 is supported since it's not a > standard adaptec card (it was bought from another company) Old 2920, AHA-2920A is using Future Domain chip. Newer 2920, AHA-2920C? is using adaptec chip. But I don't test yet. And, 2910 is using adaptec chip, too. This card has not boot-ROM. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: RELNOTES.TXT
Ken Krebs wrote... > > In /usr/src/release/texts/RELNOTES.TXT it lists the following for > supported adaptec controllers: > > Adaptec 1535 ISA SCSI controllers > Adaptec 154x series ISA SCSI controllers > Adaptec 174x series EISA SCSI controller in standard and enhanced mode. > Adaptec 274X/284X/2920/2940/2950/3940/3950 (Narrow/Wide/Twin) series > > EISA/VLB/PCI SCSI controllers. > Adaptec AIC7850, AIC7880, AIC789x, on-board SCSI controllers. > > > As far as I know, I don't think the 2920 is supported since it's not a > standard adaptec card (it was bought from another company) The 2920 is a rebadged Future Domain card, and you're right, it isn't supported. The 2920C, on the other hand, has an Adaptec 7855 on board and it is supported. The release notes should probably be qualified. > If I'm wrong, I'd be really pleased since we've been trying to get one of > these cards to be supported in FreeBSD 3.0-current. > > But if I'm right, it should be removed because it's sure to piss people > off :) It should be qualified. > The last known source for the old patches to get this card working are at > the following URL: > > http://www.sbox.tu-graz.ac.at/home/r/rmike/freebsd/welcome.html > > They, of course, don't work with CAM. Yep. -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
make release produces unbootable boot floppies, no boot loader, no /kernel
Hi ! Bad news, make release still produces non bootable floppies. I cvsupped yesterday evening at 8pm and did a make world and make release Now I tried the boot.flp image from the ftp subdir in /R/ First error message No /boot/loader Then the typical "boot banner" 2nd error message No /kernel When typing ? . .. kernel.gz When typing kernel.gz to load this kernel invalid format Well, there is _still_ something wron, believe me. Andreas /// -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: make release produces unbootable boot floppies, no boot loader, no /kernel
> Hi ! Bad news, make release still produces non bootable floppies. > I cvsupped yesterday evening at 8pm and did a make world and > make release > > Now I tried the boot.flp image from the ftp subdir in /R/ > > First error message > No /boot/loader > Then the typical "boot banner" > 2nd error message > No /kernel > When typing ? > . .. kernel.gz > When typing kernel.gz to load this kernel > invalid format Of course, it's gzipped. > Well, there is _still_ something wron, believe me. The single-floppy install is broken. Use the two-floppy install as I've been encouraging people to do now since the 12th. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Disk Geometry Patch. Could someone test this on -current.
As I now have upgraded at last, I tested the 3.0
version of the patch. It does appear to make the
system recognize the proper disk geometry where the
standard wd.c does not report the proper size.
Attached is the diff and 2 dmesgs, before and after.
(Sorry for the length of the dmesg, haven't compeltely
configured the kernel yet.)
Any thoughts on the patch?
Andrew Sherrod
---Andrew Sherrod wrote:
>
> I have found several people using IDE disks on newer Award BIOSes have
> trouble getting the boot-time probes and installation routines to recognize
> the correct disk geometry.
>
> If anyone is running 3.0 (or 2.2.x) on a machine with Award BIOS using IDE
> drives with LBA turned off in the kernel configuration, and if you have
> trouble getting dmesg/boot probes to recognize the proper disk size, could
> you test the attached patch for me?
>
> I would also like to find testers with ANY BIOS that reports a disk size too
> small. I think my patch will correct most problems with IDE geometry showing
> as smaller than it actually is. (I don't make any claims about geometries
> being reported as too large, or SCSI disks...)
>
> Thanks to anyone who can help.
>
> Andrew Sherrod
>
> P.S. I know this is not a really big problem, but it always seemed a bit
> insulting that FreeBSD had to rely on DOS boot sectors to get the correct
> disk geometry. I would rather that we could identify the correct geometry
> without having to rely on another OS.
>
> And, face it, for newbies and those not terribly computer literate, getting
> the right geometry during installation is a very nice feature. It is rather
> disheartening for a new-comer to find out that their new operating system
> can't even identify the correct disk geometry.
>
>
>
>
> _
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> >
> -
> PR: i386/9431
> -
>
> -
> Patch for 2.2.8 (May also workfor 2.2.6/2.2.7)
> -
>
> *** wd.c.2_2_8Wed Jan 13 21:07:30 1999
> --- wd.c.original.2_2_8 Wed Jan 13 21:08:24 1999
> ***
> *** 113,122
> #define WDOPT_FORCEHD(x)(((x)&0x0f00)>>8)
> #define WDOPT_MULTIMASK 0x00ff
>
> - /* This bit mask is used to determine if the drive supports LBA addressing.
> */
> -
> - #define WDCAP_LBA 0x02
> -
> /*
>* This biotab field doubles as a field for the physical unit number on
>* the controller.
> --- 113,118
> ***
> *** 1731,1745
> du->dk_dd.d_nsectors = wp->wdp_sectors;
> du->dk_dd.d_secpercyl = du->dk_dd.d_ntracks * du->dk_dd.d_nsectors;
> du->dk_dd.d_secperunit = du->dk_dd.d_secpercyl *
> du->dk_dd.d_ncylinders;
> !
> !/* Check for BIOS LBA flag. This should allow kernel to determine
> !actual disk geometry for diffiuclt BIOSes.
> !This will likely only be of use during initial installation, or
> !perhaps when configuring a new drive. Otherwise, the disk geometry
> !should already be known. -A. Sherrod 01/13/1999*/
> !
> ! if ( ( (wp->wdp_capability&WDCAP_LBA) ||
> !(wp->wdp_cylinders == 16383 ) ) &&
> du->dk_dd.d_secperunit < wp->wdp_lbasize) {
> du->dk_dd.d_secperunit = wp->wdp_lbasize;
> du->dk_dd.d_ncylinders =
> --- 1727,1733
> du->dk_dd.d_nsectors = wp->wdp_sectors;
> du->dk_dd.d_secpercyl = du->dk_dd.d_ntracks * du->dk_dd.d_nsectors;
> du->dk_dd.d_secperunit = du->dk_dd.d_secpercyl *
> du->dk_dd.d_ncylinders;
> ! if (wp->wdp_cylinders == 16383 &&
> du->dk_dd.d_secperunit < wp->wdp_lbasize) {
> du->dk_dd.d_secperunit = wp->wdp_lbasize;
> du->dk_dd.d_ncylinders =
>
> -
> Patch for 3.0
> -
>
> *** wd.c.3_0 Wed Jan 13 12:07:46 1999
> --- wd.c.original.3_0 Wed Jan 13 11:17:54 1999
> ***
> *** 130,140
> */
> #define id_physid id_scsiid
>
> - /* This bitmask is used to determine if the BIOS flags showing LBA
> support
> -are active or inactive */
> -
> - #define WDCAP_LBA0x02
> -
> /*
> * Drive states. Used to initialize drive.
> */
> --- 130,135
> ***
> *** 1954,1973
> du->dk_dd.d_ntracks * du->dk_dd.d_nsectors;
> du->dk_dd.d_secperunit =
> du->dk_dd.d_secpercyl * du->dk_dd.d_ncylinders;
> !
> ! /* If BIOS specifies LBA mode
Re: Disk Geometry Patch. Could someone test this on -current.
Appears the diff didn't get attached.
Here it is.
Sorry!
---Andrew Sherrod wrote:
>
>
> As I now have upgraded at last, I tested the 3.0
> version of the patch. It does appear to make the
> system recognize the proper disk geometry where the
> standard wd.c does not report the proper size.
> Attached is the diff and 2 dmesgs, before and after.
>
> (Sorry for the length of the dmesg, haven't compeltely
> configured the kernel yet.)
>
> Any thoughts on the patch?
>
> Andrew Sherrod
>
>
>
> ---Andrew Sherrod wrote:
> >
> > I have found several people using IDE disks on newer Award BIOSes have
> > trouble getting the boot-time probes and installation routines to recognize
> > the correct disk geometry.
> >
> > If anyone is running 3.0 (or 2.2.x) on a machine with Award BIOS using IDE
> > drives with LBA turned off in the kernel configuration, and if you have
> > trouble getting dmesg/boot probes to recognize the proper disk size, could
> > you test the attached patch for me?
> >
> > I would also like to find testers with ANY BIOS that reports a disk size
> > too small. I think my patch will correct most problems with IDE geometry
> > showing as smaller than it actually is. (I don't make any claims about
> > geometries being reported as too large, or SCSI disks...)
> >
> > Thanks to anyone who can help.
> >
> > Andrew Sherrod
> >
> > P.S. I know this is not a really big problem, but it always seemed a bit
> > insulting that FreeBSD had to rely on DOS boot sectors to get the correct
> > disk geometry. I would rather that we could identify the correct geometry
> > without having to rely on another OS.
> >
> > And, face it, for newbies and those not terribly computer literate, getting
> > the right geometry during installation is a very nice feature. It is rather
> > disheartening for a new-comer to find out that their new operating system
> > can't even identify the correct disk geometry.
> >
> >
> >
> >
> > _
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > >
> > -
> > PR: i386/9431
> > -
> >
> > -
> > Patch for 2.2.8 (May also workfor 2.2.6/2.2.7)
> > -
> >
> > *** wd.c.2_2_8 Wed Jan 13 21:07:30 1999
> > --- wd.c.original.2_2_8 Wed Jan 13 21:08:24 1999
> > ***
> > *** 113,122
> > #define WDOPT_FORCEHD(x) (((x)&0x0f00)>>8)
> > #define WDOPT_MULTIMASK 0x00ff
> >
> > - /* This bit mask is used to determine if the drive supports LBA
> > addressing. */
> > -
> > - #define WDCAP_LBA 0x02
> > -
> > /*
> >* This biotab field doubles as a field for the physical unit number on
> >* the controller.
> > --- 113,118
> > ***
> > *** 1731,1745
> > du->dk_dd.d_nsectors = wp->wdp_sectors;
> > du->dk_dd.d_secpercyl = du->dk_dd.d_ntracks * du->dk_dd.d_nsectors;
> > du->dk_dd.d_secperunit = du->dk_dd.d_secpercyl *
> > du->dk_dd.d_ncylinders;
> > !
> > !/* Check for BIOS LBA flag. This should allow kernel to determine
> > ! actual disk geometry for diffiuclt BIOSes.
> > ! This will likely only be of use during initial installation, or
> > ! perhaps when configuring a new drive. Otherwise, the disk geometry
> > ! should already be known. -A. Sherrod 01/13/1999*/
> > !
> > ! if ( ( (wp->wdp_capability&WDCAP_LBA) ||
> > !(wp->wdp_cylinders == 16383 ) ) &&
> > du->dk_dd.d_secperunit < wp->wdp_lbasize) {
> > du->dk_dd.d_secperunit = wp->wdp_lbasize;
> > du->dk_dd.d_ncylinders =
> > --- 1727,1733
> > du->dk_dd.d_nsectors = wp->wdp_sectors;
> > du->dk_dd.d_secpercyl = du->dk_dd.d_ntracks * du->dk_dd.d_nsectors;
> > du->dk_dd.d_secperunit = du->dk_dd.d_secpercyl *
> > du->dk_dd.d_ncylinders;
> > ! if (wp->wdp_cylinders == 16383 &&
> > du->dk_dd.d_secperunit < wp->wdp_lbasize) {
> > du->dk_dd.d_secperunit = wp->wdp_lbasize;
> > du->dk_dd.d_ncylinders =
> >
> > -
> > Patch for 3.0
> > -
> >
> > *** wd.c.3_0 Wed Jan 13 12:07:46 1999
> > --- wd.c.original.3_0 Wed Jan 13 11:17:54 1999
> > ***
> > *** 130,140
> > */
> > #define id_physid id_scsiid
> >
> > - /* This bitmask is used to determine if the BIOS flags showing LBA
> > support
> > -are active or inactive */
> > -
> > - #define WDCAP_LBA0x02
> > -
> > /*
> > * Drive states. Used to initialize drive.
> > */
> > --- 130,135
> > ***
> > ***
Re: aic (adaptec 152x) still not supported in -current?
> If you want SCSI support any time soon, I would suggest getting a supported > card. An ISA Advansys card might be a good, cheap substitute for your > 6360/6260 board. Adaptec SlimSCSI is major PC-Card SCSI-IF, it is based on aic6360. Now, aic not supported yet, so Note-PC user can't use any PC-Card SCSI-IF. In PAO, another PC-Card SCSI-IF supported, but these are 2.2-stable only, not yet CAMed. -- NAKAGAWA, Yoshihisa y-nak...@nwsl.mesh.ad.jp nakag...@jp.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: make release produces unbootable boot floppies, no boot loader, no /kernel
On Mon, Jan 18, 1999 at 09:52:26PM -0800, Mike Smith wrote: > > Hi ! Bad news, make release still produces non bootable floppies. > > I cvsupped yesterday evening at 8pm and did a make world and > > make release > > > > Now I tried the boot.flp image from the ftp subdir in /R/ > > > > First error message > > No /boot/loader > > Then the typical "boot banner" > > 2nd error message > > No /kernel > > When typing ? > > . .. kernel.gz > > When typing kernel.gz to load this kernel > > invalid format > > Of course, it's gzipped. > > > Well, there is _still_ something wron, believe me. > > The single-floppy install is broken. Use the two-floppy install as > I've been encouraging people to do now since the 12th. This sounds like booting/installing from CD-ROM is currently impossible as well ??? Andreas /// -- Andreas Klemmhttp://www.FreeBSD.ORG/~andreas What gives you 90% more speed, for example, in kernel compilation ? http://www.FreeBSD.ORG/~fsmp/SMP/akgraph-a/graph1.html "NT = Not Today" (Maggie Biggs) ``powered by FreeBSD SMP'' To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: make release produces unbootable boot floppies, no boot loader, no /kernel
> On Mon, Jan 18, 1999 at 09:52:26PM -0800, Mike Smith wrote: > > > Hi ! Bad news, make release still produces non bootable floppies. > > > I cvsupped yesterday evening at 8pm and did a make world and > > > make release > > > > > > Now I tried the boot.flp image from the ftp subdir in /R/ > > > > > > First error message > > > No /boot/loader > > > Then the typical "boot banner" > > > 2nd error message > > > No /kernel > > > When typing ? > > > . .. kernel.gz > > > When typing kernel.gz to load this kernel > > > invalid format > > > > Of course, it's gzipped. > > > > > Well, there is _still_ something wron, believe me. > > > > The single-floppy install is broken. Use the two-floppy install as > > I've been encouraging people to do now since the 12th. > > This sounds like booting/installing from CD-ROM is currently > impossible as well ??? That's correct. We're looking at having to move to a harddisk emulation mode to get this back on track. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: aic (adaptec 152x) still not supported in -current?
In message <199901190613.paa06...@chandra.eatell.msr.prug.or.jp> NAKAGAWA Yoshihisa writes: : Adaptec SlimSCSI is major PC-Card SCSI-IF, it is based on : aic6360. Now, aic not supported yet, so Note-PC user can't use any : PC-Card SCSI-IF. I'd love to see the aic supported, mostly for my notebook. However, no one seems to have a confluance of time, information and talent to write the driver, or even port the other one in all its gory. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
