Re: IDE CDROM not found with PIIX4 chipset, -current kernel
Nope, that code snippet is in atapi.c its not in any of the drivers...
(and newer has been).
You're right. Goes to show how long I haven't touched this part of
the code. Alas, just reviewed it out of curiosity. It sure got more
readable... :-) But I still hate those inb loops without DELAY...
There's only one, at least in my version.
I sent this in for review a year or so ago, but received no reply.
The main points are that it honours ATA timing in atapi_wait() and
checks for ARS_BUSY in atapi_wait(). This hopefully makes bogus checks
like the one in rev.1.22 unnecessary (status 0xff has ARS_BSY set so it
is invalid). I haven't tested the PC98 case. I removed PC98 code that
seems to only compensate for bugs in atapi_wait().
Bruce
diff -c2 atapi.c~ atapi.c
*** atapi.c~Sat Feb 27 19:05:47 1999
--- atapi.c Tue Dec 29 01:17:34 1998
***
*** 229,234
*/
if (ata-accel ata-intrcmd) {
! ata-intrcmd = 0;
! ata-slow = 1;
}
--- 229,234
*/
if (ata-accel ata-intrcmd) {
! ata-intrcmd = 0;
! ata-slow = 1;
}
***
*** 399,414
struct atapi_params *ap;
char tb [DEV_BSIZE];
- #ifdef PC98
- int cnt;
- outb(0x432,unit%2);
- print((unit = %d,select %d\n,unit,unit%2));
- #endif
/* Wait for controller not busy. */
- #ifdef PC98
- outb (port + AR_DRIVE, unit / 2 ? ARD_DRIVE1 : ARD_DRIVE0);
- #else
- outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0);
- #endif
if (atapi_wait (port, 0) 0) {
print ((atapiX.%d at 0x%x: controller busy, status=%b\n,
--- 399,404
***
*** 417,461
}
! /* Issue ATAPI IDENTIFY command. */
#ifdef PC98
! outb (port + AR_DRIVE, unit/2 ? ARD_DRIVE1 : ARD_DRIVE0);
!
! /* Wait for DRQ deassert. */
! for (cnt=2000; cnt0; --cnt)
! if (! (inb (port + AR_STATUS) ARS_DRQ))
! break;
!
! outb (port + AR_COMMAND, ATAPIC_IDENTIFY);
! DELAY(500);
#else
outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0);
- outb (port + AR_COMMAND, ATAPIC_IDENTIFY);
#endif
! /* Check that device is present. */
! if (inb (port + AR_STATUS) == 0xff) {
! print ((atapiX.%d at 0x%x: no device\n, unit, port));
! if (unit == 1)
! /* Select unit 0. */
! outb (port + AR_DRIVE, ARD_DRIVE0);
return (0);
}
/* Wait for data ready. */
if (atapi_wait (port, ARS_DRQ) != 0) {
print ((atapiX.%d at 0x%x: identify not ready, status=%b\n,
unit, port, inb (port + AR_STATUS), ARS_BITS));
- if (unit == 1)
- /* Select unit 0. */
- outb (port + AR_DRIVE, ARD_DRIVE0);
- return (0);
- }
-
- /* check that DRQ isn't a fake */
- if (inb (port + AR_STATUS) == 0xff) {
- print ((atapiX.%d at 0x%x: no device\n, unit, port));
- if (unit == 1)
- /* Select unit 0. */
- outb (port + AR_DRIVE, ARD_DRIVE0);
return (0);
}
--- 407,434
}
! /* Select the drive. */
#ifdef PC98
! /* XXX what is this? */
! outb(0x432,unit%2);
! print((unit = %d,select %d\n,unit,unit%2));
! outb (port + AR_DRIVE, unit / 2 ? ARD_DRIVE1 : ARD_DRIVE0);
#else
outb (port + AR_DRIVE, unit ? ARD_DRIVE1 : ARD_DRIVE0);
#endif
! /* Wait for controller not busy again. Necessary? */
! if (atapi_wait (port, 0) 0) {
! print ((atapiX.%d at 0x%x: controller busy, status=%b\n,
! unit, port, inb (port + AR_STATUS), ARS_BITS));
return (0);
}
+ /* Issue ATAPI IDENTIFY command. */
+ outb (port + AR_COMMAND, ATAPIC_IDENTIFY);
+
/* Wait for data ready. */
if (atapi_wait (port, ARS_DRQ) != 0) {
print ((atapiX.%d at 0x%x: identify not ready, status=%b\n,
unit, port, inb (port + AR_STATUS), ARS_BITS));
return (0);
}
***
*** 499,503
u_char s;
! /* Wait 5 sec for BUSY deassert. */
for (cnt=50; cnt0; --cnt) {
s = inb (port + AR_STATUS);
--- 472,479
u_char s;
! /* Wait at least 400 nsec for BSY to become valid. */
! DELAY(1);
!
! /* Wait 5 sec for BSY deassert. */
for (cnt=50; cnt0; --cnt) {
s = inb (port + AR_STATUS);
***
*** 511,518
return (s ARS_CHECK);
! /* Wait 50 msec for bits wanted. */
for (cnt=5000; cnt0; --cnt) {
s = inb (port + AR_STATUS);
! if ((s bits_wanted) == bits_wanted)
What it means when running soffice 5.01
Hello, Is there anyone knows what it means when running the soffice 5.01 . The message keeps growing as I using the soffice. Is it harmful the system? cheers Clarence = fbsd-elf# ./soffice Feb 27 22:51:03 fbsd-elf last message repeated 238 times Feb 27 22:52:12 fbsd-elf /kernel: cmd soffice.bin pid 1013 tried to use non-present sched_yield Feb 27 22:51:03 fbsd-elf last message repeated 238 times Feb 27 22:52:12 fbsd-elf /kernel: cmd soffice.bin pid 1013 tried to use non-present sched_yield = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: What it means when running soffice 5.01
On Sat, 27 Feb 1999, Chan Yiu Wah wrote: Hello, Is there anyone knows what it means when running the soffice 5.01 . The message keeps growing as I using the soffice. Is it harmful the system? You need to add these lines to your kernel config file: options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Really! strange uid value
On 26-Feb-99 John W. DeBoskey wrote: Hi, I have some machines running 3.0-19981209-SNAP. I have seen some core dumps from pdksh (which I haven't figured out yet) that have some really strange uid values. -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54 pdksh.core.xclink Whoaha, this is exactly what I got when I tried to compile some things over NFS. The created directory and files were also like this: 1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ funny, the same value. There is something left out very fundamentally somewhere. The only time(s) went it roared it's head here was with NFS (v3 and v2). Any special things about your box, because we need to find a common ground to track where it messed up. --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mount -o union broken recently?
On Fri, Feb 26, 1999 at 09:16:44PM +0100, Luigi Rizzo wrote: (about union mounts on 3.1 not returning all files with an 'ls' in 3.1 while it did in 3.0) Is it sorrect that this magic is implemented in sys/kern/vfs_lookup.c? The odd thing is that AFAICS no-one has made significant changes to this code. i just experienced the above today while trying diskless, and while ls only seems to return the entries for the topmost directory, files are accessible if you know the name. no idea if this is of any help. on a related subject; i noticed that using mount_null on a directory with device entries (e.g. still in the diskless case, say /foo/dev is an mfs partition with device entries, and i do a mount_null /foo/dev /dev ) causes very bad effects such as crashing the system when i start X. ideas about this as well ? Yes. NULLFS mounts do not work, due to a combination of aliasing problems and locking problems. There is a preliminary patch at http://www.freebsd.org/~eivind/FixNULL.patch that I believe fix the aliasing problems, and some of the locking problems, but not all. Using nullfs with this works somewhat, but sometimes get locks screwed up (which result in access to one file just hanging). Eivind. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Really! strange uid value
Jeroen Ruigrok/Asmodai once stated: = -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54 pdksh.core.xclink =this is exactly what I got when I tried to compile some things over NFS. =The created directory and files were also like this: = =1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ = =funny, the same value. There is something left out very fundamentally =somewhere. Just FYI. This number is 0xFFFE in hex... A search for this number through the sources does not bring anything under NFS itself, though the following may give a clue: src/sys/coda/coda.h: if (fid-Vnode == 0xfffe || fid-Vnode == 0x) src/sys/i386/include/apm_bios.h: #define APMINI_NOT32BIT 0xfffe src/usr.sbin/rpc.statd/file.c: status_info-ourState = (status_info-ourState + 2) 0xfffe; I ran the search over the 3.1-STABLE sources -- try it against yours... -mi To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Problem building natd
4.0-CURRENT supped about 3 hours ago, make buildworld: === usr.sbin/natd cc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/natd/natd.c /usr/src/usr.sbin/natd/natd.c: In function `SetAliasAddressFromIfName': /usr/src/usr.sbin/natd/natd.c:702: warning: implicit declaration of function `SetPacketAliasAddress' /usr/src/usr.sbin/natd/natd.c: In function `SetupPermanentLink': /usr/src/usr.sbin/natd/natd.c:1203: warning: implicit declaration of function `PacketAliasPermanentLink' cc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/natd/icmp.c cc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -o natd natd.o icmp.o -lalias natd.o: In function `SetAliasAddressFromIfName': natd.o(.text+0xc47): undefined reference to `SetPacketAliasAddress' natd.o: In function `SetupPermanentLink': natd.o(.text+0x12c4): undefined reference to `PacketAliasPermanentLink' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Any clues? Regards, Mike -- Mike Zanker | Email: a.m.zan...@open.ac.uk Network and Computer Services Group | Tel : +44 1908 652726 The Open University | Fax : +44 1908 652193 Milton Keynes, UK | PGP public key available To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kernel build failure at nfs_serv.c
On Wed, Feb 24, 1999 at 08:51:03AM +, Doug Rabson wrote: On Tue, 23 Feb 1999, Nicolas Souchu wrote: Hi folks, Updating at Mar 23 fév 1999 22:52:33 CET, cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf ../../nfs/nfs_serv.c ../../nfs/nfs_serv.c:103: `sysctl__vfs_nfs_children' undeclared here (not in a function) ../../nfs/nfs_serv.c:103: initializer element for `sysctl___vfs_nfs_async.oid_parent' is not constant *** Error code 1 Stop. Any clue? I think this is fixed - try updating nfs_serv.c World updated yesterday still fails in modules/nfs. Thanks for your help. Nicholas. -- nso...@teaser.fr / nso...@freebsd.org FreeBSD - Turning PCs into workstations - http://www.FreeBSD.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Really! strange uid value
Jeroen Ruigrok/Asmodai once stated: = -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54 pdksh.core.xclink =this is exactly what I got when I tried to compile some things over NFS. =The created directory and files were also like this: = =1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ = =funny, the same value. There is something left out very fundamentally =somewhere. Just FYI. This number is 0xFFFE in hex... A search for this number through the sources does not bring anything under NFS itself, though the following may give a clue: Remember that the nobody user is uid 65534 (0xfffe). The signed extension of this to 32 bits is 0xfffe. Maybe you're seeing uid 0 being translated to 65534 (due to NFS) and then sign extended. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kernel build failure at nfs_serv.c
On Sat, 27 Feb 1999, Nicolas Souchu wrote: On Wed, Feb 24, 1999 at 08:51:03AM +, Doug Rabson wrote: On Tue, 23 Feb 1999, Nicolas Souchu wrote: Hi folks, Updating at Mar 23 f?v 1999 22:52:33 CET, cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -DKERNEL -DVM_STACK -include opt_global.h -elf ../../nfs/nfs_serv.c ../../nfs/nfs_serv.c:103: `sysctl__vfs_nfs_children' undeclared here (not in a function) ../../nfs/nfs_serv.c:103: initializer element for `sysctl___vfs_nfs_async.oid_parent' is not constant *** Error code 1 Stop. Any clue? I think this is fixed - try updating nfs_serv.c World updated yesterday still fails in modules/nfs. Thanks for your help. If you could send me your kernel config, I'll fix it. It must be a particular combination of options which is causing trouble. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Really! strange uid value
On 27-Feb-99 sth...@nethelp.no wrote: Jeroen Ruigrok/Asmodai once stated: = -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54 pdksh.core.xclink =this is exactly what I got when I tried to compile some things over NFS. =The created directory and files were also like this: = =1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ = =funny, the same value. There is something left out very fundamentally =somewhere. Just FYI. This number is 0xFFFE in hex... A search for this number through the sources does not bring anything under NFS itself, though the following may give a clue: Remember that the nobody user is uid 65534 (0xfffe). The signed extension of this to 32 bits is 0xfffe. Maybe you're seeing uid 0 being translated to 65534 (due to NFS) and then sign extended. Could be, but that is still not correct behaviour as far as my knowledge goes. It should not get sign extended IMHO. Am I correct in assuming this (call to the more knowledgeable ones)? --- Jeroen Ruigrok van der Werven http://www.freebsdzine.org asmodai(at)wxs.nlThe idea does not replace the work... Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: Powered by Knowledge Know-how http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
make world fails on natd
My current box, cvsupped at abot 15:30 (CET) of the 27-02-1999 fails to complete the make world : === usr.sbin/natd cc -nostdinc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/natd/nat d.c cc -nostdinc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/natd/icm p.c gzip -cn /usr/src/usr.sbin/natd/natd.8 natd.8.gz /usr/src/usr.sbin/natd/natd.c: In function `SetAliasAddressFromIfName': /usr/src/usr.sbin/natd/natd.c:702: warning: implicit declaration of function `SetPacketAliasAd dress' /usr/src/usr.sbin/natd/natd.c: In function `SetupPermanentLink': /usr/src/usr.sbin/natd/natd.c:1203: warning: implicit declaration of function `PacketAliasPerm anentLink' cc -nostdinc -O -pipe -Wall -I/usr/obj/usr/src/tmp/usr/include -o natd natd.o icmp.o -lali as natd.o: In function `SetAliasAddressFromIfName': natd.o(.text+0xc47): undefined reference to `SetPacketAliasAddress' natd.o: In function `SetupPermanentLink': natd.o(.text+0x12c4): undefined reference to `PacketAliasPermanentLink' *** Error code 1 1 error -- Regards... Gianmarco Unix expert since yesterday http://www.giovannelli.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Really! strange uid value
Jeroen Ruigrok/Asmodai wrote: this is exactly what I got when I tried to compile some things over NFS. The created directory and files were also like this: 1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ funny, the same value. There is something left out very fundamentally somewhere. That looks like user nobody to me, though I might be mistaken. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: IDE CDROM not found with PIIX4 chipset, -current kernel
Bruce Evans wrote: There's only one, at least in my version. There is the PC98 one you removed, and then this one in atapi_request_immediate(): /* Wait for data i/o phase. */ for (cnt=2; cnt0; --cnt) if (((inb (ata-port + AR_IREASON) (ARI_CMD | ARI_IN)) | (inb (ata-port + AR_STATUS) ARS_DRQ)) != PHASE_CMDOUT) break; I sent this in for review a year or so ago, but received no reply. The main points are that it honours ATA timing in atapi_wait() and checks for ARS_BUSY in atapi_wait(). This hopefully makes bogus checks like the one in rev.1.22 unnecessary (status 0xff has ARS_BSY set so it is invalid). I haven't tested the PC98 case. I removed PC98 code that seems to only compensate for bugs in atapi_wait(). Looks reasonable to me, but I haven't read the specs in two years. Still, from the symptoms people described, I would urge anyone with trouble to test this patch. I realize sos is introducing a new driver soon, but, at the very least, this would be a -stable material. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org To make it absolutely clear: you stand on the wrong end of my blasters, so you better get lost before I start target practice! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Really! strange uid value
On Sat, 27 Feb 1999, Jeroen Ruigrok/Asmodai wrote: On 27-Feb-99 sth...@nethelp.no wrote: Jeroen Ruigrok/Asmodai once stated: = -rw-r--r--1 4294967294 wheel 389120 Feb 14 23:54 pdksh.core.xclink =this is exactly what I got when I tried to compile some things over NFS. =The created directory and files were also like this: = =1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ = =funny, the same value. There is something left out very fundamentally =somewhere. Just FYI. This number is 0xFFFE in hex... A search for this number through the sources does not bring anything under NFS itself, though the following may give a clue: Remember that the nobody user is uid 65534 (0xfffe). The signed extension of this to 32 bits is 0xfffe. Maybe you're seeing uid 0 being translated to 65534 (due to NFS) and then sign extended. Could be, but that is still not correct behaviour as far as my knowledge goes. It should not get sign extended IMHO. Am I correct in assuming this (call to the more knowledgeable ones)? Do you have a simple repeatable test? What OS is the server running? This kind of problem is easy to fix if I can reproduce it but I don't really have enough information. A packet trace of what happened when things went wrong would be helpful (tcpdump -vv -s300 is pretty useful). -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: What it means when running soffice 5.01
According to Chan Yiu Wah: Is there anyone knows what it means when running the soffice 5.01 . The message keeps growing as I using the soffice. Is it harmful the system? It is explained on htt://lt.tar.com/. You need the following lines in your kernel config file: # -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- # POSIX P1003.1B # Real time extensions added int the 1993 Posix # P1003_1B: Infrastructure # _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING # _KPOSIX_VERSION: Version kernel is built for options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #70: Sat Feb 27 09:43:08 CET 1999 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Really! strange uid value
=1 drwxr-xr-x 3 4294967294 wheel - 512 Feb 15 21:09 aout/ = =funny, the same value. There is something left out very fundamentally =somewhere. Just FYI. This number is 0xFFFE in hex... A search for this number through the sources does not bring anything under NFS itself, though the following may give a clue: Remember that the nobody user is uid 65534 (0xfffe). The signed extension of this to 32 bits is 0xfffe. Maybe you're seeing uid 0 being translated to 65534 (due to NFS) and then sign extended. Could be, but that is still not correct behaviour as far as my knowledge goes. It should not get sign extended IMHO. Am I correct in assuming this (call to the more knowledgeable ones)? Do you have a simple repeatable test? What OS is the server running? FreeBSD server, FreeBSD client, nfsv3: # cd world_writable_nfs_mounted_directory_which_shouldnt_exist # cat ^\ # ls -l cat.core -rw--- 1 4294967294 wheel 225280 Feb 28 03:06 cat.core 4294967294 is just the default mapped uid for root. It is (uid_t)-2. See mountd sources. It has nothing to do with user nobody or 65534, except possibly on buggy clients that silently truncate it mod 65536. Perhaps it is a bug to use (uid_t)-2 instead of 65534. For clients with only 16-bit uid_t's you would want to keep all uids on the server 65536. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Broken world
My 4.0-current buildworld broke. The sources were from yesterday night. The system is currently 4.0-current from Feb 16. My UNIX system is a 486 main board with an evergreen upgrade. The world was almost over, too! Argh! :-) Bret Ford === usr.sbin/natd gcc -O -Wall -I/tigger/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/natd/natd.c /usr/src/usr.sbin/natd/natd.c: In function `SetAliasAddressFromIfName': /usr/src/usr.sbin/natd/natd.c:702: warning: implicit declaration of function `SetPacketAliasAddress' /usr/src/usr.sbin/natd/natd.c: In function `SetupPermanentLink': /usr/src/usr.sbin/natd/natd.c:1203: warning: implicit declaration of function `PacketAliasPermanentLink' gcc -O -Wall -I/tigger/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/natd/icmp.c gcc -O -Wall -I/tigger/obj/usr/src/tmp/usr/include -o natd natd.o icmp.o -lalias natd.o: In function `SetAliasAddressFromIfName': natd.o(.text+0xc47): undefined reference to `SetPacketAliasAddress' natd.o: In function `SetupPermanentLink': natd.o(.text+0x12c4): undefined reference to `PacketAliasPermanentLink' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Really! strange uid value
I believe that (uid_t)-2 has a lot to do with the user nobody. That was the historical reason why the uid 65534 for chosen for nobody back when uid_t was only 16 bits. I would recommend that the default mapped uid for root be defined as 65534 instead of (uid_t)-2. This seems to make the most sense when trying to avoid user suprises. I would also suggest the default gid be changed similarly. (On Solaris 2.5.1, nobody is now uid 60001 with nobody4 as uid 65534 (for SunOS 4).) Jim Bloom bl...@acm.org Bruce Evans wrote: 4294967294 is just the default mapped uid for root. It is (uid_t)-2. See mountd sources. It has nothing to do with user nobody or 65534, except possibly on buggy clients that silently truncate it mod 65536. Perhaps it is a bug to use (uid_t)-2 instead of 65534. For clients with only 16-bit uid_t's you would want to keep all uids on the server 65536. Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
lockmgr panic with mmap()
The attached program sometimes causes a lockmgr panic. I do not think is always did. I am running 4.0-CURRENT form Feb 19. The trace is: panic lockmgr: locking against self lockmgr mv_map_growstack grow_stack trap_pfault trap calltrap subyte syscall ... A command on a running image such as this usually does it, though I do not know what conditions are neccessary: fincore /usr/local/netscape-4.5/communicator-4.5.bin Jonathan Hanna pango...@home.com fincore.c Description: fincore.c
Re: lockmgr panic with mmap()
On Sat, 27 Feb 1999, Jonathan Hanna wrote:
The attached program sometimes causes a lockmgr panic. I do not think is
always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
calltrap
subyte
syscall
...
A command on a running image such as this usually does it, though I do not
know what
conditions are neccessary:
fincore /usr/local/netscape-4.5/communicator-4.5.bin
Jonathan Hanna pango...@home.com
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type show copying to see the conditions.
There is absolutely no warranty for GDB; type show warranty for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2875392
initial pcb at 23ef40
panicstr: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
syncing disks... 10 10 6 done
dumping to dev 20001, offset 73728
dump 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39
38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13
12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xf0137821 in panic (fmt=0xf0206116 lockmgr: locking against myself)
at ../../kern/kern_shutdown.c:448
#2 0xf0133738 in lockmgr (lkp=0xf5f5f280, flags=2, interlkp=0x0, p=0xf5f688e0)
at ../../kern/kern_lock.c:320
#3 0xf01a5b25 in vm_map_growstack (p=0xf5f688e0, addr=134524928)
at ../../vm/vm_map.c:666
#4 0xf01dc52a in grow_stack (p=0xf5f688e0, sp=134524928)
at ../../i386/i386/vm_machdep.c:571
#5 0xf01d836f in trap_pfault (frame=0xf5f70ec8, usermode=0, eva=134524928)
at ../../i386/i386/trap.c:808
#6 0xf01d806e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1,
tf_esi = 0, tf_ebp = -168358064, tf_isp = -168358160,
tf_ebx = 672337920, tf_edx = 134524928, tf_ecx = -168366080, tf_eax = 1,
tf_trapno = 12, tf_err = 2, tf_eip = -266506240, tf_cs = 8,
tf_eflags = 66067, tf_esp = -266694180, tf_ss = 134524928})
at ../../i386/i386/trap.c:437
#7 0xf01d7000 in suibyte ()
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#9 0xf01cb69c in Xint0x80_syscall ()
#10 0x80485d1 in ?? ()
(kgdb) frame 8
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
1100error = (*callp-sy_call)(p, args);
(kgdb) print callp
$1 = (struct sysent *) 0x0
(kgdb) quit
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: mount -o union broken recently?
Julian Elischer jul...@whistle.com wrote:
On Fri, 26 Feb 1999, John Polstra wrote:
Julian Elischer wrote:
you want to commit?
(after you sir...)
No, really, after you ... :-)
Done
in 3.1 and 4
I just remembered that MNT_UNION occurs in another file which on
investigation turned out to be amongst the unionfs code that was
moved. It should be removed so that the code isn't run twice when
unionfs is enabled. Sorry for missing it the first time round! I also
tidied up the vfs_syscalls patch a bit.
Tony.
--
f.a.n.finch d...@dotat.at f...@demon.net
--- miscfs/union/union_subr.c.3.1 Sat Feb 27 20:44:14 1999
+++ miscfs/union/union_subr.c Sat Feb 27 20:47:28 1999
@@ -1183,15 +1183,6 @@
return -1; /* goto unionread */
}
}
- if (((*vp)-v_flag VROOT) ((*vp)-v_mount-mnt_flag MNT_UNION)) {
- struct vnode *tvp = *vp;
- *vp = (*vp)-v_mount-mnt_vnodecovered;
- VREF(*vp);
- fp-f_data = (caddr_t) *vp;
- fp-f_offset = 0;
- vrele(tvp);
- return -1; /* goto unionread */
- }
return error;
}
--- kern/vfs_syscalls.c.3.2 Sat Feb 27 20:55:32 1999
+++ kern/vfs_syscalls.c Sat Feb 27 21:00:26 1999
@@ -2756,23 +2756,24 @@
VOP_UNLOCK(vp, 0, p);
if (error)
return (error);
- if (union_dircheckp SCARG(uap, count) == auio.uio_resid) {
- error = union_dircheckp(p, vp, fp);
- if (error == -1)
+ if (SCARG(uap, count) == auio.uio_resid) {
+ if (union_dircheckp) {
+ error = union_dircheckp(p, vp, fp);
+ if (error == -1)
+ goto unionread;
+ if (error)
+ return (error);
+ }
+ if ((vp-v_flag VROOT)
+ (vp-v_mount-mnt_flag MNT_UNION)) {
+ struct vnode *tvp = vp;
+ vp = vp-v_mount-mnt_vnodecovered;
+ VREF(vp);
+ fp-f_data = (caddr_t) vp;
+ fp-f_offset = 0;
+ vrele(tvp);
goto unionread;
- if (error)
- return (error);
- }
- if ((SCARG(uap, count) == auio.uio_resid)
- (vp-v_flag VROOT)
- (vp-v_mount-mnt_flag MNT_UNION)) {
- struct vnode *tvp = vp;
- vp = vp-v_mount-mnt_vnodecovered;
- VREF(vp);
- fp-f_data = (caddr_t) vp;
- fp-f_offset = 0;
- vrele(tvp);
- goto unionread;
+ }
}
error = copyout((caddr_t)loff, (caddr_t)SCARG(uap, basep),
sizeof(long));
@@ -2833,23 +2834,24 @@
VOP_UNLOCK(vp, 0, p);
if (error)
return (error);
- if (union_dircheckp SCARG(uap, count) == auio.uio_resid) {
- error = union_dircheckp(p, vp, fp);
- if (error == -1)
+ if (SCARG(uap, count) == auio.uio_resid) {
+ if (union_dircheckp) {
+ error = union_dircheckp(p, vp, fp);
+ if (error == -1)
+ goto unionread;
+ if (error)
+ return (error);
+ }
+ if ((vp-v_flag VROOT)
+ (vp-v_mount-mnt_flag MNT_UNION)) {
+ struct vnode *tvp = vp;
+ vp = vp-v_mount-mnt_vnodecovered;
+ VREF(vp);
+ fp-f_data = (caddr_t) vp;
+ fp-f_offset = 0;
+ vrele(tvp);
goto unionread;
- if (error)
- return (error);
- }
- if ((SCARG(uap, count) == auio.uio_resid)
- (vp-v_flag VROOT)
- (vp-v_mount-mnt_flag MNT_UNION)) {
- struct vnode *tvp = vp;
- vp = vp-v_mount-mnt_vnodecovered;
- VREF(vp);
- fp-f_data = (caddr_t) vp;
- fp-f_offset = 0;
- vrele(tvp);
- goto unionread;
+ }
}
if (SCARG(uap, basep) != NULL) {
error = copyout((caddr_t)loff, (caddr_t)SCARG(uap, basep),
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-current in the body of the message
Re: Broken world
In article 199902271936.laa25...@uop.cs.uop.edu, Bret Ford bf...@uop.cs.uop.edu wrote: My 4.0-current buildworld broke. The sources were from yesterday night. The system is currently 4.0-current from Feb 16. My UNIX system is a 486 main board with an evergreen upgrade. The world was almost over, too! Argh! :-) Bret Ford === usr.sbin/natd gcc -O -Wall -I/tigger/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/natd/natd.c /usr/src/usr.sbin/natd/natd.c: In function `SetAliasAddressFromIfName': /usr/src/usr.sbin/natd/natd.c:702: warning: implicit declaration of function `SetPacketAliasAddress' /usr/src/usr.sbin/natd/natd.c: In function `SetupPermanentLink': /usr/src/usr.sbin/natd/natd.c:1203: warning: implicit declaration of function `PacketAliasPermanentLink' gcc -O -Wall -I/tigger/obj/usr/src/tmp/usr/include -c /usr/src/usr.sbin/natd/icmp.c gcc -O -Wall -I/tigger/obj/usr/src/tmp/usr/include -o natd natd.o icmp.o -lalias natd.o: In function `SetAliasAddressFromIfName': natd.o(.text+0xc47): undefined reference to `SetPacketAliasAddress' natd.o: In function `SetupPermanentLink': natd.o(.text+0x12c4): undefined reference to `PacketAliasPermanentLink' *** Error code 1 It was broken by the recent commit to src/lib/libalias. You can probably get around it by reverting that directory to around Feb 25. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA Nobody ever went broke underestimating the taste of the American public. -- H. L. Mencken To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
gcc
I know that, back when we ran aout, our gcc was a long way changed from the stock gnu gcc ... I'm wondering how much our gcc is changed, now, from the gcc that is the regular GNU distribution? I'm wondering about the size of a project, to upgrade the compiler (this wants a relative answer, how much larger or smaller a job is it now, that it would have been a year ago under aout)? Is anyone doing this? Has there been a decision, most especially from core, about whether we want to use the gcc 2.8.1, or the egcs compiler? What with the rather largeish changes that have gone into C++, it's becoming necessary to have a more up to date compiler. Just speaking about ports, there are a large and growing number of them that compile under 2.8.1, but have problems under 2.7.2.1 (because of exceptions, and other newer features). I'm finally feeling pressure to use a later compiler. I'm making do with the one from ports, but I'm curious about our system compiler. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
I'm wondering about the size of a project, to upgrade the compiler (this wants a relative answer, how much larger or smaller a job is it now, that it would have been a year ago under aout)? Is anyone doing this? Peter was working on it, but I strongly suspect he won't have time to even think about this in the very near future and we shouldn't allow him to add it to his plate, no matter how loudly he demands to suffer to excess. :-) It would probably be cool to find out what the last set of issues he identified and/or fixed with this was though. Has there been a decision, most especially from core, about whether we want to use the gcc 2.8.1, or the egcs compiler? I'm not sure I'd call it a decision, but there are strong leanings towards egcs. It simply seems to be moving more aggressively (and more well-fundedly) in the right directions whereas gcc 2.8.1 has been very slow to update. What with the rather largeish changes that have gone into C++, it's becoming necessary to have a more up to date compiler. Just speaking Yes. I can say authoritatively, for example, that there will probably never be a new sysinstall or package handling system without this change occurring since the new tools are written almost entirely in C++ and TCL and require many features not provided by 2.7.2.x. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Testers wanted for SiS 5591 code
I've been given some code for recognizing and initializing Sis 5591 chipsets. In particular, it solves a recently introduced problem with IDE Ultra DMA. It works fine for me, modulo a couple of puzzling messages in the verbose probes, which I'll remove when I've had time to study the data sheet. What I want to do now is to get it looked at by as many people as possible before committing it. If you have a motherboard with this chipset (and no other, not even other SiS chipsets), you can pick up ftp://ftp.lemis.com/pub/ide_pci.c. It's based on the current (since 17 January) version and goes in /sys/pci. If you do, please let me know how it works for you. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
RE: Testers wanted for SiS 5591 code
On 28-Feb-99 Greg Lehey wrote: I've been given some code for recognizing and initializing Sis 5591 chipsets. In particular, it solves a recently introduced problem with IDE Ultra DMA. It works fine for me, modulo a couple of puzzling messages in the verbose probes, which I'll remove when I've had time to study the data sheet. What I want to do now is to get it looked at by as many people as possible before committing it. If you have a motherboard with this chipset (and no other, not even other SiS chipsets), you can pick up ftp://ftp.lemis.com/pub/ide_pci.c. It's based on the current (since 17 January) version and goes in /sys/pci. If you do, please let me know how it works for you. Great, I was waiting for this.. Seems to work fine: Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 4.0-CURRENT #77: Sat Feb 27 18:09:34 PST 1999 n...@norn.ca.eu.org:/usr/src/sys/compile/NORN Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 167046751 Hz CPU: Pentium/P54C (167.05-MHz 586-class CPU) Origin = GenuineIntel Id = 0x52c Stepping=12 Features=0x1bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8 real memory = 67043328 (65472K bytes) avail memory = 62689280 (61220K bytes) Preloaded elf kernel kernel at 0xf026c000. Probing for devices on PCI bus 0: chip0: Host to PCI bridge (vendor=1039 device=5591) rev 0x02 on pci0.0.0 ide_pci0: SiS 5591 Bus-master IDE Controller rev 0xd0 int a irq 14 on pci0.0.1 chip1: SiS 85c503 rev 0x01 on pci0.1.0 chip2: PCI to PCI bridge (vendor=1039 device=0001) rev 0x00 on pci0.2.0 vga0: ATI Mach64-GT graphics accelerator rev 0x41 on pci0.9.0 es1: AudioPCI ES1370 rev 0x00 int a irq 11 on pci0.10.0 pcm1: using I/O space register mapping at 0xe400 de0: Digital 21041 Ethernet rev 0x21 int a irq 10 on pci0.11.0 de0: SMC 21041 [10Mb/s] pass 2.1 de0: address 00:e0:29:10:af:8a Probing for devices on PCI bus 1: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A ppc0 at 0x378 irq 7 on isa ppc0: Winbond chipset (NIBBLE-only) in COMPATIBLE mode plip0: PLIP network interface on ppbus 0 lpt0: generic printer on ppbus 0 lpt0: Interrupt-driven port 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 flags 0xa000a000 on isa wdc0: unit 0 (wd0): Maxtor 82560 A4 -, DMA, 32-bit wd0: 2442MB (5001696 sectors), 4962 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): FUJITSU MPC3102AT E, DMA, 32-bit wd1: 9765MB (2536 sectors), 19841 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): FX120T/b03, removable, intr, dma, iordis acd0: drive speed 2066KB/sec, 256KB cache acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm audio disc loaded, unlocked vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface de0: enabling 10baseT port Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert disabled, rule-based forwarding disabled , default to accept, logging limited to 100 packets/entry de0 XXX: driver didn't set ifq_maxlen changing root device to wd1s1a ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates n...@norn (~) dd if=/dev/zero of=testfile bs=32k count=1000 1000+0 records in 1000+0 records out 32768000 bytes transferred in 2.315757 secs (14150016 bytes/sec) --- Chris Piazza Abbotsford, BC, Canada cpia...@home.net finger n...@norn.ca.eu.org for PGP key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Testers wanted for SiS 5591 code
On Wednesday, 27 January 1999 at 18:17:20 -0800, Chris Piazza wrote: On 28-Feb-99 Greg Lehey wrote: I've been given some code for recognizing and initializing Sis 5591 chipsets. In particular, it solves a recently introduced problem with IDE Ultra DMA. It works fine for me, modulo a couple of puzzling messages in the verbose probes, which I'll remove when I've had time to study the data sheet. What I want to do now is to get it looked at by as many people as possible before committing it. If you have a motherboard with this chipset (and no other, not even other SiS chipsets), you can pick up ftp://ftp.lemis.com/pub/ide_pci.c. It's based on the current (since 17 January) version and goes in /sys/pci. If you do, please let me know how it works for you. Great, I was waiting for this.. Seems to work fine: Good to hear. wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa000a000 on isa wdc0: unit 0 (wd0): Maxtor 82560 A4 -, DMA, 32-bit wd0: 2442MB (5001696 sectors), 4962 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): FUJITSU MPC3102AT E, DMA, 32-bit wd1: 9765MB (2536 sectors), 19841 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 on isa wdc1: unit 0 (atapi): FX120T/b03, removable, intr, dma, iordis acd0: drive speed 2066KB/sec, 256KB cache acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm audio disc loaded, unlocked Try enabling UDMA on wdc1 and see if things still work OK. You could also enable multi-block DMA on both controllers. I use the flags 0xa0ffa0ff, which does both of these things. Also, if you could send me the output of a verbose boot, it would be interesting. Unfortunately, you'll need to change your kernel config to save that much output: options MSGBUF_SIZE=32768 # big msgbuf Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
TI PCI-1220 cardbus/PCI bridge
Is there any work in progress on sys/pccard/*? I'm using a Gateway Solo for the week which has the PCI/cardbus bridge mentioned in the title, and I have been getting spurious results with 4.0-CURRENT (supped a couple of days ago). If there are some patches in test which might enhance support for this laptop, pointers would be appreciated. Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: TI PCI-1220 cardbus/PCI bridge
On Sun, Feb 28, 1999 at 03:21:38PM +1300, Joe Abley wrote: Is there any work in progress on sys/pccard/*? I'm using a Gateway Solo for the week which has the PCI/cardbus bridge mentioned in the title, and I have been getting spurious results with 4.0-CURRENT (supped a couple of days ago). If there are some patches in test which might enhance support for this laptop, pointers would be appreciated. I have the same controller in my LifeBook 280dx, and I'd like to point out that it works fine with PAO, and not at all with 3.1-R. What probably needs to be done is a port of the pao3 kit (available via cvsup from jaz.jp.freebsd.org) to 3.1-R (and -stable). Maybe I need a swift kick in the rear to get off IRC and get around to it. Joe -- Nathan Dorfman nat...@rtfm.net The statements and opinions in my Unix Admin @ Frontline Communicationsusenet posts are mine, not FCC's. The light at the end of the tunnel is the headlight of an approaching train. --/usr/games/fortune To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
I know that, back when we ran aout, our gcc was a long way changed from the stock gnu gcc ... I'm wondering how much our gcc is changed, now, from the gcc that is the regular GNU distribution? $ cvs diff -r FSF /usr/src/contrib/gcc | wc 17467551 57123 [error output shows a botched import of gcc/config/alpha with no FSF tag; cvs history shows that gcc/config/alpha isn't even on a vendor branch] Bruce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Request for review: changes to if_vlan.c
While trying to figure out a way to support VLANs with the Alteon
gigabit NIC, I stumled across /sys/net/if_vlan.c. It seems simple
enough: pseudo IP interfaces are created which interacts with an
underlying physical interface and fixes up frame headers to deal
with VLAN tag encapsulation and extraction.
Unfortunately, the code totally fails to take into account the
possibility that the underlying interface can perform VLAN tag
insertion and extraction all by itself. The Alteon gigabit NIC is
just such an example: if you select 'VLAN assist' when configuring
the send/receive rings, the firmware will handle all the VLAN
naughty bits for you.
However, I still want to be able to use the VLAN pseudo interfaces
that if_vlan.c. provides, so to that end I tweaked it a little to
handle interfaces that do their own VLAN tag handling. The diffs
are appended to this message. What I did was change vlan_output()
so that if the IFF_LINK1 flag is set on the vlan pseudo interface,
the packet will be forwarded unmolested to the interface's output
routine, with a pointer to the vlan's ifnet structure in the mbuf
packet header. The underlying driver code can then track down the
vlan interface's structure information and find the vlan tag number
(which it needs to provide in the TX descriptor).
Reception is another issue; the existing vlan_input() routine expects
that it can find the 'parent' driver's ifnet structure in the mbuf
packet header and tries to extract the vlan tag directly from the
ethernet header (which it then uses to track down the associated
vlan pseudo interface). With the Alteon NIC, the driver's receive
routine already knows the tag number, but in order to get it to the
vlan code it would have to mangle the header on the packet that it
just received, which is pointless given that the firmware already went
to the trouble of finding it to begin with. Consequently, I added a
second input routine, vlan_input_tag(), which works almost like the
original vlan_input() except that the tag can pe specified explicitly
as an argument.
Lastly, I found what I think is a bug in vlan_output(). If the code
finds that the parent interface's output queue is full, it does
an IF_QFULL(), but then goes on try and queue the packet with
IF_ENQUEUE() anyway. I think this is wrong, and I inserted a
'continue' statement rahter than let the code fall through like
it was before. I'm not certain this is the correct fix though...
possibly vlan_output() should return with ENOBUFS.
Interested persons should review the diffs and pipe up if they have
some passionate argument argument against them.
Also, I should point out that while if_vlan provides the necessary
kernel hackery to implement VLANs, there isn't any user space utility
for configuring vlan interfaces (ifconfig doesn't seem to have any
vlan-specific code that I could see, and is no vlanconfig). There
also is no vlan(4) man page. If whoever originally added the vlan
code has plans to fix these two things, then by all means do so,
otherwise I'm going to take it upon myself to hack up ifconfig and
write the man pages myself.
-Bill
--
=
-Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu
Work: wp...@ctr.columbia.edu | Center for Telecommunications Research
Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City
=
It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness
=
*** if_vlan.c.orig Sat Feb 27 22:52:58 1999
--- if_vlan.c Sat Feb 27 23:04:41 1999
***
*** 39,44
--- 39,48
* ether_output() left on our output queue queue when it calls
* if_start(), rewrite them for use by the real outgoing interface,
* and ask it to send them.
+ *
+ * XXX It's incorrect to assume that we must always kludge up
+ * headers on the physical device's behalf: some devices support
+ * VLAN tag insersion and extraction in firmware.
*/
#include vlan.h
***
*** 113,124
ifp-if_resolvemulti = 0;
}
}
! PSEUDO_SET(vlaninit, if_vlan);
static void
vlan_ifinit(void *foo)
{
! ;
}
static void
--- 117,128
ifp-if_resolvemulti = 0;
}
}
! PSEUDO_SET(vlaninit, if_vlan)
static void
vlan_ifinit(void *foo)
{
! return;
}
static void
***
*** 142,163
bpf_mtap(ifp, m);
#endif /* NBPFILTER 0 */
- M_PREPEND(m, EVL_ENCAPLEN, M_DONTWAIT);
- if (m == 0)
- continue;
- /* M_PREPEND takes care of m_len, m_pkthdr.len for us */
-
/*
!* Transform the Ethernet header into an Ethernet header
!* with 802.1Q encapsulation.
Re: if_vlan (small correction)
Whoops... I just realized: the output function in if_vlan is vlan_start(), not vlan_output(), and it returns void, so what I said about ENOBUFS is wrong. I still think the 'continue' that I added is correct though. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: wp...@ctr.columbia.edu | Center for Telecommunications Research Home: wp...@skynet.ctr.columbia.edu | Columbia University, New York City = It is not I who am crazy; it is I who am mad! - Ren Hoek, Space Madness = To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: lockmgr panic with mmap() (fwd)
The attached program sometimes causes a lockmgr panic. I do not think is
always
did. I am running 4.0-CURRENT form Feb 19.
The trace is:
panic lockmgr: locking against self
lockmgr
mv_map_growstack
grow_stack
trap_pfault
trap
calltrap
subyte
syscall
...
A command on a running image such as this usually does it, though I do not
know what
conditions are neccessary:
fincore /usr/local/netscape-4.5/communicator-4.5.bin
Jonathan Hanna pango...@home.com
Yep, this is reproducible :(
GDB is free software and you are welcome to distribute copies of it
under certain conditions; type show copying to see the conditions.
There is absolutely no warranty for GDB; type show warranty for details.
GDB 4.16 (i386-unknown-freebsd),
Copyright 1996 Free Software Foundation, Inc...
IdlePTD 2875392
initial pcb at 23ef40
panicstr: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
syncing disks... 10 10 6 done
dumping to dev 20001, offset 73728
dump 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39
38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13
12 11 10 9 8 7 6 5 4 3 2 1
---
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
287 dumppcb.pcb_cr3 = rcr3();
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:287
#1 0xf0137821 in panic (fmt=0xf0206116 lockmgr: locking against myself)
at ../../kern/kern_shutdown.c:448
#2 0xf0133738 in lockmgr (lkp=0xf5f5f280, flags=2, interlkp=0x0, p=0xf5f688e0)
at ../../kern/kern_lock.c:320
#3 0xf01a5b25 in vm_map_growstack (p=0xf5f688e0, addr=134524928)
at ../../vm/vm_map.c:666
#4 0xf01dc52a in grow_stack (p=0xf5f688e0, sp=134524928)
at ../../i386/i386/vm_machdep.c:571
#5 0xf01d836f in trap_pfault (frame=0xf5f70ec8, usermode=0, eva=134524928)
at ../../i386/i386/trap.c:808
#6 0xf01d806e in trap (frame={tf_es = 16, tf_ds = 16, tf_edi = -1,
tf_esi = 0, tf_ebp = -168358064, tf_isp = -168358160,
tf_ebx = 672337920, tf_edx = 134524928, tf_ecx = -168366080, tf_eax = 1,
tf_trapno = 12, tf_err = 2, tf_eip = -266506240, tf_cs = 8,
tf_eflags = 66067, tf_esp = -266694180, tf_ss = 134524928})
at ../../i386/i386/trap.c:437
#7 0xf01d7000 in suibyte ()
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
#9 0xf01cb69c in Xint0x80_syscall ()
#10 0x80485d1 in ?? ()
(kgdb) frame 8
#8 0xf01d899f in syscall (frame={tf_es = 47, tf_ds = 47, tf_edi = 321312,
tf_esi = 134524928, tf_ebp = -272640092, tf_isp = -168357932,
tf_ebx = -272640036, tf_edx = 7, tf_ecx = 7, tf_eax = 78,
tf_trapno = 12, tf_err = 2, tf_eip = 671697364, tf_cs = 31,
tf_eflags = 582, tf_esp = -272640248, tf_ss = 47})
at ../../i386/i386/trap.c:1100
1100error = (*callp-sy_call)(p, args);
(kgdb) print callp
$1 = (struct sysent *) 0x0
(kgdb) quit
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: gcc
In message 19877.920165...@zippy.cdrom.com Jordan K. Hubbard writes: : I'm not sure I'd call it a decision, but there are strong leanings : towards egcs. It simply seems to be moving more aggressively (and : more well-fundedly) in the right directions whereas gcc 2.8.1 has been : very slow to update. I for one would love to see 2.8.1 or newer in the tree for my own, selfish reasons. Many ports (new architectures) would benefit from this. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: gcc
I for one would love to see 2.8.1 or newer in the tree for my own, selfish reasons. Many ports (new architectures) would benefit from this. Is that to say that you prefer it over egcs 1.1.1? If so, why? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: SiS 5591
Seems to work alright here. dmesg and dd tests follow. [before] mercury# dd if=/dev/zero of=/tmp/zero bs=1024k count=32 32+0 records in 32+0 records out 33554432 bytes transferred in 6.013635 secs (5579725 bytes/sec) mercury# [after] mercury# dd if=/dev/zero of=/tmp/zero bs=1024k count=32 32+0 records in 32+0 records out 33554432 bytes transferred in 5.892770 secs (5634706 bytes/sec) mercury# Not much gain with this drive :/ Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.1-STABLE #0: Sun Feb 28 01:32:47 EST 1999 galat...@mercury.novastar.com:/usr/src/sys/compile/MERCURY Timecounter i8254 frequency 1193225 Hz CPU: Pentium/P55C (166.45-MHz 586-class CPU) Origin = GenuineIntel Id = 0x543 Stepping=3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 33554432 (32768K bytes) avail memory = 29986816 (29284K bytes) Preloaded elf kernel kernel at 0xf02b7000. Probing for devices on PCI bus 0: chip0: Host to PCI bridge (vendor=1039 device=5571) rev 0x01 on pci0.0.0 chip1: SiS 85c503 rev 0x01 on pci0.1.0 ide_pci0: SiS 5591 Bus-master IDE Controller rev 0xc1 int a irq 14 on pci0.1.1 vga0: S3 Trio 64 graphics accelerator rev 0x06 int a irq 10 on pci0.7.0 xl0: 3Com 3c905 Fast Etherlink XL 10/100BaseTX rev 0x00 int a irq 11 on pci0.15.0 xl0: Ethernet address: 00:60:08:20:72:c8 xl0: autoneg complete, link status good (half-duplex, 10Mbps) Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color 16 virtual consoles, flags=0x0 atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found ppc0 at 0x378 irq 7 on isa ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A pca0 on motherboard pca0: PC speaker audio driver 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 flags 0xa0ffa0ff on isa wdc0: unit 0 (wd0): ST32531A, DMA, 32-bit, multi-block-16 wd0: 2439MB (4995648 sectors), 4956 cyls, 16 heads, 63 S/T, 512 B/S wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa wdc1: unit 0 (atapi): NEC CD-ROM DRIVE:251/4.14, removable, iordy acd0: drive speed 689KB/sec, 128KB cache acd0: supported read types: CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable changer, unlocked acd0: changer slot 0 no disk acd1: changer slot 1 no disk acd2: changer slot 2 no disk acd3: changer slot 3 no disk vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface apm0 on isa apm: found APM BIOS version 1.2 Intel Pentium detected, installing workaround for F00F bug IP packet filtering initialized, divert disabled, rule-based forwarding disabled, unlimited logging ffs_mountfs: superblock updated for soft updates ffs_mountfs: superblock updated for soft updates Tugrul Galatali To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
