Re: GEOM problems?
In message [EMAIL PROTECTED], Brian F. Feldman writes: All the partitions do mount and seem to work OK, so I'm not sure how much of this is expected behavior. Are you using dangerously-dedicated disks? That is, no fdisk-style partition table? If so, disklabel on ad0 or ad2 itself would be valid. No, GEOM is a strictly stacking system, so in that case the disklabel would be on ad0c and ad2c -- 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: devfs oddity?
In message [EMAIL PROTECTED], Bruce Evans writes: On Sat, 5 Oct 2002, Steve Kargl wrote: In message [EMAIL PROTECTED], Steve Kargl w rites: root[208] cdcontrol play cdcontrol: no CD device name specified, defaulting to /dev/cd0c cdcontrol: /dev/cd0cc: No such file or directory Why is an extra c appended to cd0c? The first c is part of the standard name for the whole of a (labelled) disk device. It's not any standard name. It is a convention used on a minority of UNIX platforms out there, and it is certainly not standard even for BSD based systems. It is also illogical, counter-intuitive and prone to mistakes. -- 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: HEADSUP! GEOM as default in 5 days... GEOM does not find da0a; goes to rootmount
In message [EMAIL PROTECTED], Daniel Flickinger writes: Do you have a complete live tree somewhere I could 'fetch' or ftp? Since the errors have been continuing for a week, it looks like I either walk forward from 17 Sep again, or It would help here if you told us what the error you get is. I could suspect that you got cought by the sort + thing. If date | sort +0 gives you an error message, try this: cd /usr/src make installincludes cd usr.bin/sort make obj make depend make all install and see if buildworld works then... -- 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: SSE
German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) Yes; I seem to have this problem on my system whether or not SSE is enabled, though. I've got a: CPU: AMD Athlon(TM) XP 2000+ (1666.65-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x662 Stepping = 2 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! I'm trying to track it down, though. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
German Tischler [EMAIL PROTECTED] wrote: Hi. I can panic my current system compiled from sources of yesterday by just starting mozilla or ogg123 ogg-file if I don't include options CPU_DISABLE_SSE in my kernel configuration file. Is anyone else seeing any SSE code related problems ? (P III based SMP system here) Yes, I see the same problems with npxrestore() in sigreturn(), but on my Athlon it seems to occur with or without SSE. I'm trying to track it down... -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
vnode locking screwed up in src/sys/ufs/ffs/ffs_snapshot.c:ffs_snapshot()
I got a crash today because xvp did not have an interlock when the call was made to vn_lock(LK_INTERLOCK): 407 if (snapdebug) 408 vprint(ffs_snapshot: busy vnode, xvp); 409 if (vn_lock(xvp, LK_EXCLUSIVE | LK_INTERLOCK, td) != 0) 410 goto loop; 411 xp = VTOI(xvp); 412 I don't in fact see any reason why xvp would have been locked already and that this could possibly be valid in the face of a mountpoint which had any vnodes at all open. This occurred on fscking my /tmp filesystem because of crashes (due to an SSE utilization bug in the kernel, it seems), which I'm sure was a filesystem in heavy use already. Does anyone have any insight on what the correct fix to this is? I don't have any idea exactly how to correct the locking in this function. Thanks for insight! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: kmem_malloc(4096): kmem_map too small
... 218222592 total allocated this machine has a total of 512Mb of RAM, and no swap. No X was running. Just ``cvs update''-ing. -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs oddity?
On Sun, 6 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: On Sat, 5 Oct 2002, Steve Kargl wrote: In message [EMAIL PROTECTED], Steve Kargl w rites: root[208] cdcontrol play cdcontrol: no CD device name specified, defaulting to /dev/cd0c cdcontrol: /dev/cd0cc: No such file or directory Why is an extra c appended to cd0c? The first c is part of the standard name for the whole of a (labelled) disk device. It's not any standard name. It is a convention used on a minority of UNIX platforms out there, and it is certainly not standard even for BSD based systems. It is a standard convention in FreeBSD-4, NetBSD and OpenBSD. Except the partition letter is actually d in NetBSD and OpenBSD for i386's and a few other arches. It is also illogical, counter-intuitive and prone to mistakes. That may be, but changing it without even preparing for the change breaks POLA. This consideration prevented me from axing partitions soon after I implemented slices. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
On Sun, Oct 06, 2002 at 07:44:56AM +0930, Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: Some time ago Scott Long pointed out to me that ccd has less overhead than vinum It does? The actual tests showed a very little improvement in a few cases, so I must admit that it made really no difference for bare striping. I have no evidence (not being a programmer), but I believe that ccd is lightweight compared to vinum, even considering only striping. That, and the time of ccd being around compared to vinum, means probably fewer bugs and better suitability for bare striping. That's my personal opinion and I will rely also on other far more knowledgeable person opinion in this particular case. To be fair I believe that vinum striping and mirroring capabilities are fully usable and proven also. I have personal experience which backs this, not that it'll matter much to anybody else. Vinum R5 is broken and I've lost interest over the years of trying to make use of it. No complaints to you, I do understand that paid work is what makes living. and is better suited for bare striping. It is? I'd be interested in details. See above. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs oddity?
On Sun, Oct 06, 2002 at 08:29:52AM +0200, Poul-Henning Kamp wrote: The first c is part of the standard name for the whole of a (labelled) disk device. It's not any standard name. It is a convention used on a minority of UNIX platforms out there, and it is certainly not standard even for BSD based systems. Since when hasn't it been standard on BSD based systems? Other than recently on FreeBSD, all other BSD systems I've used, the c partition has been necessary when wanting to operate on the entire disk. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs oddity?
On Sun, 6 Oct 2002, David O'Brien wrote: Since when hasn't it been standard on BSD based systems? Other than recently on FreeBSD, all other BSD systems I've used, the c partition has been necessary when wanting to operate on the entire disk. Has our CDROM driver ever supported multiple ISO filesystems per CD? Has it supported multi-session CDROMs? The notion of partitions on CDROMs is a little ambiguous. I'm hoping that GEOM can improve this. -- | Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD | | [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax | | http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever | To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: kmem_malloc(4096): kmem_map too small
On 06.10-03:06, Mikhail Teterin wrote: this machine has a total of 512Mb of RAM, and no swap. No X was running. Just ``cvs update''-ing. running vinum ? i am getting this consistently with vinum (but am taking an age to rebuild. did you get a backtrace ? . . . to vfs allocations . . . and a second panic on syncing disks ? -- t t z msg44097/pgp0.pgp Description: PGP signature
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Oct 6 03:16:25 PDT 2002 -- Kernel build for GENERIC completed on Sun Oct 6 03:43:12 PDT 2002 -- Kernel build for LINT started on Sun Oct 6 03:43:12 PDT 2002 -- === vinum Makefile, line 4187: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs oddity?
In message [EMAIL PROTECTED], Matthew N. Dodd w rites: On Sun, 6 Oct 2002, David O'Brien wrote: Since when hasn't it been standard on BSD based systems? Other than recently on FreeBSD, all other BSD systems I've used, the c partition has been necessary when wanting to operate on the entire disk. Has our CDROM driver ever supported multiple ISO filesystems per CD? Has it supported multi-session CDROMs? The notion of partitions on CDROMs is a little ambiguous. I'm hoping that GEOM can improve this. I'm not sure GEOM could improve it as much as atapi-cd already has improved it, I'm not sure where it is documented, but you can access each track separately with some /dev/acd0t%d kind of syntax or something. -- 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: The official GEOM is in the tree speech.
On Sat, 05 Oct 2002 22:39:03 +0200 Poul-Henning Kamp [EMAIL PROTECTED] wrote: One hand for your own code, and one hand for the infrastructure. We have several areas of the kernel which is in disrepair, the worst is buf/VM, but there are others as well. We also have people who are willing to look at it, attempt to make it better, and those people are as good as we were when we started, so why shouldn't we let them try ? We're at the point where a public page with things which need a volunteer would be nice, aren't we (yes, something like your JKH page but not only for kernel parts)? Bye, Alexander. -- Weird enough for government work. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The official GEOM is in the tree speech.
In message [EMAIL PROTECTED], Alexander Leiding er writes: On Sat, 05 Oct 2002 22:39:03 +0200 Poul-Henning Kamp [EMAIL PROTECTED] wrote: One hand for your own code, and one hand for the infrastructure. We have several areas of the kernel which is in disrepair, the worst is buf/VM, but there are others as well. We also have people who are willing to look at it, attempt to make it better, and those people are as good as we were when we started, so why shouldn't we let them try ? We're at the point where a public page with things which need a volunteer would be nice, aren't we (yes, something like your JKH page but not only for kernel parts)? Well, for that to happen it takes two things: 1. One person to write the page. 2. Somebody to keep it updated, follow up on tasks, etc etc. It needs not be the same person. -- 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: The official GEOM is in the tree speech.
On Sun, 06 Oct 2002 14:38:01 +0200 Poul-Henning Kamp [EMAIL PROTECTED] wrote: We're at the point where a public page with things which need a volunteer would be nice, aren't we (yes, something like your JKH page but not only for kernel parts)? Well, for that to happen it takes two things: 1. One person to write the page. Someone with knowledge how www/* works should be able to do this withhin some minutes... when someone provides content for the page... so we first need a description what the page is and some content for it. 2. Somebody to keep it updated, follow up on tasks, etc etc. No, you have a task? Commit it. Someone takes the task? The committer which inserted the task should update it. Bye, Alexander. -- To boldly go where I surely don't belong. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The official GEOM is in the tree speech.
In message [EMAIL PROTECTED], Alexander Leiding er writes: 2. Somebody to keep it updated, follow up on tasks, etc etc. No, you have a task? Commit it. Someone takes the task? The committer which inserted the task should update it. This was (is ?) the priciple behind our fantastic collection of unhandled PRs. We don't want to repeat that mistake. No, if you want such a page to work, it has an interested and dedicated owner, who will take an email from somebody with an idea, send it around to some likely know-it-alls to hear is this a good idea ? Format the edited version, put it on the page, correspond with volounteers, poll them to see if they gave up etc etc etc. Otherwise there is no point in even starting it. -- 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: GEOM problems?
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], walt writes: #disklabel ad0 disklabel: ioctl DIOCGDINFO: Operation not supported by device ad0 does not have a disklabel. Okay, next problem(?). Disklabel with and without the -r flag: #disklabel -r ad2s2 #size offsetfstype [fsize bsize bps/cpg] a: 17207240 77738354.2BSD0 0 0 # (Cyl. 483*- 1554*) b: 40 7373835 swap # (Cyl. 459 - 483*) c: 17607240 7373835unused0 0# (Cyl. 459 - 1554) Warning, partition c doesn't start at 0! Warning, partition c doesn't cover the whole unit! Warning, An incorrect partition c may cause problems for standard system utilities Warning, partition d: size 0, but offset 7373835 Warning, partition e: size 0, but offset 7373835 Warning, partition f: size 0, but offset 7373835 Warning, partition g: size 0, but offset 7373835 Warning, partition h: size 0, but offset 7373835 #disklabel ad2s2 #size offsetfstype [fsize bsize bps/cpg] a: 17207240 404.2BSD0 0 0 # (Cyl. 24*- 1095*) b: 400 swap # (Cyl.0 - 24*) c: 176072400unused0 0# (Cyl.0 - 1095) Warning, partition c doesn't cover the whole unit! This behavior is new with GEOM, as is the warning about c not covering the whole unit. The kernel without GEOM offers no complaints about the same label. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM problems?
In message [EMAIL PROTECTED], walt writes: #disklabel -r ad2s2 #size offsetfstype [fsize bsize bps/cpg] a: 17207240 77738354.2BSD0 0 0 # (Cyl. 483*- 1554*) #disklabel ad2s2 #size offsetfstype [fsize bsize bps/cpg] a: 17207240 404.2BSD0 0 0 # (Cyl. 24*- 1095*) This behavior is new with GEOM, as is the warning about c not covering the whole unit. The kernel without GEOM offers no complaints about the same label. This is because the old code would lie to you if you tried to read the disklabel directly off the media instead of using the ioctl() calls. I feel it is fundamentally wrong to modify data in-band this way without telling the user. Therefore I have not implemented it in GEOM. For reasons I have never fully accepted, the BSD disklabel is written to represent the entire physical disk so the ondisk information does not actually list partition 'c' as starting on sector zero, rather it lists the physical sector number (which corresponds to the start sector of that slice). The way GEOM deals with BSD labels, it will try to identify such a magic offset and correctly DTRT, but it will also accept un-offset ondisk disklabels, which I hope we can migrate to now. -- 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: make linux_base error during rpm
On Sat, 5 Oct 2002 21:28:32 -0700 Adam Kranzel [EMAIL PROTECTED] wrote: On Sat, 5 Oct 2002 21:27:07 -0700 Kris Kennaway [EMAIL PROTECTED] wrote: On Sat, Oct 05, 2002 at 08:36:48PM -0700, Adam Kranzel wrote: It has been committed, and makes it build just fine for me... OK, ignore my previous mail then. Kris I'm doing some testing, and will report back in a bit. It's possible I have something weird going on that's making it work. -Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message It works just fine for me (I cleaned out my ports tree first, to make sure I had no extra files laying around). Are you sure you have a clean /usr/include? I've seen some really weird faliures from having outdated include files (lots of things changed/moved with the upgrades of the system compiler to GCC 3.1 and then 3.2). It's safe to remove /usr/include/* just before an installworld (as far as I can tell), so you could buildworld, remove everything in /usr/include (I'd actually cuggest moving it somewhere else, in case you need it back), installworld, and try building the port again. You should also be able to remove everything in /usr/include then make installincludes in /usr/src, though I've had trouble with that before (probably pilot error though). If I think of anything else I'll let you know. -Adam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
lpt ppbus ppi modules
trying to build the current kernel as modular as possible but if i remove the 'ppbus' and 'lpt' from the kernel config the modules fail (the 'ppc' is still there of course). should these build as KLMs ? -- t t z msg44107/pgp0.pgp Description: PGP signature
Re: kernel panic from vinum during 'restore'
On 05.10-22:16, n0g0013 wrote: don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. don't know if this is related to Mikhail Teterin's post a few hours ago but i have the ddb trace. it may not be exactly accurate because i don't have a serial ddb and therefore have to copy the output from the screen. +++ ddb output from kernel panic +++ panic: kmem_malloc(4096): kmem_map too small: 23134208 total allocated Debugger(panic) Stopped at Debugger+0q45: xchgl %ebx,in_Debugger.0 db trace Debugger(c02cd335) at Debugger+0x45 panic(c02e1402,1000,161,10012,1000) at panic+0x9f kmem_malloc(c0432078,1000,4,c49b47cc,c02759a8) at kmem_malloc+0xcc page_alloc(c05ac500,1000,c49b47bf,4,0) at page_alloc+0x1a slab_zalloc(c05ac500,4,c0daba00,c05ac5e8,c05ac500) at slab_zalloc+0x108 uma_zalloc_internal(c05ac500,0,4,c0daba00) at uma_zalloc_internal+0x13c uma_zalloc_arg(c05ac500,0,4) at uma_zalloc_arg+0x2f4 getnewvnode(c02e070e,c0f4c000,c0dc1100,c49b48b8,90) at getnewvnode+0x3e9 ffs_vget(c0f4c000,486,2,c49b491c,1) at ffs_vget+0x71 ffs_valloc(c1153378,8180,c0f98780,c49b491c) at ffs_valloc+0xed ufs_makeinode(8180,c1153378,c49b4bf8,c49b4c0c) at ufs_makeinode+0x5b ufs_create(c49b4a70,c49b4a90,c01df957,c49b4a70,c02f1260) at ufs_create+0x2b ufs_vnoperate(c49b3a70) at ufs_vnoperate+0x13 VOP_CREATE(c1153378,c49b4bf8,c49b4c0c,c49b4ad4,229) at VOP_CREATE+0x37 vn_open_cred(c49b4be4,c49b4ce4,180,c0f98780,c49b4cd0) at vn_open_cred+0x154 vn_open(c49b4be4,c49b4ce4,180,c1bec3b0,c0de7b04) at vn_open+0x18 kern_open(c05b0680,80ad0c1,0,602,1b6) at kern_open+0x18b open(c05b0680,c49b4d14,3,a83,292) at open+0x18 syscall(2f,2f,2f,80ad0c1,0) at syscall+0x24a Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x08053a43, esp = 0xbfbff73c, ebp = 0xbfbff778 --- db --- ddb output from kernel panic --- * that's no fun * config is identical to before with a kernel rebuild from same sources ( some time last night ). the error i was orginally seeing (over the last week or so) seemed to appear in the vinum_devstrategy but since the various vinum changes it appears to have migrated. -- t t z ---BeginMessage--- got panic from vinum on a small striped drive with small dump/restores -- dump of usr fs to file and restore to vinum volume. dump file is about 120m. kernel built from about -0230 sources but i've been seeing them since first switched current on about 2 weeks ago. don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. +++ kernel panic message +++ panic: kmem_malloc(4096): kmem_map to small: 23179264 total allocated syncing disks... panic: allocbuf: buffer not busy Uptime: 18m12s Dumping 48 MB ata1: resetting devices .. panic: free locked buf Uptime: 18m12s Automatice Reboot in 15 seconds - press a key on the console to abort --- kernel panic message --- +++ vinum config +++ # Vinum configuration of eyore.blahdeblah.demon.co.uk, saved at Sat Oct 5 22:02:24 2002 drive snub device /dev/ad0s1h drive junk device /dev/ad2s1h volume var volume usr volume home volume software plex name var.plex0 org striped 534s vol var plex name usr.plex0 org striped 534s vol usr plex name home.plex0 org striped 534s vol home plex name software.plex0 org striped 534s vol software sd name snub.s0 drive snub plex var.plex0 len 163404s driveoffset 265s plexoffset 0s sd name junk.s0 drive junk plex var.plex0 len 163404s driveoffset 265s plexoffset 534s sd name snub.s1 drive snub plex usr.plex0 len 614100s driveoffset 164105s plexoffset 0s sd name junk.s1 drive junk plex usr.plex0 len 614100s driveoffset 164105s plexoffset 534s sd name snub.s2 drive snub plex home.plex0 len 409578s driveoffset 778505s plexoffset 0s sd name junk.s2 drive junk plex home.plex0 len 409578s driveoffset 778505s plexoffset 534s sd name snub.s3 drive snub plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 0s sd name junk.s3 drive junk plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 534s --- vinum config --- -- t t z msg44108/pgp0.pgp Description: PGP signature ---End Message--- msg44108/pgp1.pgp Description: PGP signature
Re: vnode locking screwed up in src/sys/ufs/ffs/ffs_snapshot.c:ffs_snapshot()
On Sat, Oct 05, 2002 at 11:46:45AM -0400, Brian Fundakowski Feldman wrote: I got a crash today because xvp did not have an interlock when the call was made to vn_lock(LK_INTERLOCK): 407 if (snapdebug) 408 vprint(ffs_snapshot: busy vnode, xvp); 409 if (vn_lock(xvp, LK_EXCLUSIVE | LK_INTERLOCK, td) != 0) 410goto loop; 411 xp = VTOI(xvp); 412 I don't in fact see any reason why xvp would have been locked already and that this could possibly be valid in the face of a mountpoint which had any vnodes at all open. This occurred on fscking my /tmp filesystem because of crashes (due to an SSE utilization bug in the kernel, it seems), which I'm sure was a filesystem in heavy use already. Does anyone have any insight on what the correct fix to this is? I don't have any idea exactly how to correct the locking in this function. Thanks for insight! I had the exact same panic while doing a background fsck on /var. I sent the kernel trace to the list yesterday, and forwarded to Kirk. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM problems?
On 06.10-06:43, walt wrote: Okay, next problem(?). Disklabel with and without the -r flag: don't know if it is a problem or not but i found that doing a null edit on the disk to make GEOM rewrite it's information to the disk eliminated the messages. -- t t z msg44110/pgp0.pgp Description: PGP signature
Re: devfs oddity?
In message [EMAIL PROTECTED], Steve Kargl w rites: root[208] cdcontrol play cdcontrol: no CD device name specified, defaulting to /dev/cd0c cdcontrol: /dev/cd0cc: No such file or directory Why is an extra c appended to cd0c? The first c is part of the standard name for the whole of a (labelled) disk device. It's not any standard name. It is a convention used on a minority of UNIX platforms out there, and it is certainly not standard even for BSD based systems. It's certainly standard on every BSD based system I've ever used, which goes *WAY* back. (Every BSD OS vendor has done it this way, including Sun, DEC, HP, etc...) It is also illogical, counter-intuitive and prone to mistakes. Then every standard is the same, since standards by their very nature are illogical. Doing something the same way is illogical? (If you haven't figured it out, I disagree *strongly* with the above statement.) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe ^^^ Which also used 'c' as the entire 'whole' of a labelled disk device. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM and SCSI-cd: mount not working any more
Hello, just another input for a current system (with GEOM): now it seems inpossible for me to mount a SCSI-CD pc-micha:/# mount -t cd9660 /dev/cd0 /cdrom cd9660: /dev/cd0: Invalid argument Th system has two SCSI-CD-drives (a DVD and a CD-Burner) both have the same behavior. The CD is known to be o.k., as it can be mounted with a pre-GEOM kernel or with Lx. This is the dmesg fragment for the drives: cd0 at sym0 bus 0 target 3 lun 0 cd0: PIONEER DVD-ROM DVD-304F 1.03 Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at sym0 bus 0 target 5 lun 0 cd1: YAMAHA CRW8424S 1.0j Removable CD-ROM SCSI-2 device cd1: 10.000MB/s transfers (10.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed Michael -- - michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: [EMAIL PROTECTED] Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI == instant panic
Enabling acpi leads to an instant panic during boot. The panic so early that I can't get a dump and the machine does not have serial console. The motherboard is an ASUS A7V-133. Here's a hand written panic message Copyright (c) 1992-2002 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. FreeBSD 5.0-CURRENT #1: Sat Oct 5 07:33:03 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HOTRATS Preloaded elf kernel /boot/kernel/kernel at 0xc0441000. Preloaded elf module /boot/kernel/linux.ko at 0xc04410a8. Preloaded elf module /boot/kernel/miibus.ko at 0xc0441154. Preloaded elf module /boot/kernel/if_rl.ko at 0xc0441200. Preloaded elf module /boot/kernel/snd_pcm.ko at 0xc04412ac. Preloaded elf module /boot/kernel/snd_maestro3.ko at 0xc0441358. Preloaded elf module /boot/kernel/agp.ko at 0xc044140c. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1210791212 Hz CPU: AMD Athlon(tm) Processor (1210.79-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x642 Stepping = 2 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA T,PSE36,MMX,FXSR AMD Features=0xc044RSVD,AMIE,DSP,3DNow! real memory = 134217728 (131072K bytes) avail memory = 125644800 (122700K bytes) Pentium Pro MTRR support enabled VESA: v2.0, 8128k memory, flags:0x0, mode table:0xc036ac02 (122) VESA: ATI MACH64 panic: pmap_mapdev: Couldn't alloc kernel virtual memory A verbose boot shows the following sequenc of function calls Debugger panic pmap_mapdev AcpiOsMapMemory AcpiTbGetThisTable AcpiTbGetTableBody AcpiTbGetTableRsdt AcpiLoadTable acpi_identify bus_generic_probe nexus_attach device_probe_and attach probe_and_attach root_bus_configure mi_startup -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and SCSI-cd: mount not working any more
In message [EMAIL PROTECTED], Michael Class writes: Hello, just another input for a current system (with GEOM): now it seems inpossible for me to mount a SCSI-CD pc-micha:/# mount -t cd9660 /dev/cd0 /cdrom cd9660: /dev/cd0: Invalid argument Presumably this is not a GEOM problem, but related to taking the SCSI-cd out of disk-framework of any kind. EINVAL is unfortunately a rather often used return code from the mount code in the kernel, so it will take a bit of testing to find out which particular EINVAL we're dealing with here. Can I get you to insert printfs like the one below all places in vfs_mount.c and cd9660_vfsops.c where you see it using EINVAL and try to find out which particular one it is ? printf(EINVAL HERE %s %d\n, __FILE__, __LINE__): -- 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: kernel panic from vinum during 'restore'
i have a crash dump for this now if anyone is interested. it's not exactly the same trace as it seems to originate from a VOP_LINK request this time but i guess it's the same problem. On 06.10-16:02, n0g0013 wrote: On 05.10-22:16, n0g0013 wrote: don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. don't know if this is related to Mikhail Teterin's post a few hours ago but i have the ddb trace. it may not be exactly accurate because i don't have a serial ddb and therefore have to copy the output from the screen. +++ ddb output from kernel panic +++ panic: kmem_malloc(4096): kmem_map too small: 23134208 total allocated Debugger(panic) Stopped atDebugger+0q45: xchgl %ebx,in_Debugger.0 db trace Debugger(c02cd335) at Debugger+0x45 panic(c02e1402,1000,161,10012,1000) at panic+0x9f kmem_malloc(c0432078,1000,4,c49b47cc,c02759a8) at kmem_malloc+0xcc page_alloc(c05ac500,1000,c49b47bf,4,0) at page_alloc+0x1a slab_zalloc(c05ac500,4,c0daba00,c05ac5e8,c05ac500) at slab_zalloc+0x108 uma_zalloc_internal(c05ac500,0,4,c0daba00) at uma_zalloc_internal+0x13c uma_zalloc_arg(c05ac500,0,4) at uma_zalloc_arg+0x2f4 getnewvnode(c02e070e,c0f4c000,c0dc1100,c49b48b8,90) at getnewvnode+0x3e9 ffs_vget(c0f4c000,486,2,c49b491c,1) at ffs_vget+0x71 ffs_valloc(c1153378,8180,c0f98780,c49b491c) at ffs_valloc+0xed ufs_makeinode(8180,c1153378,c49b4bf8,c49b4c0c) at ufs_makeinode+0x5b ufs_create(c49b4a70,c49b4a90,c01df957,c49b4a70,c02f1260) at ufs_create+0x2b ufs_vnoperate(c49b3a70) at ufs_vnoperate+0x13 VOP_CREATE(c1153378,c49b4bf8,c49b4c0c,c49b4ad4,229) at VOP_CREATE+0x37 vn_open_cred(c49b4be4,c49b4ce4,180,c0f98780,c49b4cd0) at vn_open_cred+0x154 vn_open(c49b4be4,c49b4ce4,180,c1bec3b0,c0de7b04) at vn_open+0x18 kern_open(c05b0680,80ad0c1,0,602,1b6) at kern_open+0x18b open(c05b0680,c49b4d14,3,a83,292) at open+0x18 syscall(2f,2f,2f,80ad0c1,0) at syscall+0x24a Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (5, FreeBSD ELF32, open), eip = 0x08053a43, esp = 0xbfbff73c, ebp = 0xbfbff778 --- db --- ddb output from kernel panic --- * that's no fun * config is identical to before with a kernel rebuild from same sources ( some time last night ). the error i was orginally seeing (over the last week or so) seemed to appear in the vinum_devstrategy but since the various vinum changes it appears to have migrated. -- t t z Date: Sat, 5 Oct 2002 22:16:10 +0100 Subject: kernel panic from vinum during 'restore' From: n0g0013 [EMAIL PROTECTED] To: current [EMAIL PROTECTED] got panic from vinum on a small striped drive with small dump/restores -- dump of usr fs to file and restore to vinum volume. dump file is about 120m. kernel built from about -0230 sources but i've been seeing them since first switched current on about 2 weeks ago. don't currently have the kernel trace for this (i'm rebuilding to get one) and the dump's not making it to disk. perhaps someone else could try and verify in the mean time. +++ kernel panic message +++ panic: kmem_malloc(4096): kmem_map to small: 23179264 total allocated syncing disks... panic: allocbuf: buffer not busy Uptime: 18m12s Dumping 48 MB ata1: resetting devices .. panic: free locked buf Uptime: 18m12s Automatice Reboot in 15 seconds - press a key on the console to abort --- kernel panic message --- +++ vinum config +++ # Vinum configuration of eyore.blahdeblah.demon.co.uk, saved at Sat Oct 5 22:02:24 2002 drive snub device /dev/ad0s1h drive junk device /dev/ad2s1h volume var volume usr volume home volume software plex name var.plex0 org striped 534s vol var plex name usr.plex0 org striped 534s vol usr plex name home.plex0 org striped 534s vol home plex name software.plex0 org striped 534s vol software sd name snub.s0 drive snub plex var.plex0 len 163404s driveoffset 265s plexoffset 0s sd name junk.s0 drive junk plex var.plex0 len 163404s driveoffset 265s plexoffset 534s sd name snub.s1 drive snub plex usr.plex0 len 614100s driveoffset 164105s plexoffset 0s sd name junk.s1 drive junk plex usr.plex0 len 614100s driveoffset 164105s plexoffset 534s sd name snub.s2 drive snub plex home.plex0 len 409578s driveoffset 778505s plexoffset 0s sd name junk.s2 drive junk plex home.plex0 len 409578s driveoffset 778505s plexoffset 534s sd name snub.s3 drive snub plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 0s sd name junk.s3 drive junk plex software.plex0 len 1638312s driveoffset 1188083s plexoffset 534s --- vinum config --- -- t t z -- t t z To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SSE
Daniel Eischen writes: [ CC list trimmed ] On Sat, 5 Oct 2002, Andrew Gallatin wrote: Daniel Eischen writes: 1.539 works. 1.540 crashes. The failure mode is: Bruce and I had a miscommunication over the setting of a flag. It turns out that we can't easily restore the FPU state from the PCB if the one in the ucontext is bad, anyways. Try the following patch: Still crashes. Do you have COMPAT_FREEBSD4 or COMPAT_43? Yes, both. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [ GEOM tests ] vinum drives lost
Yes, ccd is fairly light weight. 'man tuning' and 'man ccd' has a lot of information on how to use it. I generally recommend using a stripe size of 1152 for multitasking loads. Only use a small/tiny stripe size if you need single-tasking sequential performance (and even then you can take tune the stripe to the drive's own caching capability). The biggest mistake most people make when using striping is that they use too small a stripe size which causes nearly every read() or write() to have to be split across multiple drives, which multiplies the overhead, or causes sequential reads of medium sized files to constantly seek multiple drives, destroying the effectiveness of having two seekable heads in the first place. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI s3 suspend/resume and video
I've just gotten a new desktop (P4, Intel D845EBG2 motherboard, ATI Rage 128 Pro AGP 4x video), and I'm thrilled that I can suspend it to ACPI s3. That's awesome! However, when I resume I have no video. Is this a known bug? Is there anything I can do about it? Thanks for your help, Drew Copyright (c) 1992-2002 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. FreeBSD 5.0-CURRENT #0: Sun Oct 6 14:03:54 EDT 2002 gallatin@whisper:/usr/src/sys/i386/compile/WHISPER Preloaded elf kernel /boot/kernel/kernel at 0xc051b000. Preloaded elf module /boot/kernel/rp.ko at 0xc051b0a8. Preloaded elf module /boot/kernel/acpi.ko at 0xc051b150. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 2533435400 Hz CPU: Pentium 4 (2533.44-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf24 Stepping = 4 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 536084480 (523520K bytes) avail memory = 514764800 (502700K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: INTEL D845EBG2 on motherboard Using $PIR table, 10 entries at 0xc00f4670 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci0: ACPI PCI bus on pcib0 agp0: Intel 82845 host to AGP bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) uhci0: Intel 82801DB (ICH4) USB controller USB-A port 0xe800-0xe81f irq 11 at device 29.0 on pci0 usb0: Intel 82801DB (ICH4) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801DB (ICH4) USB controller USB-B port 0xe880-0xe89f irq 5 at device 29.1 on pci0 usb1: Intel 82801DB (ICH4) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801DB (ICH4) USB controller USB-C port 0xec00-0xec1f irq 9 at device 29.2 on pci0 usb2: Intel 82801DB (ICH4) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: serial bus, USB at device 29.7 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci2: ACPI PCI bus on pcib2 fxp0: Intel Pro/100 Ethernet port 0xdc00-0xdc3f mem 0xff9ff000-0xff9f irq 11 at device 8.0 on pci2 fxp0: Ethernet address 00:07:e9:a8:36:f2 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rp0: RocketPort PCI port 0xd880-0xd8bf irq 11 at device 13.0 on pci2 RocketPort0 (Version 3.02) 8 ports. isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH4 ATA100 controller port 0xffa0-0xffaf,0-0x3,0-0x7,0-0x3,0-0x7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) pcm0: Intel 82801DB (ICH4) port 0xe080-0xe0bf,0xe400-0xe4ff mem 0xffaff400-0xffaff4ff,0xffaff800-0xffaff9ff irq 11 at device 31.5 on pci0 acpi_button0: Sleep Button on acpi0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 plip0: PLIP network interface on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0
Re: GEOM and SCSI-cd: mount not working any more
On Sun, Oct 06, 2002 at 06:20:12PM +0200, Poul-Henning Kamp wrote: Can I get you to insert printfs like the one below all places in vfs_mount.c and cd9660_vfsops.c where you see it using EINVAL and try to find out which particular one it is ? printf(EINVAL HERE %s %d\n, __FILE__, __LINE__): printf(EINVAL HERE %s %s %d\n, __func__, __FILE__, __LINE__); even, since we do have C99 in -current. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
suggested patch for small user ppp annoyance
Once in a while, user ppp is killed rather abruptly
and it leaves a diagnostic socket behind, which blocks
the creation of a diagnostic socket after reboot.
Anyway, I propose adding another variable to rc.conf, something
along the lines of the three patches here. The default
value for pppctl_socket would be NO or just . In my case however,
I'll set it to /var/ppp/ppp.
Whaddayall think?
--- usr/src/etc/defaults/rc.conf.orig Sun Oct 6 02:21:33 2002
+++ usr/src/etc/defaults/rc.confSun Oct 6 12:59:53 2002
@@ -115,6 +115,7 @@
ppp_nat=YES # Use PPP's internal network address translation or NO.
ppp_profile=papchap # Which profile to use from /etc/ppp/ppp.conf.
ppp_user=root# Which user to run ppp as
+pppctl_socket=NO # Delete old pppctl diagnostic socket at boot (or NO).
### Network daemon (miscellaneous) ###
syslogd_enable=YES # Run syslog daemon (or NO).
--- usr/src/etc/rc.d/ppp-user.orig Sun Oct 6 01:58:05 2002
+++ usr/src/etc/rc.d/ppp-user Sun Oct 6 12:59:17 2002
@@ -15,7 +15,16 @@ start_cmd=ppp_start
stop_cmd=:
ppp_start()
-{
+{
+ # Check for orphaned pppctl diagnostic socket, delete it.
+ [ ${pppctl_socket} ] case ${pppctl_socket} in
+ [Nn][Oo])
+ # Do nothing
+ ;;
+ *)
+ [ -S ${pppctl_socket} ] rm ${pppctl_socket}
+ esac
+
# Establish ppp mode.
#
if [ ${ppp_mode} != ddial -a ${ppp_mode} != direct \
--- usr/src/etc/rc.network.orig Sat Sep 21 01:36:18 2002
+++ usr/src/etc/rc.network Sun Oct 6 12:57:29 2002
@@ -272,6 +272,16 @@ network_pass1() {
#
case ${ppp_enable} in
[Yy][Ee][Ss])
+ # Check for orphaned pppctl diagnostic socket
+ [ ${pppctl_socket ] case ${pppctl_socket} in
+ [Nn][Oo])
+ # Don't do anything
+ ;;
+ *)
+ # Delete socket if it still exists
+ [ -S ${pppctl_socket} ] rm ${pppctl_socket}
+ esac
+
# Establish ppp mode.
#
if [ ${ppp_mode} != ddial -a ${ppp_mode} != direct \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
GEOM benchmarks
A number of people have asked me for performance data on GEOM
already, so here are up-to-the-minute relevant numbers:
On my test machine (see the details below), a 512 bytes read
from the initialized first sector on a malloc-backed md(4)
device takes 21.7 microsecond, for both mdX, mdXs1
and mdXs1c.
GEOM is stacked, so there the times depend on the number
of layers we have to go through:
device time layers
-
mdX 26.8 microsecond dev, disk
mdXs1 27.1 microsecond dev, mbr, disk
mdXs1c 28.4 microsecond dev, bsd, mbr, disk
So roughly speaking, GEOM itself costs 5 microseconds per
I/O transaction and each simple geom_slicer.c based disk
geometry adds about 800nsec to that.
The transfersize does not matter in this, since geom does
not touch the actual data for the common geom_slicer.c
method.
The same read operation takes 3.6 microsecond on /dev/zero.
Now, I will agree that for md(4) with a malloc backing, this is a
very big slowdown: it takes 23% longer time, but on a regular
disk 5 microseconds is totally lost in the noise.
Some words of caution, to anyone who want to benchmark this
themselves:
With GEOM, a part of the overhead is charged against the GEOM
kernel threads, and the regular resource printout by time(1)
or similar will not account for this part of the actual CPU
usage, so if you compare GEOM to NO_GEOM worldstone, it is not
unexpected that the system time may actually drop, despite
the measurements I presented above.
It is also worth knowing that GEOM is a Giant-free zone. This means
that using GEOM opens up a window for parallelism in the middle of
the I/O path which were not previously there which means that things
may be able to arrange themselves in a different pattern.
Poul-Henning
---
The test-setup is a 1-CPU 700MHz Athlon system booted diskless on
-current kernel from this morning with no WITNESS or KTRACE, and
with no other disk activity in the system.
The test-disk is a 1 megabyte malloc backed md(4) device initialized
with
fdisk -I mdX
disklabel -r -w auto mdXs1
The test program (attached below) basically runs 100,000 loops
like this:
for(j = 0;j N; j++) {
lseek(0, SEEK_SET, 0);
i = read(0, buf, 512);
if (i != 512)
exit(2);
}
with stdin pointed at the target device by the shell.
The program outputs the number of nanoseconds per iteration of
the loop.
The testprogram is then run 10 times for each of the following
devices: /dev/zero, /dev/mdX, /dev/mdXs1, /dev/mdXs1c and the average
and standard deviation of the time output is calculated.
The raw data is included below.
---
GEOM:
zero Samples: 10Average: 3563.810900 Stddev: 43.855366
md9Samples: 10Average: 26773.133200 Stddev: 342.152442
md9s1 Samples: 10Average: 27077.471800 Stddev: 646.937932
md9s1c Samples: 10Average: 28436.273300 Stddev: 209.271601
NO_GEOM:
zero Samples: 10Average: 3741.171000 Stddev: 26.748924
md9Samples: 10Average: 21752.482800 Stddev: 181.397713
md9s1 Samples: 10Average: 21643.089000 Stddev: 204.512877
md9s1c Samples: 10Average: 21639.226900 Stddev: 158.514456
---
/* tst.c */
#include sys/time.h
#define N 10
char buf[512];
main()
{
int i, j;
int c, z;
double a;
struct timeval t1, t2;
for(j = 0;j 100; j++) {
lseek(0, SEEK_SET, 0);
i = read(0, buf, 512);
if (i != 512)
exit(2);
}
gettimeofday(t1, NULL);
for(j = 0;j N; j++) {
lseek(0, SEEK_SET, 0);
i = read(0, buf, 512);
if (i != 512)
exit(2);
}
gettimeofday(t2, NULL);
a = t2.tv_sec + t2.tv_usec / 1e6;
a -= t1.tv_sec + t1.tv_usec / 1e6;
printf(%.3f\n, (a / N) * 1e9 );
exit (0);
}
--
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
Broken ata/ad%d.
Hi After cleaning out some OBE(?) patches, the closest I can get my Libretto 110CT to booting a really recent CURRENT is terminated by a panic. Hand-written backtrace is: Debugger() panic() acpi_read_ivar() ata_dma_init() ad_attach() ata_boot_attach() run_interrupt_driven_config_hooks() mi_startup() begin() The panic message is bad ivar read request (6) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: devfs oddity?
On Sun, 6 Oct 2002 06:08:44 -0400 (EDT), Matthew N. Dodd [EMAIL PROTECTED] said: Has our CDROM driver ever supported multiple ISO filesystems per CD? Has it supported multi-session CDROMs? The notion of partitions on CDROMs is a little ambiguous. I'm hoping that GEOM can improve this. Sort of, but it often gets things wrong for the more interesting CD-ROM types. I've never had it work correctly with Photo CDs, for example; I'm always stuck doing successive `mount_cd9660 -o 12345' until I find the one that actually works (as opposed to the one the code chooses automatically, which never has a valid filesystem on it). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any users of matcd(4), mcd(4), or scd(4)?
On Thu, 3 Oct 2002, John Baldwin wrote: Are there any users who use the matcd(4), mcd(4) or scd(4) drivers? I have at least 20 Panasonic 562/563s still in service in CD-ROM server machines. They still run older versions of FreeBSD because the last time I tried to update it the matcd driver didn't work after the changes to newbus. I just noticed a couple of months ago that it worked again in 4.x and I would like to update these installations eventually and would be willing to test whatever versions of FreeBSD might get broken in order to maintain support into 5.x. Does the -CURRENT tree need to be tested now, or are patches available that may break something now, or is this future possible breakage? Later.. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and SCSI-cd: mount not working any more / fix
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Michael Class writes: Can I get you to insert printfs like the one below all places in vfs_mount.c and cd9660_vfsops.c where you see it using EINVAL and try to find out which particular one it is ? printf(EINVAL HERE %s %d\n, __FILE__, __LINE__): It is in cd9660_vfsops.c in iso_mountfs at line 340. That sounds really odd in my ears. The only think I can think off is if there is a block-size conversion issue I have overlooked. Can you try in line 1372 of scsi_cd.c to change: /* lba */ bp-bio_blkno, to /* lba */ bp-bio_blkno / 4, and see if that helps ? Hello Poul, Yes this solves the problem! Thanks a lot for the fast response. Michael -- - michael class, viktor-renner str. 39, 72074 tuebingen, frg E-Mail: [EMAIL PROTECTED] Phone: +49 7031 14-3707 (work) +49 7071 81950 (private) - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic from vinum during 'restore'
On Sun, 6 Oct 2002, fergus wrote: i have a crash dump for this now if anyone is interested. it's not exactly the same trace as it seems to originate from a VOP_LINK request this time but i guess it's the same problem. To be honest, it sounds like something is simply leaking kernel memory/address space. What you might want to do is have vmstat -m looping with a sleep in the background, writing to a log file, then see if you can figure out which number goes up, but never down.. Maybe something is leaking memory that previously wasn't. You shouldn't even need to crash the machine to figure it out, I think (although with a serious kernel memory leak scenario, that might be unavoidable :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
stdlib.h:57: redeclaration of C++ built-in type `wchar_t'
Hello, when running buildworld I get: === gnu/usr.bin/gperf/doc c++ -O -pipe-D__FBSDID=__RCSID -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/contrib/gperf/src/bool-array.cc c++ -O -pipe-D__FBSDID=__RCSID -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/contrib/gperf/src/gen-perf.cc In file included from /usr/src/contrib/gperf/src/gen-perf.cc:23: /usr/include/stdlib.h:57: redeclaration of C++ built-in type `wchar_t' *** Error code 1 #ifdef _BSD_SIZE_T_ typedef _BSD_SIZE_T_size_t; #undef _BSD_SIZE_T_ How can I resolve this redeclaration? -Hanspeter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
alpha tinderbox failure
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Oct 6 15:20:12 PDT 2002 -- Kernel build for GENERIC completed on Sun Oct 6 15:52:45 PDT 2002 -- Kernel build for LINT started on Sun Oct 6 15:52:45 PDT 2002 -- === vinum Makefile, line 4187: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The official GEOM is in the tree speech.
On Sun, 6 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Alexander Leiding er writes: 2. Somebody to keep it updated, follow up on tasks, etc etc. No, you have a task? Commit it. Someone takes the task? The committer which inserted the task should update it. This was (is ?) the priciple behind our fantastic collection of unhandled PRs. We don't want to repeat that mistake. [...] Great point. There are a ton of PRs without owners that could use a loving home. Let's all do our part in closing 1/week. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
My problems with GEOM
Hello, After recompiling a kernel after the GEOM transition, my boot gets as far as: Initializing GEOMetry subsystem ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Debugger(manual escape to debugger) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c0331a32,4,1,0,1) at Debugger+0x54 scgetc(c03cc1e0,2,c031a8f5,2fd,c1876b40) at scgetc+0x445 sckbdevent(c03a6ee0,0,c03cc1e0,c034b1c0,8) at sckbdevent+0x1d0 atkbd_intr(c03a6ee0,0,c8793d0c,c01a25c2,c03a6ee0) at atkbd_intr+0x2c atkbd_isa_intr(c03a6ee0,0,c0317bac,215,c0bbf370) at atkbd_isa_intr+0x21 ithread_loop(c185fe00,c8793d48,c031790b,34d,7641000a) at ithread_loop+0x182 fork_exit(c01a2440,c185fe00,c8793d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc8793d7c, ebp = 0 --- Am I doing something wrong here? Thanks for any help. My pre-GEOM dmesg, and kernel config follow. A kernel and world from the day before the GEOM switch works fine. Seth Hieronymus ** Copyright (c) 1992-2002 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. FreeBSD 5.0-CURRENT #1: Sat Oct 5 10:00:26 MDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hts7 Preloaded elf kernel /boot/kernel.save/kernel at 0xc0449000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04490b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 698395737 Hz CPU: Pentium III/Pentium III Xeon/Celeron (698.40-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 134217728 (131072K bytes) avail memory = 125603840 (122660K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTD RSDT on motherboard Using $PIR table, 10 entries at 0xc00fdf20 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.2 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.1 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.0 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.1 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.1 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.12.0 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.3 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.3 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.2 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12]
kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh hang in -current (kse bug?)
On Mon, 2002-10-07 at 01:10, Kris Kennaway wrote: Can anyone else reproduce this in tcsh? rpcgen -s `perl -e 'print ax5'` Word too long. And then tcsh will hang in a state unresponsive to signals. Kris Hangs here, too. (this is stable!) FreeBSD klamath.ankon.homeip.net 4.7-RC FreeBSD 4.7-RC #2: Wed Sep 25 09:51:24 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KLAMATH i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Sun, Oct 06, 2002 at 05:08:00PM -0600, Seth Hieronymus wrote: Hello, After recompiling a kernel after the GEOM transition, my boot gets as far as: Initializing GEOMetry subsystem ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Debugger(manual escape to debugger) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c0331a32,4,1,0,1) at Debugger+0x54 scgetc(c03cc1e0,2,c031a8f5,2fd,c1876b40) at scgetc+0x445 sckbdevent(c03a6ee0,0,c03cc1e0,c034b1c0,8) at sckbdevent+0x1d0 atkbd_intr(c03a6ee0,0,c8793d0c,c01a25c2,c03a6ee0) at atkbd_intr+0x2c atkbd_isa_intr(c03a6ee0,0,c0317bac,215,c0bbf370) at atkbd_isa_intr+0x21 ithread_loop(c185fe00,c8793d48,c031790b,34d,7641000a) at ithread_loop+0x182 fork_exit(c01a2440,c185fe00,c8793d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc8793d7c, ebp = 0 --- Am I doing something wrong here? Thanks for any help. My pre-GEOM dmesg, and kernel config follow. A kernel and world from the day before the GEOM switch works fine. I also have the aforementioned problem. I had this problem several months before GEOM was enabled so I can not vouch for it being GEOM- related. Any time I trace after this apparent hang I get a mostly identical trace as you have shown. I have no idea why it happens. I only know that it happens only with FreeBSD on my laptop. No other operating system I have tried on it has this problem. Unfortunately I cannot be more verbose (that I am aware of) than the trace. I have been unsuccessful at forcing a core dump, and I do not know why. I am at the point where if someone offers an idea to get more information I could possily be more useful. I will try adding printf's where I think would be useful but this is a needle in a haystack issue for me since I am not 100% aware of the internals. -- Carl Schmidt [Random Quote] Be different: conform. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: tcsh hang in -current (kse bug?)
Michael Nottebrock wrote: Kris Kennaway wrote: Can anyone else reproduce this in tcsh? Yup. My -CURRENT here is two weeks old. ... reproducible in -STABLE, too. Regards, -- Michael Nottebrock And the reasons? There are no reasons. msg44136/pgp0.pgp Description: PGP signature
Re: stdlib.h:57: redeclaration of C++ built-in type `wchar_t'
Hanspeter Roth wrote: /usr/include/stdlib.h:57: redeclaration of C++ built-in type `wchar_t' *** Error code 1 #ifdef _BSD_SIZE_T_ typedef _BSD_SIZE_T_size_t; #undef _BSD_SIZE_T_ How can I resolve this redeclaration? You failed to delete the old header files when you upgraded your compiler. The easiest answer is man rm. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdlib.h:57: redeclaration of C++ built-in type `wchar_t'
Hanspeter Roth wrote: Hello, when running buildworld I get: === gnu/usr.bin/gperf/doc c++ -O -pipe-D__FBSDID=__RCSID -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/contrib/gperf/src/bool-array.cc c++ -O -pipe-D__FBSDID=__RCSID -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/contrib/gperf/src/gen-perf.cc In file included from /usr/src/contrib/gperf/src/gen-perf.cc:23: /usr/include/stdlib.h:57: redeclaration of C++ built-in type `wchar_t' *** Error code 1 #ifdef _BSD_SIZE_T_ typedef _BSD_SIZE_T_size_t; #undef _BSD_SIZE_T_ How can I resolve this redeclaration? I'm no expert, but I'd guess you have some stale header files in /usr/include. You could try this: cd /usr mv include include.old cd /usr/src make includes make buildworld There may be things in the include.old directory you would want to move back to /usr/include [1], so I would look through it before deleting the whole thing. If you want to be more conservative you could just start by moving /usr/include/g++ out of the way instead of the whole /usr/include, but that may or may not be sufficient. [1] I'm not sure this applies to FreeBSD, since the ports are supposed to put their header files in /usr/local/include, but I don't want to give you risky advice when I'm not certain. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic from vinum during 'restore'
On Sunday, 6 October 2002 at 18:25:08 -0400, Robert Watson wrote: On Sun, 6 Oct 2002, fergus wrote: i have a crash dump for this now if anyone is interested. it's not exactly the same trace as it seems to originate from a VOP_LINK request this time but i guess it's the same problem. To be honest, it sounds like something is simply leaking kernel memory/address space. What you might want to do is have vmstat -m looping with a sleep in the background, writing to a log file, then see if you can figure out which number goes up, but never down.. Maybe something is leaking memory that previously wasn't. You shouldn't even need to crash the machine to figure it out, I think (although with a serious kernel memory leak scenario, that might be unavoidable :-). As a reminder, Vinum keeps track of its kernel memory allocation, and you can view it at any time with 'vinum info -v'. In a typical scenario, you'd expect to see about 50 to 100 kB allocated in about 50 chunks. If you see more, send me the list and I'll check if it looks like a memory leak. I haven't seen any for a long time. Greg -- 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: My problems with GEOM
On Sun, 6 Oct 2002, Carl Schmidt wrote: Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Hmm. I actually ran into this problem on some diskless booting boxes, but it went away so I assumed it was a local nit since I was messing with VFS substantially on the boxes in question. Apparently not. (This was a month or two ago, and quite pre-GEOM as default). Here's my first suggestion: the root file system is mounted by the init process--your trace shows the stack of the current interrupt thread for keyboard I/O, since that's the foreground thread when you break to the debugger. Try using 'trace 1' to trace init instead; also, if you could provide the output from the ddb ps command, that would be very useful. BTW, you really want to be using a serial console for this sort of thing -- copying stuff out by hand is (a) a pain, and (b) very error prone :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel panic trying to utilize a da(4)/umass(4) device withohci(4)
Hi. See pr kern/43462. Happens to me. I wish it would get fixed :) On Sun, 6 Oct 2002, Brian Fundakowski Feldman wrote: I can't get more info because crash dumps don't work when this happens, but for what it's worth, here's a traceback which shows what happens when I attempt to use my da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device on an OHCI-based controller. This was working just a few days ago with a UHCI controller, so ... The crash is from an invalid read at 0xbff3e000, which is PTmap plus some offset. The trace as far as I can get it, from a kernel with USB but no options enabled, would be: ohci_alloc_std_chain+0xf5 (calling a DMAADDR() function, I believe) ohci_device_bulk_start+0x0d ohci_device_bulk_transfer+0x27 usbd_transfer+0xc0 umass_setup_transfer+0x4f umass_bbb_state usb_transfer_complete ohci_softintr Can anyone confirm if this is normal or I have an exceptional system? I have two completely unrelated OHCI-based controllers in my system and neither works. -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can recover /usr/src/include diretories
In the last episode (Oct 06), suken woo said: delete the /usr/src/include dir falsely , can it recover. buildworld again ,but allways get *.h not found. faint. If you used cvsup to update your tree, just run cvsup again and it'll fetch the files over. If you used cvs, run cd /usr/src ; cvs update -dP include. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
From: Robert Watson On Sun, 6 Oct 2002, Carl Schmidt wrote: Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Hmm. I actually ran into this problem on some diskless booting boxes, but it went away so I assumed it was a local nit since I was messing with VFS substantially on the boxes in question. Apparently not. (This was a month or two ago, and quite pre-GEOM as default). Here's my first suggestion: the root file system is mounted by the init process--your trace shows the stack of the current interrupt thread for keyboard I/O, since that's the foreground thread when you break to the debugger. Try using 'trace 1' to trace init instead; also, if you could provide the output from the ddb ps command, that would be very useful. BTW, you really want to be using a serial console for this sort of thing -- copying stuff out by hand is (a) a pain, and (b) very error prone :-). Thanks for the pointers. Here's the trace 1: mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at getdiskbyname+0xa2 setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at setrootbyname+0x11 vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at vfs_mountroot_try+0x127 vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc879cd7c, ebp = 0 --- Here's the output from ps: pid proc addr uid ppid pgrp flag stat wmesg wchan cmd 36 c18f4c08 cd352000 0 0 0 204 norm[SLPQ nfsidl c035bdec][SLP] nfsio d 3 35 c18f4dc0 cd353000 0 0 0 204 norm[SLPQ nfsidl c035bde8][SLP] nfsiod 2 34 c18f7000 cd354000 0 0 0 204 norm[SLPQ nfsidl c035bde4][SLP] nfsiod 1 33 c1868528 c8e0d000 0 0 0 204 norm[SLPQ nfsidl c035bde0][SLP] nfsiod 0 32 c18686e0 c8e0e000 0 0 0 204 norm[SLPQ vlruwt c18686e0][SLP] vnlru 9 c1868898 c8e0f000 0 0 0 204 norm[SLPQ syncer c034c4cc][SLP] syncer 8 c1868a50 c8e1 0 0 0 204 norm[SLPQ psleep c03a2e00][SLP] bufdaemon 7 c1868c08 c8e11000 0 0 0 20c norm[SLPQ pgzero c03a68a8][SLP] pagezero 6 c1868dc0 c8e12000 0 0 0 204 norm[SLPQ psleep c03a68bc][SLP] vmdaemon 5 c18de000 cd309000 0 0 0 204 norm[SLPQ psleep c03612d8][SLP] pagedaemon 4 c18de1b8 cd30a000 0 0 0 204 norm[SLPQ g_down c0345678][SLP] g_down 3 c18de370 cd30b000 0 0 0 204 norm[SLPQ g_up c0345674][SLP] g_up 2 c18de528 cd30c000 0 0 0 204 norm[SLPQ g_read_data_busy c87d5c00][SLP] g_event 31 c18de6e0 cd30d000 0 0 0 204 new [IWAIT] irq8: rtc 30 c18de898 cd30e000 0 0 0 204 new [IWAIT] irq0: clk 29 c0bbf1b8 c87f4000 0 0 0 204 new [IWAIT] irq12: psm0 28 c0bbf370 c87f5000 0 0 0 204 norm[CPU 0] irq1: atkbd0 27 c0bbf528 c87f6000 0 0 0 204 new [IWAIT] irq7: ppc0 26 c0bbf6e0 c87f7000 0 0 0 204 new [IWAIT] irq4: sio0 25 c0bbf898 c87f8000 0 0 0 204 new [IWAIT] swi0: tty:sio 24 c0bbfa50 c87f9000 0 0 0 204 norm[IWAIT] irq6: fdc0 23 c0bbfc08 c87fa000 0 0 0 204 new [IWAIT] irq10: bktr0 22 c0bbfdc0 c87fb000 0 0 0 204 new [IWAIT] irq11: xl0 21 c1868000 c8dcd000 0 0 0 204 norm[IWAIT] irq15: ata1 20 c18681b8 c8dd2000 0 0 0 204 norm[IWAIT] irq14: ata 0 19 c1868370 c8dd3000 0 0 0 204 new [IWAIT] irq9: acpi0 18 c0bb8000 c8778000 0 0 0 204 new [IWAIT] irq13: 17 c0bb81b8 c87eb000 0 0 0 204 new [IWAIT] swi5: task queue 16 c0bb8370 c87ec000 0 0 0 204 new [IWAIT] swi5: acpitaskq 15 c0bb8528 c87ed000 0 0 0 204 norm[SLPQ sleep c036b040][SLP] random 14 c0bb86e0 c87ee000 0 0 0 204 new [IWAIT] swi4: vm 13 c0bb8898 c87ef000 0 0 0 20c norm[IWAIT] swi6: tty:sio clock 12 c0bb8a50 c87f 0 0 0 204 new [IWAIT] swi1: net 11 c0bb8c08 c87f1000 0 0 0 20c norm[Can run] idle 1 c0bb8dc0 c87f2000 0 0 0 200 norm[SLPQ g_waitidle c03778a0][SLP] swapper 10 c0bbf000 c87f3000 0 0 0 204 norm[CVQ ktrace c037a084][SLP] ktrace 0 c0346920 c04a2000 0 0 0 200 norm[SLPQ sched c0346920][SLP] swapper Hope that helps. Anything else you would like me to do? Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ccd performance (was: [ GEOM tests ] vinum drives lost)
On Sunday, 6 October 2002 at 11:30:16 -0700, Matthew Dillon wrote: Yes, ccd is fairly light weight. 'man tuning' and 'man ccd' has a lot of information on how to use it. I generally recommend using a stripe size of 1152 for multitasking loads. Sectors? Why particularly this value? Only use a small/tiny stripe size if you need single-tasking sequential performance (and even then you can take tune the stripe to the drive's own caching capability). The biggest mistake most people make when using striping is that they use too small a stripe size which causes nearly every read() or write() to have to be split across multiple drives, which multiplies the overhead, or causes sequential reads of medium sized files to constantly seek multiple drives, destroying the effectiveness of having two seekable heads in the first place. Pretty much exactly what I preach. One disadvantage of large stripes is that they require careful coding to optimize. I haven't looked at ccd, but I know a lot of cheap hardware RAID arrays always read an entire stripe at a time, which requires more memory and takes longer. Have you checked ccd for this? Greg -- 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: My problems with GEOM
do a 'ps' in ddb On Sun, 6 Oct 2002, Seth Hieronymus wrote: Hello, After recompiling a kernel after the GEOM transition, my boot gets as far as: Initializing GEOMetry subsystem ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Debugger(manual escape to debugger) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db trace Debugger(c0331a32,4,1,0,1) at Debugger+0x54 scgetc(c03cc1e0,2,c031a8f5,2fd,c1876b40) at scgetc+0x445 sckbdevent(c03a6ee0,0,c03cc1e0,c034b1c0,8) at sckbdevent+0x1d0 atkbd_intr(c03a6ee0,0,c8793d0c,c01a25c2,c03a6ee0) at atkbd_intr+0x2c atkbd_isa_intr(c03a6ee0,0,c0317bac,215,c0bbf370) at atkbd_isa_intr+0x21 ithread_loop(c185fe00,c8793d48,c031790b,34d,7641000a) at ithread_loop+0x182 fork_exit(c01a2440,c185fe00,c8793d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xc8793d7c, ebp = 0 --- Am I doing something wrong here? Thanks for any help. My pre-GEOM dmesg, and kernel config follow. A kernel and world from the day before the GEOM switch works fine. Seth Hieronymus ** Copyright (c) 1992-2002 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. FreeBSD 5.0-CURRENT #1: Sat Oct 5 10:00:26 MDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/hts7 Preloaded elf kernel /boot/kernel.save/kernel at 0xc0449000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04490b0. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 698395737 Hz CPU: Pentium III/Pentium III Xeon/Celeron (698.40-MHz 686-class CPU) Origin = GenuineIntel Id = 0x683 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 134217728 (131072K bytes) avail memory = 125603840 (122660K bytes) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTD RSDT on motherboard Using $PIR table, 10 entries at 0xc00fdf20 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 acpi_cpu0: CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.2 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.1 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.15.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.0 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.1 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.16.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.0 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.1 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.17.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.12.0 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.7.3 \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.1.3 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.PCI0.ISA_.LNKA irq 11: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.0 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.2 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.13.3 \\_SB_.PCI0.ISA_.LNKC irq 10: [ 3 4 5 7 9 10 11 12] low,level,sharable 0.14.1 \\_SB_.PCI0.ISA_.LNKD irq 9: [ 3 4 5 7 9
Re: My problems with GEOM
On Sun, 6 Oct 2002, Seth Hieronymus wrote: Thanks for the pointers. Here's the trace 1: mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at getdiskbyname+0xa2 setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at setrootbyname+0x11 vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at vfs_mountroot_try+0x127 vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a This sounds identical (modulo geom details) to the la-la land my boxes were going off into. As I said, I never really followed up, but it looked like one of the i/o/device transactions during the root mount was getting lost, and as a result the init thread was never waking up. I'll probably have to let someone with more i/o clue take it from here. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: tcsh hang in -current (kse bug?)
On 06-Oct-2002 (23:10:55/GMT) Kris Kennaway wrote:
Can anyone else reproduce this in tcsh?
rpcgen -s `perl -e 'print ax5'`
Word too long.
Mee too mail. Using {50,500,5000} works, hang only with 5
(not tested with others numbers). Doing:
# echo {your_command}
print only word too long without hang.
And then tcsh will hang in a state unresponsive to signals.
And 'ps -auxwww' was unable to find neither rpcgen nor perl.
All of this with a not too recent system, build on 24.9.2002 with:
*default date=2002.09.09.00.00.42
Riccardo.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
how to build native jdk13 with hotspot under current?
as title thanks any help To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In the last episode (Oct 06), Robert Watson said: On Sun, 6 Oct 2002, Seth Hieronymus wrote: Thanks for the pointers. Here's the trace 1: mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at getdiskbyname+0xa2 setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at setrootbyname+0x11 vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at vfs_mountroot_try+0x127 vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a This sounds identical (modulo geom details) to the la-la land my boxes were going off into. As I said, I never really followed up, but it looked like one of the i/o/device transactions during the root mount was getting lost, and as a result the init thread was never waking up. I'll probably have to let someone with more i/o clue take it from here. I'm not at the machine right now, but I noticed that my work machine would hang for a long time ( 5 minutes) on bootup, then continue. I finally figured out what the problem was: it has two SCSI cdrom drives, and geom apparently needed to get info on the disks for some reason. Neither drive had a CD in it, and it had to time out a read request on both drives before it would boot. Try sticking a data CD in your cdrom and see if the hang goes away. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
On Sun, Oct 06, 2002 at 08:26:03PM -0400, Robert Watson wrote: On Sun, 6 Oct 2002, Carl Schmidt wrote: Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): Hmm. I actually ran into this problem on some diskless booting boxes, but it went away so I assumed it was a local nit since I was messing with VFS substantially on the boxes in question. Apparently not. (This was a month or two ago, and quite pre-GEOM as default). Here's my first suggestion: the root file system is mounted by the init process--your trace shows the stack of the current interrupt thread for keyboard I/O, since that's the foreground thread when you break to the debugger. Try using 'trace 1' to trace init instead; also, if you could provide the output from the ddb ps command, that would be very useful. BTW, you really want to be using a serial console for this sort of thing -- copying stuff out by hand is (a) a pain, and (b) very error prone :-). I believe you were addressing the originator of this thread but I will go ahead and show my trace/ps: db trace 1 mi_switch(c0f014e0,cd33dca8,1,80202,c0f018f0) at mi_switch+0x1b3 ithread_schedule(c25e6b00,1) at ithread_schedule+0x10d sched_ithd(1) at sched_ithd+0x37 Xintr1() at Xintr1+0x67 --- interrupt, eip = 0xc025b5b0, esp = 0xcd33dcfc, ebp = 0xcd33dd04 --- cpu_unpend(cd33dd14,c018478d,cd33d3c,c019a750,2800) at cpu_unpend+0x28 cpu_critical_exit(cd33dd3c,c019a750,2800,1,73e) at cpu_critical_exit+0x12 critical_exit(2800,1,73e,0,c0f05c40) at critical_exit+0x21 ast(cd33dd48) at ast+0x39c doreti_ast() at doreti_ast+0x1a db ps 33 c25dd528 cddbf000000 204 norm[SLPQ psleep c02dc580][SLP] bufdaemon 9 c25dd6e0 cddc000 20c norm[RUNQ] pagezero 8 c25dd898 cddc1000000 204 norm[SLPQ psleep c02df91c][SLP] vmdaemon 7 c25dda50 cddc2000000 204 norm[SLPQ psleep c02c9b18][SLP] pagedaemon 6 c25ddc08 cddc3000000 204 norm[SLPQ g_down c02b1a58][SLP] g_down 5 c25dddc0 cddc4000000 204 norm[SLPQg_up c02b1a54][SLP] g_up 4 c2615000 d1ddf000000 204 norm[SLPQ g_events c02b1a4c][SLP] g_event 32 c26151b8 d1de000 204 new [IWAIT] irq8: rtc 31 c2615370 d1de1000000 204 new [IWAIT] irq0: clk 30 c2615528 d1de2000000 204 norm[IWAIT] irq6: fdc0 29 c26156e0 d1de3000000 204 new [IWAIT] irq3: sio1 28 c2615898 d1de4000000 204 new [IWAIT] irq4: sio0 27 c0f071b8 cd395000000 204 new [IWAIT] swi0: tty:sio 26 c0f07370 cd396000000 204 new [IWAIT] irq12: psm0 25 c0f07528 cd397000000 204 norm[CPU 0] irq1: atkbd0 24 c0f076e0 cd398000000 204 norm[RUNQ] irq5: pcm0 23 c0f07898 cd399000000 204 norm[IWAIT] irq15: ata1 22 c0f07a50 cd39a000000 204 norm[IWAIT] irq14: ata0 3 c0f07c08 cd39b000000 204 norm[CVQ cbb cv c25e074c][SLP] cbb1 2 c0f07dc0 cd39c000000 204 norm[CVQ cbb cv c25e014c][SLP] cbb0 21 c25dd000 cdd7e000000 204 new [IWAIT] irq11: cbb0 cbb1+ 20 c25dd1b8 cdd84000000 204 norm[SLPQ nothing c042473c][SLP] acpi_thermal 19 c25dd370 cdd85000000 204 norm[IWAIT] irq9: acpi0 18 c0f0 cd319000000 204 new [IWAIT] irq13: 17 c0f001b8 cd38c000000 204 new [IWAIT] swi5: task queue 16 c0f00370 cd38d000000 204 norm[IWAIT] swi5: acpitaskq 15 c0f00528 cd38e000000 204 norm[SLPQ sleep c03e1aa0][SLP] random 14 c0f006e0 cd38f000000 204 new [IWAIT] swi1: net 13 c0f00898 cd39000 204 new [IWAIT] swi4: vm 12 c0f00a50 cd391000000 20c norm[IWAIT] swi6: tty:sio clock 11 c0f00c08 cd392000000 20c norm[Can run] idle 1 c0f00dc0 cd393000000 0004200 norm[RUNQ] init 10 c0f07000 cd394000000 204 norm[CVQ ktrace c02d7c44][SLP] ktrace 0 c02b2780 c0453000000 200 norm[SLPQ sched c02b2780][SLP] swapper -- Carl Schmidt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and SCSI-cd: mount not working any more
On Sun, 6 Oct 2002, David O'Brien wrote: On Sun, Oct 06, 2002 at 06:20:12PM +0200, Poul-Henning Kamp wrote: Can I get you to insert printfs like the one below all places in vfs_mount.c and cd9660_vfsops.c where you see it using EINVAL and try to find out which particular one it is ? printf(EINVAL HERE %s %d\n, __FILE__, __LINE__): printf(EINVAL HERE %s %s %d\n, __func__, __FILE__, __LINE__); even, since we do have C99 in -current. :-) Or printf(foo 1\n); printf(foo 2\n); ... Using lots of __func, __FILE__, __LINE bloats the source and executable without significantly simplifying debugging, since unique strings are easy to find using grep. I'd like some of the standard bulky debugging interfaces to use the caller's pc and not pass around __func__, __FILE__, __LINE__. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
Dan, From: Dan Nelson In the last episode (Oct 06), Robert Watson said: On Sun, 6 Oct 2002, Seth Hieronymus wrote: Thanks for the pointers. Here's the trace 1: mi_switch(c0bb9988,14,c01bbe60,c0bb98f0,1) at mi_switch+0x290 msleep(c03778a0,0,68,c03153d7,14) at msleep+0x477 g_waitidle(1,c0314e10,c18f2885,c031bd64,c0b8dc20) at g_waitidle+0x8b g_dev_clone(0,c18f2885,6,c879cc08,c0bb6d80) at g_dev_clone+0x37 getdiskbyname(c18f2880,c879cc80,c0202f87,c18f2880,c18f2880) at getdiskbyname+0xa2 setrootbyname(c18f2880,c18f2880,c879cc48,c18f2880,20302020) at setrootbyname+0x11 vfs_mountroot_try(c1867220,c01912e0,c0bb8dc0,c879cd0c,c019134b) at vfs_mountroot_try+0x127 vfs_mountroot(c034b1c0,1,c0316bc7,216,203a2065) at vfs_mountroot+0x70 start_init(0,c879cd48,c031790b,34d,726f772d) at start_init+0x6b fork_exit(c01912e0,0,c879cd48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a This sounds identical (modulo geom details) to the la-la land my boxes were going off into. As I said, I never really followed up, but it looked like one of the i/o/device transactions during the root mount was getting lost, and as a result the init thread was never waking up. I'll probably have to let someone with more i/o clue take it from here. I'm not at the machine right now, but I noticed that my work machine would hang for a long time ( 5 minutes) on bootup, then continue. I finally figured out what the problem was: it has two SCSI cdrom drives, and geom apparently needed to get info on the disks for some reason. Neither drive had a CD in it, and it had to time out a read request on both drives before it would boot. Try sticking a data CD in your cdrom and see if the hang goes away. You were right. After trying both a CD, and a zip-disk in the computer (both together, and separately), having a zip-disk in the drive seems to allow the boot to continue normally. Thanks all, Seth To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
xdm can not login on current
hello folks: xdm broken on current when login . i knew this is the pam module problem,but how could i fix it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: kmem_malloc(4096): kmem_map too small
îÅĦÌÑ 06 öÏ×ÔÅÎØ 2002 03:13 am, n0g0013 ÷É ÎÁÐÉÓÁÌÉ: On 06.10-03:06, Mikhail Teterin wrote: this machine has a total of 512Mb of RAM, and no swap. No X was running. Just ``cvs update''-ing. running vinum ? i am getting this consistently with vinum (but am taking an age to rebuild. No, this is my laptop :-) did you get a backtrace ? . . . to vfs allocations . . . and a second panic on syncing disks ? No... With today's kernel, machine has already _frozen_ after swappager complained about lack of swap. Rather sad -- a not so uncommon installation with 128Mb of memory plus twice that much of swap would still have less virtual memory than this box, which seems to be suffering because all its memory is real... BTW, what happened to the NO_SWAPPING kernel option? -mi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: My problems with GEOM
In message [EMAIL PROTECTED], Seth Hieronymus writes: Hello, After recompiling a kernel after the GEOM transition, my boot gets as far as: Initializing GEOMetry subsystem ad0: 28629MB ST330630A [58168/16/63] at ata0-master UDMA33 acd0: CDROM Lite-On LTN483S 48x Max at ata1-master PIO4 afd0: 239MB IOMEGA ZIP 250 ATAPI [239/64/32] at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s1a and hangs -- only a physical reset works. However, breaking into the debugger, and running a trace, I get (hand-copied): I suspect that the afd0 may be involved, can you try to disconnect it and see if that solves the problem ? -- 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: My problems with GEOM
In message [EMAIL PROTECTED], Seth Hieronymus writes: You were right. After trying both a CD, and a zip-disk in the computer (both together, and separately), having a zip-disk in the drive seems to allow the boot to continue normally. ATA(PI) or SCSI interface ZIP ? -- 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: panic: kmem_malloc(4096): kmem_map too small
On Mon, 7 Oct 2002, Mikhail Teterin wrote: No... With today's kernel, machine has already _frozen_ after swappager complained about lack of swap. Rather sad -- a not so uncommon installation with 128Mb of memory plus twice that much of swap would still have less virtual memory than this box, which seems to be suffering because all its memory is real... BTW, what happened to the NO_SWAPPING kernel option? Nothing. I always use it, and it just works. Note that it only disables swapping (of UPAGES) and has little effect on paging to swap, and was never intended to. This is is documented very clearly in cvs history and very unclearly in NOTES: %%% RCS file: /home/ncvs/src/sys/vm/vm_glue.c,v Working file: vm_glue.c head: 1.157 ... revision 1.39 date: 1996/02/22 10:57:36; author: davidg; state: Exp; lines: +4 -3 Add a NO_SWAPPING option to disable swapping. This was originally done to help diagnose a problem on wcarchive (where the kernel stack was sometimes not present), but is useful in its own right since swapping actually reduces performance on some systems (such as wcarchive). Note: swapping in this context means making the U pages pageable and has nothing to do with generic VM paging, which is unaffected by this option. Reviewed by: dyson NOTES: ... # # Disable swapping. This option removes all code which actually performs # swapping, so it's not possible to turn it back on at run-time. # # This is sometimes usable for systems which don't have any swap space # (see also sysctls vm.defer_swapspace_pageouts and # vm.disable_swapspace_pageouts) # #!options NO_SWAPPING %%% I doubt that swapping is useful for many systems that are newer than the commit that added NO_SWAPPING. If there aren't many processes then swapping doesn't do much, and if there are a lot of processes (as on wcarchive), then you don't want to swap. The memory for the UPAGES of wcarchive's 1500 (?) processes was a whole 12MB. Much larger number of processes are common now, but memories are larger too. Work is under weigh (sic) to bloat the number of UPAGES (including kernel stack pages) and the number of processes (there are almost 100 in the kernel alone now), but hopefully it won't progress as fast as memories grow. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Junior Kernel Hacker page updated...
Terry Lambert wrote:
Stefan Farfeleder wrote:
(kgdb) l *kqueue_scan+0x242
0xc01a1212 is in kqueue_scan
(/freebsd/current/src/sys/kern/kern_event.c:716).
713 TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
714 while (count) {
715 kn = TAILQ_FIRST(kq-kq_head);
translates to: mov(%edi),%ebx
716 TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
translates to: cmpl $0x0,0x8(%ebx)
This line causes the page fault because %ebx is 0.
[ ... ]
Please try the attached patch.
-- Terry
Stefan: Did the patch fix it, or not?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: xdm can not login on current
Date: Mon, 07 Oct 2002 12:48:33 +0800 From: suken woo [EMAIL PROTECTED] xdm broken on current when login . It isn't for me, and I've been tracking -CURRENT daily for some time. i knew this is the pam module problem,but how could i fix it? Well, absent any clues as to why you think it might be broken (such as messages or other anomalous behavior), I doubt you'll get many constructive suggestions. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
