Re: XXX driver didn't initialize queue mtx
cvs annotate is your friend. The code was added in revision 1.95 of src/sys/net/if.c by Jonathan Lemon. Please talk to him about what should be done to fix the drivers. Yes, and I shall... but this came up in a public forum. I'm making a point here (that apparently you and others don't get). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4GB with NFS?
On Thu, Jan 25, 2001 at 02:18:01PM -0800, Matthew Jacob wrote: An update on this If the server is Solaris, neither NetBSD nor FreeBSD (i386 or alpha) have a problem (as clients). The problem is therefore in some interaction between this server (see http://www.traakan.com- sorta like a NetApp) and *BSD. Hmm!!! Did you check *BSD uses NFSv3 with this server ? Other than believing what it says on the server and and doing it manually, no. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
4GB with NFS?
I came across an embarrassing comparison last night- FreeBSD NFS clients (well, i386) stop writing files at 4GB. Solaris, with O_LARGEFILE options in the open arguments, does not. Does anyone here know what FreeBSD ought to be doing about this? Or have I missed something? There is no O_LARGEFILE in fcntl.h (it is present for Solaris, ConvexOS and some other platforms, I believe). I thought the *BSDs had 32 bit file support? Or is it only for local filesystems? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4GB with NFS?
On Thu, 25 Jan 2001, Dan Nelson wrote: In the last episode (Jan 25), Matthew Jacob said: I came across an embarrassing comparison last night- FreeBSD NFS clients (well, i386) stop writing files at 4GB. Solaris, with O_LARGEFILE options in the open arguments, does not. Does anyone here know what FreeBSD ought to be doing about this? Or have I missed something? There is no O_LARGEFILE in fcntl.h (it is present for Solaris, ConvexOS and some other platforms, I believe). I thought the *BSDs had 32 bit file support? Or is it only for local filesystems? FreeBSD has 64-bit file offsets by default, which make -DLARGEFILE hackery unnecessary. So I thought! Make sure you're using NFSv3 mounts (should be the default, but if not, add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, Tru64, and Solaris boxes via NFS and can access large files on all combinations of client and server. Huh. Interesting. The default showed up as a nfsv3 mount: 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 The solaris mount showed up as: 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 I'll try an explicit v3 mount/tcp and see if it's better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4GB with NFS?
To be fair, I should say that the server is a 'specical' box. But an lmdd writing to a file in 250GB partition that I started from Solaris last night is still going. The NetBSD FreeBSD writes both stopped at 4GB. I suppose it still could be the server, but, well, it's hard to sell against something that "just works"... .:-) On Thu, 25 Jan 2001, Matthew Jacob wrote: On Thu, 25 Jan 2001, Dan Nelson wrote: In the last episode (Jan 25), Matthew Jacob said: I came across an embarrassing comparison last night- FreeBSD NFS clients (well, i386) stop writing files at 4GB. Solaris, with O_LARGEFILE options in the open arguments, does not. Does anyone here know what FreeBSD ought to be doing about this? Or have I missed something? There is no O_LARGEFILE in fcntl.h (it is present for Solaris, ConvexOS and some other platforms, I believe). I thought the *BSDs had 32 bit file support? Or is it only for local filesystems? FreeBSD has 64-bit file offsets by default, which make -DLARGEFILE hackery unnecessary. So I thought! Make sure you're using NFSv3 mounts (should be the default, but if not, add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, Tru64, and Solaris boxes via NFS and can access large files on all combinations of client and server. Huh. Interesting. The default showed up as a nfsv3 mount: 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 The solaris mount showed up as: 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 I'll try an explicit v3 mount/tcp and see if it's better. 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: 4GB with NFS?
On Thu, 25 Jan 2001, Dan Nelson wrote: In the last episode (Jan 25), Matthew Jacob said: On Thu, 25 Jan 2001, Dan Nelson wrote: Make sure you're using NFSv3 mounts (should be the default, but if not, add "nfsv3" to the options column in fstab). I cross-mount FreeBSD, Tru64, and Solaris boxes via NFS and can access large files on all combinations of client and server. Huh. Interesting. The default showed up as a nfsv3 mount: 1/25 2:12 mountd/v3: granted 192.67.166.79 to /bob ro=0 uid0=60001 The solaris mount showed up as: 1/25 2:06 mountd/v3: granted 192.67.166.155 to /bob ro=0 uid0=60001 1/25 2:06 nfs/tcp accepted 192.67.166.155,1023 I'll try an explicit v3 mount/tcp and see if it's better. I use UDP mounts as it's easier to debug traces. The next step is to start looking as packet dumps... When you say that the FreeBSD clients "stop writing", what error do they get? None. As in EOF. Also, what version of FreeBSD are you using? 4.2 in this case. 1.5.1 for NetBSD. Okay- I think from what you've said and what Thor said for NetBSD is that this is "supposed to work!" (which accords with what *I* thought too). I'll do some more debugging as I can (I'm in a project deadline for 3 projects this week). But I won't let it go! I was hoping to replace my Solaris box with either FreeBSD or NetBSD as my main home directory server. FreeBSD 4.2 panics part way through the first LADDIS runs I was using to test it with and I can't get NetBSD to start as a LADDIS client (I hadn't got the auth sorted out yet), so I've been trying to scrutinize a lot of things very closely in this area. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4GB with NFS?
But I won't let it go! I was hoping to replace my Solaris box with either FreeBSD or NetBSD as my main home directory server. FreeBSD 4.2 panics part way through the first LADDIS runs I was using to test it with and I can't get NetBSD to start as a LADDIS client (I hadn't got the auth sorted out yet), so I've been trying to scrutinize a lot of things very closely in this area. This is an old problem that I think was never addressed. It has to do with the vm system (on i386). It may be fixed now, so keep playing a bit, if not open a problem report and someone ought to get to it. Yah, I was gonna do that once -current stabilized a bit. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4GB with NFS?
On Thu, 25 Jan 2001, Andrew Gallatin wrote: Matthew Jacob writes: I came across an embarrassing comparison last night- FreeBSD NFS clients (well, i386) stop writing files at 4GB. Solaris, with O_LARGEFILE options in the open arguments, does not. Does anyone here know what FreeBSD ought to be doing about this? Or have I missed something? There is no O_LARGEFILE in fcntl.h (it is present for Solaris, ConvexOS and some other platforms, I believe). I thought the *BSDs had 32 bit file support? Or is it only for local filesystems? -matt Normal /bin/dd works fine between on 4.2-RELEASE i386s here. This is writing to a raid0 fs on a FreeBSD/i386 server using an nfsv3 mount, udp, 8k read/write size: % dd if=/dev/zero of=bigfile bs=1024k count=5000 5000+0 records in 5000+0 records out 524288 bytes transferred in 471.673794 secs (5479 bytes/sec) This is writing to a software raid5 fs on a Solaris/x86 (2.8) server using an nfsv3 mount, udp, 8k read/write size: % dd if=/dev/zero of=bigfile bs=1024k count=5000 5000+0 records in 5000+0 records out 524288 bytes transferred in 1165.859965 secs (4497007 bytes/sec) Maybe you should look at "lmdd" ? Maybe it is either buggy, or it was compiled a long, long time ago? Same code compiled on Solaris is happy. (btw, this is a virgin 4.2 install, with none of my nfs opts in it). Hmm. Well, everyone sez this oughta work so I'll go and figure out why it ain't for me... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4GB with NFS?
Matthew Jacob writes: Same code compiled on Solaris is happy. Perhaps there's some braindamage in it. I'm afraid of something like: #ifdef Solaris typedef filefoo u_int64_t; #else typedef filefoo u_int32_t; #endif I'll try with dd then,... let y'all know... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4GB with NFS?
knowing NFS in general far better than *BSD in specific, I would guess the best thing to do (if you suspect server/client communication anomaly) is to grab a snoop/tcpdump of the failure. I'm trying to think of a clever way to cause the failure immediately, so you're not tracing 4GB of writes... mebbe dd's seek/skip? or just append to the existing 4GB file. also, what command are you using on the bsd's to write the 4GB file? I've lmdd or dd... definitely seen issues with VLF-capable OS's failing to write past 2/4GB due to VLF-incapable utilities. (on a related note, is there a need for vlfread()/vlfwrite() in the BSD's, or is VLF support native in the read/write calls? An update on this If the server is Solaris, neither NetBSD nor FreeBSD (i386 or alpha) have a problem (as clients). The problem is therefore in some interaction between this server (see http://www.traakan.com- sorta like a NetApp) and *BSD. Hmm!!! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world build broken in -current as of yesterday
Nope, been fixed. I fixed it quickly and was yelled at by DES who fixed it better. === usr.bin/vmstat cc -O -pipe -I/usr/src/usr.bin/vmstat/../../sys -I/usr/obj/usr/src/i386/usr/in clude -c /usr/src/usr.bin/vmstat/vmstat.c /usr/src/usr.bin/vmstat/vmstat.c:483: warning: `pgtok' redefined /usr/obj/usr/src/i386/usr/include/machine/param.h:166: warning: this is the loca tion of the previous definition /usr/src/usr.bin/vmstat/vmstat.c: In function `dozmem': /usr/src/usr.bin/vmstat/vmstat.c:907: structure has no member named `znext' *** Error code 1 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
a panic from recent changes...
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db t
Debugger(c02b8303) at Debugger+0x44
panic(c02c9040,bfc0,581000,c02ea620,c030ab0c) at panic+0x70
kmem_malloc(c0312d20,bfc0,8,bfbff810,c898) at kmem_malloc+0xd7
malloc(bfbff810,c02ea620,8,c0ff1e00,c898) at malloc+0x248
vfs_hang_addrlist(c0ff1e00,c0feac6c,c898,c0ff5000,c80c9f00) at
vfs_hang_addrlist+0x8f
vfs_export(c0ff1e00,c0feac6c,c898,4,c0ff1e00) at vfs_export+0x61
ffs_mount(c0ff1e00,809f0b0,bfbff6b8,c8ddde9c,c7add980) at ffs_mount+0x3ee
mount(c7add980,c8dddf80,809f0b1,0,0) at mount+0x5e7
syscall2(2f,2f,2f,0,0) at syscall2+0x285
Xint0x80_syscall() at Xint0x80_syscall+0x23
--- syscall 0x15, eip = 0x804f51c, esp = 0xbfbff684, ebp = 0xbfbff780 ---
mountd exporting stuff causes a panic.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: a panic from recent changes...
* Matthew Jacob [EMAIL PROTECTED] [010122 15:32] wrote:
Debugger("panic")
Stopped at Debugger+0x44: pushl %ebx
db t
Debugger(c02b8303) at Debugger+0x44
panic(c02c9040,bfc0,581000,c02ea620,c030ab0c) at panic+0x70
kmem_malloc(c0312d20,bfc0,8,bfbff810,c898) at kmem_malloc+0xd7
malloc(bfbff810,c02ea620,8,c0ff1e00,c898) at malloc+0x248
vfs_hang_addrlist(c0ff1e00,c0feac6c,c898,c0ff5000,c80c9f00) at
vfs_hang_addrlist+0x8f
vfs_export(c0ff1e00,c0feac6c,c898,4,c0ff1e00) at vfs_export+0x61
ffs_mount(c0ff1e00,809f0b0,bfbff6b8,c8ddde9c,c7add980) at ffs_mount+0x3ee
mount(c7add980,c8dddf80,809f0b1,0,0) at mount+0x5e7
syscall2(2f,2f,2f,0,0) at syscall2+0x285
Xint0x80_syscall() at Xint0x80_syscall+0x23
--- syscall 0x15, eip = 0x804f51c, esp = 0xbfbff684, ebp = 0xbfbff780 ---
mountd exporting stuff causes a panic.
This is and isn't my fault, struct ucred needs a lock for refcounts.
Since mount uses ucreds in userspace and passes them to the kernel
we have a issue when struct mtx changes. I'm going to take a shot
at removing struct ucred from userland this weekend, but you can
have a shot at it if you'd like.
The other option is to at least fix mount and friends to use
something other than ucred, and slowly remove it (struct ucred)
from userland.
Well, no, I can live w/o exporting things from a -current box until next week.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: a panic from recent changes...
mountd exporting stuff causes a panic. This is and isn't my fault, struct ucred needs a lock for refcounts. Since mount uses ucreds in userspace and passes them to the kernel we have a issue when struct mtx changes. I'm going to take a shot at removing struct ucred from userland this weekend, but you can have a shot at it if you'd like. The other option is to at least fix mount and friends to use something other than ucred, and slowly remove it (struct ucred) from userland. BTW- thanks for the quick response! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
loopback nfs hangs now propagated to -stable...
The loopback nfs hangs that have been with us for a month have now propagated to -stable. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current hangs...
I'll confirm a hang on both alpha i386 (both SCSI, qlogic ahc resp). The i386 was SMP. The Qlogic wasn't. Both were hung with phk's make -j 256 foolery. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VXA tape drive
Well, details would be nice. I checked in current with little luck. Does -current support VXA-1 tape drives by Ecrix. The site claims that freebsd does, but the only response by someone that has one says that it won't successfully backup. 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
I take that back.... Re: sio serial console in -current?
On Mon, 15 Jan 2001, Matthew Jacob wrote: FWIW, serial now is happy again. I guess the planets realigned. Nope- it just happens more fitfully. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ** HEADS UP ** bug in pkg_update
Cool! On Sat, 13 Jan 2001, David O'Brien wrote: Until Paul Richards fixes the bug, do NOT run `pkg_update' on a package w/o a version number in the name. Ie, ``pkg_update gtk.tgz'' will delete every package off your system. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX 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: sio serial console in -current?
Interesting theory, but no- that wasn't it. Matthew Jacob wrote: Something wierd has been happening lately- the serial console on my i386 machine works fine up until init is forked.. THen the output is mangled, and one gets replicated and/or mangled stuff. On a reboot I'm getthing things like: Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped It's like the output is being repeated... Anyone seen same? My guess is you might be using PHK's syslog feature and be sending console output to the console ? (I haven't tried it tho). Check your syslog.conf (or disable syslogd and see what happens). 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: sio serial console in -current?
Matthew Jacob wrote:
Yeah, weird. I'm at 9600... What's wierd is that it's got to be some userland
induced thing because printouts from the kernel are fine until init is
invoked...
This is an ongoing "Hmm, that is strange!" type problem. There are several
symptoms that I see at times:
1: console turns to garbage part way through /etc/rc and comes back to life
when /etc/rc exits and getty starts
2: console *disappears* part way through /etc/rc and comes back to life
when /etc/rc exits and getty starts
3: there is a burst of garbage after /etc/rc and before getty
4: the problem you describe I think I have seen a long time ago, once.
5: ^T and ^C and ^\ do not work ("not a controlling terminal") during
the execution of /etc/rc. There are several different ways this happens
depending on whether you go via the single user shell or not.
This happens on some machines semi regularly and occasionally on others and
"never" (yet) on some others. These are all serial consoles, and all
machines are different. SMP machines are far worse than UP, but my UP
machines have this sort of thing occasionally too.
sio for alpha seems fine. wahhh.
I am sure we can break it for compatability :-)
No doubt.
What I'm really curious about is whether I'm the only one seeing this
consistently- not the 1-3,5 above, but #4- where as soon as /sbin/init is
invoked, the serial console has this repeated output that makes it unusable,
period. I really don't want to debug this myself- I am *sooo* behind on
other FreeBSD issues that I need to spend what few FreeBSD cycles I have on
those.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HEADSUP: kernel config required
isp_pci.c just moved from sys/pci to sys/dev/isp (for maintenance ease). You will need to reconfig kernels if you included this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sio serial console in -current?
Good guess, I shouldn't wonder, but: quarm.feral.com diff /etc/rc.serial /usr/src/etc/ quarm.feral.com On Wed, 10 Jan 2001, Bruce Evans wrote: On Mon, 8 Jan 2001, Matthew Jacob wrote: Something wierd has been happening lately- the serial console on my i386 machine works fine up until init is forked.. THen the output is mangled, and one gets replicated and/or mangled stuff. On a reboot I'm getthing things like: Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped This may be caused by inconsistent settings in /etc/rc.serial. /etc/rc.serial should rarely be changed from its default of doing nothing. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
sio serial console in -current?
Something wierd has been happening lately- the serial console on my i386 machine works fine up until init is forked.. THen the output is mangled, and one gets replicated and/or mangled stuff. On a reboot I'm getthing things like: Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped It's like the output is being repeated... Anyone seen same? 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: 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
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: Current stalls...
I'm getting these on NFS for loopback. On 29-Dec-00 Poul-Henning Kamp wrote: I am totally unable to complete a cd /usr/src cvs -q update -P -d -A on any of my two -current systems. The systems stalls as described in my email yesterday. CCD is now out of the equation. I'm getting these hangs on my laptop as well, but only in the last few days. An installworld from a previously built world hangs as well. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Current stalls...
I'll try- lots on plate to do. There's a lot of iffy stuff with ithreads on alpha. But this theory of yours doesn't match the situation where I can then still log in and ping, but that the NFS loopback mount is still hosed. I went back to building across NFS and that worked mucho better. : :I'm getting these on NFS for loopback. Can you verify that it's the same as Poul's by breaking into DDB and doing a trace ? I have very little time, but what I think may be going on is that current may be exposing a bug in the specfs fsync code related to flushing dirty buffers which already have a background bitmap write in progress. I think what is going on is that interrupt threads are not able to run in -current, whereas interrupts do run in -stable, and an interrupt completing the write on a buffer is what breaks us out of the infinite loop. I noticed in Poul's 'ps' output that a number of interrupt threads were runnable, but not getting any cpu to run. The way to test this hypothesis is to give up the cpu for a tick in the specfs fsync loop, allowing interrupt threads to run. Maybe do a tsleep for hz/10 every 500 iterations or something like that. If this fixes the problem, then we have confirmation. Alternatively someone can work up a simple MARK/SCAN for specfs's fsync, ala what we do in FFS's fsync, and try that. I think MARK/SCAN may be the ultimate solution but we should home in on the problem before tring it out. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: Current stalls...
: : :I'll try- lots on plate to do. : :There's a lot of iffy stuff with ithreads on alpha. But this theory of yours :doesn't match the situation where I can then still log in and ping, but that :the NFS loopback mount is still hosed. : :I went back to building across NFS and that worked mucho better. I'm kinda shooting in the dark here, at least where -current is concerned. It's very fragile. The source of this particular problem could be anything. Maybe if we froze new development in -current and concentrated on stabilizing it for a month we could bring it back up to snuff. Nope, I doubt it. It's about what I would expect it to be. Karnak predicts that things will be miserable for about two more months and then get a lot better. Freezing development (as if you could *really* folks to do that) will make that three months or maybe four. The time to have done a rational plan to stage all of this was last May, not now. I'm actually amazed that things work as well as they do. What we really need is a few more subsystems cleaned up lockwise (I have my eye on Justin's latest CAM patches and how that will play with locking) and somebody (that might be me when if I get time for it- my current clients don't give a doodly about FreeBSD so it's hard to break loose time in a work context) to clean up the alpha ithreads stuff (I like what Doug has just passed out- I need to thank him and try it (Yes, Doug, if you're reading this, the proc holding Giant should inherit the hardware int priority)) and people to just beat on things and have things get shaken out. Given our very loose confederation, and given the downright absolute dislike some of us have for each other, this is probably the best of all possible software development worlds. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
is it possible to have a NULL procp for an NFS request?
I had a panic just now: db t tprintf() at tprintf+0x7c nfs_msg() at nfs_msg+0x28 nfs_timer() at nfs_timer+0x1fc softclock() at softclock+0x4f4 sithd_loop() at sithd_loop+0x18c exception_return() at exception_return This is where it's saying the server isn't responding... and as best as I can decode the assembly, the first argument to tprintf is NULL (a null procp) which is passed straight through as rep-r_procp in nfs_msg. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: is it possible to have a NULL procp for an NFS request?
Hmm. The client wasn't following symlinks. The patch seems
simple enough, but it probably shouldn't just swallow the
error.
It looks like the last phk simplification lost some of the
functionality of the previous code- that I can fix.
On 23 Dec 2000, Assar Westerlund wrote:
Matthew Jacob [EMAIL PROTECTED] writes:
I had a panic just now:
db t
tprintf() at tprintf+0x7c
nfs_msg() at nfs_msg+0x28
nfs_timer() at nfs_timer+0x1fc
softclock() at softclock+0x4f4
sithd_loop() at sithd_loop+0x18c
exception_return() at exception_return
Yes, this is possible, (at least) when following symbolic links. This
was discussed here on -current some time ago and I proposed the
appended simple patch, but I didn't get any feedback on it.
/assar
Index: nfs_socket.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_socket.c,v
retrieving revision 1.62
diff -u -w -u -w -r1.62 nfs_socket.c
--- nfs_socket.c 2000/11/26 20:35:21 1.62
+++ nfs_socket.c 2000/12/23 05:59:51
@@ -1969,6 +1969,7 @@
char *server, *msg;
{
+ if (p != NULL)
tprintf(p, LOG_INFO, "nfs server %s: %s\n", server, msg);
return (0);
}
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: is it possible to have a NULL procp for an NFS request?
I'm pretty sure that the server had no symlinks in that filesystem. On 23 Dec 2000, Assar Westerlund wrote: Matthew Jacob [EMAIL PROTECTED] writes: Hmm. The client wasn't following symlinks. You sure? What happens is when you queue up an nfs operation provoked by following a symlink. I couldn't figure any other way of making that happen. The patch seems simple enough, but it probably shouldn't just swallow the error. Yeah, your patch to subr_prf.c is better. Well, it covers more. Sigh. Just pluggin' holes To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Old Business: followup about dirty 'modules' directory
A month or so ago I queried/complained about src/sys/modules getting corrupted with architecture specific derived files such that I could no longer share between i386 alpha. Part of this issue had to do with having some idiocy on my part, but part of it *seems* to have to do with if you change the default /usr/obj to somewhere else. The setup I have here for all of my varied test machines is: private/per-machine /usr/src (CVS to local cvsup'd copy, ergo, out of date) shared, NFS mounted sys, mounted as /tstsys, and thence a loopback mount to a local directory for /tstsys/compile, CVS to freefall (ergo, could be kept up to the minute for all platforms) What was happening is that just one machine seemed to be polluting /tstsys/modules with derived files (.ko's, .depends, etc.). Big PITA. I queried and everyone said, "huh?", so I shut up and simply loopback mounted /tstsys/modules to a local directory for that machine as well. I finally decided that this was stupid, and looked into it more. It appears that this was the only machine that had a MAKEOBJDIRPREFIX set. Somehow this seemed to interfere with the dance that goes on with building modules for each kernel. I haven't tracked it further than this, but thought I should mention it in case anyone else has stubber their toe on this one. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: savecore broken because kern.bootfile is set wrong
Should be fixed. Savecore isn't working in -current, dying in my case with "read: invalid argument". (This is on an Alpha -- I don't have an i386 -current machine to test it on at the moment.) I traced it down to the fact that getbootfile() is returning "kernel" -- not the full pathname as the man page promises. This seems to be because the "kern.bootfile" sysctl variable isn't getting set correctly: alpha# sysctl kern.bootfile kern.bootfile: kernel Because I had an old "/kernel" file and savecore runs in "/", it was finding the wrong kernel. This seems to be some sort of coordination problem between the loader and the kernel and, maybe, the Alpha SRM. Can anybody shed some light on it? Also, in "src/sys/boot/common/boot.c" we still have this: static const char *default_bootfiles = "kernel.ko"; which isn't right any more. John 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: savecore broken because kern.bootfile is set wrong
Though the alpha code (alpha/libalpha/bootinfo.c) also fill in a lot of stuff in bi, it has no reference at all to "kernelname". Did it ever work? :-) Hmm. Maybe not. I'd convinced myself that the loader is currently just passing "kernel" either as an environmental variable or in bootinfo, but you're right about the loader. Time to fix... -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: savecore broken because kern.bootfile is set wrong
Savecore isn't working in -current, dying in my case with "read: invalid argument". (This is on an Alpha -- I don't have an i386 -current machine to test it on at the moment.) I traced it down to the fact that getbootfile() is returning "kernel" -- not the full pathname as the man page promises. This seems to be because the "kern.bootfile" sysctl variable isn't getting set correctly: alpha# sysctl kern.bootfile kern.bootfile: kernel Because I had an old "/kernel" file and savecore runs in "/", it was finding the wrong kernel. This seems to be some sort of coordination problem between the loader and the kernel and, maybe, the Alpha SRM. Can anybody shed some light Not SRM. SRM cares not. on it? Also, in "src/sys/boot/common/boot.c" we still have this: static const char *default_bootfiles = "kernel.ko"; which isn't right any more. Absolutely wrong, yes. Look at kern_mib.c: char kernelname[MAXPATHLEN] = "/kernel";/* XXX bloat */ SYSCTL_STRING(_kern, KERN_BOOTFILE, bootfile, CTLFLAG_RW, kernelname, sizeof kernelname, "Name of kernel file booted"); This is also wrong now. It's somewhat problematic in that the actual kernel name is kernel, still, but the path that it is found in depends on where the loader actually found it- that's contingent on module_path. I don't know whether the loader is supposed to modify kernelname in the loaded kernel to have the actual path or not. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: savecore broken because kern.bootfile is set wrong
kernel to have the actual path or not. It is supposed to. Looks like a bug in the alpha startup code somewhere: uname -a FreeBSD laptop.baldwin.cx 5.0-CURRENT FreeBSD 5.0-CURRENT #40: Fri Nov 10 15:17:48 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/LAPTOP-card i386 sysctl kern.bootfile kern.bootfile: /boot/kernel.card/kernel uname -a FreeBSD baz.osd.bsdi.com 5.0-CURRENT FreeBSD 5.0-CURRENT #48: Fri Nov 3 12:37:16 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/BAZ alpha sysctl kern.bootfile kern.bootfile: kernel Urgle. Okay. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: savecore broken because kern.bootfile is set wrong
kernel to have the actual path or not.
It is supposed to. Looks like a bug in the alpha startup code somewhere:
uname -a
FreeBSD laptop.baldwin.cx 5.0-CURRENT FreeBSD 5.0-CURRENT #40: Fri Nov 10
15:17:48 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/LAPTOP-card
i386
sysctl kern.bootfile
kern.bootfile: /boot/kernel.card/kernel
uname -a
FreeBSD baz.osd.bsdi.com 5.0-CURRENT FreeBSD 5.0-CURRENT #48: Fri Nov 3
12:37:16 PST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/BAZ alpha
sysctl kern.bootfile
kern.bootfile: kernel
Urgle. Okay.
Something actually was changed at some point perhaps?
On i386, kernelname is dug out of bootinfo and copied
(in assembler).
On alpha:
p = getenv("kernelname");
if (p)
strncpy(kernelname, p, sizeof(kernelname) - 1);
Did the loader used to set kernelname as an environment variable?
At any rate, this should be easy enough to fix (doing so right now).
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: savecore broken because kern.bootfile is set wrong
Well, things are more broken than I thought.
The -current loader for alpha is passing "kernel"
in the bootinfo structure- not the full pathname.
Loader bug.
What's amusing is that kenv does see a full pathname.
So, now why did the lines below fail to see the pathname?
Hmmm.. ponders
-matt
Something actually was changed at some point perhaps?
On i386, kernelname is dug out of bootinfo and copied
(in assembler).
On alpha:
p = getenv("kernelname");
if (p)
strncpy(kernelname, p, sizeof(kernelname) - 1);
Did the loader used to set kernelname as an environment variable?
It should still do it. (The forth code handles this) My only Alpha is
running -stable, and $kernelname is set correctly there (see the output
of 'kenv').
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: tar : needs some attention?
On Mon, 6 Nov 2000, John W. De Boskey wrote: Hi, Each night I run a 'make release' and then tar it off to a public storage area... For some time now, tar has been complaining... tar: cdrom/disc2/dev/acd0t32: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t33: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t34: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t35: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t36: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t37: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t38: minor number too large; not dumped tar: cdrom/disc2/dev/acd0t39: minor number too large; not dumped Is this the expected behaviour, or is it worth digging into tar and making some fixes? Nope. Expected behaviour for interoperability with other unix systems. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic in vfinddev in -current
Hmm. I've seen several panics over the last day or so with -current where / got corrupted (ino 2). On Thu, 2 Nov 2000, Justin T. Gibbs wrote: I beleive that I've somehow corrupted my /dev on my laptop. An ls -l in there causes an instant panic: Copied by hand... vfinddev(,3,c877ac84,10002,1) at vfinddev+0xc = NODEV addaliasu(c7dc0a00,10002,c0b04800,c33e1180,c0b149e4) at ufs_vinit+0x44 ufs_vinit(c0b01c00,c0abe900,c0abed00,c877acec,c333f380) at ufs_vinit+0x4e ffs_vget(c0b01c00,1882,c877ad60,0,c7dc1900) at ffs_vget+0x267 ufs_lookup(c877adb8,c877adcc,c018e6fa,c877adb8,c7dc1900) at ufs_lookup+0x995 ufs_vnoperate(c877adb8,c7dc1900,c8770c03,c877aeb4,c877adc0 at ufs_vnoperate+15 vfs_cache_lookup(c877ae10,c877ae20,c0191804,c877ae10,c7dc1900) at vfs_cache_lookup+0x28a ufs_vnoperate(c877ae10,c7dc1900,c0b1c800,c877aeb4,c77e5840) at ufs_vnoperate+0x15 lookup(c877ae8c,c02b57d8,0,c77e5840,c77e5840) at lookup+0x290 namei(c877ae8c,c02b57d8,0,c77e5840,80b4340) at namei+0x178 lstat(c88e5840,c877af80,80b4348,80b5028,80b4300) at lstat+0x41 syscall2(2f,2f,2f,80b4300,80b5028) at syscall2+0x33c Xint0x80_syscall() at Xint0x80_syscall+0x1f Since addaliasu doesn't bother to check for NODEV, I take it this is a "can't happen" situation? -- Justin 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: Our kernel just got too big again. :)
Hmm?... my forth is poor, but I don't believe that's the issue. If I understand how the floppies currently work is that it's just like our normal boot loader- we start coming up. If you want to load other drivers or modules (like ispfw), you hit the 'other than Enter' to stop the loading progress, switch floppies and load ispfw, davicom ethernet, a splash screen with jordan's face, whatever...then you type 'boot'- then the normal mfsroot flopp The problem with such an approach is that it's not very user-friendly to first-time installers who have no idea how to drive the loader. Let's not forget the linux installation floppy saga and all the confusion it's caused people just in trying to figure out which floppies to use. That would be where the forth hackery comes in - an additional set of menu options which make it a no-brainer to insert the kernel module floppy. Okay. It's your thuktun, as Niven would write you're sure this doesn't work. If you're email to -current was "only answers with patches against -current will be heard", you really should have said so. No, that wasn't the point of my email. My email was originally intended to solicit suggestions about options to remove from the kernel so that the *existing* mechanism would go back to working again. Adding a 3rd floppy to the mix is an option which has occurred to all of us at one time or another and even been a topic for fierce debate in the FreeBSD mailing lists. I would have preferred not to go there in this thread. :) Okay. I have no suggestions as to what to remove then. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Our kernel just got too big again. :)
The problem with such an approach is that it's not very user-friendly to first-time installers who have no idea how to drive the loader. Most of the relevant modules can actually be tried by sysinstall. In the CD case we can just put them on the CDROM. I'd be inclined to look for somewhere that you can fit ~110k and put nfs.ko.gz there. 8) I was thinking about making sure that drivers that would get you to your install media would be what you'd load- nothing else. This would include network drivers... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent kernels won't boot
I'm not aware of any 4MB limit on kernel size (and I ought to be if there is one 8). Can you run the details past me? (I've regularly booted much larger kernels in the past...) Alpha? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 1131 unneeded includes in the kernel...
How did you manage to generate this list. You're smoking crack on this one dev/isp/isp_target.c dev/isp/isp_freebsd.h as the isp_OS_PLATFORM.h includes is the only include this file has. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 1131 unneeded includes in the kernel...
Oh- don't get me wrong. Valuable info. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 1131 unneeded includes in the kernel...
Yes, but no. Let the MAINTAINERS shoot their own lines. A script with nag mail is good though. On Wed, 20 Sep 2000, Brandon D. Valentine wrote: On Tue, 19 Sep 2000, Matthew Jacob wrote: Oh- don't get me wrong. Valuable info. Thanks. What would be very cool is to feed this into another script which strips these unnecesary includes out. Then do a test build of LINT in your local tree and if it succeeds commit a mass removal of them. The same concept could be applied to the greater source tree. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 1131 unneeded includes in the kernel...
On Wed, 20 Sep 2000, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew J acob writes: How did you manage to generate this list. You're smoking crack on this one dev/isp/isp_target.c dev/isp/isp_freebsd.h as the isp_OS_PLATFORM.h includes is the only include this file has. Well, According to src/tools/tools/kerninclude that include is not even needed. I'm not claiming that every single line is dogmatically true, but at least it merits some amount of investigation... Sure. But your tool did not try the ISP_TARGET_MODE kernel option, which is what would then cause this file to even be compiled. The compile would fail, since 99% of all defined values, as in CT_SENDSTATUS and so on, are in files brought in by that header. I think I see what it is. The includes are outside the #ifdef ISP_TARGET_MODE but still As you say- merited investigation. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 1131 unneeded includes in the kernel...
On Wed, 20 Sep 2000, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Matthew J acob writes: How did you manage to generate this list. You're smoking crack on this one dev/isp/isp_target.c dev/isp/isp_freebsd.h as the isp_OS_PLATFORM.h includes is the only include this file has. Oh, forgot to say: it could also be indicative of options not excercised by NOTES/LINT... Yup. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newbus docs
On Thu, 14 Sep 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Julian Elischer writes: : Someone once mentionned an actual : document but I've been unable to find it. : Was it my imagination? : (and if so, why isn't there one?) What do you mean actual document? man pages are actual documents. What kind of document do you want? I would imagine an overall architecture doc. Sort of like what Jordan just did for sysinst (e.g.). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: newbus docs
In message [EMAIL PROTECTED] Matthew Jacob writes: : I would imagine an overall architecture doc. Sort of like what : Jordan just did for sysinst (e.g.). Then he should ask for an architecture doc rather than being so snippy and snide about "actual documentation." Probably, but I totally sympathize with him. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nsswitch changes break world build
Are you sure you don't have a partial update? On Wed, 6 Sep 2000, Jordan Hubbard wrote: .. during the depend phase.. /usr/src/lib/libc/../libc/gen/getgrent.c:48: nsswitch.h: No such file or directo ry /usr/src/lib/libc/../libc/gen/getpwent.c:54: nsswitch.h: No such file or directo - Jordan 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: HEADS UP: SMP code commit iminent
Progress will be more rapid with things checked in than not, as long as Jason's statement about "the (alpha) system will run" after the checkin. Jason- I think we'd all appreciate a UTC timestamp suitable for -D that we can all use to checkout stuff prior to the big change. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: SMP code commit iminent
Oops- sorry- this is what I get for catching up email after a long day. Thanks. On 5 Sep 2000, Jason Evans wrote: [-smp dropped from cc list.] On Tue, Sep 05, 2000 at 09:57:05PM -0700, Matthew Jacob wrote: Jason- I think we'd all appreciate a UTC timestamp suitable for -D that we can all use to checkout stuff prior to the big change. I initially wrote: Also in compliance with the SMP project announcement, a static tag will be created between the above-mentioned time and when the actual commit is done. Good enough? Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dirty bufs on reboot (again)?
Anyone else seen this with SMP and latest as of maybe early yesterday morning?
done
panic: vinvalbuf: dirty bufs
mp_lock = 0001; cpuid = 0; lapic.id =
Debugger("panic")
Stopped at Debugger+0x34: movb$0,in_Debugger.591
db
db t
Debugger(c0267f32) at Debugger+0x34
panic(c026c2e2,c02c0220,c8b51c60,11,c8b51c60) at panic+0xa4
vinvalbuf(c7da9ec0,1,0,0,0,0,c02c0220,0,0,1,c02c0220,0,7fff) at
vinvalbuf+0xd6
vm_object_terminate(c02c0220,c7da9ec0,c8b51c60,c7da8f00,c028eb60) at
vm_object_terminate+0x85
vclean(c7da9ec0,0,c8b51c60,c0aaa000,c8b51c60) at vclean+0xae
vflush(c0aaa000,0,2,0,c8b51c60) at vflush+0xd9
ffs_flushfiles(c0aaa000,2,c8b51c60,0,c8b51c60) at ffs_flushfiles+0x4b
ffs_unmount(c0aaa000,8,c8b51c60,c0aaa000,0) at ffs_unmount+0x3e
dounmount(c0aaa000,8,c8b51c60,c332b5c0,0) at dounmount+0xd1
vfs_unmountall(1,c8b51c60,c8b5bf80,0,0) at vfs_unmountall+0x32
boot(0,c8b5bfa0,c0243b01,c8b51c60,c8b5bf80) at boot+0x267
reboot(c8b51c60,c8b5bf80,6,0,0) at reboot+0x1c
syscall2(2f,2f,2f,0,0) at syscall2+0x219
Xint0x80_syscall() at Xint0x80_syscall+0x2b
db c
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Currents PCI support hosed ?
Maybe. It's also not clear to me whether my current breakage is PCI related or device.hints related (it appears that the read of my /boot/devices.hints file gets things garbled): Hit [Enter] to boot immediately, or any other key for command prompt. Booting [kernel]... Entering kernel at 0xfc32ec80... Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. Setting atkbd 0 at to atkbdc (string) Setting atkbd 0 irq to 1 (int) Setting atkbdc 0 at to isa (string) Setting atkbdc 0 port to 96 (int) Setting fd 0 at to fdc0 (string) Setting fd 0 drive to 0 (int) Setting fdc 0 at to isa (string) Setting fdc 0 drq to 2 (int) Setting fdc 0 irq to 6 (int) Setting fdc 0 port to 1008 (int) Setting mcclock 0 at to isa (string) Setting mcclock 0 port to 112 (int) Setting ppc 0 at to isa (string) Setting ppc 0 irq to 7 (int) Setting psm 0 at to atkbdc (string) Setting psm 0 irq to 12 (int) Setting sc 0 at to isa (string) Setting sio 0 at to isa (string) Setting sio 0 irq to 4 (int) Setting sio 0 port to 1016 (int) Setting sio 1 at to isa (string) Setting sio 1 flags to 80 (int) Setting sio 1 irq to 3 (int) Setting sio 1 port to 760 (int) Setting vga 0 at to isa (string) FreeBSD 5.0-CURRENT #0: Fri Sep 1 11:36:35 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/NG EB164 Digital AlphaPC 164 432 MHz, 432MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=1 extensions=0x1BWX OSF PAL rev: 0x1000800020117 real memory = 265904128 (259672K bytes) Physical memory chunk(s): 0x0081e000 - 0x0ff0dfff, 258932736 bytes (31608 pages) avail memory = 251535360 (245640K bytes) Preloaded elf kernel "kernel" at 0xfc802000. Preloaded elf module "ispfw.ko" at 0xfc8020c0. Preloaded elf module "randomdev.ko" at 0xfc802188. module_register: module random already exists! Module random failed to register: 17 mem: memory I/O nulldev: null device, zero device random: entropy source random: entropy source cia0: 2117x Core Logic chipset cia0: ALCOR/ALCOR2, pass 3 cia0: extended capabilities: 21DWEN,BWEN pcib0: 2117x PCI host bus adapter on cia0 pci0: physical bus=0 HANGS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Currents PCI support hosed ?
Maybe. It's also not clear to me whether my current breakage is PCI related or device.hints related (it appears that the read of my /boot/devices.hints file gets things garbled): If you want a working vidconsole on the alpha, compile your hints statically into the kernel. :) Hey- I do servers. Serial only. FreeBSD 5.0-CURRENT #0: Fri Sep 1 11:36:35 PDT 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/NG EB164 Digital AlphaPC 164 432 MHz, 432MHz 8192 byte page size, 1 processor. CPU: EV56 (21164A) major=7 minor=1 extensions=0x1BWX OSF PAL rev: 0x1000800020117 real memory = 265904128 (259672K bytes) Physical memory chunk(s): 0x0081e000 - 0x0ff0dfff, 258932736 bytes (31608 pages) avail memory = 251535360 (245640K bytes) Preloaded elf kernel "kernel" at 0xfc802000. Preloaded elf module "ispfw.ko" at 0xfc8020c0. Preloaded elf module "randomdev.ko" at 0xfc802188. module_register: module random already exists! Module random failed to register: 17 mem: memory I/O nulldev: null device, zero device random: entropy source random: entropy source cia0: 2117x Core Logic chipset cia0: ALCOR/ALCOR2, pass 3 cia0: extended capabilities: 21DWEN,BWEN pcib0: 2117x PCI host bus adapter on cia0 pci0: physical bus=0 HANGS cia's PCI bus driver is broken right now. It seems the ivar's passed around to determine which PCI space read/write functions to use is borked somehow. Drew has a patch for this that seems to fix Miata's at least. I'll forward his test patch in a second. Hopefully someone with new-bus fu can figure the problem out. Gee. I didn't know. I thought all was peachy from Doug. I haven't had time to really review them. I guess I should have. [ Let's take this to -alpha as this is an alpha problem I guess ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha devfs feedback
What names do you usually access your disks by ? Just da0a etc ?
da0{a,b,c,d} and so on..
You should be able to find those as well with the clone stuff...
Nope. Weren't there.
I booted up once. I had 3 disks- none with a FreeBSD label. The
contents of /dev for da disks was /dev/da{0,1,2}[c].
So, I did the '-Brw da0 auto' and disklabel -e trick to add
a da0a to da0. disklabel happily saw da0a after this. Nothing
in /dev. Okay- so this kind of rescan doesn't work yet.
So, I reboot. The contents of dev still are /dev/da{0,1,2}[c]. I mostly
was raising this to see if someone else has tried alpha in this regard.
If not- I can help debug this and fix it, but next week.
-matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
I do read cvs-all, and I missed it. Not did I find device.hints in the relevant Makefiles. Can you provide a pointer to details on how /boot/device.hints is used in the build process, or how having an empty one keeps you from shooting yourself in the foot? cvs-all is not appropriate. I am noticing a 3-7 day lag on UPDATING. Bad. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha devfs feedback
That's more than show up on i386's :-). After booting with -s, only the whole disk devices and the root device show up. Devices for slices and partitions slices only show up when they are opened or stat'ed. This bug is normally mostly hidden by opening most partitions to mount them. Hmm. Well, it turned out that after a period of time da0a showed up. Poul says I might be out of date src-wise. I'll update again and see. Remember that there's no such thing as slices in alpha. I thought that they worked. They should work if they are configured. Sorry- I meant "SRM doesnt' grok i386 labels". -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hints static wiring
In message [EMAIL PROTECTED] Matthew Jacob writes: : I do read cvs-all, and I missed it. Not did I find device.hints in the : relevant Makefiles. Can you provide a pointer to details on how : /boot/device.hints is used in the build process, or how having an : empty one keeps you from shooting yourself in the foot? : : cvs-all is not appropriate. I am noticing a 3-7 day lag on UPDATING. : Bad. cvs-all *IS*REQUIRED* for all people running -current. UPDATING tries to cull things from there on an as needed basis. It is a service that gets done when I have time. If someone wants to pay me a stipend to drop everything the instant something is committed to the tree and update UPDATING, then the lag will improve. Otherwise, 3-7 days really isn't that bad and will continue to be the case. Warner Oops- I realize that what I said might have been construed as criticism- not meant at all! What I meant is that while cvs-all can be read by everyone, it's not always obvious from the flood of mail there, or if you're not a developer, what needs to change. In my opinion, people making major changes that require something in UPDATING, should coordinate with you *before* the commit. Only 5 or 6 brain cells are needed for this- I sure wish some of my fellow committers weren't such skinflints in this area. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha devfs feedback
I compiled and booted on alpha. It sees my ad0 now. Plus it also sees the 3 'da' disks that were found. The only real problem is that it won't see the partitions made for 'dangerously dedicated' 'da' disks. What's the plan for addressing this? -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why no CDR ioctls for SCSI cds?
If the answer from the person who would have to approve the code had come back "Ok, provide the code and we'll see how well it works in practice", I'd do the code. But when it appears the code would never make it into the tree to be used, why waste my time? 'coz we're taking a page from Linus. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: your mail
Already told him. It is. On Sun, 20 Aug 2000, Tony Fleisher wrote: Not sure if this is related to the recent commit of DEVFS code, but a build of both the GERNERIC kernel and a custom kernel from a very recent (last few hours) cvsup of -current failed during the 'make depend' with an error trying to include "opt_devfs.h". The following following is the ouput from a custom kernel (/usr/local/src/freebsd/src is the base of my src): === md @ - /usr/local/src/freebsd/src/sys machine - /usr/local/src/freebsd/src/sys/i386/include touch opt_mfs.h touch opt_md.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I@ -I@/../includ e -I/usr/include /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c /usr/local/src/freebsd/src/sys/modules/md/../../dev/md/md.c:15: opt_devfs.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/local/src/freebsd/src/sys/modules/md. *** Error code 1 Commenting out the line: #include "opt_devfs.h" from src/sys/dev/md/md.c got rid of this error, although I am not sure that this is the correct fix. Tony. 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: Why no CDR ioctls for SCSI cds?
I'm sorry- I really haven't been paying much attention to this, but it seems it's sort of on the wrong mailing list, isn't it? Mike- can you take a deep breath and send a summary of what you see the techical problems/requirements are to the freebsd-scsi alias? I'll admit that I'm not up on a lot of this...oops- I just saw mail from you... taking offline To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in xpt_setup_ccb (cam_xpt.c)
What hardware?
On Sat, 29 Jul 2000, Alexander Leidinger wrote:
Hi,
while trying to read (dd if=/dev/cd0c) from a damaged cd (the surface is
a little bit damaged), I've got a panic:
---snip---
#0 boot (howto=260) at ../../kern/kern_shutdown.c:303
#1 0xc01a0f19 in panic (fmt=0xc029aa60 "lockmgr: pid %d, not %s %d unlocking")
at ../../kern/kern_shutdown.c:553
#2 0xc019b194 in lockmgr (lkp=0xc14f4a00, flags=65542, interlkp=0xd0e2e22c,
p=0xd0313ba0) at ../../kern/kern_lock.c:382
#3 0xc01cf2af in vop_stdunlock (ap=0xd0d2ecc8) at ../../kern/vfs_default.c:255
#4 0xc022b641 in ufs_vnoperate (ap=0xd0d2ecc8)
at ../../ufs/ufs/ufs_vnops.c:2301
#5 0xc01d22aa in vput (vp=0xd0e2e1c0) at vnode_if.h:794
#6 0xc0222ea7 in ffs_sync (mp=0xc1046a00, waitfor=2, cred=0xc0b3f980,
p=0xc037f0a0) at ../../ufs/ffs/ffs_vfsops.c:955
#7 0xc01d4295 in sync (p=0xc037f0a0, uap=0x0) at ../../kern/vfs_syscalls.c:551
#8 0xc01a094f in boot (howto=256) at ../../kern/kern_shutdown.c:225
#9 0xc01a0f19 in panic (fmt=0xc02babef "page fault")
at ../../kern/kern_shutdown.c:553
#10 0xc0265846 in trap_fatal (frame=0xd0d2ee10, eva=68)
at ../../i386/i386/trap.c:929
#11 0xc02654f9 in trap_pfault (frame=0xd0d2ee10, usermode=0, eva=68)
at ../../i386/i386/trap.c:822
#12 0xc02650bf in trap (frame={tf_fs = 16, tf_es = -791543792,
tf_ds = -1072562160, tf_edi = 1, tf_esi = -1056803840,
tf_ebp = -791482800, tf_isp = -791482820, tf_ebx = 0, tf_edx = 64,
tf_ecx = -791482776, tf_eax = 1, tf_trapno = 12, tf_err = 0,
tf_eip = -1072541595, tf_cs = 8, tf_eflags = 2163330,
tf_esp = -791482664, tf_ss = -107284}) at ../../i386/i386/trap.c:427
#13 0xc0125065 in xpt_setup_ccb (ccb_h=0xd0d2ee68, path=0x40, priority=1)
at ../../cam/cam_xpt.c:3734
#14 0xc01219c0 in cam_release_devq (path=0x40, relsim_flags=0, openings=0,
timeout=0, getcount_only=0) at ../../cam/cam_periph.c:855
---Type return to continue, or q return to quit---
#15 0xc0121b37 in camperiphdone (periph=0xc1021480, done_ccb=0xc1027400)
at ../../cam/cam_periph.c:1021
#16 0xc0127997 in camisr (queue=0xc03189b0) at ../../cam/cam_xpt.c:6328
#17 0xc01277a9 in swi_cambio () at ../../cam/cam_xpt.c:6231
#18 0xc025b900 in splz_swi ()
#19 0xc01a7451 in softclock () at ../../kern/kern_timeout.c:131
#20 0xc025b85f in doreti_swi ()
Cannot access memory at address 0x91992874.
(kgdb) up 13
#13 0xc0125065 in xpt_setup_ccb (ccb_h=0xd0d2ee68, path=0x40, priority=1)
at ../../cam/cam_xpt.c:3734
3734ccb_h-path = path;
(kgdb)
(kgdb) print path
$1 = (struct cam_path *) 0x0
(kgdb) print ccb_h
$2 = (struct ccb_hdr *) 0x0
(kgdb) up
#14 0xc01219c0 in cam_release_devq (path=0x40, relsim_flags=0, openings=0,
timeout=0, getcount_only=0) at ../../cam/cam_periph.c:855
855 xpt_setup_ccb(crs.ccb_h, path,
(kgdb) print path
$5 = (struct cam_path *) 0x40
(kgdb) print *path
Cannot access memory at address 0x40.
---snip---
It's a kernel from yesterday.
Bye,
Alexander.
--
If Bill Gates had a dime for every time a Windows box crashed...
...Oh, wait a minute, he already does.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = 7423 F3E6 3A7E B334 A9CC B10A 1F5F 130A A638 6E7E
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: HEADS UPS: loader.conf's null_load renamed
That's groovy, Sheldon.. could you maybe fix nullfs while you're at it, too? :-) On Fri, 28 Jul 2000, Sheldon Hearn wrote: I've just renamed the nullfs kernel module from null to nullfs. The only impact that this may have on some people is as follows: If you have null_load="YES" in your /boot/loader.conf, you will need to change that to nullfs_load="YES". Apologies for the inconvenience to the folks who use the nullfs code in spite of the dire warnings in NOTES. Ciao, Sheldon. 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: HEADS UPS: loader.conf's null_load renamed
Tsk. Coward. I ran for at least a week mounting /usr/src/sys/compile on top an NFS mounted /usr/src/sys before I panic'd (and read the NOTES file) Tsk. It's too bad. This works in NetBSD :-) On Fri, 28 Jul 2000, Sheldon Hearn wrote: On Fri, 28 Jul 2000 06:44:17 MST, Matthew Jacob wrote: That's groovy, Sheldon.. could you maybe fix nullfs while you're at it, too? :-) I doubt it. I'm not brave enough to go past getting a file listing within a null mount. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic: lockmgr: pid 5, not exclusive lock holder 0 unlocking
I'm running with softupdates on /, and it has happened to me several times. On Fri, 28 Jul 2000, Brian Fundakowski Feldman wrote: On Fri, 28 Jul 2000, Sheldon Hearn wrote: Just a quick note to let you two gentlement know that the problem persists with rev 1.107 of buf.h. Brian, these are realy easy for me to reproduce on my own box here. Do you want to send me the stuff for maintaining the queues that you said would help you figure out what's going on? Or are you able to reproduce this yourself? I havne't been able to reproduce this, but this case is going to have more to do with analysis of the code than with "debugging", I think. By chance are you running with softupdates enabled on /? If I can reproduce it here, I will spend a while inspecting all the state to figure this one out as best as possible. Ciao, Sheldon. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [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: a FS related patch to test please...
FWIW, works for me
On Fri, 28 Jul 2000, Poul-Henning Kamp wrote:
I'm in my beach-house and pretty offline right now, but I reviewed the
change Kirk did to addaliasu() and found at least one scenario where
it wouldn't do what he expected:
If bdevvp() is called more than once with the same dev_t we would
create more than one anonymous vnode for that dev_t and addaliasu()
would only get one of these in its yarn. This patch makes bdevvp()
only produce max one anonymous vnode per dev_t.
I don't know if the new rootfs-locating code calls bdevvp() more
than once, if it doesn't this patch is a harmless bit of overhead.
Please test, and if it doesn't do any harm I will commit it.
(This does not fix the panic everybody is talking about btw)
Poul-Henning
Index: vfs_subr.c
===
RCS file: /home/ncvs/src/sys/kern/vfs_subr.c,v
retrieving revision 1.267
diff -u -r1.267 vfs_subr.c
--- vfs_subr.c2000/07/24 05:28:29 1.267
+++ vfs_subr.c2000/07/28 19:08:36
@@ -1276,6 +1276,8 @@
*vpp = NULLVP;
return (ENXIO);
}
+ if (vfinddev(dev, VCHR, vpp))
+ return (0);
error = getnewvnode(VT_NON, (struct mount *)0, spec_vnodeop_p, nvp);
if (error) {
*vpp = NULLVP;
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | 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
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Even with version 1.54 of mfs_vnops.c and a freshly built worldand booted kernel (with ``options MFS''), I am still seeing these. Whatcould I be missing?
Thanks,
--
Jos Backus [EMAIL PROTECTED]
WebTV Networks, Inc., Mountain View, CA
I can confirm that on my system with world built from sources cvsuped on
Sunday and a kernel just built from sources cvsuped today, I see these
messages with an mfs mounted /tmp.
Hmm. They went away for me- I thought, but no, you're right. They're still
there. This is what I actually use to get rid of them:
Index: mfs_vnops.c
===
RCS file: /home/ncvs/src/sys/ufs/mfs/mfs_vnops.c,v
retrieving revision 1.53
diff -u -r1.53 mfs_vnops.c
--- mfs_vnops.c 2000/05/05 09:59:07 1.53
+++ mfs_vnops.c 2000/07/25 21:47:09
@@ -80,6 +80,7 @@
{ vop_reclaim_desc,(vop_t *) mfs_reclaim },
{ vop_strategy_desc, (vop_t *) mfs_strategy },
{ vop_unlock_desc, (vop_t *) vop_defaultop },
+ { vop_getwritemount_desc, (vop_t *) vop_stdgetwritemount },
{ NULL, NULL }
};
static struct vnodeopv_desc mfs_vnodeop_opv_desc =
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Even with version 1.54 of mfs_vnops.c and a freshly built worldand booted kernel (with ``options MFS''), I am still seeing these. Whatcould I be missing?
Somebody send it to Kirk
On Wed, 26 Jul 2000, George W. Dinolt wrote:
Mahtew Jacob wrote:
Hmm. They went away for me- I thought, but no, you're right. They're
still
there. This is what I actually use to get rid of them:
Index: mfs_vnops.c
===
RCS file: /home/ncvs/src/sys/ufs/mfs/mfs_vnops.c,v
retrieving revision 1.53
diff -u -r1.53 mfs_vnops.c
--- mfs_vnops.c 2000/05/05 09:59:07 1.53
+++ mfs_vnops.c 2000/07/25 21:47:09
@@ -80,6 +80,7 @@
{ vop_reclaim_desc,(vop_t *) mfs_reclaim },
{ vop_strategy_desc, (vop_t *) mfs_strategy },
{ vop_unlock_desc, (vop_t *) vop_defaultop },
+ { vop_getwritemount_desc, (vop_t *) vop_stdgetwritemount
},
{ NULL, NULL }
};
static struct vnodeopv_desc mfs_vnodeop_opv_desc =
I have applied the patch and rebuilt my kernel. This seems to have fixed
the problem for me. I will keep monitoring the situation. Maybe this can
get committed to -current?
Thanks,
George Dinolt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lockmgr panic in sync()
I already mentioned it On Thu, 27 Jul 2000, Andrey A. Chernov wrote: This is at current -current, softupdates. Panic happens at reboot, from sync() kernel function: panic: lockmgr: pid 1, not exlusive lock holder 0 unlocking -- Andrey A. Chernov [EMAIL PROTECTED] http://ache.pp.ru/ 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: (noperiph:ahc0:0:-1:-1): ... error
You'll have to raise issue on freebsd-scsi. I sent the likely owner of the issue mail, but they don't monitor -current. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mfs_badop...
any reason that we should be seeing these now: mfs_badop[vop_getwritemount] mfs_badop[vop_getwritemount] = 45 mfs_badop[vop_getwritemount] mfs_badop[vop_getwritemount] = 45 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dc driver and underruns (was: Strangeness with 4.0-S)
That theory is not correct, I have seen multiple Alpha machines reporting buffer underruns as well. No ATA disk in sight there.. This has been a reported feature of the tulip chip and alphas (de driver usually) forever forever forever. It's not a bug, per se, IMO. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de as a module...
*I'll* check it too- I'd *love* to have if_de as a loadable since most of the alphas I have use if_de (not dc)! On Mon, 10 Jul 2000, Mark Murray wrote: Hi Bill If I apply the enclosed patch to sys/pci/if_de.c, and make a copy of (say) sys/modules/dc to sys/modules/de (while changing all relevant dc -- de), I can build a loadable module for de. Could you please check that this works in your (no doubt) excellent laboratory and either commit or review for me to commit. Thanks! :-) M Index: sys/pci/if_de.c === RCS file: /home/ncvs/src/sys/pci/if_de.c,v retrieving revision 1.129 diff -u -d -r1.129 if_de.c --- sys/pci/if_de.c 2000/05/28 16:06:56 1.129 +++ sys/pci/if_de.c 2000/07/09 08:27:09 @@ -54,10 +54,9 @@ #include sys/bus.h #include sys/rman.h -#include "opt_inet.h" -#include "opt_ipx.h" - #include net/if.h +#include net/if_arp.h +#include net/ethernet.h #include net/if_media.h #include net/if_dl.h #ifdef TULIP_USE_SOFTINTR 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: if_de as a module...
*I'll* check it too- I'd *love* to have if_de as a loadable since most of the alphas I have use if_de (not dc)! Umm- started okay: de0: Digital 21140A Fast Ethernet port 0x10300-0x1037f mem 0x82083000-0x8208307f irq 3 at device 9.0 on pci0 de0: interrupting at CIA irq 3 de0: 21140A [10-100Mb/s] pass 2.2 de0: address 00:40:05:41:5b:e6 bpf: de0 attached de0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.67.166.23 netmask 0xff00 broadcast 192.67.166.255 ether 00:40:05:41:5b:e6 media: autoselect supported media: autoselect 100baseTX full-duplex 100baseTX 10baseT/UTP full-duplex 10baseT/UTP lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet 127.0.0.1 netmask 0xff00 add net default: gateway 192.67.166.1 Additional routing options: tcp arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt extensions=NO IP gateway=YES TCP keepalive=YES. routing daemons:. ... but then failed with: arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt and then died: rplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt NFS Portmap: RPC: Port mapper failure - RPC: Timed out fatal kernel trap: trap entry = 0x2 (memory management fault) a0 = 0x0 a1 = 0x1 a2 = 0x pc = 0x0 ra = 0xfc4cb4e0 curproc= 0 ddbprinttrap from 0x0 ddbprinttrap(0x0, 0x1, 0x, 0x2) panic: trap panic Stopped at Debugger+0x2c: ldq ra,0(sp) 0xfe0009805a00 ra=0xfc4d0ca0,sp=0xfe0009805a00 db t Debugger() at Debugger+0x2c panic() at panic+0x100 trap() at trap+0x630 XentMM() at XentMM+0x20 swi_net() at swi_net+0x40 (null)() at 0x1 --- *sigh* (whimper) On Mon, 10 Jul 2000, Mark Murray wrote: Hi Bill If I apply the enclosed patch to sys/pci/if_de.c, and make a copy of (say) sys/modules/dc to sys/modules/de (while changing all relevant dc -- de), I can build a loadable module for de. Could you please check that this works in your (no doubt) excellent laboratory and either commit or review for me to commit. Thanks! :-) M Index: sys/pci/if_de.c === RCS file: /home/ncvs/src/sys/pci/if_de.c,v retrieving revision 1.129 diff -u -d -r1.129 if_de.c --- sys/pci/if_de.c2000/05/28 16:06:56 1.129 +++ sys/pci/if_de.c 2000/07/09 08:27:09 @@ -54,10 +54,9 @@ #include sys/bus.h #include sys/rman.h -#include "opt_inet.h" -#include "opt_ipx.h" - #include net/if.h +#include net/if_arp.h +#include net/ethernet.h #include net/if_media.h #include net/if_dl.h #ifdef TULIP_USE_SOFTINTR 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
freeing free cluster?
-current, as of ~today: FreeBSD/alpha (farrago.feral.com) (console) login: panic: freeing free cluster panic Stopped at Debugger+0x2c: ldq ra,0(sp) 0xfe000a2019f0 ra=0xfc4dbd40,sp=0xfe000a2019f0 db t Debugger() at Debugger+0x2c panic() at panic+0x100 m_freem() at m_freem+0x134 nfs_writerpc() at nfs_writerpc+0x1130 nfs_doio() at nfs_doio+0x614 nfssvc_iod() at nfssvc_iod+0x264 nfssvc() at nfssvc+0xa8 syscall() at syscall+0x244 XentSys() at XentSys+0x50 (null)() at 0x12680 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: freeing free cluster?
Nope, not for me. I probably have a core dump, but because gdb is busted for alpha in -current, it won't say much. On Mon, 10 Jul 2000, Pascal Hofstee wrote: On Mon, Jul 10, 2000 at 01:15:20PM -0700, Matthew Jacob wrote: -current, as of ~today: FreeBSD/alpha (farrago.feral.com) (console) login: panic: freeing free cluster panic Stopped at Debugger+0x2c: ldq ra,0(sp) 0xfe000a2019f0 ra=0xfc4dbd40,sp=0xfe000a2019f0 I am getting a very strong suspicion, this is the same bug i have reported earlier as well as DES did in another message. Anyone here that is able to shed some more light on it ? -- Pascal Hofstee daeron @ shadowmere . student . utwente . nl Managers know it must be good because the programmers hate it so much. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_de as a module...
This doesn't happen for me except in this (loadable de) case. On Mon, 10 Jul 2000, Rodney W. Grimes wrote: Umm- started okay: : and then died: rplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt arplookup 192.67.166.155 failed: could not allocate llinfo arpresolve: can't allocate llinfo for 192.67.166.155rt NFS Portmap: RPC: Port mapper failure - RPC: Timed out Bleagh. Fooey. :-( Biiilll!!?? :-) I don't think this is Bill. What does the output of netstat -rn | grep 192.67.166.155 look like when the above is occuring? I am having similiar problems here, I just upgraded one of our main boarder routers and started getting this stuff. Is what is happening is a host specific route is getting installed by gated, and this is causing arplookup/arpresolve to have problems when it tries to go create the llinfo. We just upgraded this router from 3.4-stable of January vintage to 4.0-STABLE FreeBSD July 2 vintage. I have seen this in the past, and though it was long gone, but now that I am looking at it again I see what is happening, The message we get is the same as yours: Jul 9 17:37:02 br1 /kernel: arplookup 205.238.40.30 failed: could not allocate llinfo Jul 9 17:37:02 br1 /kernel: arpresolve: can't allocate llinfo for 205.238.40.30 rt Now if I look in my routing table when this is going on (sorry don't have it saved off anyplace I can cut and paste from right now) I see a host route out another interface!!! Yes, we have a large ospf network, yes that route will work, no it is not the right route damn it, there is a direct route via an interface, and we are trying to use it, but something is blowing chunks in rtalloc1. -- 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: Softupdates panic on SMP system
I did some thinking about this, but no real code inspection, on a walk today- I think what is occurring is that the list of directory updates is getting refreshed from another process while the first process' list is being written out. A quick hack would be to make sure this doesn't happen (no -j4 for loose and gross and incomplete, some kind of worklist ownership token so that when process A wakes back up and looks at the worklist again it can see whether it still owns that list (after all, it drops the locks so it do the write). This is mostly a Kirk issue- he could say much quicker than I about this- I'd file this as a PR - I could fool around with it a little myself, but later this week. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fwiw, release for -stable (alpha)
Huh. That's what it has. Sigh...Whine. On Wed, 5 Jul 2000, John Polstra wrote: In article [EMAIL PROTECTED], Matthew Jacob [EMAIL PROTECTED] wrote: And for -stable (instead of -current); === Creating README.html for jpeg-6b === graphics/juno-2 "Makefile", line 60: Malformed conditional (empty(TARGET)) "Makefile", line 60: Missing dependency operator "Makefile", line 64: if-less endif "Makefile", line 64: Need an operator make: fatal errors encountered -- cannot continue *** Error code 1 *Shrug* It's a mystery to me. The offending line looks like this: .if empty(TARGET) and as far as I can tell, it's valid. There is a similar construct in "src/lib/libc/Makefile.inc": .if empty(MDSRCS) and I haven't seen any complaints of problems with that. The Makefile hasn't changed since mid-April. I don't know what to advise, except check to make sure your copy of the Makefile is uncorrupted. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subtle problem du jour....
This really bit me- it shouldn't have- but it did I had a i386 system with a 4GB disk -- root partition ~1GB but the motherboard was setting up BIOS as a CHS instead of an LBA arrangement. The only time this showed up as problem was that when I reinstalled the loader (and related forth files), loader silently was not able to read /boot or /modules- the key word here is "silently". There ought to be a warning in loader(8) maybe about this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: subtle problem du jour....
On Wed, 5 Jul 2000, Mike Smith wrote: This really bit me- it shouldn't have- but it did I had a i386 system with a 4GB disk -- root partition ~1GB but the motherboard was setting up BIOS as a CHS instead of an LBA arrangement. The only time this showed up as problem was that when I reinstalled the loader (and related forth files), loader silently was not able to read /boot or /modules- the key word here is "silently". There ought to be a warning in loader(8) maybe about this? The loader used to bitch if it couldn't find its startup files, but this got turned off because people didn't like it. There would be a couple of ways to deal with the problem you're seeing (in addition to the very worthwhile documentation) - a) bitch if the loader.rc file can't be found/read. b) bitch in the BIOS disk driver if an illegal read is attempted. Both of these might have given you enough clue to help find the problem more quickly. Any comments, folks? both would have been helpful To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fwiw, release for -stable (alpha)
Making docs... === Extracting for docproj-1.1 No MD5 checksum file. === Patching for docproj-1.1 === Configuring for docproj-1.1 === Installing for docproj-1.1 === docproj-1.1 depends on executable: instant - not found ===Verifying install for instant in /usr/ports/textproc/sgmlformat Error: you don't have the right version of perl in /usr/bin. All of this looks sort of busted to me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fwiw, release for -stable (alpha)
On Tue, 4 Jul 2000, Kris Kennaway wrote: On Tue, 4 Jul 2000, Matthew Jacob wrote: Making docs... === Extracting for docproj-1.1 No MD5 checksum file. === Patching for docproj-1.1 === Configuring for docproj-1.1 === Installing for docproj-1.1 === docproj-1.1 depends on executable: instant - not found ===Verifying install for instant in /usr/ports/textproc/sgmlformat Error: you don't have the right version of perl in /usr/bin. All of this looks sort of busted to me. This is clearly a ports problem, not a -current one..actually I suspect it's already fixed - are you sure you have an up-to-date ports collection? Well, I'd just done a complete cvsup to (finally) include docs.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in boot after flushing buffers
On Fri, 30 Jun 2000, Mark Murray wrote: Interesting. I've also been seeing this on alphas. Do you have sys/dev/randomdev/randomdev.c v1.5? Now I do. Better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Mak
On Wed, 28 Jun 2000, Mark Murray wrote: Adding something to bootstrap-tools implies that we can't use the installed miniperl (backward compatibility problem) or the host doesn't have miniperl. The bootstrap-tools built miniperl would then be used throughout the build and install stages. I think that's what we have in this case. We need the newer version of miniperl to build perl, correct? Yes, and it is doing that now. Except on alpha. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic in boot after flushing buffers
Interesting. I've also been seeing this on alphas. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvsup/cvs oddities?
Can anyone shed light on why a CVSUP'd dirtree I have now always falls down with the following error?... Because it's CVSUP'd, the local repository is just /home/ncvs (NFS mounted). I cannot figure out why it all of a sudden wants to run off the Freefall . U usr.sbin/ypset/Makefile U usr.sbin/ypset/ypset.8 U usr.sbin/ypset/ypset.c cvs update: Updating usr.sbin/zic U usr.sbin/zic/Arts.htm U usr.sbin/zic/Makefile U usr.sbin/zic/Makefile.inc U usr.sbin/zic/README U usr.sbin/zic/Theory U usr.sbin/zic/WWW.htm U usr.sbin/zic/ialloc.c U usr.sbin/zic/private.h U usr.sbin/zic/scheck.c U usr.sbin/zic/zdump.8 U usr.sbin/zic/zdump.c U usr.sbin/zic/zic.8 U usr.sbin/zic/zic.c cvs update: Updating usr.sbin/zic/zdump U usr.sbin/zic/zdump/Makefile cvs update: Updating usr.sbin/zic/zic U usr.sbin/zic/zic/Makefile freefall.freebsd.org: Connection refused cvs [update aborted]: end of file from server (consult above messages if any) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup/cvs oddities?
On Sun, 25 Jun 2000, Matthew Jacob wrote: Can anyone shed light on why a CVSUP'd dirtree I have now always falls down with the following error?... Because it's CVSUP'd, the local repository is just /home/ncvs (NFS mounted). I cannot figure out why it all of a sudden wants to run off the Freefall . Check CVS/Root in that directory. If you do a remote cvs operation it sometimes likes to update the repository to point to freefall, which then screws up cvs update unless you specify "-d /home/ncvs". I have aliases lcvs and rcvs which explicitly state the -d to use (I think this advice came from the committer's guide) Oops. Somehow I had a couple of bad CVS/Root files creep in. The odd thing is that they weren't anywhere near where things died. I had to use find/grep to hunt 'em down. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Destabilization due to SMP development
On Thu, 22 Jun 2000, Greg Lehey wrote: On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote: On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote: Ok, I have put up a web page that will track my efforts. http://apollo.backplane.com/FreeBSDSmp/ Your first patchset contains only i386 code. What is the timeframe for alpha relative to i386? Will each i386 code step converted to it a short time later or finally after the i386 code completely has been stabilized? The alpha code is going to be dealt with by the alpha guys. I am not an alpha assembly programmer. There is going to be considerably more breakage for the alpha port in the next month then the i386 port, but hopefully it will get worked out. Hmm. This adds another dependency. We will really need to get the Alpha code in place before we can commit anything. Is there anybody out there who can do this? If neither Doug nor Andrew have volunteered for this, I'll take it on. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS-UP: for Qlogic (SCSI, Fibre Channel) HBA users
[ if you don't use any of the Qlogic cards, ignore this message for now ] By tonight a new version of this driver will be checked in that no longer supports most of the config options previously used. The most obvious effect of this change will be that firmware can no longer be compiled into the isp driver (no firmware compiled in has been the default for some time). Instead, a separate kernel module (ispfw) can be loaded by adding the line ispfw_load="YES" to your /boot/loader.conf options. There is no automatic mechanism for unloading this after the isp(4) driver configures, but manual unloading (or some rc script style thingie) can then reclaim the 350KBytes of memory the f/w occupies. If you don't want to use a loadable module, this can be staticly linked (as a pseudo-device- ispfw). As ever, with such changes, leading edge config, toolchain kernel source with a clean merge/config/rebuild of the kernels you use are a must. Complaints to me. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
Uh, 'help' doesn't give you a list of commands I believe. On Thu, 15 Jun 2000, Mike Smith wrote: On 15 Jun, Marc van Woerkom wrote: 3. in the boot loader I miss the list of commands, ? (i hope this was the command) just yields a number I also see this. The use of ? was a bad idea, since it's special to Forth. Use 'help' instead. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [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: HEADS UP!: config changes...
Uh, 'help' doesn't give you a list of commands I believe. Damn, it doesn't either. 'help' is the same as 'help help'. Suggestions for a better replacement for ? 'commands'? Just change unadorned help to say 'help help' to get a list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
# I cannot stress this enough: **SAVE A WORKING /kernel** cp /kernel /kernel.works Save a working /modules and /boot as well. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Mon, 8 May 2000, Warner Losh wrote:
In message [EMAIL PROTECTED] Matthew Jacob
writes:
: Oh, and in the updating of this, don't forget the FreeBSD usage of .ctl for
: tape devices- as far as I know this is the only *BSD that has this.
Which devices use .ctl? sa and ast don't seem to use them now (at the
very least they aren't created by MAKEDEV by default).
Should be:
sa*)
umask $tape_umask
unit=`expr $i : '..\(.*\)'`
chr=14
case $unit in
[0-9]|[1-9][0-9]|[1-9][0-9][0-9]|[1-9][0-9][0-9][0-9])
mknod rsa${unit}.ctl c $chr `saminor 1 ${unit} 0 0`
for m in 0 1 2 3
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Mon, 8 May 2000, Dan Nelson wrote: In the last episode (May 08), Warner Losh said: In message [EMAIL PROTECTED] Matthew Jacob writes: : Oh, and in the updating of this, don't forget the FreeBSD usage of : .ctl for tape devices- as far as I know this is the only *BSD that : has this. Which devices use .ctl? sa and ast don't seem to use them now (at the very least they aren't created by MAKEDEV by default). *.ctl is handy for getting status on a device that another process has open; if I'm dumping to /dev/nrsa0, I can run "mt -f /dev/rsa0.ctl status" on another tty and see what file/block position the tape is at. Dunno if it has any other use :) Eventually it will have/set more extended error information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
