ACPI timer bug
The clock on my ASUS P5A still runs at double speed unless I have debug.acpi.disable="timer" in loader.conf (as it has for as long as we've had ACPI support). Do any ACPI wizards have any suggestions as to how I could track down the cause of this bug, and hopefully fix it? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: question on profiling code
On Mon, 17 Feb 2003, Bruce Evans wrote: > On Sun, 16 Feb 2003, Julian Elischer wrote: > > > In addupc_intr, if the increment cannot be done immediatly, the addres > > to increment the count for is stored and the increment is done later at > > ast or userret() time... > > Note that "cannot be done immediatly" is "always except on sparc64's" > under FreeBSD, since incrementing the counter immediately is only > implemented on sparc64's. Care to explain this statement? It doesn't corelate what I see in addupc_int() which is Machine Independent. > > > is there any reason that the address of the PC needs to be stored? > > why is the address from the frame at that time not useable? > > > > is it because the PC in the return frame may be hacked up for signals? > > That's was good a reason as any. I think the next return to user mode > is to the signal handler's context (if there is a signal to be handled). > It would be wrong to use the signal handler's pc. Also, ast() doesn't > have access to the frame, funny, it uses it.. > and there is no macro like CLKF_PC() for > general frames. They seem to be the same. Macro or no macro, ast and userret can certainly access the return address. > This probably doesn't matter much, since signals are > rare and the hitting on the signal handler's pc would be perfectly > correct if the profiling interrupt occurred an instant later. that is true. > > Now there is a stronger reason: clock interrupt handling is "fast", > so it normally returns to user mode without going near ast(), and the > counter is not updated until the next non-fast interrupt or syscall. > This might not happen until another profiling interrupt clobbers the > saved pc, not to mention the saved tick count (it could just increment > the tick count so that ticks are assigned to the last saved pc instead > of lost; currently, the tick count mostly just tracks KEF_OWEUPC so > it need not be saved). This was broken by SMPng (hardclock() is not > really a fast interrupt handler but is abused as one). However, normal > applications probably make enough syscalls to get the right counter > updated, provided we use the counter for the pc at fast interrupt time > and not the counter for the pc later. I'm trying to fix this for multithreaded programs.. thanks for the answer.. I hadn't considered that reason. I assumed that the ASTPENDIG flag would be set, and that the AST would happen, (the userret certainly happens). (does it not?) > > Bruce > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
Ruslan Ermilov wrote: > > --cWoXeonUoKmBZSoM > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Sun, Feb 16, 2003 at 10:24:57AM -0800, David O'Brien wrote: > > On Sun, Feb 16, 2003 at 07:55:49PM +0200, Ruslan Ermilov wrote: > > > > Don't cross post current and developers. > > > >=20 > > > > The developers charter says it's for internal management i.e. how we > > > > manage the project and not for discussing code issues. It's badly nam= > ed, > > > > we should have called it something like "members" or "admin". > > > >=20 > > > I must disagree. This message equally applies -current as well > > > as -developers; > >=20 > > It doesn't matter what you think -- this is our written down rules. > > Please obey them. If you want to target both lists, sent the message out > > twice -- once to each list. > >=20 > OK, I stand corrected. I should have written to src-committers@. No, src-committers wouldn't have helped you. That's src developers only, not public. Do not cross-post src-committers with -current either. If you really want to have a public discussion, post to -current, and then a second "hey, look over on -current" to src-developers@. Or do a bcc: src-developers or something. But not a To:/CC: cross post. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Local repo: Perforce/CVS integration
--En cette belle journée du lundi 17 février 2003 01:21 -0600 -- Juli Mallett <[EMAIL PROTECTED]> écrivait : | * De: Mathieu Arnold <[EMAIL PROTECTED]> [ Data: 2003-02-17 ] | [ Subjecte: Re: Local repo: Perforce/CVS integration ] |> --En cette belle journée du dimanche 16 février 2003 16:08 -0600 |> -- Juli Mallett <[EMAIL PROTECTED]> écrivait : |> | FreeBSD has special great evil triggers which will import things into |> | //depot/vendor/freebsd/src/... for example, and then we just branch off |> | of there, and integ -b as needed. |> | |> | :) |> |> Are these triggers top secret, or would it be possible to share them with |> the rest of us ? | | When i said triggers above, I was thinking of something else, what I was | referring to is actually a periodic (or manually kicked off) job to import | things to the vendor area. This does not answer to the question :) -- Mathieu Arnold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Local repo: Perforce/CVS integration
* De: Mathieu Arnold <[EMAIL PROTECTED]> [ Data: 2003-02-17 ] [ Subjecte: Re: Local repo: Perforce/CVS integration ] > --En cette belle journée du dimanche 16 février 2003 16:08 -0600 > -- Juli Mallett <[EMAIL PROTECTED]> écrivait : > | FreeBSD has special great evil triggers which will import things into > | //depot/vendor/freebsd/src/... for example, and then we just branch off > | of there, and integ -b as needed. > | > | :) > > Are these triggers top secret, or would it be possible to share them with > the rest of us ? When i said triggers above, I was thinking of something else, what I was referring to is actually a periodic (or manually kicked off) job to import things to the vendor area. -- Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Local repo: Perforce/CVS integration
--En cette belle journée du dimanche 16 février 2003 16:08 -0600 -- Juli Mallett <[EMAIL PROTECTED]> écrivait : | FreeBSD has special great evil triggers which will import things into | //depot/vendor/freebsd/src/... for example, and then we just branch off | of there, and integ -b as needed. | | :) Are these triggers top secret, or would it be possible to share them with the rest of us ? -- Mathieu Arnold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: question on profiling code
Apparently, On Mon, Feb 17, 2003 at 05:35:09PM +1100, Bruce Evans said words to the effect of; > On Sun, 16 Feb 2003, Julian Elischer wrote: > > > In addupc_intr, if the increment cannot be done immediatly, the addres > > to increment the count for is stored and the increment is done later at > > ast or userret() time... > > Note that "cannot be done immediatly" is "always except on sparc64's" > under FreeBSD, since incrementing the counter immediately is only > implemented on sparc64's. > > > is there any reason that the address of the PC needs to be stored? > > why is the address from the frame at that time not useable? > > > > is it because the PC in the return frame may be hacked up for signals? > > That's was good a reason as any. I think the next return to user mode > is to the signal handler's context (if there is a signal to be handled). > It would be wrong to use the signal handler's pc. Also, ast() doesn't > have access to the frame, and there is no macro like CLKF_PC() for > general frames. This probably doesn't matter much, since signals are > rare and the hitting on the signal handler's pc would be perfectly > correct if the profiling interrupt occurred an instant later. There are macros for accessing trapframes, like the ones for clockframe, TRAPF_PC etc. > > Now there is a stronger reason: clock interrupt handling is "fast", > so it normally returns to user mode without going near ast(), and the > counter is not updated until the next non-fast interrupt or syscall. In freebsd "fast" interrupts do handle asts, on i386 they return through doreti (you may consider this a bug and have removed it in your version). I see no reason not to just use the pc in the trapframe passed to ast, even in the case of signals they won't be posted until after addupc_task is called. Jake To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The cbus driver for pc98
"M. Warner Losh" wrote: > In message: <[EMAIL PROTECTED]> > Takahashi Yoshihiro <[EMAIL PROTECTED]> writes: > : I have made the cbus driver for pc98 based on i386 isa driver. This > : completely removes that PC98 depends on isa driver and also corrects > : directory layouts (pc98/i386 -> pc98/pc98 and pc98/pc98 -> pc98/cbus). > : > : The full patch can get from > : http://home.jp.FreeBSD.org/~nyan/patches/cbus.diff.gz > : > : Soeren, please review the ata part. > : http://home.jp.FreeBSD.org/~nyan/patches/cbus-ata.diff.gz > : > : Warner, please review the oldcard part. > : http://home.jp.FreeBSD.org/~nyan/patches/cbus-pccard.diff.gz > : > : > : If it has no problem, I'll commit after required repository copy. > > Please excuse my tardiness in replying to this review request. I've > just finished a large release at work that was consuming much of my > time. > > I do not like this. It seems to take too many files and just do a > simple s/isa/cbus/g on them. However, I'm not sure that we want to do > that with so many files when the majority of them are very close to > being able to just add a second module line. I think it would be > better to implement cbus as an 'isa bus subclass'. cbus is an > isa-like bus in many respects from a programming point of view. > Copying everything is not the right way to approach this problem, > imho. It would be better if the cbus bus implemented the isa routines > and accepted that 'isa' is a bit if a misnomer. I can understand if you do not like to call your cbus hardware "ISA" devices, but also consider that on most pc-at hardware there are no "ISA" devices either. Things like the floppy controller, keyboard controller, counter/timer, rtc, etc etc are all on motherboard busses. Many are on things like X-bus, v-link, or other custom "quick and dirty" host busses. If we started i386/x-bus/* and i386/v-link/* etc then things would get ugly very quickly. Personally, I would rather live with #ifdef PC98 than to have a duplicate set of isa/* and i386/* files that are nearly identical except for include file paths, #ifdef PC98 and s/isa/cbus/. I'm sure there are other ways to improve the situation without having to resort to this mass duplication of code. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The cbus driver for pc98
In message: <[EMAIL PROTECTED]> Takahashi Yoshihiro <[EMAIL PROTECTED]> writes: : I have made the cbus driver for pc98 based on i386 isa driver. This : completely removes that PC98 depends on isa driver and also corrects : directory layouts (pc98/i386 -> pc98/pc98 and pc98/pc98 -> pc98/cbus). : : The full patch can get from : http://home.jp.FreeBSD.org/~nyan/patches/cbus.diff.gz : : Soeren, please review the ata part. : http://home.jp.FreeBSD.org/~nyan/patches/cbus-ata.diff.gz : : Warner, please review the oldcard part. : http://home.jp.FreeBSD.org/~nyan/patches/cbus-pccard.diff.gz : : : If it has no problem, I'll commit after required repository copy. Please excuse my tardiness in replying to this review request. I've just finished a large release at work that was consuming much of my time. I do not like this. It seems to take too many files and just do a simple s/isa/cbus/g on them. However, I'm not sure that we want to do that with so many files when the majority of them are very close to being able to just add a second module line. I think it would be better to implement cbus as an 'isa bus subclass'. cbus is an isa-like bus in many respects from a programming point of view. Copying everything is not the right way to approach this problem, imho. It would be better if the cbus bus implemented the isa routines and accepted that 'isa' is a bit if a misnomer. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 10:31:25PM -0800, David Schultz wrote: > > Note that I was only suggesting this patch be committed to -current > > for purposes of finding out what these applications are, and fixing > > them as appropriate. > > Then how about wrapping the warning in an #ifdef, so people who > want to find inappropriate uses of rand() can do so for as long as > they want, and everyone else who uses -CURRENT is not affected? That sounds fine to me. Kris msg52544/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 08:53:09AM +0300, Andrey A. Chernov wrote:
> On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote:
>
> > I don't think rand()
> > needs a warning message like gets() &c. because it's not as dangerous.
>
> Wait, what kind of warning __warn_references() produce? I was under
> impression that it is compile-time only.
I was referring to the __warn_references() warning in gets(), not the
annoying message written to standard error.
>
> > What I suggest instead is to remove the pathetic "insults" in rand(3)
> > ("bad" random number generator, obsoleted) and add a BUGS section
> > which describes the problem.
>
> I agree. It can be done not instead only but in addition to compile
> time warning.
>
> > I'd much prefer that rand() generated higher quality numbers, though.
>
> Current formulae generates acceptable quality numbers. Unlike in old
> variant (which generates bad quality ones), the only problem remains is
> first value monotonically increased with the seed.
Here's an interesting picture of that: http://people.freebsd.org/~tjr/rand.gif
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: question on profiling code
On Sun, 16 Feb 2003, Julian Elischer wrote: > In addupc_intr, if the increment cannot be done immediatly, the addres > to increment the count for is stored and the increment is done later at > ast or userret() time... Note that "cannot be done immediatly" is "always except on sparc64's" under FreeBSD, since incrementing the counter immediately is only implemented on sparc64's. > is there any reason that the address of the PC needs to be stored? > why is the address from the frame at that time not useable? > > is it because the PC in the return frame may be hacked up for signals? That's was good a reason as any. I think the next return to user mode is to the signal handler's context (if there is a signal to be handled). It would be wrong to use the signal handler's pc. Also, ast() doesn't have access to the frame, and there is no macro like CLKF_PC() for general frames. This probably doesn't matter much, since signals are rare and the hitting on the signal handler's pc would be perfectly correct if the profiling interrupt occurred an instant later. Now there is a stronger reason: clock interrupt handling is "fast", so it normally returns to user mode without going near ast(), and the counter is not updated until the next non-fast interrupt or syscall. This might not happen until unother profiling interrupt clobbers the saved pc, not to mention the saved tick count (it could just increment the tick count so that ticks are assigned to the last saved pc instead of lost; currently, the tick count mostly just tracks KEF_OWEUPC so it need not be saved). This was broken by SMPng (hardclock() is not really a fast interrupt handler but is abused as one). However, normal applications probably make enough syscalls to get the right counter updated, provided we use the counter for the pc at fast interrupt time and not the counter for the pc later. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
Thus spake Kris Kennaway <[EMAIL PROTECTED]>: > On Mon, Feb 17, 2003 at 04:40:48PM +1100, Tim Robbins wrote: > > > I disagree. It's safe to use rand() in games and in certain kinds of > > simulations when you don't care that the distribution isn't quite > > uniform, or when you prefer speed over quality. I don't think rand() > > needs a warning message like gets() &c. because it's not as dangerous. > > The problem is that there are a number of applications that use it > when they should not. I've given examples of two of them, and there > are probably lots of others I haven't noticed. For example, I just > checked, and libICE appears to use rand() for cookie generation. This > is completely bogus, and insecure. > > Note that I was only suggesting this patch be committed to -current > for purposes of finding out what these applications are, and fixing > them as appropriate. Then how about wrapping the warning in an #ifdef, so people who want to find inappropriate uses of rand() can do so for as long as they want, and everyone else who uses -CURRENT is not affected? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/pci/if* fixes
One thing: you don't need to move the allocation of the interrupt, just the turning it on. However, if you move the location that you turn it on be careful that the driver doesn't do something silly in its attach routine. I was wrong a while ago when I said that the attach routines typically turned on the interrupts in the card. That's usually done in the the if_init() routine that the driver registers. So the advise about doing the enabling of interrupts last in the attach routine should be considered bogus. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Console API related patch.
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes: >> This patch changes the API so that rather than pass a "dev_t" to the >> console functions, the "struct consdev *" is passed: >> >> -typedefvoidcn_putc_t(dev_t, int); >> +typedefvoidcn_putc_t(struct consdev *, int); >> > >I like this. On the ia64 branch I completely ignore the dev argument >and instead use a static softc. The dev_t is unknown until after >bus enumeration in principle anyway. Yeah, I saw that. Actually I think more or less any console driver which uses the dev_t arg is wrong about doing that, but we can fix that subsequently. >I'll test ia64, both CVS an P4. Let me know when you like to >commit this so that I can schedule around that... I'm no no particular hurry, so whenever I have sufficient feedback to convince me that its safe. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sys/pci/if* fixes
In message: <[EMAIL PROTECTED]> Nate Lawson <[EMAIL PROTECTED]> writes: : * Does each device that uses miibus need to explicitly call : device_delete_child when it is detaching? Should it do it also in its : attach routine if it encounters an error? I assume all drivers need to do : this after a successful mii_phy_probe(). Yes. Yes. Yes. : * Does it need to call bus_generic_detach on itself? Yes. At least I've had lots of luck doing it and it doesn't hurt. : * Is it ok to return other errors (ENOMEM) from a device_attach method? Yes. Lots of devices return other errors, ENXIO is a common one. ENOMEM was an invention in the early days and is likely slightly bogus because it is supposed to be for malloc failures, not 'I can't get this resource' in general (but given its long usage, the bogusness level is fairly low). Matt's point about 'disabling interrupts' is that the driver writer should turn off the 'please interrupt on interesting things' bit in the device's registers. It should enable this bit the very last thing in the attach routine and the race should be solved that way. What Matt fails to realize is that in the shared interrupt case there's a problem. Some devices will indicate that they have interesting events that have happened, even when the interrupt mask register is 'cleared'. In those cases, once the ISR is registered and fielding interrupts (possibly from other devices) the race condition exists. Short of turning off ALL interrupts from the processor (or some way of doing a spl-like masking of interrupt), the race would still be there. Unless I misunderstand what Matt is saying. I'm still concerned about LOR that happens. If you hold a driver lock when ether_ifattach is called, you'll have a lock order: DRIVER_LOCK IFNET_LOCK however, the slotmo routine takes IFNET_LOCK and then calls the watchdog routine. Typically, in this routine, you take out the driver lock, which results in the following lock order: IFNET_LOCK DRIVER_LOCK when I was tracking down the interrupt problem on kldload for cardbus, I noticed a LOR like this in dc, but I couldn't find where it was happening at the time and now that the interrupt problem is solved, I'm not seeing the LOR since interrupts happen and I don't get to the watchdog routine :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Clock disabled during DDB
In message <[EMAIL PROTECTED]>, Bruce Evans writes: >The >piix timecounter has a lower frequency than the TSC, but for some >reason we mask it to 24 bits (16M cycles @ 3.5+ MHz = 4+ seconds). We do this because the spec defines it as either 32 or 24 bit and some 24 bit implementations claim to have 32 bits. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 04:40:48PM +1100, Tim Robbins wrote: > I disagree. It's safe to use rand() in games and in certain kinds of > simulations when you don't care that the distribution isn't quite > uniform, or when you prefer speed over quality. I don't think rand() > needs a warning message like gets() &c. because it's not as dangerous. The problem is that there are a number of applications that use it when they should not. I've given examples of two of them, and there are probably lots of others I haven't noticed. For example, I just checked, and libICE appears to use rand() for cookie generation. This is completely bogus, and insecure. Note that I was only suggesting this patch be committed to -current for purposes of finding out what these applications are, and fixing them as appropriate. > I'd much prefer that rand() generated higher quality numbers, though. Me too, but that is apparently not possible because of API constraints. Kris msg52536/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libc/stdlib rand.c
Thus spake Kris Kennaway <[EMAIL PROTECTED]>: > I think we should commit this patch (to -current) and fix all the > problems that pop up. For example, it's used in awk (which started > this set of changes), and in some of the XFree86 libraries. ... > +__warn_references(rand_r, > + "warning: rand_r() does not produce high-quality random numbers and should not >generally be used"); Many programmers who use rand() are aware that it isn't very good, but don't care for their particular application. For instance, for games or for randomized backoff in network protocols, you might just want a sequence of numbers that looks kinda random, and you don't care that there happens to be a pattern in the lowest-order bits that you see only if you look carefully. rand() isn't like gets() because it's nearly impossible to write a robust program using gets(). It might make sense to put in the warning just to check whether someone used rand() when they really wanted cryptographic-quality randomness, but people would probably get annoyed if the next release of FreeBSD nagged them about every use of rand(). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
* De: "Andrey A. Chernov" <[EMAIL PROTECTED]> [ Data: 2003-02-16 ] [ Subjecte: Re: cvs commit: src/lib/libc/stdlib rand.c ] > On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote: > > > I don't think rand() > > needs a warning message like gets() &c. because it's not as dangerous. > > Wait, what kind of warning __warn_references() produce? I was under > impression that it is compile-time only. I don't like the idea of this, people using rand incorrectly deserve to get their foot shot off. People using it legitimately don't need to have their heart skip a beat whenever thye link on FreeBSD because it looks like there's some danger to using rand(), when it is perfectly good at what it does, for a lot of common uses. Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Mon, Feb 17, 2003 at 16:40:48 +1100, Tim Robbins wrote:
> I don't think rand()
> needs a warning message like gets() &c. because it's not as dangerous.
Wait, what kind of warning __warn_references() produce? I was under
impression that it is compile-time only.
> What I suggest instead is to remove the pathetic "insults" in rand(3)
> ("bad" random number generator, obsoleted) and add a BUGS section
> which describes the problem.
I agree. It can be done not instead only but in addition to compile
time warning.
> I'd much prefer that rand() generated higher quality numbers, though.
Current formulae generates acceptable quality numbers. Unlike in old
variant (which generates bad quality ones), the only problem remains is
first value monotonically increased with the seed.
--
Andrey A. Chernov
http://ache.pp.ru/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: sys/pci/if* fixes
In message: <[EMAIL PROTECTED]>
"Matthew N. Dodd" <[EMAIL PROTECTED]> writes:
: On Fri, 14 Feb 2003, Nate Lawson wrote:
: > Also, except for xl, all drivers have a common cleanup on error in
: > attach that backs out allocated resources with no assumptions about the
: > order they were allocated in.
:
: Please see if_pcn.c for the correct approach to freeing resources; its not
: necessary to wrap evrything in 'if (sc && error != 0) {}'. If execution
: reaches the 'fail' label then you assume that is what happened.
:
: I also think you should just drop and reaquire locks around the
: bus_setup_intr() rather than moving code around.
I don't think that's reasonable. The reason that the lock is there is
so that the ISR can't interrupt the attach routine if interrupts are
enabled. Also, you can't hold the driver lock when you call the
network if attach routines because then you get lock order reversals
in the watchdog routine
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: call for testers: cd(4) changes
On Sat, Feb 15, 2003 at 12:20:46 +0100, Thomas Quinot wrote:
> Le 2003-02-15, Kenneth D. Merry écrivait :
>
> > - Automatically detect CDROM drives that can't handle 6 byte mode
> >sense and mode select, and adjust our command size accordingly.
> >More information on that below.
> >
> > - MODE_SENSE and MODE_SELECT translation removed in ATAPICAM and in
> >the umass(4) driver, since there's no way for that to work properly
> >(see below).
>
> I'm afraid things are not as simple as that. Unfortunately you cannot
> expect ATAPI drives to properly reject MODE_{SENSE,SELECT}_6 and try the
> _10 variants in that case: the reason why ATAPICAM inconditionnally
> translates the _6 commands into _10 is because some ATAPI drives have
> been found to lock up when they rececive the _6 commands, whereas the
> ATAPI specification only mandates the implementation of the _10
> versions.
The translation produces bogus results, so we can't really keep it around.
In the mode sense case, the caller will be looking in the wrong place for
the page. In the mode select page, the drive will be looking for the page
at the wrong offset, and the page will be truncated.
The two alternatives I can think of are getting the CAM_NEW_TRAN_CODE
working, so we'll know that drives that talk ATAPI can't do 10 byte mode
sense/select, or quirking drives that are known to hang when they get 6
byte commands.
The long term plan is the first alternative; that really is the cleanest
way to do it. In the short term, I'll put in a quirk mechanism. I'll be
somewhat strict about making submitters prove that the drive has a
problem, and documenting it in a PR audit trail. (The same sort of
approach Nate is using with the da(4) driver quirks.) We should be able
to remove all drives with the 10 byte quirk once we get the
CAM_NEW_TRAN_CODE done.
> > - The media validation routine also reads the table of contents off
> >the drive.
>
> Great! That could also allow the creation of per-track /dev nodes, as
> acd has.
Yep.
Ken
--
Kenneth Merry
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 08:57:29PM -0800, Kris Kennaway wrote:
> On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote:
>
> > So, monotonically increased seed->first value correlation problem remains...
>
> I think we should commit this patch (to -current) and fix all the
> problems that pop up. For example, it's used in awk (which started
> this set of changes), and in some of the XFree86 libraries.
>
> Kris
>
> Index: stdlib/rand.c
> ===
> RCS file: /mnt2/ncvs/src/lib/libc/stdlib/rand.c,v
> retrieving revision 1.14
> diff -u -r1.14 rand.c
> --- stdlib/rand.c 5 Feb 2003 21:25:50 - 1.14
> +++ stdlib/rand.c 8 Feb 2003 06:07:55 -
> @@ -86,6 +86,8 @@
> #endif /* !USE_WEAK_SEEDING */
> }
>
> +__warn_references(rand_r,
> + "warning: rand_r() does not produce high-quality random numbers and should not
>generally be used");
>
> int
> rand_r(unsigned int *ctx)
> @@ -99,6 +101,9 @@
>
>
> static u_long next = 892053144; /* after srand(1), NSHUFF counted */
> +
> +__warn_references(rand,
> + "warning: rand() does not produce high-quality random numbers and should not
>generally be used");
>
> int
> rand()
I disagree. It's safe to use rand() in games and in certain kinds of
simulations when you don't care that the distribution isn't quite
uniform, or when you prefer speed over quality. I don't think rand()
needs a warning message like gets() &c. because it's not as dangerous.
What I suggest instead is to remove the pathetic "insults" in rand(3)
("bad" random number generator, obsoleted) and add a BUGS section
which describes the problem.
I'd much prefer that rand() generated higher quality numbers, though.
Tim
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Clock disabled during DDB
On Sun, 16 Feb 2003, Kris Kennaway wrote: > Is it an expected feature that the system clock is not updated when > the system is sitting in DDB? Yes. Interrupts must be disabled while ddb is running, so the time cannot be updated normally. Timecounting can mostly work if it is driven by a timecounter with a slow clock and a large mask, but there are few or none such timecounters available. The i8254 timecounter wraps after 1/hz seconds. The TSC wraps after 4G cycles (2 seconds at 2GHz) since we don't (and currently can't) use all its bits. The piix timecounter has a lower frequency than the TSC, but for some reason we mask it to 24 bits (16M cycles @ 3.5+ MHz = 4+ seconds). The acpi timecounter is the same as the piix timecounter except it has more style bugs and less bitrot. Times once sometimes went backwards after exiting ddb due to overflow in timecounter code when the delta-counts were unexpectedly large. I think this has been fixed. Things sometimes (mostly) sort of worked before RELENG_5 (except in my version) because of a bug in ddb -- it didn't mask interrupts properly, so all sorts of interrupts including timeout interrupts were handled while ddb was running unless ddb was invoked with those interrupts already masked. > I just had 8 machines sitting in DDB > for about 20 minutes at boot (because of that &^@%&^ sysctl LOR), and > ntpd refused to time-sync them when I continued, because the clock had > fallen too far behind: > > Feb 16 17:18:08 gohan12 ntpd[177]: time correction of 1149 seconds exceeds >sanity limit (1000); set clock manually to the correct UTC time. > Feb 16 17:18:12 gohan10 ntpd[177]: time correction of 1155 seconds exceeds >sanity limit (1000); set clock manually to the correct UTC time. > Feb 16 17:18:00 gohan15 ntpd[177]: time correction of 1169 seconds exceeds >sanity limit (1000); set clock manually to the correct UTC time. You shouldn't let ddb be invoked on machines that need to keep the correct time. However, I like to invoke ddb on all my machines including my ntp server, so I had to fix this problem years ago :-). My fix involves syncing with the RTC in rtcintr() 2-3 seconds after leaving ddb. My code doesn't work in plain -current because SMPng made rtcintr() a fast interrupt (rtcintr() is a normal interrupt in my kernel but this requires large unfinished changes). It could be done almost as well in an application, preferably ntp itself. ntpd -g might work. What is really needed is a way to force ntpd to step the clock (forwards only) without losing more state than necessary. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 20:57:29 -0800, Kris Kennaway wrote: > On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote: > > > So, monotonically increased seed->first value correlation problem remains... > > I think we should commit this patch (to -current) and fix all the > problems that pop up. For example, it's used in awk (which started > this set of changes), and in some of the XFree86 libraries. I agree. (diff is for old rand.c, but idea is clear in anycase). I have no fancy ideas how to fix correlation problem AND keep rand_r() compatibility at the same time. All linear mod-type generators share this problem with monotonic seeding and usual solution is shuffling array (more complex code than I use), but it will be incompatible with rand_r() again. If we back out most of changes and return to very first formulae with overflow, we 1) Make monotonic increasing for seed->first_value less visible. 2) Not fix seed->first_value correlation (taking some parts of bits will show repeated pattern). 3) Make distribution and lower bits bad. -- Andrey A. Chernov http://ache.pp.ru/ msg52528/pgp0.pgp Description: PGP signature
LOR: tcp_input.c -> tcp_usrreq.c
Hi, I've seen the following come up here and there. A quick search of the archive didn't come with anything: lock order reversal 1st 0xc65de7dc inp (inp) @ ../../../netinet/tcp_input.c:636 2nd 0xc035eccc tcp (tcp) @ ../../../netinet/tcp_usrreq.c:621 Stack backtrace: backtrace(c032cd1d,c035eccc,c03323a7,c03323a7,c0333e0d) at backtrace+0x17 witness_lock(c035eccc,8,c0333e0d,26d,0) at witness_lock+0x65a _mtx_lock_flags(c035eccc,0,c0333e0d,26d,0) at _mtx_lock_flags+0xb1 tcp_usr_rcvd(c6662a00,80,df152a74,c01abc8d,c0386be0) at tcp_usr_rcvd+0x30 soreceive(c6662a00,df152ac4,df152ad0,df152ac8,0) at soreceive+0xa1a nfsrv_rcv(c6662a00,c84b9e80,1,c65de82c,e1c4) at nfsrv_rcv+0x8a sowakeup(c6662a00,c6662a4c,c0236cd0,c65de82c,108) at sowakeup+0x97 tcp_input(c227fb00,14,df152c30,c01ba7a1,df152c4c) at tcp_input+0x2698 ip_input(c227fb00,0,c0333230,3b5,2) at ip_input+0x79e ipintr(c03280a9,217,c223ebc0,c2248e80,c224bd20) at ipintr+0x88 swi_net(0,0,c03280a9,217,c224a564) at swi_net+0x2f ithread_loop(c2248e80,df152d48,c0327f26,368,c224bd20) at ithread_loop+0x16c fork_exit(c01a2f90,c2248e80,df152d48) at fork_exit+0xc4 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf152d7c, ebp = 0 --- largo# uname -a FreeBSD largo.properkernel.com 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Sat Feb 15 22:25:46 EST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/LARGO i386 Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/lib/libc/stdlib rand.c
On Sun, Feb 16, 2003 at 07:52:35PM -0800, Andrey A. Chernov wrote: > So, monotonically increased seed->first value correlation problem remains... I think we should commit this patch (to -current) and fix all the problems that pop up. For example, it's used in awk (which started this set of changes), and in some of the XFree86 libraries. Kris Index: stdlib/rand.c === RCS file: /mnt2/ncvs/src/lib/libc/stdlib/rand.c,v retrieving revision 1.14 diff -u -r1.14 rand.c --- stdlib/rand.c 5 Feb 2003 21:25:50 - 1.14 +++ stdlib/rand.c 8 Feb 2003 06:07:55 - @@ -86,6 +86,8 @@ #endif /* !USE_WEAK_SEEDING */ } +__warn_references(rand_r, + "warning: rand_r() does not produce high-quality random numbers and should not +generally be used"); int rand_r(unsigned int *ctx) @@ -99,6 +101,9 @@ static u_long next = 892053144; /* after srand(1), NSHUFF counted */ + +__warn_references(rand, + "warning: rand() does not produce high-quality random numbers and should not +generally be used"); int rand() msg52526/pgp0.pgp Description: PGP signature
Need an expert's advise on WITNESS problem(?) (very long)
Dear Hackers,
I need an expert's advice on the small locking/WITNESS problem
(if this is a real problem of course). It basically boils down
to the following:
Consider three (3) MTX_DEF mutexes: A, B1 and B2. Mutex A has a
name "mutex_A" and type "type_A". Mutex B1 has a name "mutex_B1"
and mutex B2 has name "mutex_B2". Both mutex B1 and B2 have the
same type "type_B". Please note that mutexes B1 and B2 are
completely independent from each other. They just have the same
mutex type (B1 and B2 are used for fine grained locking).
Now consider the code that has two (2) paths: P1 and P2.
On the path P1 the code first acquires mutex A and then mutex
B1. Then the code releases mutex B1 and then mutex A.
On the path P2 the code first acquires mutex B2 and then mutex
A. Then the code releases mutex B2 and then mutex A.
So the code's flow looks something like this
--->---\ /--->--- B1 --->--- Code path P1
A
---<---/ \---<--- B2 ---<--- Code path P2
Now the problem (again if this is a problem) is that WITNESS
code builds relations between mutex types (or at least I think
it does). So when the code runs, WITNESS will build relations
between mutex types for the first path the code follows (lets
say P1). Later when the code follows the second path (in this
example P2), WITNESS will create "lock order reversal" message.
The questions are:
1) Is anything wrong with the such code and/or mutex use?
Since mutexes B1 and B2 are completely independent, there
is no deadlock danger, right? Please tell me if I'm wrong
and missing something here.
2) Is there any way to resolve the problem? I'm prepared to
change/re-design my code if needed.
3) Is WITNESS right in this case?
I have attached a small "spherical cow" that demonstrates
the example above. Just compile and load ng_cow.ko module
and then try
# ngctl msg cow: moo
Please advise.
thanks,
max
Makefile
CFLAGS+=-g
KMOD= ng_cow
SRCS= ng_cow.c
NOMAN=
.include
=== ng_cow.c ==
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define NG_COW_NODE_TYPE"cow"
#define NGM_COW_COOKIE 1018303300
#define NGM_COW_MOO 1
#ifdef NG_SEPARATE_MALLOC
MALLOC_DEFINE(M_NETGRAPH_COW, "cow", "Netgraph spherical cow");
#else
#define M_NETGRAPH_COW M_NETGRAPH
#endif
static ng_constructor_t ng_cow_constructor;
static ng_rcvmsg_t ng_cow_rcvmsg;
static ng_shutdown_tng_cow_shutdown;
static ng_newhook_t ng_cow_newhook;
static ng_connect_t ng_cow_connect;
static ng_rcvdata_t ng_cow_rcvdata;
static ng_disconnect_t ng_cow_disconnect;
static int ng_cow_modevent (module_t, int, void *);
static const struct ng_cmdlist ng_cow_cmdlist[] = {
{
NGM_COW_COOKIE,
NGM_COW_MOO,
"moo",
NULL,
NULL
},
{ 0, }
};
static struct ng_type typestruct = {
NG_ABI_VERSION,
NG_COW_NODE_TYPE, /* typename */
ng_cow_modevent,/* modevent */
ng_cow_constructor, /* constructor */
ng_cow_rcvmsg, /* control message */
ng_cow_shutdown,/* destructor */
ng_cow_newhook, /* new hook */
NULL, /* find hook */
ng_cow_connect, /* connect hook */
ng_cow_rcvdata, /* data */
ng_cow_disconnect, /* disconnect hook */
ng_cow_cmdlist /* node command list */
};
NETGRAPH_INIT(cow, &typestruct);
MODULE_VERSION(ng_cow, 1);
static node_p the_node = NULL;
static struct mtx a, b1, b2;
static int
ng_cow_modevent(module_t mod, int event, void *data)
{
int error = 0;
switch (event) {
case MOD_LOAD:
error = ng_make_node_common(&typestruct, &the_node);
if (error != 0)
break;
error = ng_name_node(the_node, NG_COW_NODE_TYPE);
if (error != 0) {
NG_NODE_UNREF(the_node);
the_node = NULL;
break;
}
mtx_init(&a, "mutex_A", "type_A", MTX_DEF);
mtx_init(&b1, "mutex_B1", "type_B", MTX_DEF);
mtx_init(&b2, "mutex_B2", "type_B", MTX_DEF);
break;
case MOD_UNLOAD:
mtx_destroy(&a);
mtx_destroy(&b1);
mtx_destroy(&b2);
break;
default:
error = EOPNOTSUPP;
break;
}
return (error);
}
static int
ng_cow_constructor(node_p node)
{
return (EINVAL);
}
static int
ng_cow_newhook(node_p node, hook_p hook, char const *name)
{
return (EINVAL);
}
static int
ng_cow_connect(hook_p hook)
{
return (EINVAL);
}
static int
ng_cow_disconnect(ho
Problems creating and writing to disk slices
I've been trying to move the installed OSes around on my hard disk, but am having a huge amount of trouble doing so. The task involves dd'ing the slices off the disk for safe-keeping, modifying the on-disk slice table, then dd'ing the slices back onto the disk in their new locations. However, sysinstall doesn't work for manipulating the slice table and labels. It gives me errors saying it couldn't write to the device. Manually doing the work using fdisk and disklabel yield multiple problems: - Fdisk returns device busy errors when trying to write to the slice table to make a modification to a slice that has no mounted filesystems. I can only modify the slice table if I boot from either DOS or an off-disk OS (like the Fix-It CD). - After the slice is created and I've rebooted back into 5.0p1, the lack of a /dev/ad4s1c device node means I have to use `disklabel -w -r ad4s1 auto` to create the c partition, then `disklabel -e -r ad4s1` to modify the label. The editor comes up with a label with the c partition offset of 0. I add the other partitions making calculations to ensure the partitions start/end on boundaries. Exiting the editor, disklabel complains that the 'c' partition doesn't begin with sector 0 and doesn't cover the whole disk, and also that my last partition goes past the end of the unit. Reeditting the label, the offsets are now shifted by 63. Re-adjusting the partition sizes and offsets doesn't fix the problem even though the numbers indicate that everything is aligned properly and within the slice boundaries. After growing quite frustrated with this, I gave up and booted into DOS and was able to create the slice. Booting back into 5.0p1, fdisk tells me the slice is fine, and the size and geometry are an exact match to what I was trying to make fdisk use. All that's left is to dd the original slice back into place, but `dd if=win98.ad4s1 of=/dev/ad4s1 bs=1024k` returns an error saying that writing to ad4s1 failed because the device is busy. How can the device be busy? The above practices have worked fine for a long time in 4.x and still do even in 4.7p4, which is on this same machine. The disklabel in 4.7p4 doesn't complain about the state of the labels, and sysinstall can manipulate the slice table and labels just fine on the live disk. What's changed in 5.x to make this not work, and what do I need to do to accomplish my task? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-STABLE Roadmap
On Sun, 16 Feb 2003, Pawel Jakub Dawidek wrote: > On Sun, Feb 16, 2003 at 02:08:35PM -0700, Scott Long wrote: > +> Pawel Jakub Dawidek wrote: > +> > +> >On Thu, Feb 13, 2003 at 08:28:43PM -0800, Sam Leffler wrote: > +> >+> This can quickly turn into a bikeshed, but suggest ones. We're > +> >looking for > +> >+> good benchmarks. [...] > +> > > +> >Look at: > +> > > +> > http://www.web-polygraph.org > +> > > +> >It provides tests for www-cache/proxy stuff. > +> >We can test many things with it: > +> > > +> > - how fast could we generate workload, > +> > - how heavy load could we handle, > +> > - how fast is squid running on FreeBSD, > +> > - how fast is squid rewritten with libkse, > +> > - etc. > +> > > +> >And this is good stablility test. > +> >This is real good and free stuff, I use it on 4.x. > +> > > +> Thanks for the pointer, this looks very interesting. How hard > +> is it to set up? [...] > > Setting it up is quite simple, but it doesn't compile with gcc 3.x... There were too many non-backwards compatible changes in 3.x and the compiler was not stable enough last time we checked. We will probably check and port again some time soon. GCC 2.9x should work fine though. Polygraph is relatively easy to setup on FreeBSD for standard tests, using two PCs. Testing with more PCs, with non-standard workloads, and/or on a regular basis requires writing scripts and can get pretty evolved (which let's us sell a pre-configured appliance that does Polygraph test management :). How-Tos for standard tests on FreeBSD are available at: http://www.measurement-factory.com/support.html > Yes, on website kernel patches are avaliable for tunning, but for new > releases of 4.x this isn't necessary, all could be configure with kernel > options and sysctls (for 4.8): > > options MAXFILES=16384 > options HZ=1000 > options NMBCLUSTERS=32678 > > kern.ipc.somaxconn=1024 > net.inet.ip.portrange.last=4 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.msl=3000 One of our kernel patches optimizes handling of 1000s of IP aliases per FreeBSD box. The patch is required for older 4.x kernels to perform at decent levels. IIRC, the patch does not work for recent kernels, probably because of the SYN cache changes. I do not know whether any alias-related optimizations are still needed for recent kernels though. Perhaps the SYN cache solves the original scalability problem. > Rest is quite simple/well documented. Tests in theory could be run > on one machine, so... And some nice looking results generated by > web-polygraph: > > Without any proxy: > http://garage.freebsd.pl/pm3-15-11-2k2 > With squid: > http://garage.freebsd.pl/pm3-05-11-2k2 > http://garage.freebsd.pl/pm3-06-11-2k2 > With external proxy: > http://garage.freebsd.pl/pm3-29-01-2k3 Please note that a couple of the results I looked at are invalid from PolyMix workload rules/design point of view. The first thing to check is that you have huge numbers of request in waiting queue, compared to active transactions (shown on the same "xact_lvl" graph). Most likely, you overloaded the device under test, and most request ended up in queues instead of on the wire. I may be missing something though -- I am just looking at your results without much knowledge of their history/purpose... See last cache-off results for valid examples: http://www.measurement-factory.com/results/ If you have any Polygraph-specific questions, I would be happy to answer them, especially if it can help FreeBSD folks in any way. Good luck, Alex. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: atapicam not in NOTES?
My apologies to the list for not looking in /sys/conf/NOTES before posting. I wasn't aware of the "split". :) A. msg52522/pgp0.pgp Description: PGP signature
Re: Clock disabled during DDB
On 2003-02-16 18:05, Kris Kennaway <[EMAIL PROTECTED]> wrote: > Is it an expected feature that the system clock is not updated when > the system is sitting in DDB? I just had 8 machines sitting in DDB > for about 20 minutes at boot (because of that &^@%&^ sysctl LOR), > and ntpd refused to time-sync them when I continued, because the > clock had fallen too far behind: I think I'm not the best possible person to answer this, but I recall reading posts that mentioned interrupts being disabled while in DDB. Since the system time is updated by an interrupt, it falls behind if you leave a machine in DDB for too long. Someone with more system time foo correct me if I'm wrong, please. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
atapicam not in NOTES?
I can't seem to find atapicam in NOTES. Is this voluntary? On the atapicam website, it says that it's been integrated into current. I can build a 5.0-release kernel with it, so has it just been forgotten from NOTES? :) Thanks A. anarcat@lenny[~/dump/c/src/sys/i386/conf]% cvs -R status NOTES === File: NOTES Status: Up-to-date Working revision:1.1070 Wed Jan 15 20:15:33 2003 Repository revision: 1.1070 /home/ncvs/src/sys/i386/conf/NOTES,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) anarcat@lenny[~/dump/c/src/sys/i386/conf]% grep -i ata NOTES anarcat@lenny[~/dump/c/src/sys/i386/conf]% msg52520/pgp0.pgp Description: PGP signature
question on profiling code
In addupc_intr, if the increment cannot be done immediatly, the addres to increment the count for is stored and the increment is done later at ast or userret() time... is there any reason that the address of the PC needs to be stored? why is the address from the frame at that time not useable? is it because the PC in the return frame may be hacked up for signals? They are going to quite a lot of trouble to save teh PC address between the original addupc_intr and the ast()/userret() There must be a reason, but I can't see it. (the values are stored in the struct uprof, associated with the process.) Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Clock disabled during DDB
Is it an expected feature that the system clock is not updated when the system is sitting in DDB? I just had 8 machines sitting in DDB for about 20 minutes at boot (because of that &^@%&^ sysctl LOR), and ntpd refused to time-sync them when I continued, because the clock had fallen too far behind: Feb 16 17:18:08 gohan12 ntpd[177]: time correction of 1149 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Feb 16 17:18:12 gohan10 ntpd[177]: time correction of 1155 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. Feb 16 17:18:00 gohan15 ntpd[177]: time correction of 1169 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. ... Kris msg52514/pgp0.pgp Description: PGP signature
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 20:16:43 -0500, Garance A Drosihn wrote: > > to indicate localhost. Andrey provided a patch which allows OPIE > to keep that standard (to OPIE) meaning. Could people try his > patch and then explain why it does not solve the problem they are > trying to solve? The problem already resolved, des commits acceptable for both parties solution (which use part of my "" patch too). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: resource usage overflow
On Mon, 17 Feb 2003, Bruce Evans wrote: > On Sun, 16 Feb 2003, Julian Elischer wrote: > > > 3/ would 64 bits be enough? We are getting both bigger and faster > > 64000 times faster and 64000 times bigger and we are back at seven > > seconds. 640 times faster and 640 times bigger and we are still only at > > 7 seconds (19 hours) before overflow. > > Er, 64 bit longs provide a factor of 4 billion (not 64000) for bloat. > not that I said 64000 twice... multiply them.. > Bruce > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: resource usage overflow
On Sun, 16 Feb 2003, Julian Elischer wrote: > In the resource usage we have teh following values calculated.. > > longru_ixrss; /* integral shared memory size */ > longru_idrss; /* integral unshared data " */ > longru_isrss; /* integral unshared stack " */ > > in statclock() we have: > ru->ru_ixrss += pgtok(vm->vm_tsize); > ru->ru_idrss += pgtok(vm->vm_dsize); > ru->ru_isrss += pgtok(vm->vm_ssize); > > in other words these ore incremented at the rate of statclock > (for example 1kHz in not unheard of now). > > Assuming that I have a 600MB process (e.g. fsck doing a 1TB fileesyste > uses 667MB in pass 1 alone). > this means that the number of ticks we can count this amount of memory > usage for is: > 4E9/6E5 = 7.1E3 or 7100 ticks or, Strictly half of that on machines with 32-bit longs (they overflow at 2G, not 4G), and 2 billion times that on machines with 64-bit longs. > in the realworld (TM)... seven seconds if I am doing stats and profiling > at 1kHz. You shouldn't do stats at 1kHz. Even the basic tick counters are in danger of overflow if the statclock frequency is large (the counters are 64-bit, but the algorithms that use them (in calcru()) only work if they aren't much larger than 2^32). The profiling clock is normally scaled down to get a statclock of nearly 128Hz. However, no scaling of the scheduling clock is done for arches that don't have a separate profiling or statistics clock and use the scheduling clock for both. Large scheduling clock frequencies are more useful and less harmful than large statclock frequencies. > I think I could make a case for these figures being extended to 64 bits > but: They are already 64-bits on arches with 64-bit longs. > 1/ is it worth it? what uses them? Easier to drop them. In /usr/src, they are used in csh(1) (time builtin), time(1), window(1), acct(2), and potentially anything that calls getrusage(2). I think they are worth keeping for time(1), but it doesn't matter a lot of they are wrong. > 2/ are these mandated by any standard? would making them 64 bits > break anything? They aren't in POSIX-1.2001 (draft). Making them 64-bits on arches with 32-bit longs would break binary compatibilty of getrusage() too and other syscalls that return a struct rusage. > 3/ would 64 bits be enough? We are getting both bigger and faster > 64000 times faster and 64000 times bigger and we are back at seven > seconds. 640 times faster and 640 times bigger and we are still only at > 7 seconds (19 hours) before overflow. Er, 64 bit longs provide a factor of 4 billion (not 64000) for bloat. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
At 3:48 PM + 2/16/03, Mark Murray wrote:
"Andrey A. Chernov" writes:
> On Sun, Feb 16, 2003, Dag-Erling Smorgrav wrote:
> > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes:
> > Admins with no /etc/opieaccess AFFECTED!
>
> Admins with no /etc/opieaccess IDIOTS for not running mergemaster!
> Moreover, admins WITH old /etc/opieaccess (i.e. without your
> line) are affected too! Local logins becomes mysteriosly
> disabled for their users.
With a suitable "HEADS UP!" and appropriate changes to the
documentation, might is be possible to move _all_ policy control
into PAM, instead of having it split between OPIE and PAM?
If I understand this right, the issue is not some split between
OPIE and PAM. The issue is that OPIE wants a zero-length hostname
to indicate localhost. Andrey provided a patch which allows OPIE
to keep that standard (to OPIE) meaning. Could people try his
patch and then explain why it does not solve the problem they are
trying to solve?
If it means that PAM needs to be changed to use the same token
("") for localhost, that seems fine to me. Just as long as it's
documented.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
³ëÈ¿ªÀü "¼ºÀåÈ£¸£¸ó" Çô¹Ø¿¡ »Ñ¸®´Â ½ºÇÁ·¹ÀÌ Å¸ÀÙ. 100% ³×Ãò·² È£¸£¸ó. Made in U.S.A - ¹Ì FDA ½ÂÀÎÁ¦Ç°!!!
Title: ¼ºÀå È£¸£¸óÀÇ ³î¶ó¿î È¿°ú¸¦ °æÇè Çϼ¼¿ä! ÁÁÀº °Ç ´Ù ¾Æ´Âµ¥ °¡°ÝÀÌ ºÎ´ã µÇ½Å´Ù±¸¿ä? ¢º Áß°£ À¯ÅëÀ» °ÅÄ¡Áö ¾Ê°í ¹Ì±¹ÇöÁö·Î ºÎÅÍ Á÷Æǵ˴ϴÙ. ¾ÆÁ÷µµ º¸µû¸® Àå¼ö³ª ÇǺιæ,¼öÀÔ»óÁ¡µî¿¡¼ °í°¡¸¦ ÁÖ°í ±¸ÀÔÇϽʴϱî? Áß±¹»ê °¡Â¥´Â ¾Æ´Ò·±Áö? . ¢º ¸Þ°¡ HGH´Â ÃÖ°í¹ÐµµÀÇ È£¸£¸ó ÇÔ·®(ml´ç 645ng)°ú ÀÎü¿¡ À¯ÇØÇÑ ¾ËÄÝÀ» ÀüÇô »ç¿ëÇÏÁö ¾Ê´Â 100% ¹ÏÀ» ¼ö ÀÖ´Â ³×Ãß·² ¼ºÀå È£¸£¸ó ÀÔ´Ï´Ù. ¢º ÀϺΠºÎÃÌ¿¡¼ °í°¡·Î ½ÃÆǵǴ ¼ºÀåÈ£¸£¸óÀÇ 95%°¡ Áß±¹À̳ª µ¿³²¾Æ¿¡¼ Á¦Á¶µÈ °¡Â¥¶ó´Â ¹æ¼Ûº¸µµ ³»¿ë´ë·Î ±¸ÀÔ ½Ã °¢º°È÷ À¯ÀÇÇϼžßÇÕ´Ï´Ù. ±¸Çϱ⵵ ¾î·Á¿ü´ø ¼ºÀå È£¸£¸ó ÀÌÁ¦ °ÅÇ°¾ø´Â °¡°Ý¿¡ ¾È½ÉÇÏ°í ÁÖ¹®Çϼ¼¿ä! ¹Ì±¹ ÇöÁö¿¡¼ Á÷Á¢ EMS(±¹Á¦ Ư±Þ ¿ìÆí ¼ºñ½º)·Î ´ì±îÁö 4Àϸ¸¿¡ ¹è¼ÛÇØ µå¸³´Ï´Ù. * º» Á¦Ç°Àº ¹Ì±¹ FDA ½ÂÀÎ Á¦Ç°À̸ç FDA NDC(National Drug Code)# 65596-9302-1 MAID IN USA ȨÆäÀÌÁö : www.okbody.com | ¹®ÀÇ(0011-714-350-7243) | À̸ÞÀÏ [EMAIL PROTECTED] MSBIONIC www.okbody.com 2245 W. Broadway Ave., Anaheim, CA 92804 U.S.A º» ¸ÞÀÏÀ» ¼ö½Å°ÅºÎ ÇϽ÷Á¸é ?subject=¼ö½Å°ÅºÎ&Body=¸ÞÀϼö½Å([EMAIL PROTECTED])À» ¿øÄ¡¾Ê½À´Ï´Ù">¿©±â¸¦ ´·¯ÁÖ¼¼¿ä. If you wish to unsubscribe this type of e-mail, please click ?subject=¼ö½Å°ÅºÎ&Body=¸ÞÀϼö½Å([EMAIL PROTECTED])À» ¿øÄ¡¾Ê½À´Ï´Ù">Here To Unsubscribe: send mail to [E
Re: resource usage overflow
At 2:48 PM -0800 2/16/03, Julian Elischer wrote: I think I could make a case for these figures being extended to 64 bits but: 1/ is it worth it? what uses them? Easier to drop them. 2/ are these mandated by any standard? would making them 64 bits break anything? 3/ would 64 bits be enough? We are getting both bigger and faster 64000 times faster and 64000 times bigger and we are back at seven seconds. 640 times faster and 640 times bigger and we are still only at 7 seconds (19 hours) before overflow. When we're at only 400 times faster and 400 times bigger, we can always decide to increase it again... -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1 (fwd)
On Mon, 17 Feb 2003, leafy wrote: > On Sun, Feb 16, 2003 at 10:28:25AM -0800, Steve Kargl wrote: > > > these apply to both world and ports. and the strange ld-elf.so.1 error > > > still ocurs. > > > > > > > I just built mozilla with gcc 3.2.2 without a problem. > > > > -- > > Steve > Mine does without any problem too. It's only uic which causes the error. (and >resulting in truss core dump) > If building KDE ports is the only thing you need - just move (temporarily) this plugin out of its dir. I know it isn'y a solution, but at least it works. BTW, it also works for some reason if you declare qCleanupImages_wizards() as static void qCleanupImages_wizards() instead of void qCleanupImages_wizards() in qmake_image_collection.cpp. Again, it's silly but for some reason it works. Designer dies later, though, if you add /usr/local/lib/kde3/plugins dir. But KDE itself works, once again. Any C++/QT gurus? Regards, Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
On Mon, Feb 17, 2003 at 08:28:58AM +0800, leafy wrote: > On Sun, Feb 16, 2003 at 10:28:25AM -0800, Steve Kargl wrote: > > > these apply to both world and ports. and the strange ld-elf.so.1 error > > > still ocurs. > > > > > > > I just built mozilla with gcc 3.2.2 without a problem. > > > Mine does without any problem too. It's only uic which causes the > error. (and resulting in truss core dump) > Use ktrace(1). -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
On Sun, Feb 16, 2003 at 10:28:25AM -0800, Steve Kargl wrote: > > these apply to both world and ports. and the strange ld-elf.so.1 error > > still ocurs. > > > > I just built mozilla with gcc 3.2.2 without a problem. > > -- > Steve Mine does without any problem too. It's only uic which causes the error. (and resulting in truss core dump) -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
On Sun, Feb 16, 2003 at 07:44:40PM +0100, Jens Rehsack wrote: > I'm not sure, but isn't the '-f' parameter required, if the portversion > didn't change but an upgrade should be forced? > > Jens Yes, I did a 'portupgrade -fra' several times. But it hits the same spot with the same error everytime. -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Console API related patch.
On Sun, Feb 16, 2003 at 09:45:28PM +0100, Poul-Henning Kamp wrote:
>
> I am trying to do some weird things with some custom console code and
> got stuck on the fact that our console code belives all consoles have
> a dev_t.
>
> This patch changes the API so that rather than pass a "dev_t" to the
> console functions, the "struct consdev *" is passed:
>
> -typedefvoidcn_putc_t(dev_t, int);
> +typedefvoidcn_putc_t(struct consdev *, int);
>
> The dev_t can still be gotten hold of:
>
>int
> -zs_cncheckc(dev_t dev)
> +zs_cncheckc(struct consdev *cp)
>{
> int s = spltty();
> - int c = zs_maygetc(zs_console_addr, minor(dev));
> + int c = zs_maygetc(zs_console_addr, minor(cp->cn_dev));
> splx(s);
> return c;
>}
I like this. On the ia64 branch I completely ignore the dev argument
and instead use a static softc. The dev_t is unknown until after
bus enumeration in principle anyway.
> The patch compiles and runs on all platforms I can currently test,
> but I'd like if some of you can give it a spin too:
>
> http://phk.freebsd.dk/patch/console.patch
>
> The patch just does the not quite mechanical switch, some of the drivers
> could get some mileage from the cn_arg field but I have not tried that.
I'll test ia64, both CVS an P4. Let me know when you like to
commit this so that I can schedule around that...
--
Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
On Mon, Feb 17, 2003 at 01:51:20 +0300, Andrey A. Chernov wrote: > properly). If you tune opiezed+pamified apps to work as you need, pure > opized stops working and vice versa. In this phrase I mean documented OPIE tuning of OPIE config files (old way), without any new additions and requirements, basically I mean old setups working for years. F.e. if you delete /etc/opieaccess (which is legal from OPIE point of view), you will be not able to log in locally via opiezed+pamified apps, but able with opiezed. (Remember, we talk about initial variant from des, now he fix situation and people who want to shoot their foot needs to remove default PAM configuration option "allow_local") -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 15:39:51 -0600, Juli Mallett wrote: > > Can you explain how this stops purely opieized apps from working? I was > under the impression the implicit case was still there, we just have a > more explicit contract with the OPIE system. This is not pure situation but mix with opiezed and opiezed+pamified apps families contradiction. Each of the families will produce different behaviour in the variant was commited initially by des (now he fix things properly). If you tune opiezed+pamified apps to work as you need, pure opizeded stops working and vice versa. I mean localhost handling. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
resource usage overflow
In the resource usage we have teh following values calculated.. longru_ixrss; /* integral shared memory size */ longru_idrss; /* integral unshared data " */ longru_isrss; /* integral unshared stack " */ in statclock() we have: ru->ru_ixrss += pgtok(vm->vm_tsize); ru->ru_idrss += pgtok(vm->vm_dsize); ru->ru_isrss += pgtok(vm->vm_ssize); in other words these ore incremented at the rate of statclock (for example 1kHz in not unheard of now). Assuming that I have a 600MB process (e.g. fsck doing a 1TB fileesyste uses 667MB in pass 1 alone). this means that the number of ticks we can count this amount of memory usage for is: 4E9/6E5 = 7.1E3 or 7100 ticks or, in the realworld (TM)... seven seconds if I am doing stats and profiling at 1kHz. I think I could make a case for these figures being extended to 64 bits but: 1/ is it worth it? what uses them? Easier to drop them. 2/ are these mandated by any standard? would making them 64 bits break anything? 3/ would 64 bits be enough? We are getting both bigger and faster 64000 times faster and 64000 times bigger and we are back at seven seconds. 640 times faster and 640 times bigger and we are still only at 7 seconds (19 hours) before overflow. Julian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
[developers@ removed from CC list] On Sun, Feb 16, 2003 at 07:55:49PM +0200, Ruslan Ermilov wrote: > On Sun, Feb 16, 2003 at 11:50:46AM +, Paul Richards wrote: > > Don't cross post current and developers. > > > > The developers charter says it's for internal management i.e. how we > > manage the project and not for discussing code issues. It's badly named, > > we should have called it something like "members" or "admin". > > > I must disagree. This message equally applies -current as well > as -developers; I was interested in hearing from both -current > users and ACPI developers, and developers are not guaranteed to > be subscribed to the -current mailing list, are they? I think anybody using -current is expected to be subscribed to -current. I think it follows that if you develop for -current that you at least be on -current (the commit bit is optional, the mailinglist subscription is not :-) Something like that. No written-down rules AFAICT, but just plain common sense. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Local repo: Perforce/CVS integration
* De: Chris BeHanna <[EMAIL PROTECTED]> [ Data: 2003-02-16 ] [ Subjecte: Local repo: Perforce/CVS integration ] > For those of you doing development with Perforce, could you talk a > little bit about how this is done? > > Do you do a cvsup nightly and import that on a vendor branch, then > integrate it into your working tree? (That sounds like it would work.) > Do you use cvs2p4? How about going in the other direction (from your > local branches back to the trunk?) > > I'm reasonably well-versed in both CVS and Perforce, and Perforce > just does merging *so* much better than CVS that'd I'd rather use it, > but I'd also rather crib from someone who has a process that's > working, rather than roll my own. FreeBSD has special great evil triggers which will import things into //depot/vendor/freebsd/src/... for example, and then we just branch off of there, and integ -b as needed. :) As for the CVS merge, I personally keep vendor/freebsd/src in my client view, as well, and use diff(1) to manually prepare both change diffs (modification) and additions, in whatever style I prefer. If it is just for review, I'd use diff2 :) Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: se7500+dual xeon?
On Fri, 7 Feb 2003, Victor Ponomarev wrote: > Thanks to all! > > As I wrote it's a my mistake with kernel installing. I should pay more > attention on upper part of dmesg ouput to > see that new kernel didn't install. > > By the way does anyone compare heavy load multiprocessor performance > 5.0-RELEASE and 4.7-STABLE? > Is it worth to upgrade a production machine? That's a matter of personal opinion. Though I haven't had any stability issues with -current on my UP and SMP hardware, it's generally bad mojo to put -current on a production machine. Regards, > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Local repo: Perforce/CVS integration
For those of you doing development with Perforce, could you talk a little bit about how this is done? Do you do a cvsup nightly and import that on a vendor branch, then integrate it into your working tree? (That sounds like it would work.) Do you use cvs2p4? How about going in the other direction (from your local branches back to the trunk?) I'm reasonably well-versed in both CVS and Perforce, and Perforce just does merging *so* much better than CVS that'd I'd rather use it, but I'd also rather crib from someone who has a process that's working, rather than roll my own. Thanks, -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
"David O'Brien" writes: > On Sun, Feb 16, 2003 at 07:11:49PM +, Mark Murray wrote: > > In the case where an application is OPIEised and not PAMised, we > > need to figure out something; PAMizing such apps is not terribly > > hard. If any of them are in the base system, then this situation > > is a bug in its own right. If they are ports, they need to fall in > > with FreeBSD/sysadmin policy. > > I'll state it again, because many don't seem to listen -- many of us > consider OPIEized, but not PAMized 3rd party ports a Good Thing. PAM is > nothing but a PITA, OPIE offers useful real functionality. David, This is not a failure to understand; it is a disagreement. I am asserting that PAM is the way FreeBSD is doing its authentication policy-setting. I am asserting that as a result of this applications need to comply, somehow. Right now, this is not hard. In future, it may get harder. DES has committed some PAM policy tweaks that make this possible. Bear in mind that PAM may leave you behind at some point; it is in the focus. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-STABLE Roadmap
On Sun, Feb 16, 2003 at 02:08:35PM -0700, Scott Long wrote: +> Pawel Jakub Dawidek wrote: +> +> >On Thu, Feb 13, 2003 at 08:28:43PM -0800, Sam Leffler wrote: +> >+> This can quickly turn into a bikeshed, but suggest ones. We're +> >looking for +> >+> good benchmarks. [...] +> > +> >Look at: +> > +> >http://www.web-polygraph.org +> > +> >It provides tests for www-cache/proxy stuff. +> >We can test many things with it: +> > +> >- how fast could we generate workload, +> >- how heavy load could we handle, +> >- how fast is squid running on FreeBSD, +> >- how fast is squid rewritten with libkse, +> >- etc. +> > +> >And this is good stablility test. +> >This is real good and free stuff, I use it on 4.x. +> > +> Thanks for the pointer, this looks very interesting. How hard +> is it to set up? [...] Setting it up is quite simple, but it doesn't compile with gcc 3.x... Authors of this stuff proposing to use it with FreeBSD 4.x, so it is well tested on out favorite system:) +> [...] DO you have any test configuations and/or +> scripts that we could adapt? Yes, on website kernel patches are avaliable for tunning, but for new releases of 4.x this isn't necessary, all could be configure with kernel options and sysctls (for 4.8): options MAXFILES=16384 options HZ=1000 options NMBCLUSTERS=32678 kern.ipc.somaxconn=1024 net.inet.ip.portrange.last=4 net.inet.tcp.delayed_ack=0 net.inet.tcp.msl=3000 Rest is quite simple/well documented. Tests in theory could be run on one machine, so... And some nice looking results generated by web-polygraph: Without any proxy: http://garage.freebsd.pl/pm3-15-11-2k2 With squid: http://garage.freebsd.pl/pm3-05-11-2k2 http://garage.freebsd.pl/pm3-06-11-2k2 With external proxy: http://garage.freebsd.pl/pm3-29-01-2k3 PS. I'm CC-ing this thread to one of polygraph's authors, he could be interested as well. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg52494/pgp0.pgp Description: PGP signature
Re: OPIE breakage: backout & patch for review
* De: "Andrey A. Chernov" <[EMAIL PROTECTED]> [ Data: 2003-02-16 ] [ Subjecte: Re: OPIE breakage: backout & patch for review ] > On Sun, Feb 16, 2003 at 19:11:49 +, Mark Murray wrote: > > > > In the case where an application is OPIEised and not PAMised, we > > need to figure out something; PAMizing such apps is not terribly > > hard. If any of them are in the base system, then this situation > > We are not in the situation to force users and admins to rewrite their > OPIE apps under new PAM framework. I always believe that non-destructive > for OPIE defaults (i.e. PAM only) solution is possible here, but not > being PAM specialist, can't demonstrate it. Recent des commits solve > problem correctly. Can you explain how this stops purely opieized apps from working? I was under the impression the implicit case was still there, we just have a more explicit contract with the OPIE system. -- Juli Mallett <[EMAIL PROTECTED]> - AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer - ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD - Never trust an ELF, COFF or Mach-O! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
On Sun, Feb 16, 2003 at 10:24:57AM -0800, David O'Brien wrote: > On Sun, Feb 16, 2003 at 07:55:49PM +0200, Ruslan Ermilov wrote: > > > Don't cross post current and developers. > > > > > > The developers charter says it's for internal management i.e. how we > > > manage the project and not for discussing code issues. It's badly named, > > > we should have called it something like "members" or "admin". > > > > > I must disagree. This message equally applies -current as well > > as -developers; > > It doesn't matter what you think -- this is our written down rules. > Please obey them. If you want to target both lists, sent the message out > twice -- once to each list. > OK, I stand corrected. I should have written to src-committers@. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg52493/pgp0.pgp Description: PGP signature
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 07:11:49PM +, Mark Murray wrote: > In the case where an application is OPIEised and not PAMised, we > need to figure out something; PAMizing such apps is not terribly > hard. If any of them are in the base system, then this situation > is a bug in its own right. If they are ports, they need to fall in > with FreeBSD/sysadmin policy. I'll state it again, because many don't seem to listen -- many of us consider OPIEized, but not PAMized 3rd party ports a Good Thing. PAM is nothing but a PITA, OPIE offers useful real functionality. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-STABLE Roadmap
Pawel Jakub Dawidek wrote: On Thu, Feb 13, 2003 at 08:28:43PM -0800, Sam Leffler wrote: +> This can quickly turn into a bikeshed, but suggest ones. We're looking for +> good benchmarks. [...] Look at: http://www.web-polygraph.org It provides tests for www-cache/proxy stuff. We can test many things with it: - how fast could we generate workload, - how heavy load could we handle, - how fast is squid running on FreeBSD, - how fast is squid rewritten with libkse, - etc. And this is good stablility test. This is real good and free stuff, I use it on 4.x. Thanks for the pointer, this looks very interesting. How hard is it to set up? DO you have any test configuations and/or scripts that we could adapt? Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 19:11:49 +, Mark Murray wrote: > > In the case where an application is OPIEised and not PAMised, we > need to figure out something; PAMizing such apps is not terribly > hard. If any of them are in the base system, then this situation We are not in the situation to force users and admins to rewrite their OPIE apps under new PAM framework. I always believe that non-destructive for OPIE defaults (i.e. PAM only) solution is possible here, but not being PAM specialist, can't demonstrate it. Recent des commits solve problem correctly. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Console API related patch.
I am trying to do some weird things with some custom console code and
got stuck on the fact that our console code belives all consoles have
a dev_t.
This patch changes the API so that rather than pass a "dev_t" to the
console functions, the "struct consdev *" is passed:
-typedefvoidcn_putc_t(dev_t, int);
+typedefvoidcn_putc_t(struct consdev *, int);
The dev_t can still be gotten hold of:
int
-zs_cncheckc(dev_t dev)
+zs_cncheckc(struct consdev *cp)
{
int s = spltty();
- int c = zs_maygetc(zs_console_addr, minor(dev));
+ int c = zs_maygetc(zs_console_addr, minor(cp->cn_dev));
splx(s);
return c;
}
But in addition to this I have added a driver-private element to the
consdev structure for other needs:
+ void*cn_arg;/* drivers method argument */
The patch compiles and runs on all platforms I can currently test,
but I'd like if some of you can give it a spin too:
http://phk.freebsd.dk/patch/console.patch
The patch just does the not quite mechanical switch, some of the drivers
could get some mileage from the cn_arg field but I have not tried that.
Thanks in advance,
Poul-Henning
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
SecureRPC/NFS, kerberized NFS
Hello. My question is very simple. Does FreeBSD, either 4.7/4.8 or 5.0 support SecureRPC, especially SecureNFS? I found the keyserv facility, installed the databases and read some note in mknetid(8): -n netid_file Specify the location of the netid information file. The com- piled-in default is /etc/netid. Note that no error is generated if the netid database can't be found. The netid database is not likely to be present on most systems until Secure RPC support is added to FreeBSD. For me that sounds like FreeBSD does not have SecureRPC support and therefore no SecureNFS support. My intention is that I wish to setup a secure NFS environment with FreeBSD's basics and had neither success with SecureRPC nor KERBEROS V. In that part FreeBSD lacks in appropriate documentation, but may netsources told that securing via SecureRPC and/or kerberos should be possible. Can someone give me a hint or confirm the lack of SecureRPC in recent FreeBSD versions? Thanks in advance, Oliver -- MfG O. Hartmann [EMAIL PROTECTED] -- IT-Administration des Institutes fuer Physik der Atmosphaere (IPA) -- Johannes Gutenberg Universitaet Mainz Becherweg 21 55099 Mainz Tel: +496131/3924662 (Maschinenraum) Tel: +496131/3924144 (Buero) FAX: +496131/3923532 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LukemFTP and command-line multiple downloads
On 14-Feb-2003 Kris Kennaway wrote:
| On Fri, Feb 14, 2003 at 03:37:49PM -0800, Kris Kennaway wrote:
|> On Fri, Feb 14, 2003 at 03:34:06PM -0800, Kris Kennaway wrote:
|> > Since upgrading bento to running 5.0, it appears that I can no longer
|> > download multiple files from a FTP server by specifying a glob
|> > pattern
|> > on the command-line:
|> >
|> > e.g.
|> >
|> > /usr/bin/ftp -4a
|> > ftp://snapshots.jp.freebsd.org/pub/FreeBSD/snapshots/alpha/5-LATEST/ba
|> > se/base.\?\?
|>
|> This appears to work (as it used to) under 4.x.
|
| It was pointed out to me that this is because 5.0 now uses
| lukemftp..can the maintainers please look into this ASAP? In the
| meantime I'll have to stick with the older 5.0 ftp client.
|
Try the attached patch. If this works for you I'll pass it on to Luke.
Mike
--
Mike Heffner
<[EMAIL PROTECTED]>
Index: fetch.c
===
RCS file: /cvs/ncvs/src/contrib/lukemftp/src/fetch.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 fetch.c
--- fetch.c 15 Jun 2002 09:40:34 - 1.1.1.3
+++ fetch.c 16 Feb 2003 19:47:46 -
@@ -1372,7 +1372,7 @@
dir ? dir : "", file ? file : "");
dirhasglob = filehasglob = 0;
- if (doglob && urltype == CLASSIC_URL_T) {
+ if (doglob && (urltype == CLASSIC_URL_T || urltype == FTP_URL_T)) {
if (! EMPTYSTRING(dir) && strpbrk(dir, "*?[]{}") != NULL)
dirhasglob = 1;
if (! EMPTYSTRING(file) && strpbrk(file, "*?[]{}") != NULL)
Re: OPIE breakage: backout & patch for review
"David O'Brien" writes: > > With a suitable "HEADS UP!" and appropriate changes to the documentation, > > might is be possible to move _all_ policy control into PAM, instead of > > having it split between OPIE and PAM? > > Nope. What about opieized, but not pamized applications? > OPIE needs to act on FreeBSD like it does on every other Unix platform. > It really does seem like DES is chaning existing practice. Changing existing practice is what I'm asking about. If there is a particular policy on a FreeBSD box, then OPIE should really be falling in with that, no? In the case where an application is OPIEised and not PAMised, we need to figure out something; PAMizing such apps is not terribly hard. If any of them are in the base system, then this situation is a bug in its own right. If they are ports, they need to fall in with FreeBSD/sysadmin policy. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
enhancements for libradius - commiter wanted
Hi,
I already tried some weeks ago to find (at [EMAIL PROTECTED]) someone who
can review and commit this code, but nobody replied, so I try it again:
I made the radius integration for mpd. During this work I missed some
functions in libradius.
Here is a short changelog:
- added rad_demangle for demangling user-passwords (needed for MS-CHAPv1
MPPE-keys).
- added rad_demangle_mppe_key for demangling mppe-keys (needed for
MS-CHAPv2 MPPE-keys).
- added some typecasts to avoid compilation warnings
- if the programmer has not called rad_create_request() but rad_put_*,
then a weird error message was returned => fixed.
The rad_demangle_mppe_key function was taken from userland ppp.
I also opened a pr:
http://www.freebsd.org/cgi/query-pr.cgi?pr=46555
bye,
--
--- -
Michael Bretterklieber- [EMAIL PROTECTED]
JAWA Management Software GmbH - http://www.jawa.at
Liebenauer Hauptstr. 200-- privat ---
A-8041 GRAZ GSM: ++43-(0)676-93 96 698
Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED]
Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com
--- -
"...the number of UNIX installations has grown to 10, with more
expected..." - Dennis Ritchie and Ken Thompson, June 1972
diff -u libradius/Makefile libradius_new/Makefile
--- libradius/Makefile Mon Dec 23 16:07:51 2002
+++ libradius_new/Makefile Sat Jan 4 23:25:13 2003
@@ -31,7 +31,7 @@
DPADD+=${LIBMD}
LDADD+=-lmd
SHLIB_MAJOR= 1
-SHLIB_MINOR= 0
+SHLIB_MINOR= 1
MAN= libradius.3 radius.conf.5
.include
diff -u libradius/radlib.c libradius_new/radlib.c
--- libradius/radlib.c Sat Jan 4 23:26:58 2003
+++ libradius_new/radlib.c Sat Jan 4 23:24:46 2003
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -243,7 +244,7 @@
sizeof srvp->addr.sin_addr);
}
if (port != 0)
- srvp->addr.sin_port = htons(port);
+ srvp->addr.sin_port = htons((u_short)port);
else {
struct servent *sent;
@@ -513,11 +514,12 @@
for (i = 0; i < LEN_AUTH; i += 2) {
long r;
r = random();
- h->request[POS_AUTH+i] = r;
- h->request[POS_AUTH+i+1] = r >> 8;
+ h->request[POS_AUTH+i] = (u_char)r;
+ h->request[POS_AUTH+i+1] = (u_char)(r >> 8);
}
h->req_len = POS_ATTRS;
clear_password(h);
+ h->request_created = 1;
return 0;
}
@@ -569,7 +571,7 @@
}
type = h->response[h->resp_pos++];
*len = h->response[h->resp_pos++] - 2;
- if (h->resp_pos + *len > h->resp_len) {
+ if (h->resp_pos + (int)*len > h->resp_len) {
generr(h, "Malformed attribute in response");
return -1;
}
@@ -671,6 +673,7 @@
h->pass_pos = 0;
h->chap_pass = 0;
h->type = RADIUS_AUTH;
+h->request_created = 0;
}
return h;
}
@@ -703,6 +706,11 @@
{
int result;
+ if (!h->request_created) {
+ generr(h, "Please call rad_create_request()");
+ return -1;
+}
+
if (type == RAD_USER_PASSWORD)
result = put_password_attr(h, type, value, len);
else {
@@ -892,6 +900,11 @@
struct vendor_attribute *attr;
int res;
+ if (!h->request_created) {
+ generr(h, "Please call rad_create_request()");
+ return -1;
+}
+
if ((attr = malloc(len + 6)) == NULL) {
generr(h, "malloc failure (%d bytes)", len + 6);
return -1;
@@ -945,3 +958,122 @@
return (h->servers[h->srv].secret);
}
+int
+rad_demangle(struct rad_handle *h, const void *mangled, size_t mlen, u_char
+*demangled)
+{
+ char R[LEN_AUTH];
+ const char *S;
+ int i, Ppos;
+ MD5_CTX Context;
+ u_char b[16], *C;
+
+ if ((mlen % 16 != 0) || (mlen > 128)) {
+ generr(h, "Cannot interpret mangled data of length %ld", (u_long)mlen);
+ return -1;
+ }
+
+ C = (u_char *)mangled;
+
+ /* We need the shared secret as Salt */
+ S = rad_server_secret(h);
+
+ /* We need the request authenticator */
+ if (rad_request_authenticator(h, R, sizeof R) != LEN_AUTH) {
+ generr(h, "Cannot obtain the RADIUS request authenticator");
+return -1;
+ }
+
+ MD5Init(&Context);
+ MD5Update(&Context, S, strlen(S));
+ MD5Update(&Context, R, LEN_AUTH);
+ MD5Final(b, &Context);
+ Ppos = 0;
+ while (mlen) {
+
+ mlen -= 16;
+ for (i = 0; i < 16; i++)
+ demangled[Ppos++] = C[i] ^ b[i
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 03:48:20PM +, Mark Murray wrote: > "Andrey A. Chernov" writes: > > On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote: > > > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > > > > Admins with no /etc/opieaccess AFFECTED! > > > > > > Admins with no /etc/opieaccess IDIOTS for not running mergemaster! > > > > Moreover, admins WITH old /etc/opieaccess (i.e. without your line) > > are affected too! Local logins becomes mysteriosly disabled for their > > users. > > With a suitable "HEADS UP!" and appropriate changes to the documentation, > might is be possible to move _all_ policy control into PAM, instead of > having it split between OPIE and PAM? Nope. What about opieized, but not pamized applications? OPIE needs to act on FreeBSD like it does on every other Unix platform. It really does seem like DES is chaning existing practice. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
On Sun, Feb 16, 2003 at 08:29:21PM +0900, Makoto Matsushita wrote: > > It seems that our kenrel for kern.flp does not fit again :-( Why oh why, doesn't the tenderbox do "make release" instead of just "make buildworld"??? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
leafy wrote: > I rebuilt and installed world on Friday and reinstalled ALL my ports with >'portupgrade -ra'. I have found the exact line that will trigger the ld "undefined >symbol" error. > > /usr/X11R6/bin/uic -nounload -tr tr2i18n -i htmlpageinfo.h ./htmlpageinfo.ui > >htmlpageinfo.cc.temp ; ret=$?; sed -e "s,tr2i18n( \"\" ),QString::null,g" >htmlpageinfo.cc.temp | sed -e "s,tr2i18n( \"\"\, \"\" ),QString::null,g" | sed -e >"s,image\([0-9][0-9]*\)_data,img\1_htmlpageinfo,g" >> htmlpageinfo.cc ; rm -f >htmlpageinfo.cc.temp ; if test "$ret" = 0; then echo '#include "htmlpageinfo.moc"' >>>htmlpageinfo.cc; else rm -f htmlpageinfo.cc ; exit $ret ; fi > > Error is: > /usr/libexec/ld-elf.so.1: /usr/X11R6/plugins/designer/libwizards.so: Undefined >symbol "_Z22qCleanupImages_wizardsv" > > Grepping the corresponding library: > leafy@leafy:/usr/X11R6/plugins/designer$ nm libwizards.so |grep Z22 > 000256f0 T _Z22qCleanupImages_wizardsv > > So ld is not finding a symbol which is in the correct library. > > Jiawei Ye > I'm not sure, but isn't the '-f' parameter required, if the portversion didn't change but an upgrade should be forced? Jens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5-STABLE Roadmap
On Thu, Feb 13, 2003 at 08:28:43PM -0800, Sam Leffler wrote: +> This can quickly turn into a bikeshed, but suggest ones. We're looking for +> good benchmarks. [...] Look at: http://www.web-polygraph.org It provides tests for www-cache/proxy stuff. We can test many things with it: - how fast could we generate workload, - how heavy load could we handle, - how fast is squid running on FreeBSD, - how fast is squid rewritten with libkse, - etc. And this is good stablility test. This is real good and free stuff, I use it on 4.x. -- Pawel Jakub Dawidek UNIX Systems Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am. msg52484/pgp0.pgp Description: PGP signature
UFS/SOFTUPDATE inconsistency
[root@southcross root]# fsck /dev/ad0s1e ** /dev/ad0s1e (NO WRITE) ** Last Mounted on /usr ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames MISSING '.' I=667872 OWNER=root MODE=40755 SIZE=512 MTIME=Feb 10 16:54 2003 DIR=/ports/cad/gwave UNEXPECTED SOFT UPDATE INCONSISTENCY CANNOT FIX, FIRST ENTRY IN DIRECTORY CONTAINS files UNEXPECTED SOFT UPDATE INCONSISTENCY ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FREE BLK COUNT(S) WRONG IN SUPERBLK SALVAGE? no SUMMARY INFORMATION BAD SALVAGE? no BLK(S) MISSING IN BIT MAPS SALVAGE? no 209599 files, 1970937 used, 2594963 free (52235 frags, 317841 blocks, 1.1% fragm entation) [root@southcross root]# any on how to fix it? -- Paolo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI error
from my dmesg: [snip] acpi0: on motherboard ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31 Using $PIR table, 6 entries at 0xc00f1a70 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 [snip] but at the end: [snip] acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ACPI-1287: *** Error: Method execution failed, AE_AML_UNINITIALIZED_ELEMENT [snip] -- Paolo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
On Sun, Feb 16, 2003 at 01:04:33PM +0800, leafy wrote: > On Sun, Feb 16, 2003 at 02:09:24AM +0800, leafy wrote: > > Grepping the corresponding library: > > leafy@leafy:/usr/X11R6/plugins/designer$ nm libwizards.so |grep Z22 > > 000256f0 T _Z22qCleanupImages_wizardsv > > > > So ld is not finding a symbol which is in the correct library. > > > > Jiawei Ye > 1. no CPU optimization used > 2. no extra CFLAGS > 3. no extra CXXFLAGS > > these apply to both world and ports. and the strange ld-elf.so.1 error > still ocurs. > I just built mozilla with gcc 3.2.2 without a problem. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
On Sun, Feb 16, 2003 at 07:55:49PM +0200, Ruslan Ermilov wrote: > > Don't cross post current and developers. > > > > The developers charter says it's for internal management i.e. how we > > manage the project and not for discussing code issues. It's badly named, > > we should have called it something like "members" or "admin". > > > I must disagree. This message equally applies -current as well > as -developers; It doesn't matter what you think -- this is our written down rules. Please obey them. If you want to target both lists, sent the message out twice -- once to each list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libaddr2line: what is FreeBSD analog ?
Maybe anyone will enlighten me: I am working with the port lang/gnat (Ada compiler) and it links with nonexistent libaddr2line (symbol convert_addresses) to find the line numbers from executables. Where to look for the correct way to resolve addresses to line numbers in FreeBSD ? Thanx, Yuri. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
On Sun, Feb 16, 2003 at 11:50:46AM +, Paul Richards wrote: > Don't cross post current and developers. > > The developers charter says it's for internal management i.e. how we > manage the project and not for discussing code issues. It's badly named, > we should have called it something like "members" or "admin". > I must disagree. This message equally applies -current as well as -developers; I was interested in hearing from both -current users and ACPI developers, and developers are not guaranteed to be subscribed to the -current mailing list, are they? > On Sat, 2003-02-15 at 02:49, Ruslan Ermilov wrote: > > ACPI thermal panics my ThinkPad 600X, is anyone > > interested in a crash dump analysis? > > > > > > Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg52478/pgp0.pgp Description: PGP signature
Re: ACPI thermal panics ThinkPad 600X
On Sun, Feb 16, 2003 at 05:45:42PM +0100, Wiktor Niesiobedzki wrote: > On Sat, Feb 15, 2003 at 11:16:12PM +0200, Ruslan Ermilov wrote: > > Me being dumb. Forgot to comment out the apm "disabled" hint > > in /boot/device.hints. Still, scary things happen after > > resuming from zzz(8). "ata1: resetting devices..." forever. > > > Did you happen to have: > options AUTO_EOI_1 > in your kernel configuration? > No. It says something about the temperature exceeding the system limit and barfs. I thought I'd better live with APM for the time being rather than with ACPI without thermal -- I noticed that the cooler isn't so active without it. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg52477/pgp0.pgp Description: PGP signature
login_cap(3) for lukemftpd (resource limit, MAC support ...)
Hello David, hello list!
According to a thread about lukemftpd several months ago, there are
several points speaking against lukemftpd in the base system,
- missing PAM
- missing login_cap
were the main arguments against lukemftpd, as far I can remember.
In the meantime, David has incorporated a patch for supporting PAM.
So I started to take some code bits from the original ftpd to add
login_cap support and to activate wtmp/utmp support in lukemftpd.
You can find the patches (against 5-CURRENT) attached to this mail.
Regards,
/\/\ichael Ranner
[EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED]
--
JAWA Management Software GmbH - http://www.jawa.at/
Liebenauer Hauptstrasse 2oo - A-8041 Graz
Tel +43 316 403274 21 - Fax +43 316 403274 10
--
Mariazell Online - http://www.mariazell.at/
--
-BEGIN GEEK CODE BLOCK-
GIT/CS/AT dx(-) s+:(++:) a- C++ UBLVS$ P++>+++$ L-(+)$ E---
W+++$ N+(++) o-- K- w--()$ O-(--) M@ V-(--) PS+>++ PE(-) Y+ PGP(-)
t+ 5+ X+++() R* tv++ b+(++) DI++ D-(--) G- e h--(*) r++ y?
--END GEEK CODE BLOCK--
--- Makefile.orig Sun Feb 16 15:35:58 2003
+++ Makefile Sun Feb 16 15:29:34 2003
@@ -9,7 +9,7 @@
PROG= lukemftpd
MAN= lukemftpd.8 ftpd.conf.5 ftpusers.5
MLINKS= ftpusers.5 ftpchroot.5
-SRCS= cmds.c conf.c ftpd.c ftpcmd.y popen.c
+SRCS= cmds.c conf.c ftpd.c ftpcmd.y logutmp.c logwtmp.c popen.c
SRCS+= strsuftoll.c
WFORMAT= 0
@@ -28,7 +28,7 @@
DPADD+= ${LIBM}
LDADD+= -lm
-CFLAGS+= -DUSE_OPIE -DUSE_PAM
+CFLAGS+= -DUSE_OPIE -DUSE_PAM -DSUPPORT_UTMP -DLOGIN_CAP
DPADD+= ${LIBOPIE} ${LIBPAM}
LDADD+= -lopie -lpam
--- src/logutmp.c.old Sat May 26 16:07:13 2001
+++ src/logutmp.c Sat May 26 16:07:39 2001
@@ -45,7 +45,7 @@
*/
void
-login(const UTMP *ut)
+ftpd_login(const UTMP *ut)
{
UTMP ubuf;
@@ -85,7 +85,7 @@
}
int
-logout(const char *line)
+ftpd_logout(const char *line)
{
UTMP ut;
int rval;
--- src/logwtmp.c.orig Sun Feb 16 14:56:13 2003
+++ src/logwtmp.c Sun Feb 16 17:24:20 2003
@@ -73,7 +73,7 @@
* after login, but before logout).
*/
void
-logwtmp(const char *line, const char *name, const char *host)
+ftpd_logwtmp(const char *line, const char *name, const char *host)
{
struct utmp ut;
struct stat buf;
171a172,174
> #ifdef LOGIN_CAP
> #include
> #endif
979c982
< login(&utmp);
---
> ftpd_login(&utmp);
982c985
< logwtmp(line, name, host);
---
> ftpd_logwtmp(line, name, host);
996c999
< okwtmp = logout(ttyline) & dowtmp;
---
> okwtmp = ftpd_logout(ttyline) & dowtmp;
1004c1007
< logwtmp(ttyline, "", "");
---
> ftpd_logwtmp(ttyline, "", "");
1031a1035,1039
> #ifdef LOGIN_CAP
> setusercontext(NULL, getpwuid(0), (uid_t)0,
> LOGIN_SETPRIORITY|LOGIN_SETRESOURCES|LOGIN_SETUMASK|
> LOGIN_SETMAC);
> #endif
1045a1054,1056
> #ifdef LOGIN_CAP
> login_cap_t *lc = NULL;
> #endif
1156a1168,1195
>
> #ifdef LOGIN_CAP
> if ((lc = login_getpwclass(pw)) != NULL) {
> char remote_ip[MAXHOSTNAMELEN];
>
> getnameinfo((struct sockaddr *)&his_addr, his_addr.su_len,
> remote_ip, sizeof(remote_ip) - 1, NULL, 0,
> NI_NUMERICHOST);
> remote_ip[sizeof(remote_ip) - 1] = 0;
> if (!auth_hostok(lc, remotehost, remote_ip)) {
> syslog(LOG_INFO|LOG_AUTH,
> "FTP LOGIN FAILED (HOST) as %s: permission denied.",
> pw->pw_name);
> reply(530, "Permission denied.\n");
> pw = NULL;
> return;
> }
> if (!auth_timeok(lc, time(NULL))) {
> reply(530, "Login not available right now.\n");
> pw = NULL;
> return;
> }
> }
> setusercontext(lc, pw, (uid_t)0,
> LOGIN_SETPRIORITY|
> LOGIN_SETRESOURCES|LOGIN_SETUMASK|LOGIN_SETMAC);
> #endif
>
1349a1389,1391
> #ifdef LOGIN_CAP
> login_close(lc);
> #endif
1353a1396,1398
> #ifdef LOGIN_CAP
> login_close(lc);
> #endif
Re: ACPI: working ACPI vs broken ACPI
On Sat, Feb 15, 2003 at 08:27:45PM -0600, Mike Silbersack wrote the words in effect of: > > On Sat, 15 Feb 2003, Martin Blapp wrote: > > > Feb 13 17:41:05 ibm-01 kernel: ACPI-0625: *** Info: GPE Block0 defined as GPE0 > > to GPE31 > > Feb 13 17:41:05 ibm-01 kernel: ACPI-0625: *** Info: GPE Block1 defined as GPE32 > > to GPE63 > > I see similar errors on my Presario 2100US... > > > Wild guess: Seem to result from this. If I'm looking at NetBSD's > > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/acpi/acpi_ec.c they > > have a lot done since they took acpi from us. I'm sure it works > > for netbsd. > > > > Is anybody working on this ? > > > > Martin > > I've been trying to load that URL since yesterday, but it's not working > from here. Can you elaborate on what it does? Try the following URL: - http://cvsweb.no.netbsd.org/bsdweb.cgi/src/sys/dev/acpi/acpi_ec.c Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ia64 tinderbox failure
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
> fstab: /etc/fstab:0: No such file or directory > /dev/md1c: 1.4MB (2880 sectors) block size 4096, fragment size 512 > using 1 cylinder groups of 1.41MB, 360 blks, 32 inodes. > super-block backups (for fsck -b #) at: > 32 > + mount /dev/md1c /mnt > + [ -d /R/stage/image.kern ] > + set -e > + cd /R/stage/image.kern > + find+ cpio -dump . -print /mnt > > cpio: write error: No space left on device > *** Error code 1 > (End quote) > What about moving the slip driver (sl) to the drivers floppy? I know its not much, but it is enough to make things fit on the floppy again. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
On Sat, Feb 15, 2003 at 11:16:12PM +0200, Ruslan Ermilov wrote: > Me being dumb. Forgot to comment out the apm "disabled" hint > in /boot/device.hints. Still, scary things happen after > resuming from zzz(8). "ata1: resetting devices..." forever. > Did you happen to have: options AUTO_EOI_1 in your kernel configuration? Cheers, Wiktor Niesiobedzki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
"Andrey A. Chernov" writes: > On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote: > > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > > > Admins with no /etc/opieaccess AFFECTED! > > > > Admins with no /etc/opieaccess IDIOTS for not running mergemaster! > > Moreover, admins WITH old /etc/opieaccess (i.e. without your line) > are affected too! Local logins becomes mysteriosly disabled for their > users. With a suitable "HEADS UP!" and appropriate changes to the documentation, might is be possible to move _all_ policy control into PAM, instead of having it split between OPIE and PAM? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
On Sun, Feb 16, 2003 at 02:28:52PM +0800, leafy wrote: > /usr/X11R6/bin/uic -i htmlpageinfo.h ./htmlpageinfo.ui > In my attemp to 'truss' the above line, I get a truss.core instead. backtrace as follows: Core was generated by `truss'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libc.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libc.so.5 Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)... done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 0x280bf8b3 in kill () from /usr/lib/libc.so.5 (gdb) backtrace #0 0x280bf8b3 in kill () from /usr/lib/libc.so.5 #1 0x0804932c in free () #2 0x08048d15 in free () (gdb) -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 5, Samba and ACL support
On Fri, Feb 14, 2003 at 03:37:50PM -0800, Terry Lambert wrote the words in effect of: > "local.freebsd.current" wrote: > > I've been hanging on for a production-ready FreeBSD which > > supports ACLs so I can replace an NFS server and an NT > > fileserver with one box which can do both. > > > > Changing company circumstances mean that I am forced to > > look to doing that now, rather than waiting for 5.1 or > > 5.2. > > > > So I'd appreciate feedback from anyone who is using 5.0 > > as a Samba server with ACL support - is it indistinguishable > > from an NT fileserver from the client POV? > > ACLs in UFS are not the same thing as ACLs in NT, they are > POSIX ACLs, implement as part of MAC (Mandatory Access Controls) > requirements. > > Do not expect them to interoperate with Samba as if Samba were > an NT server that supported NT ACLs. > > Same thing for ACLs in Linux and other UNIX OS's, BTW: they > tend to comply with the POSIX standard, not with the NT stuff, > for which I don't think there is a published standard (only > documentation). Erm, Terry, I think jedgar@ got ACL's working with Windows NT and so did I (think) in one of my Samba+ACL's test. Please check the following URL(s) regarding Samba+ACLs: - http://people.freebsd.org/~jedgar/ACL/ - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/fs-acl.html - http://samba.mirror.ac.uk/samba/whatsnew/samba-2.2.6.html Samba 2.2.6 should work with ACLs with an 'external patch'. See it's release notes for more information. Hope that helps. Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0 RELEASE ISO problems
I decided to test the 5.0 ISO today. It turned out bad. I have a dual PIII 800MHz with an Advansys SCSI controller with two Plextor CD drives. The reader drive is device 0,6,0 and the writer drive is device 0,4,0. I can boot the CD from the reader drive but when it gets to the part where it's going to load the kernel I get an error saying the kernel could not be found. I decided to create a floppy instead. I used the floppy images from the CD and created kern and mfsroot. I booted and went to the configuration part. After the partitioning I was asked if where I wanted to install from. I went for FTP via firewall and tried to get an IPv6 address from my router - no luck. The router works and I when I use freebsd current on my other disk there are no problems with IPv6. So I went on with normal IPv4. After saying yes to the fact that I 'really' wanted to go on the installer tries to create the filesystem. Somehow it decides to look for device '/dev/X' and fails. After this I rebooted... The motherboard is an Asus P2B-D and the disk is a Seagate IV 80GB IDE. Motherboard BIOS revision is 1013. I hope this helps those creating the ISO's. Sven Esbjerg -- Fight Internet Censorship! http://www.eff.org ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Libalias Corruption
I've had a weird problem since installing 5-CURRENT on my gateway, traffic originating from the gateway is fine, as is UDP from the unregistered network behind it, however, TCP traffic from the unregistered network is dropped. It seems that natd/libalias is corrupting the tcp header. The firewall works fine, and I have IPFW and divert sockets compiled into the kernel. The same behaviour is exhibited regardless of whether I have my own firewall rules loaded, or am using 'sh /etc/rc.firewall open'. Outputs below: picard# uname -a FreeBSD picard.dyn.newmillennium.net.au 5.0-CURRENT FreeBSD 5.0-CURRENT #11: Sat Feb 15 17:51:58 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PICARD i386 picard# netstat -s | grep 'bad header checksums' Warning: sysctl(net.inet6.ip6.rip6stats): No such file or directory 49 bad header checksums picard# tcpdump -i rl2 host dhcp-194.nmn.cafn (FTP from windows box behind the gateway) 23:11:55.075298 dhcp-194.nmn.cafn.1047 > ftp.beastie.tdk.net.ftp: S 2949494356:2949494356(0) win 64240 (DF) 23:11:58.076300 dhcp-194.nmn.cafn.1047 > ftp.beastie.tdk.net.ftp: S 2949494356:2949494356(0) win 64240 (DF) 23:12:04.085186 dhcp-194.nmn.cafn.1047 > ftp.beastie.tdk.net.ftp: S 2949494356:2949494356(0) win 64240 (DF) picard# tcpdump -i tun0 23:11:55.075912 ppp82.act.padsl.internode.on.net.1047 > ftp.beastie.tdk.net.ftp: S 2949494356:2949494356(0) win 64240 (DF) 23:11:55.699558 ftp.beastie.tdk.net.ftp > ppp82.act.padsl.internode.on.net.1047: S 1498138710:1498138710(0) ack 2949494357 win 57344 (DF) 23:11:58.076850 ppp82.act.padsl.internode.on.net.1047 > ftp.beastie.tdk.net.ftp: S 2949494356:2949494356(0) win 64240 (DF) 23:11:58.652724 ftp.beastie.tdk.net.ftp > ppp82.act.padsl.internode.on.net.1047: S 1498138710:1498138710(0) ack 2949494357 win 57344 (DF) 23:11:58.653300 ftp.beastie.tdk.net.ftp > ppp82.act.padsl.internode.on.net.1047: S 1498138710:1498138710(0) ack 2949494357 win 57344 (DF) .23:12:04.085667 ppp82.act.padsl.internode.on.net.1047 > ftp.beastie.tdk.net.ftp: S 2949494356:2949494356(0) win 64240 (DF) 23:12:04.585676 ftp.beastie.tdk.net.ftp > ppp82.act.padsl.internode.on.net.1047: S 1498138710:1498138710(0) ack 2949494357 win 57344 (DF) 23:12:04.664324 ftp.beastie.tdk.net.ftp > ppp82.act.padsl.internode.on.net.1047: S 1498138710:1498138710(0) ack 2949494357 win 57344 (DF) 23:12:16.672935 ftp.beastie.tdk.net.ftp > ppp82.act.padsl.internode.on.net.1047: S 1498138710:1498138710(0) ack 2949494357 win 57344 (DF) picard# netstat -s | grep 'bad header checksums' 55 bad header checksums -- Alastair D'Silva mob: 0413 485 733 Networking Consultant fax: 0413 181 661 New Millennium Networking web: http://www.newmillennium.net.au To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
Sorry for spamming again. matusita> Ok, we have to shrink at least 7kbytes of kernel on kern.flp. If you are serious about this, attached below is a current kernel configuration file for kern.flp kernel named BOOTMFS (attention: it is only just for boot floppy, not GENERIC nor default installed kernel). Anybody knows what happen if _KPOSIX_PRIORITY_SCHEDULING is removed? -- - Makoto `MAR' Matsushita # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.376 2003/02/13 22:24:43 obrien Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident BOOTMFS #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. options SCHED_4BSD #4BSD scheduler options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options MD_ROOT #MD is a potential root device options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev # output. Adds ~128k to driver. # output. Adds ~215k to driver. # Debugging for use in -current # To make an SMP kernel, the next two are needed #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives options ATA_STATIC_ID #Static device numbering # SCSI Controllers device ahb # EISA AHA1742 family device ahc # AHA2940 and onboard AIC7xxx devices device ahd # AHA39320/29320 and onboard AIC79xx devices device amd # AMD 53C974 (Tekram DC-390(T)) device isp # Qlogic family device mpt # LSI-Logic MPT-Fusion #device ncr # NCR/Symbios Logic device sym # NCR/Symbios Logic (newer chipsets + those of `ncr') device trm # Tekram DC395U/UW/F DC315U adapters device adv # Advansys SCSI adapters device adw # Advansys wide SCSI adapters device aha # Adaptec 154x SCSI adapters device aic # Adaptec 15[012]x SCSI adapters, AIC-6[23]60. device bt # Buslogic/Mylex MultiMaster SCSI adapters device ncv # NCR 53C500 device nsp # Workbit Ninja SCSI-3 device stg # TMC 18C30/18C50 # RAID controllers interfaced to the SCSI subsystem device asr # DPT SmartRAID V, VI and Adaptec SCSI RAID device ciss# Compaq Smart RAID 5* device dpt # DPT Smartcache III, IV - See NOTES for options! device iir # Intel Integrated RAID # SCSI peripherals device scbus # SCSI bus (required) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD # RAID controllers device aac # Adaptec FSA RAID device aacp# SCSI passthrough for aac (requires CAM) device ida # Compaq Smart RAID device pst # Promise Supertrak SX6000 # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote: > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > > Admins with no /etc/opieaccess AFFECTED! > > Admins with no /etc/opieaccess IDIOTS for not running mergemaster! Moreover, admins WITH old /etc/opieaccess (i.e. without your line) are affected too! Local logins becomes mysteriosly disabled for their users. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI thermal panics ThinkPad 600X
Don't cross post current and developers. The developers charter says it's for internal management i.e. how we manage the project and not for discussing code issues. It's badly named, we should have called it something like "members" or "admin". On Sat, 2003-02-15 at 02:49, Ruslan Ermilov wrote: > ACPI thermal panics my ThinkPad 600X, is anyone > interested in a crash dump analysis? > > > Cheers, -- Paul Richards <[EMAIL PROTECTED]> FreeBSD Services Ltd To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 12:16:27 +0100, Dag-Erling Smorgrav wrote: > > My message <[EMAIL PROTECTED]> dated 2003-02-16 > 00:46:27 CET contained all the information you needed. If you mean that quote from it: "This behaviour was very surprising to people who wanted to prevent OPIE users from using their passwords even locally." The answer was obvious - such people should read OPIE documentation to not be so surprised. I don't think that people who not read docs is "information I need". > Do you really think that your hysterical reaction, bombarding me with > message upon incriminatory message and completely ignoring what I say I not bombarding you, I answer sequentally on each message and many of them comes when I write answer. About ignoring, I see situation, like you ignore me. BTW, do you ever think that "bombarding" and "ignoring" terms can't co-exist, they are oppisite? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD/i386 kern.flp flooding again
Ouch.. matusita> % gzip loader I've forgotten that this loader is already kgzip(8)ed, ignore me. Sorry. Ok, we have to shrink at least 7kbytes of kernel on kern.flp. -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes: >> Please take this to private email. > >I not see enough good will from des side for it. Then please just stop. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 11:21:15 +, Mark Murray wrote: > > Does the ""-as-localhost-alias break other PAM modules? No, it is local variable for that module. > In what way does "localhost" or NULL break OPIE? Look into any pre-PAM code which use OPIE, like login code. Host (rhost) is only set to some name for non-local logins. Local logins set it to "" The comment in the OPIE accessfile.c confirms it too. If you set host to "localhost" or NULL, it not recognized as localhost inside OPIE code, i.e. in the accessfile.c, so some functionality (like always allowing localhost) will be lost. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
FreeBSD/i386 kern.flp flooding again
It seems that our kenrel for kern.flp does not fit again :-( (Quote from "make release" logfile) + mdconfig -a -t vnode -f /R/stage/floppies/kern.flp + MDDEVICE=md1 + [ ! -c /dev/md1 ] + disklabel -w -B -b /R/stage/trees/base/boot/boot md1 fd1440 + newfs -i 8 -o space -m 0 /dev/md1c fstab: /etc/fstab:0: No such file or directory /dev/md1c: 1.4MB (2880 sectors) block size 4096, fragment size 512 using 1 cylinder groups of 1.41MB, 360 blks, 32 inodes. super-block backups (for fsck -b #) at: 32 + mount /dev/md1c /mnt + [ -d /R/stage/image.kern ] + set -e + cd /R/stage/image.kern + find+ cpio -dump . -print /mnt cpio: write error: No space left on device *** Error code 1 (End quote) There are about 1414kbytes in image.kern directory. Note that kern.flp has about 1407kbytes (see below); reduce 7k is required. % pwd /R/stage/image.kern % ls -lR total 1313 drwxr-xr-x 2 root wheel 512 Feb 16 09:31 boot -r-xr-xr-x 1 root wheel 1327754 Feb 16 09:31 kernel.gz ./boot: total 100 -rw-r--r-- 1 root wheel 2352 Feb 16 09:31 device.hints -rwxr-xr-x 1 root wheel 97639 Feb 16 09:31 loader -rw-r--r-- 1 root wheel245 Feb 16 09:31 loader.rc % Apparantly, we have a chance to gzip /boot/loader: % cd boot % gzip loader % ls -l loader.gz -rwxr-xr-x 1 root wheel 90372 Feb 16 09:31 loader.gz % And, it fits to 1.44MB floppy again: % df /mnt Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/md1c 1407 1404 3 100%/mnt % ls -lR /mnt total 1305 drwxr-xr-x 2 root wheel 512 Feb 16 20:16 boot -r-xr-xr-x 1 root wheel 1327754 Feb 16 09:31 kernel.gz /mnt/boot: total 99 -rw-r--r-- 1 root wheel 2352 Feb 16 09:31 device.hints -rwxr-xr-x 1 root wheel 90372 Feb 16 09:31 loader.gz -rw-r--r-- 1 root wheel245 Feb 16 09:31 loader.rc There are ONLY 3 kbytes left, maybe it flood again in very near future:) Anyway that's all about current 5-current kern.flp problem -- How do you think about this? May I gzip /boot/loader on kern.flp? Do you know any drivers/features which can drop from the kernel on kern.flp? -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
"Andrey A. Chernov" writes: > On Sun, Feb 16, 2003 at 11:01:43 +0100, Dag-Erling Smorgrav wrote: > > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > > > [...] > > > > Please disregard. Andrey does not know what he's talking about and > > ignores any attempt at explaining what the real issue is and what real > > users want. > > Unless you specify exact details of what I ignore, I'll be forced to > treat your reply as NO REVIEW and commit this changes. No, Andrey, you will not. > P.S. It really des who ignore that simple fact that "" was localhost alias > in OPIE for years before any evil PAM appearse. As you see, I am specific. Does the ""-as-localhost-alias break other PAM modules? In what way does "localhost" or NULL break OPIE? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
Dag-Erling Smorgrav writes: > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > > Admins with no /etc/opieaccess AFFECTED! > > Admins with no /etc/opieaccess IDIOTS for not running mergemaster! POLA. We don't want to burn our user/admins. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 12:06:36 +0100, Dag-Erling Smorgrav wrote: > "Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > > Admins with no /etc/opieaccess AFFECTED! > > Admins with no /etc/opieaccess IDIOTS for not running mergemaster! First of all, there are many years of existen OPIE administration practice which every OPIE admin know, and this practice says that this file is not needed in many setups. In hypotetical case that FreeBSD deside to break this rule for some unknown reason, it must be well documented in both manpages and release notes. But, currently documented exact oppisite variant. Please read this quote from opieaccess(5), where OPIE authors explicetely state that this file can leads to security hole and always should be treated as optional. "In any environment, it should be considered a transition tool and not a permanent fixture. When it is not being used as a transition tool, a version of OPIE that has been built without support for the opieaccess file should be built to prevent the possibility of an attacker using this file as a means to circumvent the OPIE software." Even some new admins read manpages and delete this file after reading that. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
"Andrey A. Chernov" <[EMAIL PROTECTED]> writes: > But... Nonsense from my side happens only because > 1) I see the breakage. > 2) Seen breakage, I try to guess what des means, when he made it, > having no information from des. > 3) If I guess it (with no information) incorrectly, it not means > that breakage not exist, it still there. My message <[EMAIL PROTECTED]> dated 2003-02-16 00:46:27 CET contained all the information you needed. Do you really think that your hysterical reaction, bombarding me with message upon incriminatory message and completely ignoring what I say unless it can be twisted into a confirmation of your theory, is the correct way of presenting your case and convincing me of the validity of your arguments? And do you always have to react as if every commit I make to any part of the tree with which you are remotely familiar is a personal attack against you? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OPIE breakage: backout & patch for review
On Sun, Feb 16, 2003 at 11:58:57 +0100, [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, "Andrey A. Chernov" writes: > >On Sun, Feb 16, 2003 at 13:27:38 +0300, Andrey A. Chernov wrote: > >> > >> Unless you specify exact details of what I ignore, I'll be forced to > >> treat your reply as NO REVIEW and commit this changes. > > > >Well, after numerous exchanges of nonsense messages [...] > > That is probably the most precise summary so far (NB: "exchanges" implies > that the non-sense goes both ways). Yes, but nonsense from my side is more detailed. :-) But... Nonsense from my side happens only because 1) I see the breakage. 2) Seen breakage, I try to guess what des means, when he made it, having no information from des. 3) If I guess it (with no information) incorrectly, it not means that breakage not exist, it still there. > Please take this to private email. I not see enough good will from des side for it. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
