No Subject
unsubscribe freebsd-current To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: just moved to current, mouse is jerky
Raymond Kohler wrote:
- Original Message -
From: Donald J. Maddox [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 30, 2001 12:10 AM
Subject: Re: just moved to current, mouse is jerky
Try not using /dev/{u}random (don't load random.ko at boot). The random
device uses mouse interrupts to harvest entropy, and it can cause some
real jerkiness in the mouse. Of course, if you need to use something
that really NEEDS good randomness, like SSH, then not loading random.ko
is not really an option :(
Actually, I'm not loading Yarrow in the first place. That's why I think this
is weird.
(That and the fact that the last time I tried current, just after the
4.0-RELEASE was
split off, this was already happening.) It only happens on this box and
apparently
nobody else sees this exact problem (the last time I asked about it, back
then,
nobody answered it). I'm going to try it as a serial mouse and see what
happens.
Are you running a fresh current? It happened to me about 2-3 weeks ago -
exactly the same symptoms, but then last Friday I did a 'make world' and
the problem disappeared. I'm running Inspiron 5000, using internal
track-pad (/dev/psm0, ps/2 mouse), no fancy modules settings, just plain
-current - whether this loads random.ko I have no idea ATM.
--
Andrzej
//
// Andrzej Bialecki [EMAIL PROTECTED], Chief System Architect
// WebGiro AB, Sweden (http://www.webgiro.com)
//
// [EMAIL PROTECTED] FreeBSD developer (http://www.freebsd.org)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: -current lockups
On Tue, 31 Jul 2001, John Baldwin wrote: On 31-Jul-01 Vincent Poy wrote: On Mon, 30 Jul 2001, John Baldwin wrote: On 30-Jul-01 Sheldon Hearn wrote: On Mon, 30 Jul 2001 07:38:47 MST, David O'Brien wrote: However, those boxes were panicing often before I made that statement. So I still believe current is now in better shape than it was in June. I'll be a lot happier when I can enabled DDB_UNATTENDED and do whatever it is that causes my panic of the day and actually get a crashdump instead of panic: witness_restore: lock (sleep mutex) Giant not locked This is a different one. Is this during the dump itself? That I can try to work on. (Basically, I need to make witness just stop doing all of its various checks if panicstr != NULL). I'm getting the following lock order reversal for any -current since July 19, 2001 including today and it just hangs solid after this, no db prompt or anything... It only happens after passwd or chpass successfully rebuilds the database, vipw works fine. root@pele [9:29pm][/usr/temp] Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 This is due to the way that lockmgr locks are implemented unfortunately, and will be fixed when vm maps switch to sx locks instead of lockmgr locks. Interesting. Is there a workaround so it just reboots instead of freezing? Also, I noticed that you committed some changes to the kernel, is that supposed to help it any? Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lockups
On 31-Jul-01 Vincent Poy wrote: On Tue, 31 Jul 2001, John Baldwin wrote: root@pele [9:29pm][/usr/temp] Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 This is due to the way that lockmgr locks are implemented unfortunately, and will be fixed when vm maps switch to sx locks instead of lockmgr locks. Interesting. Is there a workaround so it just reboots instead of freezing? Also, I noticed that you committed some changes to the kernel, is that supposed to help it any? There is currently not a workaround. The changes committed fix other things, but not this problem. I haven't actually seen this lock order cause a freeze before to be honest. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lockups
On Tue, 31 Jul 2001, John Baldwin wrote: On 31-Jul-01 Vincent Poy wrote: On Tue, 31 Jul 2001, John Baldwin wrote: root@pele [9:29pm][/usr/temp] Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 This is due to the way that lockmgr locks are implemented unfortunately, and will be fixed when vm maps switch to sx locks instead of lockmgr locks. Interesting. Is there a workaround so it just reboots instead of freezing? Also, I noticed that you committed some changes to the kernel, is that supposed to help it any? There is currently not a workaround. The changes committed fix other things, but not this problem. I haven't actually seen this lock order cause a freeze before to be honest. Yeah, that's the weird part... I thought adding a DDB_UNATTENDED as a option would atleast make it reboot or something... Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lockups
On 31-Jul-01 Vincent Poy wrote: On Tue, 31 Jul 2001, John Baldwin wrote: On 31-Jul-01 Vincent Poy wrote: On Tue, 31 Jul 2001, John Baldwin wrote: root@pele [9:29pm][/usr/temp] Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 This is due to the way that lockmgr locks are implemented unfortunately, and will be fixed when vm maps switch to sx locks instead of lockmgr locks. Interesting. Is there a workaround so it just reboots instead of freezing? Also, I noticed that you committed some changes to the kernel, is that supposed to help it any? There is currently not a workaround. The changes committed fix other things, but not this problem. I haven't actually seen this lock order cause a freeze before to be honest. Yeah, that's the weird part... I thought adding a DDB_UNATTENDED as a option would atleast make it reboot or something... Well, since it is a lock order reversal, there is the chance of it resulting in a deadlock though the chances of that on a UP machine would be very, very rare indeed. The reversal in question is triggered when we swap a process out. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: quick informal survey: OpenSSH broken?
On Tue, Jul 31, 2001 at 01:39:14PM -0400, Robert Watson wrote: what was going on, and given that scp doesn't support -1, was a bit of a pain. Brian, what about adding -1 to SCP? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lockups
On Tue, 31 Jul 2001, John Baldwin wrote: On 31-Jul-01 Vincent Poy wrote: On Tue, 31 Jul 2001, John Baldwin wrote: root@pele [9:29pm][/usr/temp] Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 This is due to the way that lockmgr locks are implemented unfortunately, and will be fixed when vm maps switch to sx locks instead of lockmgr locks. Interesting. Is there a workaround so it just reboots instead of freezing? Also, I noticed that you committed some changes to the kernel, is that supposed to help it any? There is currently not a workaround. The changes committed fix other things, but not this problem. I haven't actually seen this lock order cause a freeze before to be honest. Yeah, that's the weird part... I thought adding a DDB_UNATTENDED as a option would atleast make it reboot or something... Well, since it is a lock order reversal, there is the chance of it resulting in a deadlock though the chances of that on a UP machine would be very, very rare indeed. The reversal in question is triggered when we swap a process out. Yep, it's so rare that nothing can trigger it except for passwd and chpass after they successfully exit and do the following successfully... passwd: updating the database... passwd: done Even vipw doesn't trigger it which I thought it would as it would do all the users rather than just one. Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
IPSEC/IPSEC_ESP module(s)
Has anyone attempted to make a loadable module out of IPSEC yet? brad To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ohci_process_done hangs when uhub detached
Hi, Last weekend I replaced my socket7 MVP3 board (w/ K6-2+) to ASUS CUSI-FX socket370 SiS630E board (w/ VIA C3 733MHz), then I found kernel panics when USB HUBs are detached. My USB setup is as follows: FreeBSD PC--+ | CPU_switcherHUB1HUB2-Mouse || Windows PC--++USB-PS/2---Keyboard Mouse and USB-PS/2 translator are detached safely. When switching FreeBSD to Windows, kernel hangs with flood of "db" prompts. This is also the case when I pull out USB cable between switcher and HUB1. When pulling cable between HUB1-HUB2 out, the following error messages are indicated and I can check trace result: uhub3: detached ohci_device_ctrl_close: pipe=0xc122e580 ohci_process_done: err cc=5 (DEVICE_NOT_RESPONDING), xfer=0xc103b500 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0e6 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01daa5d stack pointer = 0x10:0xc79a5f20 frame pointer = 0x10:0xc79a5f34 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def31 1, gran 1 processor eflags= interrupt enabled, resume, IOPL=0 current process = 18 (irq 9: ohci0++) kernel: type 12 trap, code=0 Stopped at ohci_process_done+0x21d:movl%eax,0x8(%edx) db trace ohci_process_done(c080e000,580620,c1024340,c1016a80,4)at ohci_process_done+0x21d ohci_intr1(c080e000,c79a5f7c,c0214157,c080e000,c0213e98) at ohci_intr1+0x139 ohci_intr(c080e000) at ohci_intr+0x15 ithread_loop(c1016a80,c79af5fa8) at ithread_loop+0x2bf fork_exit(c0213e98,c1016a80,c79a5fa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db == With MVP3 chipset (UHCI) the setup above have worked peacefully, so I guess it's due to OHCI code and/or SiS 630E chipset. -- FUJIMOTO Kou, Dept. of Information Sciences, Tokyo Denki Univ. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: X in free(): error: recursive call.
On Sun, Jul 29, 2001 at 04:38:06PM +0200, Sheldon Hearn wrote: On Sun, 29 Jul 2001 22:29:40 +0800, Michael Robinson wrote: I'd like to get advice on which of the following courses of action to take: 1. Isolate and fix the problem. I would need some help here. Try a better-proven release of XFree86, namely 3.3.6. Based on my preliminary efforts to isolate the problem, it seems pretty clear that A) the code path required to reach the error is not exposed by the malloc API to applications (after all, how could an application call free recursively?), and B) it likely has something to do with an overlooked race condition in the thread safety retrofit of libc late last year. But, as was mentioned previously, XFree86 3.3.6 doesn't have the required chip support for the Dell 5000e, so that's not an option, regardless. I welcome further suggestions, though. -Michael Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: X in free(): error: recursive call.
Hello, I was running in the same problem early this year. Probably you have found my mails in the archive. Unfortunately I was not able solve the problem. I am running now 3.3.6 on my laptop (which furtunately supports the graphics chips that my laptop has). Just as a datapoint: My understanding of the problem is that it is really a problem of XFree (as opposed to FreeBSD) There seems to be a situation where malloc is called within a signal handler. It was explained to me that malloc cannot be recursively called. Therefore, if a signal interrupts Xfree when it is in the libc *alloc-functions, this can crash the server. The following trace shows this scenario: #0 0x2820a9e8 in kill () from /usr/lib/libc.so.5 #1 0x2825bb3d in abort () from /usr/lib/libc.so.5 #2 0x2825a682 in isatty () from /usr/lib/libc.so.5 #3 0x2825a6b0 in isatty () from /usr/lib/libc.so.5 #4 0x2825b6a6 in malloc () from /usr/lib/libc.so.5 #5 0x80d19ff in Xalloc (amount=16) at utils.c:1225 #6 0x80cc30c in TimerSet (timer=0x0, flags=0, millis=50, func=0x8788ef0, arg=0x88a0b00) at WaitFor.c:744 #7 0x87890fa in ?? () #8 0x878927d in ?? () #9 0x8788bf0 in ?? () #10 0x807da23 in xf86SigioReadInput (fd=7, closure=0x88a0b00) at xf86Events.c:1039 #11 0x8093d48 in xf86SIGIO (sig=23) at sigio.c:99 #12 0xbfbfffac in ?? () #13 0x2825b1b0 in isatty () from /usr/lib/libc.so.5 #14 0x2825b901 in realloc () from /usr/lib/libc.so.5 #15 0x80d1b18 in Xrealloc (ptr=0x8eb3000, amount=4096) at utils.c:1322 #16 0x80ceef4 in StandardReadRequestFromClient (client=0x8a0d100) at io.c:403 #17 0x80ac00c in Dispatch () at dispatch.c:438 #18 0x80bc395 in main (argc=3, argv=0xbfbffdc0, envp=0xbfbffdd0) at main.c:439 #19 0x806b31d in _start () My understanding is that the problem is with XFree using malloc in a signal-handler. Strange enough, my system at home (with a Matrox G400-Card and Xfree86-4.1.0) does not show this symptom. Michael On Tue, 31 Jul 2001, Michael Robinson wrote: On Sun, Jul 29, 2001 at 04:38:06PM +0200, Sheldon Hearn wrote: On Sun, 29 Jul 2001 22:29:40 +0800, Michael Robinson wrote: I'd like to get advice on which of the following courses of action to take: 1. Isolate and fix the problem. I would need some help here. Try a better-proven release of XFree86, namely 3.3.6. Based on my preliminary efforts to isolate the problem, it seems pretty clear that A) the code path required to reach the error is not exposed by the malloc API to applications (after all, how could an application call free recursively?), and B) it likely has something to do with an overlooked race condition in the thread safety retrofit of libc late last year. But, as was mentioned previously, XFree86 3.3.6 doesn't have the required chip support for the Dell 5000e, so that's not an option, regardless. I welcome further suggestions, though. -Michael Robinson To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message ___ Michael ClassE-Mail: [EMAIL PROTECTED] E-Business Solution Division ___ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI: Clock problems in -current
- What power management hardware your system has: look at the output of pciconf -lv for a power management controller, eg: This machine has no separate controller. Attached is the complete output of pciconf -lv That's OK; I can probably safely assume it's the M1533 device. - which timecounter is in use on your system, eg: mass# sysctl kern.timecounter.hardware kern.timecounter.hardware: ACPI During the Off/2 errors this variable contained ACPI Ok, so far so good. - whether you are seeing any *time went backwards console messages. Tons of, even with negative CPU-Usage times. Ok, I think we have the enemy in sight. Can you please say: set debug.acpi.timer_test=yes at the loader prompt and boot? Ideally, you'll get a message timer is not monotonic, followed by some numbers. If this is the case, then I need to get smarter with the ACPI timer probe. Thanks! -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lockups
On Mon, 30 Jul 2001, John Baldwin wrote: On 30-Jul-01 Sheldon Hearn wrote: On Mon, 30 Jul 2001 07:38:47 MST, David O'Brien wrote: However, those boxes were panicing often before I made that statement. So I still believe current is now in better shape than it was in June. I'll be a lot happier when I can enabled DDB_UNATTENDED and do whatever it is that causes my panic of the day and actually get a crashdump instead of panic: witness_restore: lock (sleep mutex) Giant not locked This is a different one. Is this during the dump itself? That I can try to work on. (Basically, I need to make witness just stop doing all of its various checks if panicstr != NULL). I'm getting the following lock order reversal for any -current since July 19, 2001 including today and it just hangs solid after this, no db prompt or anything... It only happens after passwd or chpass successfully rebuilds the database, vipw works fine. root@pele [9:29pm][/usr/temp] Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Cheers, Vince - [EMAIL PROTECTED] - Vice President __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su root broken in -CURRENT
Sheldon Hearn wrote: The FreeBSD 4.3 manpage says: Only users who are a member of group 0 (normally ``wheel'') can su to ``root''. If group 0 is missing or empty, any user can su to ``root''. I guess that could (at a stretch) be interpreted the same as OpenBSD's behaviour. I guess I'll withdraw my complaint, since it just boils down to the behaviour changed! now. The reason for this is that the pam code for doing the enforcement is being trusted utterly. In the past, we would consider both the primary group (the group from the passwd file entry), and the auxillary groups (the groups from the groups file entries, if any), as synonymous. With the pam code being used, we no longer consider the primary group to be on the same par as the groups file entries. IMO, this is bad, and should be fixed: the OpenBSD code is just a rationalization of the behaviour forced when you don't consider the user's primary group. It seems very odd to me that the primary group is ignored, while the auxillary group memberships are what determines whether or not it's possible for a person to su... call me crazy, but I think it's the job of the interface to rationalize this, so that the _most significant group membership_ is not ignored. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: new libmp imported
Kris Kennaway [EMAIL PROTECTED] writes: On Mon, Jul 30, 2001 at 07:44:33AM -0700, David O'Brien wrote: On Sun, Jul 29, 2001, Kris Kennaway wrote: installed. This would involve a repo copy of crypto/openssl/crypto/bn to contrib/openssl-bn or something, and I'd keep the two in sync with future vendor imports. You're likely to get people saying repo bloat. And it does seem a little wrong to have two copies in the tree like that. Just what programs are affected by this issue (ie, which use libmp)? I don't have the list to hand right now, but they all related to the secure RPC code which arguably should be in the crypto distribution anyway. All the telnets, usr.sbin/keyserv, usr.bin/chkey, and usr.bin/newkey. The telnets need it for SRA, and the others are all SecureRPC-related as you say. I don't know how we distinguish crypto code, but I would think they all fit it there. Seeing as how this is a relatively minor problem, I plan to `cvs rm` libgmp tomorrow. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lockups
On Mon, 30 Jul 2001 16:52:27 +0200, Sheldon Hearn wrote:
I'll be a lot happier when I can enabled DDB_UNATTENDED and do whatever
it is that causes my panic of the day and actually get a crashdump
instead of
panic: witness_restore: lock (sleep mutex) Giant not locked
Right! We have interesting progress!
The following patchset fixes two problems:
1) The witness code may still panic when panicstr is not NULL. This is
a problem when the original panic was caused by the witness code
itself.
Solution: when panicstr != NULL, witness backs off on the fascism.
2) The ata code calls await/mawait inside a dump. This results in a
hard, uninterruptable lock in ad_reinit(). An NMI might interrupt
it, but not all of us have NMI boards.
Solution: as a quick fix, when panicstr != NULL, bail out of
masleep() without spinning on mutexes.
The real solution here is arguably for the ata code to be aware of
the fact that sleeping inside a dump (i.e. panicstr != NULL) is bad
and stop doing so.
With these fixes in place, I can get a crashdump with a populated
ktr_buf from a witness-related panic. Joy!
Many thanks to jhb for providing the patch for #1 above and to peter for
the patch for #2 above. None of this is actually my own work. I'm just
the guy pressing the panic button on his box incessantly. :-)
Ciao,
Sheldon.
Index: kern/kern_mutex.c
===
RCS file: /home/ncvs/src/sys/kern/kern_mutex.c,v
retrieving revision 1.64
diff -u -d -r1.64 kern_mutex.c
--- kern/kern_mutex.c 2001/06/25 18:29:32 1.64
+++ kern/kern_mutex.c 2001/07/30 23:14:32
@@ -562,6 +562,9 @@
void
_mtx_assert(struct mtx *m, int what, const char *file, int line)
{
+
+ if (panicstr != NULL)
+ return;
switch (what) {
case MA_OWNED:
case MA_OWNED | MA_RECURSED:
Index: kern/kern_synch.c
===
RCS file: /home/ncvs/src/sys/kern/kern_synch.c,v
retrieving revision 1.148
diff -u -d -r1.148 kern_synch.c
--- kern/kern_synch.c 2001/07/06 01:16:42 1.148
+++ kern/kern_synch.c 2001/07/31 01:07:23
@@ -554,6 +554,18 @@
KASSERT(timo 0 || mtx_owned(Giant) || mtx != NULL,
(sleeping without a mutex));
mtx_lock_spin(sched_lock);
+ if (cold || panicstr) {
+ /*
+* After a panic, or during autoconfiguration,
+* just give interrupts a chance, then just return;
+* don't run any other procs or panic below,
+* in case this is the idle process and already asleep.
+*/
+ if (mtx != NULL priority PDROP)
+ mtx_unlock_flags(mtx, MTX_NOSWITCH);
+ mtx_unlock_spin(sched_lock);
+ return (0);
+ }
DROP_GIANT_NOSWITCH();
if (mtx != NULL) {
mtx_assert(mtx, MA_OWNED | MA_NOTRECURSED);
Index: kern/subr_trap.c
===
RCS file: /home/ncvs/src/sys/kern/subr_trap.c,v
retrieving revision 1.196
diff -u -d -r1.196 subr_trap.c
--- kern/subr_trap.c2001/07/04 15:36:30 1.196
+++ kern/subr_trap.c2001/07/30 23:14:42
@@ -72,9 +72,9 @@
while ((sig = CURSIG(p)) != 0)
postsig(sig);
mtx_unlock(Giant);
+ PROC_UNLOCK(p);
mtx_lock_spin(sched_lock);
- PROC_UNLOCK_NOSWITCH(p);
p-p_pri.pri_level = p-p_pri.pri_user;
if (resched_wanted(p)) {
/*
@@ -96,24 +96,22 @@
while ((sig = CURSIG(p)) != 0)
postsig(sig);
mtx_unlock(Giant);
- mtx_lock_spin(sched_lock);
- PROC_UNLOCK_NOSWITCH(p);
- }
+ PROC_UNLOCK(p);
+ } else
+ mtx_unlock_spin(sched_lock);
/*
* Charge system time if profiling.
*/
- if (p-p_sflag PS_PROFIL) {
- mtx_unlock_spin(sched_lock);
+ if (p-p_sflag PS_PROFIL)
addupc_task(p, TRAPF_PC(frame),
(u_int)(p-p_sticks - oticks) * psratio);
- } else
- mtx_unlock_spin(sched_lock);
}
/*
* Process an asynchronous software trap.
* This is relatively easy.
+ * This function will return with interrupts disabled.
*/
void
ast(framep)
@@ -121,68 +119,64 @@
{
struct proc *p = CURPROC;
u_quad_t sticks;
+ critical_t s;
+ int sflag;
#if defined(DEV_NPX) !defined(SMP)
int ucode;
#endif
KASSERT(TRAPF_USERMODE(framep), (ast in kernel mode));
-
- /*
-* We check for a pending AST here rather than in the assembly as
-* acquiring and releasing mutexes in assembly is not fun.
-*/
- mtx_lock_spin(sched_lock);
- if (!(astpending(p) || resched_wanted(p))) {
-
Re: Help wanted: loadable SMBFS
[Aside: problems getting crashdumps resolved, see message with ] [Message-ID [EMAIL PROTECTED] sent to -current] [with subject Re: -current lockups. ] On Mon, 30 Jul 2001 00:00:53 +0200, Sheldon Hearn wrote: I got a little help from some folks on IRC who helped me with a disassembly that confirms a null pointer dereference in the STAILQ_REMOVE(). Hi John, So now that I have crashdumps working (thanks!), I've got a populated ktr_buf in my crashdump. Sadly, I don't understand much of what's in it. Is there a magic look for this to find where 90rql (the smbfs request lock) got accidentally removed from all_locks, or does this require intelligence? If so, do I send you the output of Greg Lehy's ktr GDB macro? What's standard procedure with these things? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Current XFree86
Upgraded my laptop to current the other day, just to get the cardbus cards working (which works like a charm). Found a problem though related to XFree86. When I run startx X initiates for a short while, but dies with the message: (EE) xf86OpenSerial: Cannot open device /dev/psm0 Device busy. And then it's over :) What am I missing? (of course XFree86 ran on the box (4.3-STABLE) before the upgrade) -- __o regards, Gunnar ---_ \,_ email: [EMAIL PROTECTED] (_)/ (_) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su root broken in -CURRENT
On Tue, 31 Jul 2001 05:35:00 +0100, Joshua Goodall wrote: The FreeBSD 4.3 manpage says: Only users who are a member of group 0 (normally ``wheel'') can su to ``root''. If group 0 is missing or empty, any user can su to ``root''. I guess that could (at a stretch) be interpreted the same as OpenBSD's behaviour. I guess I'll withdraw my complaint, since it just boils down to the behaviour changed! now. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Current XFree86
++ 31/07/01 14:06 +0200 - Gunnar Flygt: | (EE) xf86OpenSerial: Cannot open device /dev/psm0 | Device busy. | And then it's over :) Sounds like you're running moused. I don't think XFree86 4.1 can use /dev/sysmouse and interact with moused like 3.3.6 could. -pete -- Pete Fritchman [EMAIL PROTECTED] Databits Network Services, Inc. http://databits.net finger [EMAIL PROTECTED] for PGP key To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Current XFree86
Date: Tue, 31 Jul 2001 08:45:41 -0400 From: Pete Fritchman [EMAIL PROTECTED] ++ 31/07/01 14:06 +0200 - Gunnar Flygt: | (EE) xf86OpenSerial: Cannot open device /dev/psm0 | Device busy. | And then it's over :) Sounds like you're running moused. I don't think XFree86 4.1 can use /dev/sysmouse and interact with moused like 3.3.6 could. I'm running XFree86 4.1.0_4 on my laptop (tracking both -STABLE and -CURRENT daily), and I use moused just fine. However, the Device (in /etc/XF86Config) is listed as /dev/mouse, and in (-CURRENT's) /etc/rc.devfs, I have ln -fs /dev/sysmouse /dev/mouse I've seen no problems attributable to mouse interactions. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: acpica malfunctions
Hi, Mike Smith wrote: I've just committed a slightly different patch, based on a mix of your ideas and mine (mostly yours). Can you test the -current code, and let me know what I broke this time? 8) As haro wrote, acpi_pcib.c rev1.11 + neckpain's patch does work on my machine too. But rev1.12 cause panic while booting on my PCG-C1VSX/K (NEWCARD + acpica). pccbb0: RF5C475 PCI-CardBus Bridge at device 12.0 on pci0 pccbb0: PCI Memory allocated: 4400 acpi_pcib0: matched entry for 0.12.INTA (source \_SB_.LINKB) acpi_pcib0: possible interrupts: 9 acpi_pcib0: couldn't route interrupt 9 via \_SB_.LINKB - AE_BAD_PARAMETER pccbb: Unable to map IRQ... panic: resource_list_release: can't find resource Debugger(panic) Stopped at Debugger+0x44: pushl %ebx db dmesg with acpi_pcib.c rev1.11 + neckpain's patch is as follows ACPI debug layer 0x0 debug level 0x0 Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sun Jul 29 15:46:16 JST 2001 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ALASKAN Timecounter i8254 frequency 1193182 Hz CPU: Transmeta(tm) Crusoe(tm) Processor TM5600 (661.67-MHz 586-class CPU) Origin = GenuineTMx86 Id = 0x543 real memory = 117374976 (114624K bytes) avail memory = 108027904 (105496K bytes) Preloaded elf kernel kernel at 0xc05f9000. WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 9 entries at 0xc00fdf30 acpi0: SONY P1 on motherboard Timecounter ACPI frequency 3579545 Hz acpi_cpu0: CPU on acpi0 acpi_cpu: CLK_VAL field overflows P_CNT register acpi_cpu: CLK_VAL field overlaps THT_EN bit acpi_tz0: thermal zone on acpi0 acpi_lid0: Control Method Lid Switch on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge on acpi0 pci0: PCI bus on acpi_pcib0 pci0: memory, RAM at 0.1 (no driver attached) pci0: memory, RAM at 0.2 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0x1000-0x100f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0x1020-0x103f irq 9 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub1: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2 uhub1: 2 ports with 2 removable, self powered ugen0: Sony USB Memory Stick Slot, rev 1.10/1.80, addr 3 pci0: bridge, PCI-unknown at 7.3 (no driver attached) pci0: serial bus, FireWire at 8.0 (no driver attached) pcm0: Yamaha DS-1E (YMF754) mem 0xfc108000-0xfc10 irq 9 at device 9.0 on pci0 pci0: simple comms at 10.0 (no driver attached) pci0: multimedia at 11.0 (no driver attached) pccbb0: RF5C475 PCI-CardBus Bridge at device 12.0 on pci0 pccbb0: PCI Memory allocated: 4400 acpi_pcib0: matched entry for 0.12.INTA (source \\_SB_.LNKB) acpi_pcib0: possible interrupts: 9 acpi_pcib0: routed interrupt 9 via \\_SB_.LNKB cardbus0: Cardbus bus (newcard) on pccbb0 pccard0: 16-bit PCCard bus on pccbb0 pci0: display, VGA at 13.0 (no driver attached) acpi_ec0: embedded controller on acpi0 acpi_cmbat0: Control method Battery on acpi0 acpi_acad0: AC adapter on acpi0 acpi_timer0: 24-bit timer at 3.579545MHz port 0x8008-0x800b on acpi0 (omitting the rest) -- Yoichi Nakayama [EMAIL PROTECTED] E-ken, Dept. of Physics, Nagoya University http://www.eken.phys.nagoya-u.ac.jp/~yoichi/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: acpica malfunctions
Hello Nakayama-san, From: [EMAIL PROTECTED] Date: Tue, 31 Jul 2001 23:28:39 +0900 ::Hi, :: :: Mike Smith wrote: :: I've just committed a slightly different patch, based on a mix of your :: ideas and mine (mostly yours). Can you test the -current code, and let :: me know what I broke this time? 8) :: ::As haro wrote, acpi_pcib.c rev1.11 + neckpain's patch does work ::on my machine too. But rev1.12 cause panic while booting on my ::PCG-C1VSX/K (NEWCARD + acpica). New patch was posted by [EMAIL PROTECTED] for rev1.12 on -current. My PCG-Z505V/BP booted fine with the new patch. Have a try with it. Hope this helps, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Help wanted: loadable SMBFS
On 31-Jul-01 Sheldon Hearn wrote: [Aside: problems getting crashdumps resolved, see message with ] [Message-ID [EMAIL PROTECTED] sent to -current] [with subject Re: -current lockups. ] On Mon, 30 Jul 2001 00:00:53 +0200, Sheldon Hearn wrote: I got a little help from some folks on IRC who helped me with a disassembly that confirms a null pointer dereference in the STAILQ_REMOVE(). Hi John, So now that I have crashdumps working (thanks!), I've got a populated ktr_buf in my crashdump. Sadly, I don't understand much of what's in it. Is there a magic look for this to find where 90rql (the smbfs request lock) got accidentally removed from all_locks, or does this require intelligence? If so, do I send you the output of Greg Lehy's ktr GDB macro? What's standard procedure with these things? If it works. :) It may need updating to work right. Basically the KTR buffer is kind of like a printf buffer. Various points in the code stuff messages into it when an event happens (such as getting a lock, releasing a lock, etc.) There should be an event right at the end about the lock in question being destroyed for example (if you had KTR_LOCK turned on). You might then look in the logs to see where else the same lock was messed with. Ciao, Sheldon. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current lockups
On 31-Jul-01 Vincent Poy wrote: On Mon, 30 Jul 2001, John Baldwin wrote: On 30-Jul-01 Sheldon Hearn wrote: On Mon, 30 Jul 2001 07:38:47 MST, David O'Brien wrote: However, those boxes were panicing often before I made that statement. So I still believe current is now in better shape than it was in June. I'll be a lot happier when I can enabled DDB_UNATTENDED and do whatever it is that causes my panic of the day and actually get a crashdump instead of panic: witness_restore: lock (sleep mutex) Giant not locked This is a different one. Is this during the dump itself? That I can try to work on. (Basically, I need to make witness just stop doing all of its various checks if panicstr != NULL). I'm getting the following lock order reversal for any -current since July 19, 2001 including today and it just hangs solid after this, no db prompt or anything... It only happens after passwd or chpass successfully rebuilds the database, vipw works fine. root@pele [9:29pm][/usr/temp] Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: lock order reversal Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 1st 0xd92fea9c process lock @ /usr/src/sys/vm/vm_glue.c:469 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 Jul 28 21:29:40 pele /boot/kernel/kernel: 2nd 0xc118dfb0 lockmgr interlock @ /usr/src/sys/kern/kern_lock.c:239 This is due to the way that lockmgr locks are implemented unfortunately, and will be fixed when vm maps switch to sx locks instead of lockmgr locks. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su root broken in -CURRENT
On 31-Jul-01 Terry Lambert wrote: Sheldon Hearn wrote: The FreeBSD 4.3 manpage says: Only users who are a member of group 0 (normally ``wheel'') can su to ``root''. If group 0 is missing or empty, any user can su to ``root''. I guess that could (at a stretch) be interpreted the same as OpenBSD's behaviour. I guess I'll withdraw my complaint, since it just boils down to the behaviour changed! now. The reason for this is that the pam code for doing the enforcement is being trusted utterly. In the past, we would consider both the primary group (the group from the passwd file entry), and the auxillary groups (the groups from the groups file entries, if any), as synonymous. With the pam code being used, we no longer consider the primary group to be on the same par as the groups file entries. IMO, this is bad, and should be fixed: the OpenBSD code is just a rationalization of the behaviour forced when you don't consider the user's primary group. It seems very odd to me that the primary group is ignored, while the auxillary group memberships are what determines whether or not it's possible for a person to su... call me crazy, but I think it's the job of the interface to rationalize this, so that the _most significant group membership_ is not ignored. I agree. The only people who want this are those who think a wheel group is a sign of oppresion and don't want to limit the availability of 'su' to just wheel users. At least that seems to be the only reason the check is there. You could still achieve that by not having any users have wheel as their primary group. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
libpam build broken in current
libpam will not build if you don't have the stock ssh installed. I use ssh from ports. (libpam)502}make === modules === modules/pam_deny === modules/pam_ftp === modules/pam_nologin === modules/pam_opie === modules/pam_permit === modules/pam_radius === modules/pam_rootok === modules/pam_securetty === modules/pam_ssh building shared library pam_ssh.so /usr/libexec/elf/ld: cannot find -lssh *** Error code 1 Stop in /usr/src/lib/libpam/modules/pam_ssh. *** Error code 1 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su root broken in -CURRENT
On Tue, 31 Jul 2001, Terry Lambert wrote: The reason for this is that the pam code for doing the enforcement is being trusted utterly. In the past, we would consider both the primary group (the group from the passwd file entry), and the auxillary groups (the groups from the groups file entries, if any), as synonymous. With the pam code being used, we no longer consider the primary group to be on the same par as the groups file entries. I can pin this down at r1.26 of su.c (Mon May 25 03:34:52 1998 UTC (3 years, 2 months ago) by steve) Prior to this date only appearance in /etc/group was considered. The change occurred in response to PR bin/6696 Like terry, I prefer the semantics whereby the users primary group is considered. Three years of precedent should be sufficient to have this change to pam_wheel.c, I hope, before PAM use in su is MFC'd. I have just entered a PR on this. cc'd to: markm Joshua To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: quick informal survey: OpenSSH broken?
My only real observation is that with Protocol using (2) by default, my logins to RELENG_4 boxes using RSA key authentication are broken. If I stick a Protocol 1 in, it works fine, but it took me a bit to figure out what was going on, and given that scp doesn't support -1, was a bit of a pain. I haven't tried using OpenSSH 2.9 with Kerberos as yet, but that would be something to test. Let me know if you need access to a KerberosIV realm to test with. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sun, 29 Jul 2001, Brian Fundakowski Feldman wrote: I need to know, if OpenSSH is ever going to get MFC'ed, are there any people currently running OpenSSH 2.9 from -CURRENT's base and getting major problems with it? Or even minor ones that actually make things more difficult? I want to have no real outstanding issues, except simple ones like Protocol being set to 2,1 by default (which is a reasonable default nowadays), before I MFC OpenSSH, because I really don't want to leave anyone screwed over in the process. So let me know, ASAP, what problems you all are having with OpenSSH in -CURRENT, specifically in the FreeBSD-specific parts. I'm also not certain of KRB4 and KRB5 auth still both work properly, and need that verified. Thanks, everybody. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: quick informal survey: OpenSSH broken?
* Robert Watson [EMAIL PROTECTED] [010731 12:39] wrote: My only real observation is that with Protocol using (2) by default, my logins to RELENG_4 boxes using RSA key authentication are broken. If I stick a Protocol 1 in, it works fine, but it took me a bit to figure out what was going on, and given that scp doesn't support -1, was a bit of a pain. I haven't tried using OpenSSH 2.9 with Kerberos as yet, but that would be something to test. Let me know if you need access to a KerberosIV realm to test with. The protocol 2,1 thing should not be MFC'd. Unless you intend this to be your usual of breakage of ssh around -release time. :) Please keep it 1,2 at least for the time being. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su root broken in -CURRENT
I have the PR, and I will fix this :-) M On Tue, 31 Jul 2001, Terry Lambert wrote: The reason for this is that the pam code for doing the enforcement is being trusted utterly. In the past, we would consider both the primary group (the group from the passwd file entry), and the auxillary groups (the groups from the groups file entries, if any), as synonymous. With the pam code being used, we no longer consider the primary group to be on the same par as the groups file entries. I can pin this down at r1.26 of su.c (Mon May 25 03:34:52 1998 UTC (3 years, 2 months ago) by steve) Prior to this date only appearance in /etc/group was considered. The change occurred in response to PR bin/6696 Like terry, I prefer the semantics whereby the users primary group is considered. Three years of precedent should be sufficient to have this change to pam_wheel.c, I hope, before PAM use in su is MFC'd. I have just entered a PR on this. cc'd to: markm Joshua -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
