Re: if_fpa.c is broke again.
Jim Bryant wrote: Hi, it looks like if_fpa.c has been modified again, but was checked into CVS untested. Actually, the problem is the opposite.. It has not been modified, but some of the old backwards compatability infrastructure got cleaned out, leaving fpa broken. It doesn't appear to be too hard to adapt to newbus, is it a major showstopper for you? from a basic GENERIC, with nothing other than the fddi and fpa devices added to the config, I get the attached messages on compile. also, i noticed that in pdareg.h, that the full duplex options are included in the structs, but they are used nowhere int he driver itself, that seems to use the adapter in half duplex mode. Are there plans to add the full duplex functionality in the near future? --- cc -c -O2 -mpentiumpro -march=pentiumpro -pipe -Wall -Wredundant-decls -Wnest ed-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winli ne -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sy s -I/usr/src/sys/dev -I/usr/src/sys/../include -I/usr/src/sys/contrib/dev/a cpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred- stack-boundary=2 /usr/src/sys/dev/pdq/if_fpa.c /usr/src/sys/dev/pdq/if_fpa.c:141: syntax error before `config_id' /usr/src/sys/dev/pdq/if_fpa.c:143: warning: function declaration isn't a prot otype /usr/src/sys/dev/pdq/if_fpa.c: In function `pdq_pci_probe': /usr/src/sys/dev/pdq/if_fpa.c:144: `device_id' undeclared (first use in this function) /usr/src/sys/dev/pdq/if_fpa.c:144: (Each undeclared identifier is reported on ly once /usr/src/sys/dev/pdq/if_fpa.c:144: for each function it appears in.) /usr/src/sys/dev/pdq/if_fpa.c: At top level: /usr/src/sys/dev/pdq/if_fpa.c:152: syntax error before `config_id' /usr/src/sys/dev/pdq/if_fpa.c:154: warning: function declaration isn't a prot otype /usr/src/sys/dev/pdq/if_fpa.c: In function `pdq_pci_attach': /usr/src/sys/dev/pdq/if_fpa.c:159: `unit' undeclared (first use in this funct ion) /usr/src/sys/dev/pdq/if_fpa.c:165: warning: implicit declaration of function `pci_conf_read' /usr/src/sys/dev/pdq/if_fpa.c:165: `config_id' undeclared (first use in this function) /usr/src/sys/dev/pdq/if_fpa.c:169: warning: implicit declaration of function `pci_conf_write' /usr/src/sys/dev/pdq/if_fpa.c:176: warning: implicit declaration of function `pci_map_mem' /usr/src/sys/dev/pdq/if_fpa.c:194: warning: implicit declaration of function `pci_map_int' /usr/src/sys/dev/pdq/if_fpa.c: At top level: /usr/src/sys/dev/pdq/if_fpa.c:210: variable `fpadevice' has initializer but i ncomplete type /usr/src/sys/dev/pdq/if_fpa.c:211: warning: excess elements in struct initial izer /usr/src/sys/dev/pdq/if_fpa.c:211: warning: (near initialization for `fpadevi ce') /usr/src/sys/dev/pdq/if_fpa.c:212: warning: excess elements in struct initial izer /usr/src/sys/dev/pdq/if_fpa.c:212: warning: (near initialization for `fpadevi ce') /usr/src/sys/dev/pdq/if_fpa.c:213: warning: excess elements in struct initial izer /usr/src/sys/dev/pdq/if_fpa.c:213: warning: (near initialization for `fpadevi ce') /usr/src/sys/dev/pdq/if_fpa.c:214: warning: excess elements in struct initial izer /usr/src/sys/dev/pdq/if_fpa.c:214: warning: (near initialization for `fpadevi ce') /usr/src/sys/dev/pdq/if_fpa.c:216: warning: excess elements in struct initial izer /usr/src/sys/dev/pdq/if_fpa.c:216: warning: (near initialization for `fpadevi ce') /usr/src/sys/dev/pdq/if_fpa.c:218: warning: type defaults to `int' in declara tion of `COMPAT_PCI_DRIVER' /usr/src/sys/dev/pdq/if_fpa.c:218: warning: parameter names (without types) i n function declaration /usr/src/sys/dev/pdq/if_fpa.c:218: warning: data definition has no type or st orage class /usr/src/sys/dev/pdq/if_fpa.c:210: warning: `fpadevice' defined but not used *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. jim -- All opinions expressed are mine, if you| "I will not be pushed, stamped, think otherwise, then go jump into turbid | briefed, debriefed, indexed, or radioactive waters and yell WAHOO !!! | numbered!" - #1, "The Prisoner" - - [EMAIL PROTECTED] KC5VDJ - HF to 23cm KC5VDJ@NW0I.#NEKS.KS.USA.NOA M HF/VHF: IC-706MkII VHF/UHF/SHF: IC-T81AKPC3+ PK-232MBXGrid: EM28p x - - ET has one helluva sense of humor, always anal-probing right-wing schizos! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for
Re: state of usb?
Could you send me the output of dmesg and the complaints usbd is producing? Nick On Tue, 21 Nov 2000 [EMAIL PROTECTED] wrote: What is the current state of the usbd? I keep getting messages that complain about a host controller error and a shutdown of the usb interface. And I don't even have any devices on my usb ports... JAN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Watch 100's of Channels on your New Free Satellite System!
FREE Satellite T.V. System and FREE Installation For a limited time we'll give you this top of the line Digital Satellite System for FREE! We'll even include Free installation. Enjoy 100's of Channels of crystal clear digital picture and cd stereo sound on your FREE Satellite TV System. Why pay for these items in a retail store, when we're giving you the same satellite package for free. Call 888-514-6881 to be Guaranteed Your FREE Satellite Today This Innovative 20" Satellite includes a stereo receiver and an infrared remote. With this FREE offer you will have both Interactive Television Capability and an On Screen Program Guide. This limited time FREE offer is much less than the monthly cost of cable tv. All you have to do is call us to arrange delivery. If you call today, we'll throw in a second receiver for your second T.V. free. Call 888-514-6881 to Begin Surfing through 100's of Channels Today! To be removed send email to [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
System hangs with -current ...
Over the past several months, as others have reported, I've been getting
system hangs using 5.0-CURRENT w/ SMP ... I've got DDB enabled, but
ctl-alt-esc doesn't break me to the debugger ...
I'm not complaining about the hangs, if I was overly concerned, I'd run
-STABLE, but I'm wondering how one goes about providing debug information
on them other then through DDB?
Thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Hey
Hey whats up- You gotta check out this A HREF="http://www.politiciansstink.com"www.Politicians Stink.com /A it's great. A couple of college kids set it up I think- If only CNN could write like that. Ne way give it a look- Cya around To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Subscription
Hello BSD gurus, Please subscribe me to what all newbies should know. I am currently trying to learn UNIX in all of its flavors. I might be too ambitious, but I'm too ignorant to the intracacies of UNIX to know better. I have acces to Sun Solaris and HP UNIX, andI have successfully installed both. However, I have found your site to be the most help/hope to my self-led instruction. Thank you for access to your books and software. sincerely from a BSD novice in training
Core dumps on Current Make World this morning
All the machines that I have running Current dumped core at the same place this morning. === share/termcap ex - /usr/src/share/termcap/termcap.src /usr/src/share/termcap/reorder /dev/null Segmentation fault - core dumped *** Error code 139 Stop in /usr/src/share/termcap. *** Error code 1 For a couple of days now, I haven't been able to use vi because it also dumps core on all the machines except the only one that was able to build world and a new kernel yesterday, just good timing I guess. I haven't seen this on the list. Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
do a 'make -k world' ... I had the same problem with vi, and the same
SegFault ... by using -k, it bypasses the error, which allows it to get to
the point that the newer vi is installed, which doesn't SegFault ...
On Tue, 2 Jan 2001, Charlie Root wrote:
All the machines that I have running Current dumped core at the same
place this morning.
=== share/termcap
ex - /usr/src/share/termcap/termcap.src /usr/src/share/termcap/reorder
/dev/null
Segmentation fault - core dumped
*** Error code 139
Stop in /usr/src/share/termcap.
*** Error code 1
For a couple of days now, I haven't been able to use vi because it also
dumps core on all the machines except the only one that was able to
build world and a new kernel yesterday, just good timing I guess. I
haven't seen this on the list.
Thanks,
ed
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
The Hermit Hacker wrote:
do a 'make -k world' ... I had the same problem with vi, and the same
SegFault ... by using -k, it bypasses the error, which allows it to get to
the point that the newer vi is installed, which doesn't SegFault ...
Thanks, I just started them all up with -k . I didn't even think of that.
Thanks again,
ed
On Tue, 2 Jan 2001, Charlie Root wrote:
All the machines that I have running Current dumped core at the same
place this morning.
=== share/termcap
ex - /usr/src/share/termcap/termcap.src /usr/src/share/termcap/reorder
/dev/null
Segmentation fault - core dumped
*** Error code 139
Stop in /usr/src/share/termcap.
*** Error code 1
For a couple of days now, I haven't been able to use vi because it also
dumps core on all the machines except the only one that was able to
build world and a new kernel yesterday, just good timing I guess. I
haven't seen this on the list.
Thanks,
ed
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
Same with me. All the machines that I have running Current dumped core at the same place this morning. === share/termcap ex - /usr/src/share/termcap/termcap.src /usr/src/share/termcap/reorder /dev/null Segmentation fault - core dumped *** Error code 139 Stop in /usr/src/share/termcap. *** Error code 1 For a couple of days now, I haven't been able to use vi because it also dumps core on all the machines except the only one that was able to build world and a new kernel yesterday, just good timing I guess. I haven't seen this on the list. Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current stalls...(now also panic)
Mark, Thanks a lot. I read Marc's mail first so I'm trying the -k solution first but I will also take USB support out of the kernels that have it. Thanks, ed Mark Hittinger wrote: Maybe this is related, maybe not... I upgraded to the latest CURRENT available this morning and now I also see occasional (albeit short) hangs sometimes, although the machine seems to be responsive otherwise. I see this also. If you aren't using USB but have it compiled into your kernel try commenting out all the "device" entries after "# USB support" in the config file. A kernel built without USB may not show the hangs. I think there is a buglet that has krept into the USB code within the last couple of weeks. Later Mark Hittinger Earthlink [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current stalls...(now also panic)
Szilveszter, I've got some other weird problems with cores and panics but vi is the only one that I can define well enough. I'm also taking all USB support from the kernels that have it to see if my other strange problems disappear like access to mysql databases with php4 cvs and some strange library problems that I am having with my new XFree4.0.2_3 with kde-2.0.1 and LinuxNetscape that I just installed on Dec. 31. (Poor timing, but sorting these things out is what makes life interesting :-) Thanks, ed Szilveszter Adam wrote: Hi! Maybe this is related, maybe not... I upgraded to the latest CURRENT available this morning and now I also see occasional (albeit short) hangs sometimes, although the machine seems to be responsive otherwise. But, not only that, I also got a cool panic while trying to do some stuff (like compiling the docs) and pressing Ctrl-Z in another tty. No X, no nothing. I was dropped into the debugger, but since I am not a ddb artist, I tried to avoid to type the whole trace by hand and in the process managed to reboot the box... oh well. Next time I will know. But, the panic message was this: panic: blockable mtx_enter() of lockmgr interlock when not legal @ ../../kern/kern_lock.c:247 Maybe this rings a bell with someone. The error was appearently caught by WITNESS, which I also have enabled in my kernel (albeit without MUTEX_DEBUG, because *that* really made it impossible to do anything sensible on the machine...) Hardware-wise, nothing fancy here... UP PII-233, 128M non-ECC RAM, all-IDE, two disks, one CD-ROM. Next time, I promise to write down all the details... but just wanted to chime in quickly since this might be related to the hangs other people are seeing, but maybe they don't panic() because they don't have WITNESS enabled (just speculating) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: System hangs with -current ...
On 02-Jan-01 The Hermit Hacker wrote: Over the past several months, as others have reported, I've been getting system hangs using 5.0-CURRENT w/ SMP ... I've got DDB enabled, but ctl-alt-esc doesn't break me to the debugger ... I'm not complaining about the hangs, if I was overly concerned, I'd run -STABLE, but I'm wondering how one goes about providing debug information on them other then through DDB? Not easily. :( If you can make the problem easily repeatable, then you can try turning on KTR in your kernel (see NOTES, you will need KTR_EXTEND), setting up a serial console that you log the output of, create a shell script that runs the following commands: #!/bin/sh # Turn on KTR_INTR, KTR_PROC, and KTR_LOCK sysctl -w debug.ktr_mask=0x1208 sysctl -w debug.ktr_verbose=2 run_magic_command_that_hangs_my_machine and run the script. You probably want to run it over a tty or remote login so tthat the serial console output is just the logging (warning, it will be very verbose!). Also, you probably want to use http://www.FreeBSD.org/~jhb/patches/mtx_quiet.patch to shut up most of the irrelevant and cluttery mutex trace messages. Note that having this much logging on will probably slow the machine to a crawl as well, so you may have to just start this up and go off and do something else until it hangs. :-/ Another alternative is to rig up a NMI debouncer and use it to break into the debugger. Then you can start poking around to see who owns sched_lock, etc. Thanks ... -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Core dumps on Current Make World this morning
same here as well... i did a make -k buildworld and that worked for me/.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Matthew Jacob Sent: Tuesday, January 02, 2001 1:06 PM To: Charlie Root Cc: [EMAIL PROTECTED] Subject: Re: Core dumps on Current Make World this morning Same with me. All the machines that I have running Current dumped core at the same place this morning. === share/termcap ex - /usr/src/share/termcap/termcap.src /usr/src/share/termcap/reorder /dev/null Segmentation fault - core dumped *** Error code 139 Stop in /usr/src/share/termcap. *** Error code 1 For a couple of days now, I haven't been able to use vi because it also dumps core on all the machines except the only one that was able to build world and a new kernel yesterday, just good timing I guess. I haven't seen this on the list. Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Weird NFS error using Solaris 8 client
In December 1998 a message from Paul van der Zwan with a similar
subject
( http://lists.openresources.com/FreeBSD/freebsd-current/msg00018.html )
started a thread dealing with a problem of bad timestamps for NFS
files. By the end of the thread Doug Rabson had apparently solved the
problem for FreeBSD NFS clients and a Solaris 7 NFS server.
Unfortunately, the problem does not seem to have been solved yet for a
FreeBSD NFS server with Solaris 8 NFS clients.
Our FreeBSD NFS server is running 4.1.1-stable. Our Solaris clients are
running Solaris 5.8. I can produce our problem with the same test program
that was used in that message from 1998:
#include fcntl.h
main()
{
int rv;
rv=open("testfile1",O_CREAT|O_RDWR|O_EXCL,0666);
if ( rv 0 )
perror("testfile1");
rv=open("testfile2",O_CREAT|O_RDWR,0666);
if ( rv 0 )
perror("testfile2");
}
When I run the above program on a FreeBSD client using a FreeBSD NFS
server there are no errors reported. I can list the files:
[culler@seifert culler]$ ls -l testfile*
-rw--- 1 culler 30007 0 Jan 2 14:07 testfile1
-rw--- 1 culler 30007 0 Jan 2 14:07 testfile2
But, if I now login to a Solaris 8 client which is using the same FreeBSD
NFS server I am not able to stat testfile1:
[culler@neumann culler]$ ls -l testfile*
ls: testfile1: Value too large for defined data type
-rw--- 1 culler 30007 0 Jan 2 14:07 testfile2
If I go back to the FreeBSD client and touch testfile1, the error
disappears:
[culler@seifert culler]$ touch testfile1
[culler@neumann culler]$ ls -l testfile1
-rw--- 1 culler 30007 0 Jan 2 14:11 testfile1
I presume that the problem still has to do with bad timestamps, but
under some slightly different situation than in December 1998. Can
anyone help us? Sadly, pine seems to trigger this bug, so we are
getting a fair number of these bad files. Thanks.
Marc Culler
Department of Mathematics
University of Illinois at Chicago
PS Here are the revision numbers for nfs_vnops.c and nfs_vfsops.c on our
FreeBSD test machines.
FreeBSD client:
$FreeBSD: src/sys/nfs/nfs_vnops.c,v 1.150 2000/01/05 00:32:18 dillon Exp $
$FreeBSD: src/sys/nfs/nfs_vfsops.c,v 1.91 2000/01/05 05:11:37 dillon Exp $
FreeBSD server:
$FreeBSD: src/sys/nfs/nfs_vnops.c,v 1.150 2000/01/05 00:32:18 dillon Exp $
$FreeBSD: src/sys/nfs/nfs_vfsops.c,v 1.91.2.1 2000/09/10 01:45:36 ps Exp $
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message [EMAIL PROTECTED] Matthew Jacob writes: : Same with me. This sounds like a job for Captain UPDATING: 20010101: ex and vi were broken by some changes to sys/queue.h. If you have a bad vi (and are getting core dumps when building termcap), you can work around this problem by adding -k to your command line. This will cause the build to complete and install a new vi. Once that's done, you can rebuild again without the -k to pick up anything that might have been ignored by the -k option. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
Ta-da! In message [EMAIL PROTECTED] Matthew Jacob writes: : Same with me. This sounds like a job for Captain UPDATING: 20010101: ex and vi were broken by some changes to sys/queue.h. If you have a bad vi (and are getting core dumps when building termcap), you can work around this problem by adding -k to your command line. This will cause the build to complete and install a new vi. Once that's done, you can rebuild again without the -k to pick up anything that might have been ignored by the -k option. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
How do you create your leads? 15344
Title: Email Letter Reach Millions With Your Product or Service! We are a professional commercial e-mail service that has been in business for over 6 years. We can help you reach more potential customers through e-mail. No doubt you've heard every horror story about UCE, but frankly it's not true. There is a very small element that does not want the Internet to be used for commercial purposes, but isn't that what the Internet really is? And it completely legal to send commercial e-mail. There is Target and Bulk Email. We can send either for you! We've mailed for hundreds of Fortune 500 companies over the last 6 years, and many of them you would recognize. Here are some of the advantages: No Printing Cost! No Handling (stuffing envelops)! No Postage! Cost Effective Too! We do all the mailing, you have no hassle! We will assist you in the preparation of your e-mail letter! We provide you with "FREE" voice mail! Results!!! Ask us for our Special Introduction Price when you phone. We will show you that e-mailing works! For complete details, phone (877) 203-3700 ext. 150 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
:Ta-da! : : : In message [EMAIL PROTECTED] Matthew Jacob :writes: : : Same with me. : : This sounds like a job for Captain UPDATING: : : 20010101: : ex and vi were broken by some changes to sys/queue.h. If : you have a bad vi (and are getting core dumps when building : termcap), you can work around this problem by adding -k to : your command line. This will cause the build to complete : and install a new vi. Once that's done, you can rebuild again : without the -k to pick up anything that might have been : ignored by the -k option. Why in (insert favorite deity)'s name does ex and vi depend on sys/queue.h ? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
Why in (insert favorite deity)'s name does ex and vi depend on sys/queue.h ? Oh, christ, who knows? I just saw the new David Mamet film "State Main"... in one scene, Alec Baldwin has just crashed a stationwagon and flipped it, wiping out the only stoplight in this town. he crawls out of the wreckage, lounges against the car and says, "Well... that happened." Thie sys/queue.h is probably of the same order. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message [EMAIL PROTECTED] Matt Dillon writes: : Why in (insert favorite deity)'s name does ex and vi depend on : sys/queue.h ? Because it does. :-) Lots of places in the userland tree use it. phk committed a fix to vi that broke vi, and that's the problem. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message [EMAIL PROTECTED] Matthew Jacob writes: : Same with me. This sounds like a job for Captain UPDATING: Don't you just need to rebuild vi/ex? Ie would not: cd /usr/src/usr.bin/vi; make cleandir make obj make depend make all install fix the problem? Two buildworlds seems like a big sledgehammer when a small tap with a 2oz would do :-) 20010101: ex and vi were broken by some changes to sys/queue.h. If you have a bad vi (and are getting core dumps when building termcap), you can work around this problem by adding -k to your command line. This will cause the build to complete and install a new vi. Once that's done, you can rebuild again without the -k to pick up anything that might have been ignored by the -k option. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message [EMAIL PROTECTED], Matt Dillon writes: :Ta-da! : : : In message [EMAIL PROTECTED] Matthew Jacob writes: : : Same with me. : : This sounds like a job for Captain UPDATING: : : 20010101: : ex and vi were broken by some changes to sys/queue.h. If : you have a bad vi (and are getting core dumps when building : termcap), you can work around this problem by adding -k to : your command line. This will cause the build to complete : and install a new vi. Once that's done, you can rebuild again : without the -k to pick up anything that might have been : ignored by the -k option. Why in (insert favorite deity)'s name does ex and vi depend on sys/queue.h ? Actually they don't, they depend on db1.85's "mpool" which depends on sys/queue.h since it lives in libc. vi/ex comes with their own copy of sys/queue.h -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message [EMAIL PROTECTED] "Rodney W. Grimes" writes: : This sounds like a job for Captain UPDATING: : : Don't you just need to rebuild vi/ex? Ie would not: : cd /usr/src/usr.bin/vi; : make cleandir make obj make depend make all install : fix the problem? : : Two buildworlds seems like a big sledgehammer when a small tap with : a 2oz would do :-) If someone with a bad vi tries this and it works, I'll change it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message [EMAIL PROTECTED], "Rodney W. Grimes" writes : In message [EMAIL PROTECTED] Matthew Jacob writes: : Same with me. This sounds like a job for Captain UPDATING: Don't you just need to rebuild vi/ex? Ie would not: cd /usr/src/usr.bin/vi; make cleandir make obj make depend make all install fix the problem? Two buildworlds seems like a big sledgehammer when a small tap with a 2oz would do :-) It's actually libc you need to reinstall (unless your vi/ex is statically linked). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core dumps on Current Make World this morning
In message [EMAIL PROTECTED], "Rodney W. Grimes" writes : In message [EMAIL PROTECTED] Matthew Jacob writes: : Same with me. This sounds like a job for Captain UPDATING: Don't you just need to rebuild vi/ex? Ie would not: cd /usr/src/usr.bin/vi; make cleandir make obj make depend make all install fix the problem? Two buildworlds seems like a big sledgehammer when a small tap with a 2oz would do :-) It's actually libc you need to reinstall (unless your vi/ex is statically linked). Okay... cd /usr/src/lib/libc; make cleandir make obj make depend make all install -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: hw.sndunit - hw.snd.unit
A heads up to everyone who has hw.sndunit set to something in /etc/sysctl.conf, it is now hw.snd.unit. -FW: [EMAIL PROTECTED]- jhb 2001/01/02 17:25:26 PST Modified files: sys/dev/sound/pcmsound.c sound.h Log: Create a new sysctl node 'hw.snd' and move 'hw.sndunit' to 'hw.snd.unit'. Reviewed by: cg --End of forwarded message- -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Fatal trap while printing under SMP
When trying to print using a current SMP kernel, I get the following: Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0c00 fault virtual address = 0xe1810412 fault code = supervisor write, page not present instruction pointer = 0x8:0xcb0a7977 stack pointer = 0x10:0xcb08cf84 frame pointer = 0x10:0xcb08cf9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 30652 (irq7: lpt0) trap number = 12 panic: page fault cpuid = 1; lapic.id = 0c00 boot() called on cpu#1 syncing disks... Printing works fine with a current non SMP kernel. Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fatal trap while printing under SMP
On Tuesday, 2 January 2001 at 20:49:04 -0800, Manfred Antar wrote: When trying to print using a current SMP kernel, I get the following: Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0c00 fault virtual address = 0xe1810412 fault code = supervisor write, page not present instruction pointer = 0x8:0xcb0a7977 stack pointer = 0x10:0xcb08cf84 frame pointer = 0x10:0xcb08cf9c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 30652 (irq7: lpt0) trap number = 12 panic: page fault cpuid = 1; lapic.id = 0c00 boot() called on cpu#1 We really need more information than this. Can you get a dump, or at least a stack trace? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Fatal trap while printing under SMP
Here is what I saw on 12/24. This is with DDB and KTRACE. I added options WITNESS options INVARIANT_SUPPORT options INVARIANTS but gained no futher information. Fatal Trap 12: page fault while in kernel mode cpuid=0; lapic.id= fault virtual address = 0x18c7a2bb fault code= 0x8:0xc6bb0ca0 stack pointer = 0x10:0xc7aa1f84 frame pointer = 0x10:0xc7aa1f9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor flags = interrupt enabled, resume, IOPL=0 current process = 416 (irq7, lpt0) kernel: type 12 trap, code=0 cpu0 stopping CPUs: 0x0002... stopped stopped at 0xc6bb0ca0: movb 0x18c7a22b, %al db trace _end(0) at 0xc6bb0ca0 fork_trampoline() at fork_trampoline+0x45 tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unexpected vn driver lock:
I see these messages regularly when building releases on my SMP current box. It happens during the part where the floppies are built. It does not break the build process and the machine does not panic, so it isn't a big problem for me. Maybe it rings a bell for someone. This is with a kernel built yesterday, but it also happened with a kernel built on Dec 21. # unexpected vn driver lock: 0xc9494d00: type VREG, usecount 2, writecount 1, refcount 541, flags (VOBJBUF) tag VT_UFS, ino 403493, on dev #da/20 (13, 20) lock type inode: EXCL (count 1) by pid 4 unexpected vn driver lock: 0xc9494d00: type VREG, usecount 2, writecount 1, refcount 322, flags (VOBJBUF) tag VT_UFS, ino 403493, on dev #da/20 (13, 20) lock type inode: EXCL (count 1) by pid 4 unexpected vn driver lock: 0xc9580f00: type VREG, usecount 2, writecount 1, refcount 361, flags (VOBJBUF) tag VT_UFS, ino 382428, on dev #da/20 (13, 20) lock type inode: EXCL (count 1) by pid 4 unexpected vn driver lock: 0xc90c4d00: type VREG, usecount 2, writecount 1, refcount 541, flags (VOBJBUF) tag VT_UFS, ino 404067, on dev #da/20 (13, 20) lock type inode: EXCL (count 1) by pid 4 unexpected vn driver lock: 0xc90c4d00: type VREG, usecount 2, writecount 1, refcount 181, flags (VOBJBUF) tag VT_UFS, ino 404079, on dev #da/20 (13, 20) lock type inode: EXCL (count 1) by pid 76048 ## John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
