Re: cvs commit: src/sbin/umount umount.c
In message <[EMAIL PROTECTED]>, Ian Dowse writes:
>I was planning to return a filesystem ID of {st_dev, 0} to non-root
>users,
Please notice that st_dev is not constant across reboots.
Suggest you hash the real fsid and use the hash instead.
--
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hello! Yes, unsigned, so we have 4G limit, which may simple be overflowed by (for example) PPPoE connection. Yes, RADIUS standard defines new attributes for big words, but current PPP does not supports it (it, so our knowledge about RFC is useless :) Again, rad_put_int defined u_int32_t parameter, so if a have dowloaded 4.5G (for example) what number will send to radius? Regards, Boris Barney Wolff wrote: On Wed, Nov 19, 2003 at 09:00:01AM +0500, Boris Kovalenko wrote: I found a serious bug in RADIUS accounting code. The problem is that OctetsIn and OctetsOut are defined as unsingned long long, but the RADIUS supports only INT32 values, so, when we're doing rad_put_int(r->cx.rad, RAD_ACCT_OUTPUT_OCTETS, stats->OctetsOut) in radius.c for OctetsOut (and OctetsIn also) we loosing information if OctetsOut is greater then INT32_MAX. This should be fixed. Note that RADIUS integers are unsigned, so the limit is 2^32-1. Also, RFC2869 defines attributes to hold the high-order parts. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: > Hello! > > Yes, unsigned, so we have 4G limit, which may simple be overflowed > by (for example) PPPoE connection. Yes, RADIUS standard defines new > attributes for big words, but current PPP does not supports it (it, so > our knowledge about RFC is useless :) Again, rad_put_int defined > u_int32_t parameter, so if a have dowloaded 4.5G (for example) what > number will send to radius? > How about sending periodic RADIUS accounting updates? After each accounting update the counters could be reset, but I'm not sure whether this is RFC compliant, i.e. whether allways the complete value has to be send or whether the counters could be reset, after each update. For Mpd we implemented it without resetting the counters, but maybe that's not 100% right. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hello! Standard PPP does not support UPDATE packets, and of course (as my RADIUS knowledge) the counters should not be resetted, because RADIUS updates the same record. Regards, Boris Michael Bretterklieber wrote: Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: Hello! Yes, unsigned, so we have 4G limit, which may simple be overflowed by (for example) PPPoE connection. Yes, RADIUS standard defines new attributes for big words, but current PPP does not supports it (it, so our knowledge about RFC is useless :) Again, rad_put_int defined u_int32_t parameter, so if a have dowloaded 4.5G (for example) what number will send to radius? How about sending periodic RADIUS accounting updates? After each accounting update the counters could be reset, but I'm not sure whether this is RFC compliant, i.e. whether allways the complete value has to be send or whether the counters could be reset, after each update. For Mpd we implemented it without resetting the counters, but maybe that's not 100% right. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: build world question
Jason <[EMAIL PROTECTED]> writes: > I told it to make buildworld, do I also need to tell it make world? 'make world' simply does buildworld followed by installworld. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hi Boris, On Wed, 19 Nov 2003, Boris Kovalenko wrote: > Hello! > > Standard PPP does not support UPDATE packets, and of course (as my but a patch could be written :-) > RADIUS knowledge) the counters should not be resetted, because RADIUS > updates the same record. The RFC says: 5.4. Acct-Output-Octets blabla can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. It looks like, that these counters must not present in accounting updates. bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS broken in -CURRENT as of 16 hours ago?
Hi all, I might be completely off here, but since I did a update/buildkernel/buildworld yesterday evening, NFS seems to act up. I can mount a remote NFS resource locally and access it, but when I try to access a subdirectory it seems to hang and never return. I currently have two zombie mc-processes (midnight commander) due to this, and ls'ing the subdirs hangs infinitely. I have absolutely no clue what else the cause could be. I'm always very careful to only change one thing at a time (ok this was two things, kernel and world..) and then check that my working environment is OK. Mergemaster replaced two files, mac.conf and motd. Anyone else seeing the same or something similiar? Oh and for the record, I am right now unable to start rxvt. Xterm works. And now rxvt works again. Something funky is going on :) Could this be related to the last major change, the dynamic root? /Eirik signature.asc Description: This is a digitally signed message part
Re: ppp RADIUS accounting bug
The RFC says: 5.4. Acct-Output-Octets blabla can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop. It looks like, that these counters must not present in accounting updates. You are right, but your words - "but a patch could be written :-)". Again, I'm talking not about UPDATE packets and presence of any attributes in RADIUS requests. I'm talking about wrong handling of Acct-Input-Octets & Acct-Output-Octets with current PPP RADIUS implementation. How this will be done, by implementing RFC2869 support or just by resending STOP request N times is not so important, but somehow this should be done. I may try to write patch myself, but I'm looking for someone who supervises my patch and commit it if no problems will be founded. Regards, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hi, On Wed, 19 Nov 2003, Boris Kovalenko wrote: > > >The RFC says: > > > >5.4. Acct-Output-Octets > > > >blabla > > > >can only be > > present in Accounting-Request records where the Acct-Status-Type > > is set to Stop. > > > >It looks like, that these counters must not present in accounting updates. > > > You are right, but your words - "but a patch could be written :-)". > Again, I'm talking not about UPDATE packets and presence of any > attributes in RADIUS requests. I'm talking about wrong handling of > Acct-Input-Octets & Acct-Output-Octets with current PPP RADIUS > implementation. How this will be done, by implementing RFC2869 support IMHO this would be the right way, because RFC 2869 definitely says: "Note that all information in an interim message is cumulative (i.e. number of packets sent is the total since the beginning of the session, not since the last interim message)." So sending interim update packets won't help. > looking for someone who supervises my patch and commit it if no problems > will be founded. this can be a problem :-) bye, -- --- -- Michael Bretterklieber - http://www.bretterklieber.com A-Quadrat Automation GmbH - http://www.a-quadrat.at Tel: ++43-(0)3172-41679 - GSM: ++43-(0)699 12861847 --- -- "...the number of UNIX installations has grown to 10, with more expected..." - Dennis Ritchie and Ken Thompson, June 1972 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Tue, Nov 18, 2003 at 06:26:21PM -0800, Matthew Dillon wrote: > > :Our rationale for encouraging Gordon is as follows: > : > :1. 4.x upgrade path: As we approach 5-STABLE, a lot of users might want > :to upgrade from 4-STABLE. Historically in 4.x, the / partition has > :been very modest in size. One just simply cannot cram the bloat that > :has grown in 5.x into a 4.x partition scheme. Of course there is the > :venerable 'dump - clean install - restore' scheme, but we were looking > :for something a little more user-friendly. > > This argument would apply to very old 4.x users but not to anyone who > installed it as of March 2001. I bumped the nominal size of the > root partition to 128MB in 1.98.2.7 of sysinstall/label.c. Don't you think that people are able to change defaults if they think thats appropriate? > Prior to that Jordan had bumped the root partition size to 100MB > in 1.98.2.3 in March 2001. It was 50MB before then, which is too > small even for 4.x. Hm, then why do I have still room on my 50MB root partition? $ df Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/vinum/root49583 29040 1657764%/ Thats enough for installworld (if softupdates are turned off) Gunther ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Tue, 18 Nov 2003 [EMAIL PROTECTED] wrote: > Garrett Wollman said: > > < > > > > If the object is to maximally 'share', > > > > The object, AIUI, is for ~username expansion to work in the shells > > when the user stored somewhere defined by an external NSS module. I > > don't believe that there is anything else in a (sane) shell that > > cares. > > > It is a fallacy that EVERYTHING (e.g. libc) needs to be dynamically > linked to support that feature. A single, self contained library > that might even be sparse WRT memory isn't going to hurt much. It's a fallacy that ANYTHING (except nscd/lookupd) needs to be dynamically linked to support that feature :-) -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/ User interface? I hardly know 'er! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ppp RADIUS accounting bug
Hello! So sending interim update packets won't help. Like I said :) looking for someone who supervises my patch and commit it if no problems will be founded. this can be a problem :-) This is the problem now :) I'm wondering if I only one useing ppp with RADIUS accounting with FreeBSD. Regards, Boris ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using Geom to mirror root partitions?
On Sat, Nov 15, 2003 at 09:42:18AM +0100, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Josef Karthauser writes: > > >What's the best way to prepare for this? Should I leave some > >unallocated space at the beginning of the disk so that any magic geom > >bits can be inserted later? > > Rather: leave a bit free at the end. > How much would you recommend I leave? Proportional to the disk size, or just enough space for data structures? Joe -- Josef Karthauser ([EMAIL PROTECTED]) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ An eclectic mix of fact and theory. = pgp0.pgp Description: PGP signature
Re: Using Geom to mirror root partitions?
In message <[EMAIL PROTECTED]>, Josef Karthauser writes: > >--RnlQjJ0d97Da+TV1 >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Sat, Nov 15, 2003 at 09:42:18AM +0100, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Josef Karthauser w= >rites: >>=20 >> >What's the best way to prepare for this? Should I leave some >> >unallocated space at the beginning of the disk so that any magic geom >> >bits can be inserted later? >>=20 >> Rather: leave a bit free at the end. >>=20 > >How much would you recommend I leave? Proportional to the disk size, or >just enough space for data structures? In theory one sector should do fine, but make it a bit more. -- 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. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PATCH] Please test SMP changes
[ Bcc'd to various arch mailing lists ] Please test the patch at http://www.FreeBSD.org/~jhb/patches/smp.patch You can apply it to a sys/ check out by using patch -p6. It moves the setting of mp_maxid into a separate function (cpu_mp_setmaxid()) that is called before loader tunables so that UMA and others can use it. cpu_mp_probe() is now called at SI_SUB_CPU / SI_ORDER_SECOND like it used to be. This is necessay to re-enable the ACPI module on i386. I have tested it on i386 but not on other archs. Please be sure to test that a normal SMP kernel works as well as booting an SMP kernel with 'kern.smp.disabled'. cpu_mp_probe() is no longer called if SMP is disabled in the loader using the tunable. Thanks. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
[cc: dropped] I suppose I should comment on this thread, since I'm closely related to at least two of the rationales mentioned for moving towards an all-dynamically-linked system. (I would prefer to stay out of this thread. In my mind we've had all these arguments in various forums months ago and the issue was put to rest.) On Tue, Nov 18, 2003 at 05:06:06PM -0700, Scott Long wrote: > 2. NSS support out-of-the-box: Again, this is a user-experience issue > in that forcing NSS users to recompile world was seen as a potential > roadblock to them. Some followups mentioned that a different implementation of NSS would not require dynamically linked binaries. This is technically true. Certainly, I explored that avenue. But practical considerations made that alternative a poor choice. Supporting NSS really also means supporting (in as much as possible) the existing base of NSS modules. These modules were all designed to be loaded by libc and invoked in-process. (nscd doesn't do what some seem to think it does, and in practice it is not well-loved.) Existing NSS modules also shaped some other decisions that I made (such as API entry points and thread awareness or lack thereof). Breaking with the fundamental designs of NSS as found on Solaris and Linux means practically starting from scratch when `porting' NSS modules. I'm sure someone more clever and with more time could make it work out-of-process. Based on my experience, I think the result would be overengineered. *shrug* Finally, if we could call `dlopen' from statically-linked binaries, this wouldn't be an issue. I'd really like to see dlopen support for statically-linked binaries, for NSS and many other applications. > 3. Binary security updates: there is a lot of interest in providing a > binary update mechanism for doing security updates. Having a dynamic > root means that vulnerable libraries can be updated without having to > update all of the static binaries that might use them. Actually, not only binary security updates but any security updates, or bug fixes for that matter. If there is a bug in a library, fixing that bug on your system is much more straightforward if everything is dynamically linked. It is much easier to rebuild libc or libcrypto and restart applications then to have to go through an entire `make world'. It can be hard for many administrators to avoid `make world', because it is not always easy to ascertain what applications are using what APIs and libraries. There's been a lot of talk about performance, but for my environment all the workhorse applications are already dynamically linked. I'd guess that is the case for most FreeBSD users. And of course, most FreeBSD binaries--- in the base system, in ports, and commercially available--- are already dynamically linked. For the minority of users that it actually has a performance impact (show of hands?), of course they are sophisticated enough to build the affected binaries statically. Unless we are talking about /bin/sh, they probably already have to go through special measures to get a statically linked binary. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
In a message written on Wed, Nov 19, 2003 at 08:10:59AM -0600, Jacques A. Vidrine wrote: > statically. Unless we are talking about /bin/sh, they probably already > have to go through special measures to get a statically linked binary. Something has been bothering me about the whole /bin/sh function, and today when fixing a box I realized what it was. To boot a machine into single user mode you need a kernel, init, and /bin/sh (minimally). It would seem to me that alone is a good argument for those three things to be static. Yes, I'm one of those people who rebuilds kernels without modules. The kernel problem doesn't bother me as much, as you can always boot without loading modules, so it's not really a "part of the required kernel is dynamic" problem. Outside of these issues I have no problem with a dynamic root and a /rescue. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Unfortunate dynamic linking for everything
On Wed, Nov 19, 2003 at 09:19:50AM -0500, Leo Bicknell wrote: > To boot a machine into single user mode you need a kernel, init, > and /bin/sh (minimally). Roughly the same thing was bothering me last night. You get a chance to specify the shell when init is in the last phase of getting you to single-user mode so you can say /rescue/sh at that point. init is another story and I asked someone about that, they said it either is or will shortly be a loader option so you can override that to be /rescue/init that way. -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vinum error: statfs related?
Any more word on this? I haven't tried creating a new volume to see if it will create because i don't want to loose wants currently there. Not trying to harrass anyone, just checking :). Daryl --- Robert Watson <[EMAIL PROTECTED]> wrote: > > On Fri, 17 Jan 2003, Eric Anholt wrote: > > > I'm getting the same (no > drives/subdisks/plexes/volumes found) trying to > > upgrade from a Nov 11 kernel/userland to Nov 16th > kernel. I tried > > seeing if using a Nov 16th vinum binary would load > them, but after doing > > a stop/start, the system paniced, and it seems my > swap is too small to > > dump on. Kernel was built using configure > MYKERNEL; cd > > ../compile/MYKERNEL; make depend all install > instead of buildkernel. DDB > > enabled but no invariants/witness, not sure what > else from my config > > might be applicable. > > I'm able to trigger this warning simply by starting > and stopping Vinum > without a Vinum configuration: > > ttyp0: > crash2# vinum start > ** no drives found: No such file or directory > crash2# vinum stop > vinum unloaded > > console: > vinum: loaded > vinum: no drives found > vinum: exiting with malloc table inconsistency at > 0xc2053c00 from > vinumio.c:755 > vinum: unloaded > > I attempted to experiment some with Vinum today. > After fixing a bug in > the vinum user tool to stop trying to create device > nodes and directories > in devfs, it seemed to come up OK (fix committed). > I documented the bug > that vinum won't work with storage devices with > sector sizes other than > DEV_BSIZE (512) in the vinum.8 man page, since I > don't have time to fix it > today. I created a malloc md-backed vinum array > with seeming ease, but > was unable to newfs the result: > > ttyp0: > crash2# mdconfig -a -t malloc -s 1m > md0 > crash2# mdconfig -a -t malloc -s 1m > md1 > crash2# mdconfig -a -t malloc -s 1m > md2 > crash2# vinum > vinum -> concat /dev/md0 /dev/md1 /dev/md2 > vinum -> quit > crash2# newfs /dev/vinum/vinum0 > /dev/vinum/vinum0: 2.6MB (5348 sectors) block size > 16384, fragment size 2048 > using 4 cylinder groups of 0.66MB, 42 > blks, 128 inodes. > super-block backups (for fsck -b #) at: >160, 1504, 2848, 4192 > cg 0: bad magic number > > console: > vinum: loaded > vinum: drive vinumdrive0 is up > vinum: drive vinumdrive1 is up > vinum: drive vinumdrive2 is up > vinum: vinum0.p0.s0 is up > vinum: vinum0.p0.s1 is up > vinum: vinum0.p0.s2 is up > vinum: vinum0.p0 is up > vinum: vinum0 is up > > So clearly UFS is unhappy with something about the > array. I tried > reading/writing stuff to/from the array with pretty > mixed results: > > ttyp0: > crash2# diskinfo /dev/vinum/vinum0 > /dev/vinum/vinum0 512 2738688 5349 > crash2# dd if=/dev/random of=/data.file bs=512 > count=5349 > 5349+0 records in > 5349+0 records out > 2738688 bytes transferred in 2.520634 secs > (1086508 bytes/sec) > crash2# dd if=/data.file of=/dev/vinum/vinum0 > bs=512 count=5349 > 5349+0 records in > 5349+0 records out > 2738688 bytes transferred in 2.464483 secs > (263 bytes/sec) > crash2# dd if=/dev/vinum/vinum0 of=/data.file2 > bs=512 count=5349 > 5349+0 records in > 5349+0 records out > 2738688 bytes transferred in 2.467386 secs > (1109955 bytes/sec) > crash2# ls -l /data.f* > -rw-r--r-- 1 root wheel 2738688 Nov 17 17:02 > /data.file > -rw-r--r-- 1 root wheel 2738688 Nov 17 17:03 > /data.file2 > crash2# md5 /data.file* > MD5 (/data.file) = > ce76d17b337f70c1d4d53b48cf08f906 > MD5 (/data.file2) = > b1d08e0fe52ecff364a894edf43caef2 > > The reason for the somewhat long copy times is that > / for this box is out > of NFS. To be sure, I ran this a second time: > > MD5 (/data.file.3) = > d0c9d71cfacedc70358be028f0c346dd > MD5 (/data.file.4) = > 0ea319da8e68550c2ebf91e6b1618976 > > It sounds like there's a serious problem with Vinum > right now. I took a > look through the vinum data structures, and I > couldn't see any obvious > problems that could have stemmed from the statfs() > change: specifically, I > didn't see any data structures that would have > changed size as a result of > the change. So I'm guessing it was some other > similarly timed change, but > I'm not sure what. > > It's interesting to observe that I didn't get the > malloc failure when I > unloaded Vinum after the above tests: it appears to > occur as a result of a > configuration difficulty (such as a failure to find > one), and so may > actually be a red herring for the underlying > problem. Or at least, an > independent bug/feature. > > I'm heading home for the day, when I head home, I'll > try changing around > the testing procedure to attempt to identify what > exactly is getting > corrupted in my dd tests. > > Robert N M Watson FreeBSD Core Team, > TrustedBSD Projects > [EMAIL PROTECTED] Network Associates > Laboratories > ___
Re: Unfortunate dynamic linking for everything
In a message written on Wed, Nov 19, 2003 at 09:25:35AM -0500, Ken Smith wrote: > Roughly the same thing was bothering me last night. You get a chance > to specify the shell when init is in the last phase of getting you to > single-user mode so you can say /rescue/sh at that point. init is > another story and I asked someone about that, they said it either is > or will shortly be a loader option so you can override that to be > /rescue/init that way. Perhaps /rescue/sh should be the default when booting into single user. The more I think about init the more I don't like dynamic linking for it. init needs to have as few failure modes as possible. I do still think it's fine for all the other /bin and /sbin things. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
ICH4 gaps in sound.
I have a pcm0: port 0xbc40-0xbc7f,0xb800-0xb8ff mem 0xf4fff400-0xf4fff4ff,0xf4fff800-0xf4fff9ff irq 11 at device 31.5 on pci0 pcm0: in my laptop. During sound playback I hear small gaps in the sound output. My sense is that they occur every second or so ... about the size of the application buffers that are sent to the sound device. I'm using xmms for playback. The gaps are a pop or click in the sound and don't seem to represent any change in the timing of the sound. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: another trap 12 while in kernel mode
On Wed, 19 Nov 2003, Bjoern A. Zeeb wrote: > I am regularly getting those but unfortunately I neither have DDB in > that kernel nor can get a crash dump nor do I have built wie DEBUG=-g. > > Is there anything more I can do apart from rebuilding kernel with > support of all the missing debugging flags (which is in progress) ? You should still be able to turn the bad instruction pointer into at least a function name using nm on your compiled kernel. Run nm on the kernel binary, and search through it until you find the symbols just before (lower) and just after (higher) than the value listed for the instruction pointer below. That would at least tell us what function the fault is occuring in. I suspect to get anywhere useful, we'll need the full debugging results, but it's probably a useful start, and it will allow us to be sure the panics you might get after you have debugging support compiled in are the same failure mode. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories > > I am logged in via serial console on this machine btw but I am not > sure if this is the killing criteria for this panic. According to the > log I write there had been no output for a long time before. > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x6c2f6e81 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc055a00a > stack pointer = 0x10:0xc9b4acac > frame pointer = 0x10:0xc9b4acac > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 26 (swi8: tty:sio clock) > trap number = 12 > panic: page fault > > syncing disks, buffers remaining... 426 426 426 426 426 426 426 426 426 426 426 426 > 426 426 426 426 426 426 426 426 > giving up on 349 buffers > Uptime: 6h46m27s > pfs_vncache_unload(): 1 entries remaining > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > > -- > Bjoern A. Zeebbzeeb at Zabbadoz dot NeT > 56 69 73 69 74http://www.zabbadoz.net/ > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: another trap 12 while in kernel mode
On Wed, 19 Nov 2003, Robert Watson wrote: Hi, > You should still be able to turn the bad instruction pointer into at least > a function name using nm on your compiled kernel. Run nm on the kernel > binary, and search through it until you find the symbols just before > (lower) and just after (higher) than the value listed for the instruction > pointer below. That would at least tell us what function the fault is > occuring in. I suspect to get anywhere useful, we'll need the full > debugging results, but it's probably a useful start, and it will allow us > to be sure the panics you might get after you have debugging support > compiled in are the same failure mode. thanks for your answer. > > instruction pointer = 0x8:0xc055a00a c0559e10 T key_sa_routechange c0559f10 t key_sa_chgstate c0559fb0 T key_sa_stir_iv c0559fe0 t key_sp_dead c0559ff0 t key_sp_unlink c055a020 t key_alloc_mbuf c055a100 t kdebug_typestr c055a150 t kdebug_sadb_msg_typestr c055a170 t kdebug_sadb_ext_typestr Cc'ed ume. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
Ok, here's the final patch. I believe it fixes both problems.
* Add a DEVMETHOD for acpi so that child detach methods get called. Add
an acpi_cpu method for both detach and shutdown that disables entry to
acpi_cpu_idle and then IPIs/waits for threads to exit. This fixes a panic
late in reboot in the SMP case.
* In the !SMP case, don't use the processor id filled out by the MADT
since there can only be one processor. This was causing a panic in
acpi_cpu_idle if the id was 1 since the data was being dereferenced from
cpu_softc[1] even though the actual data was in cpu_softc[0] (which is
correct).
* Rework the initialization functions so that cpu_idle_hook is written
late in the boot process.
* Make the P_BLK, P_BLK_LEN, and cpu_cx_count all softc-local variables.
This will help SMP boxes that have _CST or multiple P_BLKs. No such boxes
are known at this time.
* Always allocate the C1 state, even if the P_BLK is invalid. This means
we will always take over idling if enabled. Remove the value -1 as valid
for cx_lowest since this is redundant with machdep.cpu_idle_hlt.
* Reduce locking for the throttle initialization case to around the write
to the smi_cmd port. Add disabled code to write the CST_CNT. It will be
enabled once _CST re-evaluation is tested (post 5.2R).
Thank you: dfr, imp, jhb, marcel, peter
-Nate
Index: sys/dev/acpica/acpi_cpu.c
===
RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v
retrieving revision 1.19
diff -u -r1.19 acpi_cpu.c
--- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19
+++ sys/dev/acpica/acpi_cpu.c 19 Nov 2003 15:21:07 -
@@ -1,5 +1,5 @@
/*-
- * Copyright (c) 2003 Nate Lawson
+ * Copyright (c) 2003 Nate Lawson (SDG)
* Copyright (c) 2001 Michael Smith
* All rights reserved.
*
@@ -30,20 +30,21 @@
#include "opt_acpi.h"
#include
-#include
-#include
#include
+#include
+#include
#include
+#include
#include
-#include
#include
#include
+#include
#include
-#include
#ifdef __ia64__
#include
#endif
+#include
#include "acpi.h"
#include
@@ -77,9 +78,11 @@
device_tcpu_dev;
ACPI_HANDLE cpu_handle;
uint32_tcpu_id;/* ACPI processor id */
+uint32_tcpu_p_blk; /* ACPI P_BLK location */
+uint32_tcpu_p_blk_len; /* P_BLK length (must be 6). */
struct resource*cpu_p_cnt; /* Throttling control register */
struct acpi_cx cpu_cx_states[MAX_CX_STATES];
-int cpu_bm_ok; /* Bus mastering control available. */
+int cpu_cx_count; /* Number of valid Cx states. */
};
#define CPU_GET_REG(reg, width)\
@@ -116,10 +119,9 @@
#define PCI_REVISION_4M3
/* Platform hardware resource information. */
-static uint32_t cpu_p_blk; /* ACPI P_BLK location */
-static uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */
static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */
static uint8_t cpu_pstate_cnt;/* Register to take over throttling. */
+static uint8_t cpu_cst_cnt; /* Indicate we are _CST aware. */
static uint32_t cpu_rid; /* Driver-wide resource id. */
static uint32_t cpu_quirks;/* Indicate any hardware bugs. */
@@ -128,6 +130,9 @@
static uint32_t cpu_cx_next; /* State to use for next sleep. */
static uint32_t cpu_non_c3;/* Index of lowest non-C3 state. */
static struct acpi_cx_stats cpu_cx_stats[MAX_CX_STATES];
+#ifdef SMP
+static int cpu_idle_busy; /* Count of CPUs in acpi_cpu_idle. */
+#endif
/* Values for sysctl. */
static uint32_t cpu_current_state;
@@ -146,11 +151,13 @@
static int acpi_cpu_probe(device_t dev);
static int acpi_cpu_attach(device_t dev);
+static int acpi_cpu_detach(device_t dev);
static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc);
static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc);
static voidacpi_cpu_startup(void *arg);
static voidacpi_cpu_startup_throttling(void);
+static voidacpi_cpu_startup_cx(void);
static voidacpi_cpu_throttle_set(uint32_t speed);
static voidacpi_cpu_idle(void);
static voidacpi_cpu_c1(void);
@@ -166,6 +173,8 @@
/* Device interface */
DEVMETHOD(device_probe,acpi_cpu_probe),
DEVMETHOD(device_attach, acpi_cpu_attach),
+DEVMETHOD(device_detach, acpi_cpu_detach),
+DEVMETHOD(device_shutdown, acpi_cpu_detach),
{0, 0}
};
@@ -178,6 +187,7 @@
static devclass_t acpi_cpu_devclass;
DRIVER_MODULE(acpi_cpu, acpi, acpi_cpu_driver, acpi_cpu_devclass, 0, 0);
+
static int
acpi_cpu_probe(device_t dev)
{
@@ -272,11 +282,10 @@
AcpiEvaluateOb
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Nate Lawson wrote: > Ok, here's the final patch. I believe it fixes both problems. Success! The system rebooted without panicking. It even came back up cleanly. :-) In an earlier e-mail, you asked me for dmesg output. I've attached it on the off chance you still want it. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories > > * Add a DEVMETHOD for acpi so that child detach methods get called. Add > an acpi_cpu method for both detach and shutdown that disables entry to > acpi_cpu_idle and then IPIs/waits for threads to exit. This fixes a panic > late in reboot in the SMP case. > > * In the !SMP case, don't use the processor id filled out by the MADT > since there can only be one processor. This was causing a panic in > acpi_cpu_idle if the id was 1 since the data was being dereferenced from > cpu_softc[1] even though the actual data was in cpu_softc[0] (which is > correct). > > * Rework the initialization functions so that cpu_idle_hook is written > late in the boot process. > > * Make the P_BLK, P_BLK_LEN, and cpu_cx_count all softc-local variables. > This will help SMP boxes that have _CST or multiple P_BLKs. No such boxes > are known at this time. > > * Always allocate the C1 state, even if the P_BLK is invalid. This means > we will always take over idling if enabled. Remove the value -1 as valid > for cx_lowest since this is redundant with machdep.cpu_idle_hlt. > > * Reduce locking for the throttle initialization case to around the write > to the smi_cmd port. Add disabled code to write the CST_CNT. It will be > enabled once _CST re-evaluation is tested (post 5.2R). > > Thank you:dfr, imp, jhb, marcel, peter > > -Nate > > Index: sys/dev/acpica/acpi_cpu.c > === > RCS file: /home/ncvs/src/sys/dev/acpica/acpi_cpu.c,v > retrieving revision 1.19 > diff -u -r1.19 acpi_cpu.c > --- sys/dev/acpica/acpi_cpu.c 15 Nov 2003 19:26:05 - 1.19 > +++ sys/dev/acpica/acpi_cpu.c 19 Nov 2003 15:21:07 - > @@ -1,5 +1,5 @@ > /*- > - * Copyright (c) 2003 Nate Lawson > + * Copyright (c) 2003 Nate Lawson (SDG) > * Copyright (c) 2001 Michael Smith > * All rights reserved. > * > @@ -30,20 +30,21 @@ > > #include "opt_acpi.h" > #include > -#include > -#include > #include > +#include > +#include > #include > +#include > #include > -#include > #include > > #include > +#include > #include > -#include > #ifdef __ia64__ > #include > #endif > +#include > > #include "acpi.h" > #include > @@ -77,9 +78,11 @@ > device_t cpu_dev; > ACPI_HANDLE cpu_handle; > uint32_t cpu_id;/* ACPI processor id */ > +uint32_t cpu_p_blk; /* ACPI P_BLK location */ > +uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */ > struct resource *cpu_p_cnt; /* Throttling control register */ > struct acpi_cxcpu_cx_states[MAX_CX_STATES]; > -int cpu_bm_ok; /* Bus mastering control available. */ > +int cpu_cx_count; /* Number of valid Cx states. */ > }; > > #define CPU_GET_REG(reg, width) \ > @@ -116,10 +119,9 @@ > #define PCI_REVISION_4M 3 > > /* Platform hardware resource information. */ > -static uint32_t cpu_p_blk; /* ACPI P_BLK location */ > -static uint32_t cpu_p_blk_len; /* P_BLK length (must be 6). */ > static uint32_t cpu_smi_cmd; /* Value to write to SMI_CMD. */ > static uint8_tcpu_pstate_cnt;/* Register to take over throttling. */ > +static uint8_tcpu_cst_cnt; /* Indicate we are _CST aware. */ > static uint32_t cpu_rid; /* Driver-wide resource id. */ > static uint32_t cpu_quirks;/* Indicate any hardware bugs. */ > > @@ -128,6 +130,9 @@ > static uint32_t cpu_cx_next; /* State to use for next sleep. */ > static uint32_t cpu_non_c3;/* Index of lowest non-C3 state. */ > static struct acpi_cx_stats cpu_cx_stats[MAX_CX_STATES]; > +#ifdef SMP > +static intcpu_idle_busy; /* Count of CPUs in acpi_cpu_idle. */ > +#endif > > /* Values for sysctl. */ > static uint32_t cpu_current_state; > @@ -146,11 +151,13 @@ > > static int acpi_cpu_probe(device_t dev); > static int acpi_cpu_attach(device_t dev); > +static int acpi_cpu_detach(device_t dev); > static int acpi_cpu_throttle_probe(struct acpi_cpu_softc *sc); > static int acpi_cpu_cx_probe(struct acpi_cpu_softc *sc); > static int acpi_cpu_cx_cst(struct acpi_cpu_softc *sc); > static void acpi_cpu_startup(void *arg); > static void acpi_cpu_startup_throttling(void); > +static void acpi_cpu_startup_cx(void); > static void acpi_cpu_throttle_set(uint32_t speed); > static
Re: [PATCH] Please test SMP changes
John Baldwin wrote: [ Bcc'd to various arch mailing lists ] Please test the patch at http://www.FreeBSD.org/~jhb/patches/smp.patch You can apply it to a sys/ check out by using patch -p6. It moves the setting of mp_maxid into a separate function (cpu_mp_setmaxid()) that is called before loader tunables so that UMA and others can use it. cpu_mp_probe() is now called at SI_SUB_CPU / SI_ORDER_SECOND like it used to be. This is necessay to re-enable the ACPI module on i386. I have tested it on i386 but not on other archs. Please be sure to test that a normal SMP kernel works as well as booting an SMP kernel with 'kern.smp.disabled'. cpu_mp_probe() is no longer called if SMP is disabled in the loader using the tunable. Thanks. What all do I need to adjust on my end, other patches? I took 'device acpi' out of my kernel, but if I try to boot with the acpi module loaded, the kernel still uses MPTable for interrupts: Copyright (c) 1992-2003 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.1-CURRENT #0: Wed Nov 19 08:55:07 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MAXKERNEL_DEBUG Preloaded elf kernel "/boot/kernel/kernel" at 0xc07d8000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07d8250. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (350.80-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 402587648 (383 MB) avail memory = 385548288 (367 MB) MPTable: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard ACPI-0168: *** Error: Could not transition to ACPI mode. acpi0: Could not enable ACPI: AE_NO_HARDWARE_RESPONSE device_probe_and_attach: acpi0 attach returned 6 Pete... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ATAPI CD Changer problem in -CURRENT
I just upgraded my workstation from 5.1-RELEASE to todays -CURRENT. When I boot it, I get the following messages about my CD drives: acd0-5: CDROM with 6 CD changer at ata1-master PIO4 acd6: DVDROM at ata1-slave PIO4 acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST error=4 acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST error=4 acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST error=4 acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST error=4 I get the 4 failures after the 2 first slots (both containing a CD) have been probed, and I guess there is an error for every empty slot. In 5.1-RELEASE the kernel didn't change through the drives while booting. It is a little annoying, but not my main concern. The real problem is, that only the first slot works. When I try to mount a cd from the second slot (acd1), I get this: borg# mount /drv/cd2 cd9660: /dev/acd1: Input/output error It doesn't make any difference whether acd0 is mounted or not. If you need further information about the problem, let me know. Thanks. -- Best regards Christian Laursen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI CD Changer problem in -CURRENT
Christian Laursen wrote: I just upgraded my workstation from 5.1-RELEASE to todays -CURRENT. When I boot it, I get the following messages about my CD drives: acd0-5: CDROM with 6 CD changer at ata1-master PIO4 acd6: DVDROM at ata1-slave PIO4 acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST error=4 acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST error=4 acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST error=4 acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST error=4 I get the 4 failures after the 2 first slots (both containing a CD) have been probed, and I guess there is an error for every empty slot. In 5.1-RELEASE the kernel didn't change through the drives while booting. It is a little annoying, but not my main concern. The real problem is, that only the first slot works. When I try to mount a cd from the second slot (acd1), I get this: borg# mount /drv/cd2 cd9660: /dev/acd1: Input/output error It doesn't make any difference whether acd0 is mounted or not. If you need further information about the problem, let me know. I'm seeing the same thing on my laptop with an internal DVDROM/CDRW drive. Never did that before (something changed since Nov 14th-ish). Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
: Don't you think that people are able to change defaults if they think : thats appropriate? : :> Prior to that Jordan had bumped the root partition size to 100MB :> in 1.98.2.3 in March 2001. It was 50MB before then, which is too :> small even for 4.x. : : Hm, then why do I have still room on my 50MB root partition? : :$ df :Filesystem 1K-blocksUsed Avail Capacity Mounted on :/dev/vinum/root49583 29040 1657764%/ : : Thats enough for installworld (if softupdates are turned off) : : Gunther Try running installkernel and see what happens when it tries to rename the old kernel and modules and install a new one. Or try installing a kernel.debug (which is 14MB+) instead of a kernel. The point here is that just because you can barely squeeze the system into 50MB doesn't mean it's a good idea to. It might work for a very narrow use pattern, but it will create terrible problems if you ever tried to expand your use and the system defaults have to cover more then just generic users reasonably. This is why the default is no longer 50MB. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Wed, Nov 19, 2003 at 09:25:35AM -0500, Ken Smith wrote: > On Wed, Nov 19, 2003 at 09:19:50AM -0500, Leo Bicknell wrote: > > > To boot a machine into single user mode you need a kernel, init, > > and /bin/sh (minimally). > > Roughly the same thing was bothering me last night. You get a chance > to specify the shell when init is in the last phase of getting you to > single-user mode so you can say /rescue/sh at that point. init is > another story and I asked someone about that, they said it either is > or will shortly be a loader option so you can override that to be > /rescue/init that way. set init_path=/rescue/init It's rather non-intuitive. It works, but having a static /sbin/init avoids having to muck around in the loader in order to get to the rescue bits. If you need the rescue bits, you pretty much always need to use /rescue/init anyway. A dynamicly linked /sbin/init just makes it harder to get to the rescue bits, so it makes sense to link init(8) staticly. Especially since there's no advantage to dynamic linking init(8) that compensates for the inconvience. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Robert Watson wrote: > On Wed, 19 Nov 2003, Nate Lawson wrote: > > > Ok, here's the final patch. I believe it fixes both problems. > > Success! The system rebooted without panicking. It even came back up > cleanly. :-) Good to hear. I think Don has the same problem as Harald so perhaps he can report on the patch. > In an earlier e-mail, you asked me for dmesg output. I've attached it on > the off chance you still want it. Looks great! sysctl hw.acpi.cpu? -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Nate Lawson wrote: > On Wed, 19 Nov 2003, Robert Watson wrote: > > On Wed, 19 Nov 2003, Nate Lawson wrote: > > > > > Ok, here's the final patch. I believe it fixes both problems. > > > > Success! The system rebooted without panicking. It even came back up > > cleanly. :-) > > Good to hear. I think Don has the same problem as Harald so perhaps he > can report on the patch. > > > In an earlier e-mail, you asked me for dmesg output. I've attached it on > > the off chance you still want it. > > Looks great! sysctl hw.acpi.cpu? crash2:~> sysctl hw.acpi.cpu hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 2902705/0 Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Alpha SMP panic
On 17-Nov-2003 Kris Kennaway wrote: > On Sun, Nov 16, 2003 at 06:39:17PM -0800, David O'Brien wrote: >> # cd /usr/src ; cvs -qR up -PdA >> ... >> U sys/netgraph/bluetooth/include/ng_btsocket_hci_raw.h >> U sys/netgraph/bluetooth/include/ng_btsocket_l2cap.h >> U sys/netgraph/bluetooth/include/ng_btsocket_rfcomm.h >> panic: Assertion td->td_turnstile != NULL failed at >> ../../../kern/subr_turnstile.c:427 >> cpuid = 1; >> panic >> spin lock sched lock held by 0xfc001f053c80 for > 5 seconds > > I'm able to easily produce this on two amd64 machines too. Can you try this: http://www.FreeBSD.org/~jhb/patches/spurious.patch It includes the TD_ON_RUNQ() fix as well as some assertions that should hopefully catch the bug the assertion above is catching if it's not a case of nesting on a turnstile. A backtrace from the first panic might help if you can get it. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Robert Watson wrote: > On Wed, 19 Nov 2003, Nate Lawson wrote: > > On Wed, 19 Nov 2003, Robert Watson wrote: > > > Success! The system rebooted without panicking. It even came back up > > > cleanly. :-) > > > > Good to hear. I think Don has the same problem as Harald so perhaps he > > can report on the patch. > > > > > In an earlier e-mail, you asked me for dmesg output. I've attached it on > > > the off chance you still want it. > > > > Looks great! sysctl hw.acpi.cpu? > > crash2:~> sysctl hw.acpi.cpu > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 2902705/0 Ok, this is correct. Hopefully SMP boxes in the future will have multiple P_BLKs and/or _CST and we can have better power savings. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
--On Wednesday, November 19, 2003 12:30 AM -0500 Garance A Drosihn <[EMAIL PROTECTED]> wrote: have a: chflags ldcache /bin/sh Shouldn't that be 'chmod +t /bin/sh' ??? --lyndon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hard lock-up writing to tape
On Tuesday 18 November 2003 08:29 pm, Bruce Evans wrote: > > This could be from a speed mismatch or from kern.consmute somehwo getting > set. I had wondered about a speed mismatch, but everything I've found says 9600. I did not know to look at kern.consmute. I'll check that. > - -current has the kern.console sysctl for enabling multiple consoles > (buut only 1 sio one). You can boot with a syscons console and then > enable the serial, and the latter should work if it is on a working > port to begin with. Anyway, this sysctl shows which sio port can be > a console, if any. Is there any documentation on this sysctl? I'm not sure what I should set it to. After a normal boot, it reads: kern.console: consolectl,/ttyd1,consolectl, > - RELENG_4 and -current have the machdep.conspeed sysctl for setting the > console speed. That is the expected 9600. mike ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PATCH] Please test SMP changes
On 19-Nov-2003 Peter Schultz wrote: > John Baldwin wrote: >> [ Bcc'd to various arch mailing lists ] >> >> Please test the patch at http://www.FreeBSD.org/~jhb/patches/smp.patch >> You can apply it to a sys/ check out by using patch -p6. It moves >> the setting of mp_maxid into a separate function (cpu_mp_setmaxid()) >> that is called before loader tunables so that UMA and others can use >> it. cpu_mp_probe() is now called at SI_SUB_CPU / SI_ORDER_SECOND like >> it used to be. This is necessay to re-enable the ACPI module on i386. >> I have tested it on i386 but not on other archs. Please be sure to >> test that a normal SMP kernel works as well as booting an SMP kernel >> with 'kern.smp.disabled'. cpu_mp_probe() is no longer called if SMP >> is disabled in the loader using the tunable. Thanks. >> > What all do I need to adjust on my end, other patches? I took 'device > acpi' out of my kernel, but if I try to boot with the acpi module > loaded, the kernel still uses MPTable for interrupts: No, please. Don't disable ACPI. This is not all the patches to do that. Mostly I just want to mkae sure that I don't break SMP probing on all the different architectures. i386 seems to be working fine, I'm primarily after testing on the other archs: alpha, amd64, ia64, and sparc64 in particular to make sure I didn't break SMP probing on those archs. To be clear: ACPI needs _more_ patches in addition to smp.patch before it will work as a module again. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
WRITE_DMA and stopevent 2 errors installing a current snap from yesterday.
I was trying to install a current snapshot from yesterday on my laptop but without being able to finish because of errors some of which I was able to transcribe manually. I hope this is useful to someone and if you have any suggestions as to what the next step is, that to would be appreciated. ad0: WARNING - WRITE_DMA recovered from missing interrupt And many of the following. There are probably others but . . . . . I didn't get them. Checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r=0 0xc2e4faa8 locked @ /usr/src/sys/kern/subr_trap.c:260 Checking stopevent 2 with the following non-sleepable locks held: exclusive sleep mutex sigacts r=0 0xc2e4faa8 locked @ /usr/src/sys/kern/kern_synch.c:293 These were all I was able to copy. _ Share holiday photos without swamping your Inbox. Get MSN Extra Storage now! http://join.msn.com/?PAGE=features/es ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bge0 read timed out / cardbus activation
I recently cvsup'ed (yesterday, and again this morning), and build/installed world/kernel etc. Now, when I connect a cardbus card (in this case, it's a firewire card), my broadcom bge0 interface goes crazy, stops functioning, and I get this: Nov 19 10:18:32 neutrino kernel: cardbus0: Resource not specified in CIS: id=10, size=1 Nov 19 10:18:32 neutrino kernel: bge1: mem 0xf601-0xf601 irq 11 at device 0.0 on cardbus0 Nov 19 10:18:32 neutrino kernel: bge1: RX CPU self-diagnostics failed! Nov 19 10:18:32 neutrino kernel: bge1: chip initialization failed Nov 19 10:18:32 neutrino kernel: device_probe_and_attach: bge1 attach returned 6 Nov 19 10:18:32 neutrino kernel: cbb0: CardBus card activation failed Nov 19 10:18:32 neutrino kernel: bge0: PHY read timed out Nov 19 10:18:48 neutrino last message repeated 85 times My gigabit ethernet (the broadcom) card device (which is onboard - this is a laptop) is bge0. Notice above it complains about bge1, then the "PHY read timed out" errors start. If I boot with the card installed, here's what I get: Nov 19 10:23:35 neutrino kernel: bge0: PHY read timed out Nov 19 10:23:35 neutrino last message repeated 9 times Nov 19 10:23:35 neutrino kernel: bge0: RX CPU self-diagnostics failed! Nov 19 10:23:35 neutrino kernel: bge0: flow-through queue init failed Nov 19 10:23:35 neutrino kernel: bge0: initialization failure Anyone have any ideas on what caused this breakage? Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATAPI CD Changer problem in -CURRENT
It seems Christian Laursen wrote: > I just upgraded my workstation from 5.1-RELEASE to todays -CURRENT. > > When I boot it, I get the following messages about my CD drives: > > acd0-5: CDROM with 6 CD changer at ata1-master PIO4 > acd6: DVDROM at ata1-slave PIO4 > acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST > error=4 > acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST > error=4 > acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST > error=4 > acd0-5: FAILURE - LOAD_UNLOAD status=51 sensekey=ILLEGAL REQUEST > error=4 > > I get the 4 failures after the 2 first slots (both containing a CD) > have been probed, and I guess there is an error for every empty slot. Yep. > In 5.1-RELEASE the kernel didn't change through the drives while > booting. It is a little annoying, but not my main concern. Thats GEOM that tries to "taste" every device showing up, I guess we will have to live with it, but yes its annoying. I've thought about returning early in open if device knows there is no media avaliable, but its not foolproof either.. > The real problem is, that only the first slot works. When I try > to mount a cd from the second slot (acd1), I get this: > > borg# mount /drv/cd2 > cd9660: /dev/acd1: Input/output error > > It doesn't make any difference whether acd0 is mounted or not. Hmm, its been some time since I tried my old shaky changer, I'll admit to that, I'll dig it out and look into this... -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Wed, 19 Nov 2003, Marcel Moolenaar wrote: > set init_path=/rescue/init If dynamic root were ready to be turned on, then /rescue/init would be in the default init_path. > A dynamicly linked /sbin/init just > makes it harder to get to the rescue bits, so it makes sense to > link init(8) staticly. Especially since there's no advantage to > dynamic linking init(8) that compensates for the inconvience. It obviously uses NSS. How else could it be so bloated? : $ ls -l /sbin/init -r-x-- 1 root wheel 453348 Nov 18 10:30 /sbin/init (My version is linked statically of course.) The NSS parts of init might not be needed in normal operation, but its hard to tell. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Thu, Nov 20, 2003 at 06:27:31AM +1100, Bruce Evans wrote: > > set init_path=/rescue/init > > If dynamic root were ready to be turned on, then /rescue/init would be > in the default init_path. I had that explained to me too. :-) There is a loop in sys/kern/init_main.c that "probes" for an init to run. But it only does what you want for cases of the files not existing or otherwise just totally not executable. It won't handle the "started but then dumped core" case the way it would need to if /sbin/init were to fail because of shared library problems. So if just relying on this mechanism it would either not work right (/sbin/init in the path before /rescue/init) or it would always start /rescue/init (/rescue/init before /sbin/init in the path). -- Ken Smith - From there to here, from here to | [EMAIL PROTECTED] there, funny things are everywhere. | - Theodore Geisel | ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Updated acpi_cpu patch
On Wednesday 19 November 2003 16:31, Nate Lawson wrote: > Ok, here's the final patch. I believe it fixes both problems. > *SCHNIP* Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure to have the correct one and applied your patch. hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 27743/0 No Problems at booting/rebooting Attached my dmesg but it doesn't show anything unusual/debug. Thanks, -Harry Copyright (c) 1992-2003 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.1-CURRENT #50: Wed Nov 19 21:01:37 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CALE Preloaded elf kernel "/boot/kernel/kernel" at 0xc09d9000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc09d9244. Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc09d92f0. ACPI APIC Table: Timecounter "i8254" frequency 1183576 Hz quality 0 CPU: Intel(R) Celeron(TM) CPU1100MHz (1095.82-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 268173312 (255 MB) avail memory = 250781696 (239 MB) ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard Pentium Pro MTRR support enabled VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc07760c2 (122) VESA: NVIDIA acpi0: on motherboard pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2a10 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: port 0x530-0x537 on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pcib1: slot 0 INTA is routed to irq 16 nvidia0: mem 0xf000-0xf3ff,0xfd00-0xfdff irq 16 at device 0.0 on pci2 pcib2: at device 30.0 on pci0 pci1: on pcib2 fxp0: port 0xdf00-0xdf3f mem 0xfc9ff000-0xfc9f irq 20 at device 8.0 on pci1 fxp0: Ethernet address 00:03:47:f0:c2:ef miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci0 ata1: [MPSAFE] uhci0: port 0xef40-0xef5f irq 19 at device 31.2 on pci0 usb0: 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 ichsmb0: port 0xefa0-0xefaf irq 17 at device 31.3 on pci0 smbus0: on ichsmb0 smb0: on smbus0 uhci1: port 0xef80-0xef9f irq 23 at device 31.4 on pci0 usb1: 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 uhub2: Standard Microsystems product 0x0140, class 9/0, rev 1.10/0.00, addr 2 uhub2: 4 ports with 4 removable, self powered ums0: Microsoft Microsoft IntelliMouse® Explorer, rev 1.10/1.14, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. uhub3: Texas Instruments General Purpose USB Hub, class 9/0, rev 1.10/1.01, addr 4 uhub3: 2 ports with 2 removable, bus powered pcm0: port 0xef00-0xef3f,0xe800-0xe8ff irq 17 at device 31.5 on pci0 pcm0: atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 fdc0: 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 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A npx0: [FAST] npx0: on motherboard npx0: INT 16 interface orm0: at iomem 0xd0800-0xd17ff,0xcf800-0xd07ff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter "TSC" frequency 1095817986 Hz quality 800 Timecounters tick every 1.000 msec GEOM: create disk ad0 dp=0xc2dbbd60 ad0: 39083MB [79408/16/63] at ata0-master UDMA100 acd0: CDROM at ata1-master PIO4 pcm0: measured ac97 link rate at 55942 Hz Mounting root from ufs:/dev/ad0s2a module_register: module uhub/ums already exists! Module uhub/ums failed to register: 17 Warning: pid 578 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 584 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 585 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 605 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 606 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 607 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 608 used static ldt allocation. See the i386_set_ldt man page for more info Warning: pid 611 used static ldt allocation. Se
Re: Updated acpi_cpu patch
On Wed, 19 Nov 2003, Harald Schmalzbauer wrote: > On Wednesday 19 November 2003 16:31, Nate Lawson wrote: > > Ok, here's the final patch. I believe it fixes both problems. > > > *SCHNIP* > > Yep, seems really final. I downloaded the acpi_cpi.c from cvs-web to be sure > to have the correct one and applied your patch. > > hw.acpi.cpu.cx_supported: C1/0 > hw.acpi.cpu.cx_lowest: 0 > hw.acpi.cpu.cx_history: 27743/0 > > No Problems at booting/rebooting Thanks, I'll commit it now. -Nate ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Thu, 20 Nov 2003, Bruce Evans wrote:
> On Wed, 19 Nov 2003, Marcel Moolenaar wrote:
>
> > set init_path=/rescue/init
>
> If dynamic root were ready to be turned on, then /rescue/init would be
> in the default init_path.
The fallback path only works if the exec() fails cleanly without actually
starting the userspace code. Peter and I have been talking about
improving failure mode handling by having rtld return a special error code
if (getpid() == 1 && oops_shlib_problem) and having special kernel
handling, but that's complicated by the fact that presumably you'd then
need to pick up the whole init thing in exit() rather than continuing it
in start_init(). In the meantime, Gordon has committed a change to always
link init statically.
> > A dynamicly linked /sbin/init just
> > makes it harder to get to the rescue bits, so it makes sense to
> > link init(8) staticly. Especially since there's no advantage to
> > dynamic linking init(8) that compensates for the inconvience.
>
> It obviously uses NSS. How else could it be so bloated? :
>
> $ ls -l /sbin/init
> -r-x-- 1 root wheel 453348 Nov 18 10:30 /sbin/init
>
> (My version is linked statically of course.)
>
> The NSS parts of init might not be needed in normal operation, but its
> hard to tell.
There appear to be at least two dependencies there, from my reading:
(1) getpwnam("root") so that we can check the root password when the
console isn't marked as secure.
(2) Calls to setusercontext() to set up resources when running rc, also
for uid 0, which results in libutil looking up the user to find the
class.
I think that while home directory completion is useful for sh, it's safe
to have a working assumption of a local root user in the password file,
and that when prompting for a single user mode password, access to
directory services is probably going to fail anyway.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: natd-Related Panic (?)
> Try re-cvsup-ing. I was struck by the same problem and it was fixed with > rev 1.256 of ip_input.c Sure enough... Cheers -- Rogelio ECCE HOMO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hard lock-up writing to tape
On Wed, 19 Nov 2003, Mike Durian wrote: > On Tuesday 18 November 2003 08:29 pm, Bruce Evans wrote: > > - -current has the kern.console sysctl for enabling multiple consoles > > (buut only 1 sio one). You can boot with a syscons console and then > > enable the serial, and the latter should work if it is on a working > > port to begin with. Anyway, this sysctl shows which sio port can be > > a console, if any. > > Is there any documentation on this sysctl? I'm not sure what I > should set it to. After a normal boot, it reads: Only in the source code. > kern.console: consolectl,/ttyd1,consolectl, Not even the bug that syscons's consolectl device is printed here is documented (the actual syscons console is on /dev/ttyv0, but this bogusly shares a tty struct with /dev/consolectl and many things cannot tell the difference. This bug also messes up the columns in pstat -t, since consolectl is too wide to fit). Anyway, the stuff to the left of the slash in the above is the list of active consoles and the stuff to the right of the slash is the list of possible consoles. You have to move stuff from one list to the other. I vaguely remember that this is done using '-' to delete things from the left hand list and something more direct to add them. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
SL> Date: Tue, 18 Nov 2003 17:06:06 -0700 (MST) SL> From: Scott Long SL> 3. Binary security updates: there is a lot of interest in providing a SL> binary update mechanism for doing security updates. Having a dynamic SL> root means that vulnerable libraries can be updated without having to SL> update all of the static binaries that might use them. Although this doesn't help the upgrade process, what if one symbol (such as function name + CVS tag) were exported per function? One could check for a vulnerability by strings | grep funcname | inspect CVS tag. A more elegant approach would be to store such versioning in another segment and have a tool that understands the data, a la debugger symbols. On a different note: + Some of us have had a few bad experiences with glibc (granted, it's glibc) upgrades when the shell, cp, ls, et cetera are dynamically linked. + I put the shell of choice and all of SSH's guts on the root partition... if /usr gets clobbered, I still want to be able to boot and log in remotely. If / gets clobbered, I have bigger problems. :-) Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
GAD> Date: Tue, 18 Nov 2003 21:54:53 -0500 GAD> From: Garance A Drosihn GAD> Many freebsd users (me for one) are still living on a modem, GAD> where even one bump of 1.5 meg is a significant issue... GAD> GAD> Remember that the issue we're talking about is security GAD> updates, not full system upgrades. "Everyone" would want GAD> the security updates, even if they're on a slow link. When security updates change but a few bytes, it seems that some xdiff- or rsync-like algorithm would be an apropriate way to distribute patches. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _ DO NOT send mail to the following addresses : [EMAIL PROTECTED] -or- [EMAIL PROTECTED] -or- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
:GAD> Many freebsd users (me for one) are still living on a modem, :GAD> where even one bump of 1.5 meg is a significant issue... :GAD> :GAD> Remember that the issue we're talking about is security :GAD> updates, not full system upgrades. "Everyone" would want :GAD> the security updates, even if they're on a slow link. : :When security updates change but a few bytes, it seems that some :xdiff- or rsync-like algorithm would be an apropriate way to :distribute patches. : : :Eddy :-- :Brotsman & Dreger, Inc. - EverQuick Internet Division Security updates are a red hearing regardless because they are few and far between compared to even a modem-user's bandwidth (especially those modem users who are likely to read the security lists aren't going to care if it takes an hour to download a non optimal binary patch if it only happens a few times a year). -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Wed, 19 Nov 2003, Ken Smith wrote: > On Thu, Nov 20, 2003 at 06:27:31AM +1100, Bruce Evans wrote: > > > > set init_path=/rescue/init > > > > If dynamic root were ready to be turned on, then /rescue/init would be > > in the default init_path. > > I had that explained to me too. :-) > > There is a loop in sys/kern/init_main.c that "probes" for an init > to run. But it only does what you want for cases of the files > not existing or otherwise just totally not executable. It won't > handle the "started but then dumped core" case the way it would > need to if /sbin/init were to fail because of shared library > problems. So if just relying on this mechanism it would either > not work right (/sbin/init in the path before /rescue/init) or > it would always start /rescue/init (/rescue/init before /sbin/init > in the path). Oops, better add "... and error handling for init_path would be fixed" -). I should have remembered this since I got bitten by it recently. I was trying to boot RELENG_3 and had a backup init that worked but that didn't help because there was an execable init earlier in the path. Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
list of wellknown LORs ?
Hi, is anybody involved in fixing perhaps going to put up a site with all the wellknown LORs and perhaps a state (like: work in progress (by ...), ingorable, ...). I have seen three the last minutes where at least two seem to be known when grepping through my mailing lists archives and one of those two has a promised fix with upcoming chnages... wouldn't it be good to have one resource for overall status and may reduce noice ? lock order reversal 1st 0xc3a23090 rtentry (rtentry) @ HEAD/compile-20031119-1814/sys/net/rtsock.c:389 2nd 0xc396587c radix node head (radix node head) @ HEAD/compile-20031119-1814/sys/net/route.c:1114 STATE: "go away with forthcoming changes" (sam, current@ 2003-11-xx) lock order reversal 1st 0xc3a368f8 inp (inp) @ HEAD/compile-20031119-1814/sys/netinet/tcp_usrreq.c:363 2nd 0xc063b4ac div (div) @ HEAD/compile-20031119-1814/sys/netinet/ip_divert.c:238 STATE: known: http://lists.freebsd.org/pipermail/freebsd-current/2003-August/008743.html + fix available ? lock order reversal 1st 0xc063b580 IPFW dynamic rules (IPFW dynamic rules) @ HEAD/compile-20031119-1814/sys/netinet/ip_fw2.c:2934 2nd 0xc063b548 IPFW static rules (IPFW static rules) @ HEAD/compile-20031119-1814/sys/netinet/ip_fw2.c:1586 Stack backtrace: backtrace(1,0,,c06155f0,c0615618) at backtrace+0x12 witness_lock(c063b548,8,c05cf951,632,c063b548) at witness_lock+0x534 _mtx_lock_flags(c063b548,0,c05cf951,632) at _mtx_lock_flags+0x7f ipfw_chk(c9b4ac0c,0,c9b4abb4,c04ba25c,c0615870) at ipfw_chk+0x28e ip_output(c2f8f600,0,0,0,0) at ip_output+0x9f3 send_pkt(c3b1a91c,e2e48f46,1a0e0dd3,2,e) at send_pkt+0x13c ipfw_tick(0) at ipfw_tick+0xae softclock(0) at softclock+0x176 ithread_loop(c2f6d580,c9b4ad48,c2f6d580,c048ab00,0) at ithread_loop+0x12b fork_exit(c048ab00,c2f6d580,c9b4ad48) at fork_exit+0x90 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc9b4ad7c, ebp = 0 --- STATE: unknown ??? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: another trap 12 while in kernel mode (now with trace)
On Wed, 19 Nov 2003, Robert Watson wrote: > You should still be able to turn the bad instruction pointer into at least > a function name using nm on your compiled kernel. Run nm on the kernel > binary, and search through it until you find the symbols just before > (lower) and just after (higher) than the value listed for the instruction > pointer below. That would at least tell us what function the fault is > occuring in. I suspect to get anywhere useful, we'll need the full > debugging results, but it's probably a useful start, and it will allow us > to be sure the panics you might get after you have debugging support > compiled in are the same failure mode. Ok, I could trigger it or s.th. very related by doing this: crisco# ps ax | grep rac | grep -v grep 348 ?? Is 0:04.50 /usr/local/sbin/racoon -f /usr/local/etc/racoon/racoon.conf crisco# kill -9 348 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0df fault code = supervisor read, page not present instruction pointer = 0x8:0xc055088c stack pointer = 0x10:0xc9b5c8dc frame pointer = 0x10:0xc9b5c8e4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 485 (sshd) kernel: type 12 trap, code=0 Stopped at key_cmpspidx_withmask+0x2c: movb0x1(%ebx),%al db> trace key_cmpspidx_withmask(deadc0de,c9b5c914) at key_cmpspidx_withmask+0x2c key_allocsp(0,c9b5c914,2,16000210,c1426f0a) at key_allocsp+0x8b ipsec4_getpolicybyaddr(c2fa7c00,2,0,c9b5ca88,0) at ipsec4_getpolicybyaddr+0x69 ip_output(c2fa7c00,0,c3a36b00,0,0) at ip_output+0x770 tcp_output(c3a386f4,0,c3a36ac4,0,30) at tcp_output+0xbf0 tcp_usr_send(c3a091e0,0,c2fa7700,0,0) at tcp_usr_send+0x18b sosend(c3a091e0,0,c9b5cc88,c2fa7700,0) at sosend+0x405 soo_write(c3a9b7b4,c9b5cc88,c3a58c80,0,c2f83a00) at soo_write+0x37 dofilewrite(c2f83a00,c3a9b7b4,5,807a000,30) at dofilewrite+0x7b write(c2f83a00,c9b5cd14,3,ab,286) at write+0x3e syscall(2f,2f,2f,806cc08,8076860) at syscall+0x202 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x28258b6f, esp = 0xbfbfe4cc, ebp = 0xbfbfe4f8 --- db> where key_cmpspidx_withmask(deadc0de,c9b5c914) at key_cmpspidx_withmask+0x2c key_allocsp(0,c9b5c914,2,16000210,c1426f0a) at key_allocsp+0x8b ipsec4_getpolicybyaddr(c2fa7c00,2,0,c9b5ca88,0) at ipsec4_getpolicybyaddr+0x69 ip_output(c2fa7c00,0,c3a36b00,0,0) at ip_output+0x770 tcp_output(c3a386f4,0,c3a36ac4,0,30) at tcp_output+0xbf0 tcp_usr_send(c3a091e0,0,c2fa7700,0,0) at tcp_usr_send+0x18b sosend(c3a091e0,0,c9b5cc88,c2fa7700,0) at sosend+0x405 soo_write(c3a9b7b4,c9b5cc88,c3a58c80,0,c2f83a00) at soo_write+0x37 dofilewrite(c2f83a00,c3a9b7b4,5,807a000,30) at dofilewrite+0x7b write(c2f83a00,c9b5cd14,3,ab,286) at write+0x3e syscall(2f,2f,2f,806cc08,8076860) at syscall+0x202 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x28258b6f, esp = 0xbfbfe4cc, ebp = 0xbfbfe4f8 --- db> show locks exclusive sleep mutex inp r = 0 (0xc3a36b74) locked @ HEAD/compile-20031119-1814/sys/netinet/tcp_usrreq.c:670 exclusive sleep mutex tcp r = 0 (0xc063bc6c) locked @ HEAD/compile-20031119-1814/sys/netinet/tcp_usrreq.c:653 exclusive sleep mutex Giant r = 0 (0xc0610680) locked @ HEAD/compile-20031119-1814/sys/vm/vm_fault.c:223 db> show reg cs 0x8 ds0x10 es0x10 fs0x18 ss0x10 eax 0 ecx 0 edx 0 ebx 0xdeadc0de esp 0xc9b5c8dc ebp 0xc9b5c8e4 esi 0xc9b5c914 edi0x2 eip 0xc055088c key_cmpspidx_withmask+0x2c efl0x10286 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 key_cmpspidx_withmask+0x2c: movb0x1(%ebx),%al db> ps pid proc uarea uid ppid pgrp flag stat wmesgwchan cmd 804 c3adcc5c ca470 455 804 0004002 [SLP]ttyin 0xc3976a10] csh 550 c3ae0388 ca4740000 549 550 0004002 [RUNQ] csh 549 c3adc710 ca46d000 1060 486 549 0004102 [SLP]wait 0xc3adc710] su 486 c3936c5c ca06f000 1060 485 486 0004002 [SLP]pause 0xc39e5000] csh 485 c39af000 ca08f000 1060 482 482 100 [CPU 0] sshd 482 c3a3f388 ca4070000 284 482 100 [SLP]sbwait 0xc3ac442c] sshd 460 c39b1e20 ca0c4000 25 458 458 0004100 [CV]select 0xc0638a04] qmgr 459 c39b18d4 ca0c1000 25 458 458 0004100 [CV]select 0xc0638a04] pickup 458 c39b1710 ca0c0 1 458 0004100 [CV]select 0xc0638a04] master 455 c39afa98 ca0950000 1 455 0004102 [SLP]wait 0xc39afa98] login 384 c39b1388 ca0be0000 1 384 000
DStumbler / BSD-AirTools Error with new Wi code?
I have been getting the following error when attempting to use dstumbler with 5.1-RELEASE-p10: error: unable to ioctl device socket: Invalid argument After much searching around newsgroups/mailing lists it looks like the Wi(4) code was changed and dstumbler never got updated. I found one patch that supposedly fixed support on some cards, however, it didn't seem to work on mine. Has anyone worked on this in -current? Or does anyone know of patches that aren't in CVS yet that might work? Here is my info: lilshadow# dmesg |grep wi0 wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard2 wi0: 802.11 address: 00:02:2d:84:22:18 wi0: using Lucent Embedded WaveLAN/IEEE wi0: Lucent Firmware: Station (8.10.1) wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps Wireless card works fine otherwise. Thanks for the help in advance. -- Ryan "leadZERO" Sommers Gamer's Impact President [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: acpi_cpu_idle panic (Was: Re: kernel panic with todays source)
Nate Lawson wrote: On Tue, 18 Nov 2003, Eric Anderson wrote: Nate Lawson wrote: cvsup to -current as of today would be a good first start. The code was committed Nov 15. Then boot with acpi enabled and post the output of sysctl hw.acpi.cpu. You can try different levels by doing sysctl hw.acpi.cpu.cx_lowest=x where x is 0...(number_supported_states - 1) Thanks! I've rebuilt and am happy to say that nothing is hosed and I booted successfully :) Here's my sysctl output: $ sysctl hw.acpi.cpu hw.acpi.cpu.max_speed: 8 hw.acpi.cpu.current_speed: 4 hw.acpi.cpu.performance_speed: 8 hw.acpi.cpu.economy_speed: 4 You should run a benchmark with different values for hw.acpi.cpu.current_speed to be sure the throttling control still works ok. I left it mostly intact so you shouldn't see any problems but it's still good to test. As you change it, you should see dmesg output of "acpi_cpu0: set speed to xx%" I can change the hw.acpi.cpu.economy_speed value, but the current_speed is read only. When I set economy speed, it automatically bumps the current speed down to my economy value (as expected). However, no dmesg output. The only note I see is when going from AC to battery, I get: kernel: system power profile changed to 'economy' and of course going back to aAC shows 'performance' instead of economy. I never see any "set speed to xx%". hw.acpi.cpu.cx_supported: C1/1 C2/1 C3/85 C3/185 hw.acpi.cpu.cx_lowest: 0 hw.acpi.cpu.cx_history: 23589/0 0/0 0/0 0/0 I played with the different levels a bit, and can't tell much difference in them. Let me know what else I can try to break with this. Just for the info, I booted with a/c plugged in, but did the sysctl running on battery. You should set hw.acpi.cpu.cx_lowest to 1 regularly and 2 or 3 if you're using battery. This will save on heat. I'd also be interested in if you'd set it to 3 while on battery and run a typical workload for an hour and then send me the result of sysctl hw.acpi.cpu. The cx_history value helps me know if my scheduler is accurate. I'll try this tomorrow - anyway to get it to automatically set it to a value when going in to economy mode? Eric Anderson Systems Administrator Centaur Technology Say hi to Tom Crispin for me. :) He says "hi" :) (small world, eh?) On a side note - can I do anything with the "lid control switch" acpi piece? I'd like to make it turn off the screen and go into a sleep mode (it goes into sleep, but the screen stays lit up). Thanks for the great work! Eric -- -- Eric Anderson Systems Administrator Centaur Technology All generalizations are false, including this one. -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Current SMP with ACPI dies in a second
Tomi Vainio writes: > My old MSI-6120 SMP system has been unusable quite a while with ACPI. > I've got these so far: > - Couldn't get vector from ISR > - vmstat -i shows high interrupt rates and system is very slow > - kernel trap 12 panic > > Latest problem is something like this: > pfs_vncache_unload(): 2 entries remaining > current process = 27 (irq17: fxp0) > kernel trap 12 > stray irq20 > > Kernel config, dmesg, acpidump, etc. files available at > http://tomppa.iki.fi/~tomppa/FreeBSD/ > With latest source cvsupped 15 minutes ago system don't panic anymore but it's still unusable with acpi because of too high interrupt rate from acpi device. vmstat -i interrupt total rate irq1: atkbd0 291 1 irq0: clk 28360 99 irq6: fdc0 5 0 irq8: rtc 36303127 irq12: psm0 942 3 irq14: ata0 10 0 irq15: ata1 49 0 irq16: ahc0 ahc17788 27 irq17: fxp0 2886 10 irq19: uhci0 bktr0 31336110 irq20: acpi011614583 40896 irq9: intpm01376 4 Total 11723929 41281 Tomppa ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DStumbler / BSD-AirTools Error with new Wi code?
> I have been getting the following error when attempting to use dstumbler > with 5.1-RELEASE-p10: > > error: unable to ioctl device socket: Invalid argument > > After much searching around newsgroups/mailing lists it looks like the > Wi(4) code was changed and dstumbler never got updated. I found one patch > that supposedly fixed support on some cards, however, it didn't seem to > work on mine. Has anyone worked on this in -current? Or does anyone know of > patches that aren't in CVS yet that might work? I just updated it yesterday. Update to 0.3 and things should work: dstumbler wi0 -o -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: list of wellknown LORs ?
On Wednesday 19 November 2003 02:12 pm, Bjoern A. Zeeb wrote: > Hi, > > is anybody involved in fixing perhaps going to put up a site with all the > wellknown LORs and perhaps a state (like: work in progress (by ...), > ingorable, ...). > > I have seen three the last minutes where at least two seem to be known > when grepping through my mailing lists archives and one of those two > has a promised fix with upcoming chnages... > > wouldn't it be good to have one resource for overall status and may > reduce noice ? > > > > lock order reversal > 1st 0xc3a23090 rtentry (rtentry) @ > HEAD/compile-20031119-1814/sys/net/rtsock.c:389 2nd 0xc396587c radix node > head (radix node head) @ HEAD/compile-20031119-1814/sys/net/route.c:1114 > > STATE: > "go away with forthcoming changes" (sam, current@ 2003-11-xx) > Correct, this and at least one other in the routing table should go away with changes about to be committed. > > ---- > lock order reversal > 1st 0xc3a368f8 inp (inp) @ > HEAD/compile-20031119-1814/sys/netinet/tcp_usrreq.c:363 2nd 0xc063b4ac div > (div) @ HEAD/compile-20031119-1814/sys/netinet/ip_divert.c:238 > > STATE: > known: > http://lists.freebsd.org/pipermail/freebsd-current/2003-August/008743.html > + fix available ? > > > > lock order reversal > 1st 0xc063b580 IPFW dynamic rules (IPFW dynamic rules) @ > HEAD/compile-20031119-1814/sys/netinet/ip_fw2.c:2934 2nd 0xc063b548 IPFW > static rules (IPFW static rules) @ > HEAD/compile-20031119-1814/sys/netinet/ip_fw2.c:1586 Stack backtrace: > backtrace(1,0,,c06155f0,c0615618) at backtrace+0x12 > witness_lock(c063b548,8,c05cf951,632,c063b548) at witness_lock+0x534 > _mtx_lock_flags(c063b548,0,c05cf951,632) at _mtx_lock_flags+0x7f > ipfw_chk(c9b4ac0c,0,c9b4abb4,c04ba25c,c0615870) at ipfw_chk+0x28e > ip_output(c2f8f600,0,0,0,0) at ip_output+0x9f3 > send_pkt(c3b1a91c,e2e48f46,1a0e0dd3,2,e) at send_pkt+0x13c > ipfw_tick(0) at ipfw_tick+0xae > softclock(0) at softclock+0x176 > ithread_loop(c2f6d580,c9b4ad48,c2f6d580,c048ab00,0) at ithread_loop+0x12b > fork_exit(c048ab00,c2f6d580,c9b4ad48) at fork_exit+0x90 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc9b4ad7c, ebp = 0 --- There are part of a set of "middleware" LOR's that also have been waiting on the routing table changes. Once those changes are committed I will resolve them. Sam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DStumbler / BSD-AirTools Error with new Wi code?
I upgraded to 0.3 and installed. However, I'm still getting errors no matter how I run it: dstumbler wi0 -o error: cannot use monitor mode on non-prism2 cards dstumbler wi0 -s error: unable to ioctl device socket: Invalid argument same for just running dstumbler wi0. Any ideas? Sean Chittenden writes: I have been getting the following error when attempting to use dstumbler with 5.1-RELEASE-p10: error: unable to ioctl device socket: Invalid argument After much searching around newsgroups/mailing lists it looks like the Wi(4) code was changed and dstumbler never got updated. I found one patch that supposedly fixed support on some cards, however, it didn't seem to work on mine. Has anyone worked on this in -current? Or does anyone know of patches that aren't in CVS yet that might work? I just updated it yesterday. Update to 0.3 and things should work: dstumbler wi0 -o -sc -- Sean Chittenden -- Ryan "leadZERO" Sommers Gamer's Impact President [EMAIL PROTECTED] ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DStumbler / BSD-AirTools Error with new Wi code?
> I have been getting the following error when attempting to use dstumbler > with 5.1-RELEASE-p10: > > error: unable to ioctl device socket: Invalid argument > > After much searching around newsgroups/mailing lists it looks like the > Wi(4) code was changed and dstumbler never got updated. I found one patch > that supposedly fixed support on some cards, however, it didn't seem to > work on mine. Has anyone worked on this in -current? Or does anyone know of > patches that aren't in CVS yet that might work? > > Here is my info: > lilshadow# dmesg |grep wi0 > wi0: at port 0x100-0x13f irq 11 > function 0 config 1 on pccard2 > wi0: 802.11 address: 00:02:2d:84:22:18 > wi0: using Lucent Embedded WaveLAN/IEEE > wi0: Lucent Firmware: Station (8.10.1) > wi0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > Wireless card works fine otherwise. Have you tried just `dstumbler wi0` ? I need the -o with my Netgear card. $ dmesg | grep wi0 wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard0 wi0: 802.11 address: 00:30:ab:11:f6:88 wi0: using RF:PRISM2 MAC:HFA3841 CARD:HWB3163 rev.A wi0: Intersil Firmware: Primary (0.3.0), Station (0.8.3) wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps $ sudo dstumbler wi0 -o [fires up] I don't know if Lucent cards are supported or not. How old is your kernel, btw? You should update to -CURRENT as there have been many wlan fixes since 5.1-RELEASE. -sc -- Sean Chittenden ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
installworld failure
"/usr/src/bin/csh/Makefile", line 3: warning: "cd /usr/src/bin/csh/../../contrib/tcsh/nls/ukrainian; echo set[0-9]*" returned non-zero status install -s -o root -g wheel -m 555 csh /bin install -o root -g wheel -m 444 /usr/src/bin/csh/../../contrib/tcsh/complete.tcsh /usr/src/bin/csh/../../contrib/tcsh/csh-mode.el /usr/share/examples/tcsh cat /usr/src/bin/csh/../../contrib/tcsh/nls/et/ > et_EE.ISO8859-15.msg gencat -new et_EE.ISO8859-15.cat et_EE.ISO8859-15.msg gencat:No such file or directory *** Error code 1 Stop in /usr/src/bin/csh. *** Error code 1 Stop in /usr/src/bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. ekg# ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
Gordon Tetlow wrote: On Tue, Nov 18, 2003 at 08:03:23PM -0500, [EMAIL PROTECTED] wrote: However, PAM and NSS 'tricks' really seem to be exactly that, and certainly worthy of special builds. However, that isn't necessary, yet still not building everything with a shared libc. Things like nss_ldap (which is used *heavily* at my place of employment) are some reasons that FreeBSD doesn't make it into more places. It was the reason why FreeBSD isn't being used here. Calling them 'tricks' (and succumbing to the name calling you wanted to avoid) doesn't change the fact that every major contender (IRIX, Solaris, Linux to name a few) all support this feature set. The fact that you can't easily do centralized authentication (nss_ldap and pam_ldap) with FreeBSD is a major show stopper. At my former employer, we built several very large systems that required centralized authentication using ldap. We had to use Linux, since none of the BSD's supported this correctly at the time. I don't really care whether everything is statically or dynamically linked. With the fast machines and huge disks these days, bloat is not much of an issue. But nss and pam need to work correctly. If the folks that are against dynamic linking have an alternate method to make this work, I'm all for it. But it needs to be more than theory. We need code. To be honest, I've never understood the (seemingly irrational) resistance against this change. Solaris made this change 10 years ago. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
GEOM CD panic reloaded
Hi, GEOM still panics when you insert second CD with non-data tracks,
even with phk's and sos's fixes. Both kernel and world are from Nov 20
0100 UTC
uname -a
FreeBSD hood.oook.cz 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Nov 20
02:59:56 CET 2003
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x1c
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc05a5e53
stack pointer = 0x10:0xde007c68
frame pointer = 0x10:0xde007c80
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 2 (g_event)
trap number = 12
panic: page fault
cpuid = 0;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc05886d1 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc0588b1f in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc070b846 in trap_fatal (frame=0xde007c28, eva=0) at
/usr/src/sys/i386/i386/trap.c:821
#4 0xc070b4c2 in trap_pfault (frame=0xde007c28, usermode=0, eva=28) at
/usr/src/sys/i386/i386/trap.c:735
#5 0xc070b01d in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 0, tf_esi = -969426560, tf_ebp =
-570393472, tf_isp = -570393516, tf_ebx = -970579488, tf_edx = 0, tf_ecx =
-1065553212, tf_eax = 1, tf_trapno = 12, tf_err = 0, tf_eip = -1067819437, tf_cs = 8,
tf_eflags = 66051, tf_esp = -968736384, tf_ss = -570393448}) at
/usr/src/sys/i386/i386/trap.c:420
#6 0xc06f6ff8 in calltrap () at {standard input}:94
#7 0xc054ece8 in g_destroy_provider (pp=0xc62621e0) at
/usr/src/sys/geom/geom_subr.c:426
#8 0xc054bc95 in g_orphan_register (pp=0xc637b980) at
/usr/src/sys/geom/geom_event.c:143
#9 0xc054bdbc in one_event () at /usr/src/sys/geom/geom_event.c:169
#10 0xc054bfe5 in g_run_events () at /usr/src/sys/geom/geom_event.c:202
#11 0xc054d015 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134
#12 0xc0570f60 in fork_exit (callout=0xc054cff0 , arg=0x0,
frame=0x0) at /usr/src/sys/kern/kern_fork.c:793
(kgdb) up 7
#7 0xc054ece8 in g_destroy_provider (pp=0xc62621e0) at
/usr/src/sys/geom/geom_subr.c:426
426 devstat_remove_entry(pp->stat);
(kgdb) print *pp
$1 = {name = 0x0, provider = {le_next = 0x0, le_prev = 0x0}, geom = 0x0, consumers =
{lh_first = 0x0}, acr = 0, acw = 0, ace = 0, error = 0, orphan = {tqe_next = 0x0,
tqe_prev = 0x0}, index = 0,
mediasize = 0, sectorsize = 0, stripesize = 0, stripeoffset = 0, stat = 0x0, nstart
= 0, nend = 0, flags = 0}
(kgdb) print *gp
$4 = {name = 0xc6219af0 "acd0", class = 0xc077aaa0, geom = {le_next = 0x0, le_prev =
0xc077aac4}, consumer = {lh_first = 0x0}, provider = {lh_first = 0xc6424580}, geoms =
{tqe_next = 0xc637bc00,
tqe_prev = 0xc236bc98}, rank = 1, start = 0xc0494fb0 , spoiled =
0, dumpconf = 0, access = 0xc0493fc0 , orphan = 0, ioctl = 0xc0494230
,
softc = 0xc6253800, flags = 0}
(kgdb) up
#8 0xc054bc95 in g_orphan_register (pp=0xc637b980) at
/usr/src/sys/geom/geom_event.c:143
143 g_destroy_provider(pp);
(kgdb) print *pp
$5 = {name = 0xc6219af0 "acd0", provider = {le_next = 0xc077aaa0, le_prev = 0x0}, geom
= 0xc077aac4, consumers = {lh_first = 0x0}, acr = -968735360, acw = -969425920, ace =
-1036600168, error = 1,
orphan = {tqe_next = 0xc0494fb0, tqe_prev = 0x0}, index = 0, mediasize = 3226025920,
sectorsize = 3226026544, stripesize = 3324327936, stripeoffset = 0, stat = 0x0, nstart
= 0, nend = 0, flags = 0}
This looks painfully similar to panic I was reporting on Nov 10.
How to reproduce:
1. Insert non-data CD like VideoCD
2. cdcontrol -f /dev/acd0 info
3. Play it (mplayer -vcd 2)
4. Insert ordinary data CD
5. cdcontrol -f /dev/acd0 info
It prints correct information of new CD and instantly panics.
--
Pav Lucistnik <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
signature.asc
Description: Toto je =?iso-8859-2?Q?digit=E1ln=EC?= =?ISO-8859-1?Q?_podepsan=E1?= =?iso-8859-2?Q?_=E8=E1st?= =?ISO-8859-1?Q?_zpr=E1vy?=
Re: Unfortunate dynamic linking for everything
In the last episode (Nov 19), Richard Coleman said: > I don't really care whether everything is statically or dynamically > linked. With the fast machines and huge disks these days, bloat is not > much of an issue. But nss and pam need to work correctly. If the folks > that are against dynamic linking have an alternate method to make this > work, I'm all for it. But it needs to be more than theory. We need code. > > To be honest, I've never understood the (seemingly irrational) > resistance against this change. Solaris made this change 10 years ago. Not completely: $ uname -a SunOS pd1 5.9 Generic_112233-08 sun4u sparc SUNW,Ultra-Enterprise $ file /bin/sh /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically linked, stripped $ file /sbin/* | grep statically | cut -d: -f1 | fmt /sbin/autopush /sbin/fdisk /sbin/jsh /sbin/mount /sbin/sh /sbin/soconfig /sbin/sync /sbin/umount /sbin/uname -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
Dan Nelson wrote: In the last episode (Nov 19), Richard Coleman said: I don't really care whether everything is statically or dynamically linked. With the fast machines and huge disks these days, bloat is not much of an issue. But nss and pam need to work correctly. If the folks that are against dynamic linking have an alternate method to make this work, I'm all for it. But it needs to be more than theory. We need code. To be honest, I've never understood the (seemingly irrational) resistance against this change. Solaris made this change 10 years ago. Not completely: $ uname -a SunOS pd1 5.9 Generic_112233-08 sun4u sparc SUNW,Ultra-Enterprise $ file /bin/sh /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically linked, stripped $ file /sbin/* | grep statically | cut -d: -f1 | fmt /sbin/autopush /sbin/fdisk /sbin/jsh /sbin/mount /sbin/sh /sbin/soconfig /sbin/sync /sbin/umount /sbin/uname I have no problem with FreeBSD doing something similar and leaving a few binaries static. I think most of the resistance to that was due to the increased complexity of the build system. It seems /bin/sh is the real sticking point. But if the compromise is to statically link /bin/sh, that would be cool with me. Other than tilde expansion not working when using nss_ldap, I can't think of any other problems. I consider that a minor blemish I could easily live with. Normal users will not generally have /bin/sh has their shell anyways. And I could always compile a dynamically linked version into /usr/bin if necessary. To be honest, 98% of the time that someone notices brokeness due to nss_ldap, it comes when using /bin/ls. Richard Coleman [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)
Josef Karthauser <[EMAIL PROTECTED]> wrote: > On Sun, Nov 17, 2002 at 01:18:00PM -0500, Brian F. Feldman wrote: > > > > > 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. > > > > Anyone? I kinda want to use my CF reader. > > > > There are rumours that OHCI is borked in NetBSD too and this is a bug > that we've inherited. Me, I've not got an OHCI system to test just > UHCI. > > Did it used to work, and got broken, or has it never worked? Jeez, it's been broken a year and it's almost 5.2-RELEASE now. Does anyone have ANY leads on these problems? I know precisely nothing about how my USB hardware is supposed to work, but this OHCI+EHCI stuff definitely doesn't, and it's really not uncommon at all. Is it unbroken in NetBSD currently? -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ <> [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
On Wed, 19 Nov 2003, Dan Nelson wrote: > In the last episode (Nov 19), Richard Coleman said: > > I don't really care whether everything is statically or dynamically > > linked. With the fast machines and huge disks these days, bloat is not > > much of an issue. But nss and pam need to work correctly. If the folks > > that are against dynamic linking have an alternate method to make this > > work, I'm all for it. But it needs to be more than theory. We need code. > > > > To be honest, I've never understood the (seemingly irrational) > > resistance against this change. Solaris made this change 10 years ago. > > Not completely: > > $ uname -a > SunOS pd1 5.9 Generic_112233-08 sun4u sparc SUNW,Ultra-Enterprise > $ file /bin/sh > /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically linked, > stripped > $ file /sbin/* | grep statically | cut -d: -f1 | fmt > /sbin/autopush /sbin/fdisk /sbin/jsh /sbin/mount /sbin/sh > /sbin/soconfig /sbin/sync /sbin/umount /sbin/uname Seems to depend a bit on the install, maybe... raven:~> uname -a SunOS raven 5.8 Generic_108528-06 sun4u sparc SUNW,Ultra-250 raven:~> file /bin/sh /sbin/sh /bin/sh:ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped /sbin/sh: ELF 32-bit MSB executable SPARC Version 1, statically linked, stripped Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: named problem (introduced in 5.1)
On Wed, 19 Nov 2003, Aleksander Rozman - Andy wrote: > I updated all /etc files with files from source tree (which is cvsuped to > 5.1-RELEASE) but it doesn't work? Does anybody have any idea where the > problem lies? Your named.root is out of date. Also, mergemaster is really handy for keeping the config files synced. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
M. Warner Losh said: > In message: <[EMAIL PROTECTED]> > Garance A Drosihn <[EMAIL PROTECTED]> writes: > : At 9:02 PM -0500 11/18/03, [EMAIL PROTECTED] wrote: > : > Of course, there was a development resource limitation, > : >but the decision (discussion) was made approx 6months ago? > : >(Enough time to solve the problem without a GLOBAL > : >performance hit.) > : > : Well, yes, perhaps. But there is that issue of "development > : resource limitation". Back when we did debate this publicly, > : no one stepped forward and said "I have the time to implement > : a better solution". Thus, we went with this solution. > > And it still isn't too late for someone to step forward with a better > solution. Or to develop one. The main reason we went with dynamic / > was to be able to get dynamic libary/loading support for newer > authentication and user technologies. The size advantage is one minor > added benefit. > (My last last email on this topic -- I had one previous last message :-)). My reason for bringing this shared lib issue up is indeed related to 'performance', but also the apparent loss of performance (or other non-obvious features) through 'incrementalism.' When spending time on optimizing the FreeBSD VM and buffer cache performance, I had found that the total system performance is very difficult to recover when several (new or pre-existing) impedements are consipiring against best possible performance. VERY OFTEN, you'll not be able to accurately measure each of the incremental performance lossages, but eventually the system will disappoint. If someone very strongly wants XYZ feature that has been impeding the product adoption, then the solution SHOULD NOT be at the cost of other positive (and hard earned) attributes of the project. Just because a certain part of the project isn't being actively worked on, that doesn't mean that the previous work should be slowly and surely degraded by EITHER valid new features, or creeping featurism. If the XYZ feature was strongly desired, then it is important to develop a 'best' solution rather than an expedient answer. It is very clear that building all binaries as fully 'shared' is NOT a necessary prerequisite for the new (and apparently necessary for some applications) features. This doesn't mean that building everything shared (in the way it is done today) shouldn't be a temporary work-around. (*My biggest concern about building programs shared is about shells, but other -- already well shared and performance sensitive processes should also be carefully considered.) I am NOT religious about this issue, but definitely religious about the QUALITY of system wide performance and administrative behavior of a system., Hopefully, when an expedient solution is developed, then that should be remembered, and those who changed the system behavior should work (advocate, program, redesign, etc -- or whatever) to recover the previous desirable attribute. It is almost impossible for someone to follow along trying to clean up 'undesirable' side effects, unless there is a specific assignment to do that. It does seem appropriate that those who had benefitted most for the adoption of the new features should contribute towards an effort to make the 'features' better (which might include assisting in the stewardship of performance, or other negatively changed attributes.) Quality of an OS isn't just dependent on the number of features on a dot item list, but also on how those dot-items avoid accumulating negative effects on other attributes of the system. When I was working on FreeBSD, one of my goals was to avoid making the same mistakes as other OSes had made. Bloat and loss of performance from 'uncareful' addition of features is something that should be avoided -- it has already been perfected by other OS vendors. (Please don't reduce my argument to the absurd by mentioning Plan9 :-)). The 'bloat' attribute is something that I'd like to see FreeBSD avoid. Stagnation also needs to be avoided :-). John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ICH4 gaps in sound.
Mine is ICH3 with the same problem; this depends on a change sometime between last Friday (worked fine) and this morning (broke) PST... It looks as if someone made a change to interrupt routing sometime since the changes to the fsstat struct (I had recompiled then and the sound problem was NOT present; today I recompile and it is.) I may be blowing smoke; the problem could also be in the sound driver itself... My system is a Sony VAIO R505ES with Yamaha sound chip, I suspect it doesn't matter just which sound chip you have. As I say, my sound was normal this morning with a compile on the 14th, and is now broken. There could also be a problem with interrupt sharing (almost everything on this laptop is on IRQ 9), but enough other things work that I somehow doubt it. (first thing that normally breaks with interrupt sharing problems is my wi0 Orinoco built-in, and *that* is working fine.) Problem here is that ICHx sound appears to depend on what some would consider a redundant interrupt routing request (at least in VAIO configuration); several people in the past have "cleaned up" the apparent redundancy and it breaks Sony's sound :-( dmesg excerpt here: pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff irq 9 at device 31.5 on pci0 pcm0: -- Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
Richard Coleman wrote: It seems /bin/sh is the real sticking point. There is a problem here: Unix systems have historically used /bin/sh for two somewhat contradictory purposes: * the system script interpreter * as a user shell The user shell must be dynamically linked in order to support centralized administration. I personally see no way around that. Given that many users do rely on /bin/sh, it seems that /bin/sh must be dynamically linked. There are good reasons to want the system script interpreter statically linked. Maybe it's time to separate these two functions? I would be content to have a static /sbin/sh that is used as the system script interpreter for rc scripts, etc. Tim Kientzle ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unfortunate dynamic linking for everything
Tim Kientzle said: > Richard Coleman wrote: > > It seems /bin/sh is the real sticking point. > > There is a problem here: Unix systems have historically used > /bin/sh for two somewhat contradictory purposes: >* the system script interpreter >* as a user shell > > The user shell must be dynamically linked in order > to support centralized administration. I personally > see no way around that. Given that many users do > rely on /bin/sh, it seems that /bin/sh must be > dynamically linked. > It isn't necessary for the shell to be dynamically linked (efficiency issue WRT the sparse allocations and greater COW overheads/etc) for the shell to programmatically link in a module for optional feature sets. This can even be placed under a libc call (which then wouldn't encumber the shell unless the feature was active and increase the footprint of generally all libc routines.) John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Memory modified after free
Hi,
got this one over the night:
--- cut ---
Memory modified after free 0xc3a58a00(124) val=deadc0dd @ 0xc3a58a1c
panic: Most recently used by soname
Debugger("panic")
Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0
db> show reg
cs 0x8
ds0x10
es0x10
fs0x18
ss0x10
eax 0x12
ecx0x1
edx 0
ebx 0
esp 0xca09bac0
ebp 0xca09bac4
esi 0xc05ddd4f
edi0x1
eip 0xc0595ba5 Debugger+0x45
efl 0x296
dr0 0
dr1 0
dr2 0
dr3 0
dr4 0x0ff0
dr5 0x400
dr6 0x0ff0
dr7 0x400
Debugger+0x45: xchgl %ebx,in_Debugger.0
db> trace
Debugger(c05c5718) at Debugger+0x45
panic(c05ddd4f,c05cb3c3,c05ddd20,c3a58a00,7c) at panic+0xb7
mtrash_ctor(c3a58a00,80,0) at mtrash_ctor+0x53
uma_zalloc_arg(c2c3bb40,0,1) at uma_zalloc_arg+0x15e
malloc(48,c06002a0,1,0,ca09bb84) at malloc+0xbd
keydb_newsecpolicy(c2f8de18,c397d400,10,ca09bba4,c054d6a8) at keydb_newsecpolicy+0x12
key_newsp(0,8,1,c2f8de18,c397d400) at key_newsp+0xa5
key_msg2sp(c2f8de18,10,ca09bbb8,3,c2f8de18) at key_msg2sp+0x68
ipsec_set_policy(c397d400,1c,c2f8de18,10,1) at ipsec_set_policy+0x7f
ipsec6_set_policy(c3a0c9f0,1c,c2f8de18,10,1) at ipsec6_set_policy+0x8f
ip6_ctloutput(c3a2f3c0,ca09bcc0,ca09bd14,c39b0140,ca09bcec) at ip6_ctloutput+0x80a
sosetopt(c3a2f3c0,ca09bcc0,c3a2f3c0,1,29) at sosetopt+0x2c
setsockopt(c39b0140,ca09bd14,5,aa,202) at setsockopt+0x90
syscall(2f,2f,2f,808f612,29) at syscall+0x202
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (105, FreeBSD ELF32, setsockopt), eip = 0x2822f32f, esp = 0xbfbfed1c, ebp
= 0xbfbfed58 ---
db> show locks
exclusive sleep mutex Giant r = 0 (0xc0610680) locked @
HEAD/compile-20031119-1814/sys/kern/uipc_syscalls.c:1312
db> cont
syncing disks, buffers remaining... 398 398...
--- cut ---
--
Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT
56 69 73 69 74 http://www.zabbadoz.net/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Help request: problems with a 5.1 server and large numbers of ssh users.
Hi folks, I have a problem, and I am unable to find previous discussions of it. Any pointers or clues would be much appreciated. I have a FreeBSD 5.1 server that needs to be able to handle several thousand simultaneous ssh sessions from distinct users. (I am using FreeBSD 5.1 because I need to be able to support ldap authentication.) Hardware info: CPU: AMD Athlon(tm) MP 2000+ (1666.74-MHz 686-class CPU) real memory = 1610088448 (1535 MB) avail memory = 1558822912 (1486 MB) My version of ssh is 3.6.1p2 patched to address the security concerns. (I am not using 3.7.1p because it dropped support for password authentication with PAM, and I cannot assume keyboard-interactive authentication will be present in my users' clients.) All of these users are doing ssh port forwarding, and are not assigned ptys. I have not modified login.conf in any way -- the defaults of "no limits" remain. The kernel tunables in /boot/loader.conf are set to: kern.maxfiles="49312" kern.maxproc="24656" kern.maxprocperuid="11094" kern.ipc.maxsockets="24656" kern.ipc.somaxconn="8192" The kernel is compiled with NMBCLUSTERS=65536 and maxusers=0 (which defaults to 384). The problem is that after about 150 users log in (300ish sshd sessions, since I am using privsep), incoming connections start getting dropped. i.e., bash-2.05b# ssh -v localhost OpenSSH_3.6.1p2, SSH protocols 1.5/2.0, OpenSSL 0x0090701f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: Connecting to localhost [::1] port 22. socket: Protocol not supported debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: identity file /root/.ssh/identity type -1 debug1: identity file /root/.ssh/id_rsa type -1 debug1: identity file /root/.ssh/id_dsa type -1 ssh_exchange_identification: Connection closed by remote host debug1: Calling cleanup 0x805f010(0x0) bash-2.05b# It is my intuition from this behavior that the sshd master process listening for connections is unable to spawn a new process to complete the authentication step, and thus the connection is being dropped. There is no information of use in dmesg, nor in the system logs. (I've cranked up LogLevel to DEBUG3 in sshd_config). I have a RedHat Linux server running the 2.4.18-3smp kernel on a dual Athlon MP 1800+ and 2048MB RAM that is known to handle 1000 users without issue -- so I have to believe the FreeBSD box, though not as beefy hardware-wise, should be able to do better than a few hundred users. I believe this to be some sort of resource limit issue, but I have addressed everything I could think of. Here's the sysctl vm.zone output: vm.zone: ITEMSIZE LIMIT USEDFREE REQUESTS FFS2 dinode: 256,0, 1089, 21, 1359 FFS1 dinode: 128,0, 0, 0,0 FFS inode: 144,0, 1089, 59, 1359 SWAPMETA:276, 121576, 0, 0,0 unpcb: 140,65548,329, 63,31364 ripcb: 228,49317, 0, 0,0 syncache:136,15370, 0, 58,36747 tcptw:48,49385, 3812,255,89831 tcpcb: 360,49313, 1048, 63, 195072 inpcb: 228,49317, 4921, 94, 195072 udpcb: 228,49317, 1, 33, 114497 socket: 256,49320, 1383,102, 340934 KNOTE:64,0, 0,124, 114453 PIPE:176,0,622, 68,17402 DIRHASH:1024,0,138, 6, 138 NAMEI: 1024,0, 9, 11, 451791 VNODEPOLL:76,0, 0, 0,0 VNODE: 292,0, 1473, 35, 1473 g_bio: 144,0,259, 49, 186276 VMSPACE: 256,0,424, 26,11035 UPCALL: 44,0, 0, 0,0 KSE: 64,0,496, 62, 496 KSEGRP: 120,0,496, 62, 496 THREAD: 292,0,496, 11, 496 PROC:480,0,461, 35,11074 Files:60,0, 6051,153, 89241268 65536: 65536,0, 3, 3,3 32768: 32768,0, 3, 3, 32 16384: 16384,0, 56, 22, 1733 8192: 8192,0, 2, 4, 50 4096: 4096,0,736, 44,11965 2048: 2048,0, 71, 5, 359215 1024: 1024,0,408, 20, 284756 512: 512,0,102, 18,43908 256: 256,0, 5166, 84, 131327 128: 128,0, 6784,253, 535182 64: 64,0, 3032, 68,87489 32: 32,0, 2155,182, 211243 16: 16,0, 4485,
Re: ppp RADIUS accounting bug
On Wed, Nov 19, 2003 at 09:00:01AM +0500, Boris Kovalenko wrote: > >I found a serious bug in RADIUS accounting code. The problem is that > OctetsIn and OctetsOut are defined as unsingned long long, but the > RADIUS supports only INT32 values, so, when > we're doing rad_put_int(r->cx.rad, RAD_ACCT_OUTPUT_OCTETS, > stats->OctetsOut) in radius.c for OctetsOut (and OctetsIn also) we > loosing information if OctetsOut is greater then INT32_MAX. This should > be fixed. Note that RADIUS integers are unsigned, so the limit is 2^32-1. Also, RFC2869 defines attributes to hold the high-order parts. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
