Re: Problems with bktr on -current
On Sun, Aug 03, 2003 at 03:35:17PM +0200, Guido Berhoerster wrote: > Hello, > I've got some trouble with the bktr-driver on FreeBSD 5.x. With > fxtv the video-output is distorted and choppy, it appears that > only odd scanlines are redrawn regularly while even scanlines > remain for like half a second as "ghost images". When the fxtv > window is overlapped by some other window the video is only > updated about every 30 seconds. When using mplayer's > bsdbt848-driver I get an undistorted image but also choppy video. > I wasn't able to test it with xawtv since it's still broken on > 5.x. > This is a regression over 4.x, where everything works flawlessly. > I can reproduce these Problems on FreeBSD 5.0, 5.1, -CURRENT and > also on NetBSD 1.6.1. So my guess is that this is related to some > more recent patches which have been applied to FreeBSD 5.x and > NetBSD 1.6.1 but not FreeBSD 4.8. > Does anybody have similar problems or does anybody know what > changes might have caused this problem? I had a very similar problem a couple of months ago. I recall that my problem had to do with the kernel and fxtv being built with different headers. Are you building fxtv from scratch on each system or using the same binary? -- David P. Reese, Jr. [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR: sched lock vs. sio + panic in sched_choose() [ULE + SMPpanic]
Hm... Getting a core wont be that easy. After the previously mentionsed
sched_choose() panic:
db> call doadump
Dumping 383 MB
ata0: resetting devices ..
panic: blockable sleep lock (sleep mutex) PCPU 512 @ /usr/src/sys/vm/uma_core.c:1343
cpuid = 0; lapic.id =
Debugger("panic")
Fatal trap 3: breakpoint instruction fault while in kernel mode
cpuid = 0; lapic.id =
instruction pointer = 0x8:0xc039a615
stack pointer = 0x10:0xd79ae618
frame pointer = 0x10:0xd79ae624
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= IOPL = 0
current process = 4649 (sysctl)
Stopped at sched_choose+0x77: movl0x38(%eax),%eax
Nice.
--
David P. Reese Jr. [EMAIL PROTECTED]
--
It can be argued that returning a NULL pointer when asked to allocate
zero bytes is a silly response to a silly question.
-- FreeBSD manual page for malloc(3)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR: sched lock vs. sio + panic in sched_choose() [ULE + SMPpanic]
On Fri, Jun 06, 2003 at 12:39:46PM -0400, John Baldwin wrote: > > On 06-Jun-2003 David P. Reese Jr. wrote: > > I've been getting a lot of these for the last two weeks on my SMP box. > > This panic is on -CURRENT from earlier today. Scheduler is ULE. > > > > lock order reversal > > 1st 0xc047f820 sched lock (sched lock) @ /usr/src/sys/kern/kern_intr.c:548 > > 2nd 0xc04b83c0 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3242 > > This is a duplicate panic because you are using a serial console. > > > Stack backtrace: > > backtrace(c0400378,c04b83c0,c0463120,c0463120,c041266b) at backtrace+0x17 > > witness_lock(c04b83c0,8,c041266b,caa,c11efc00) at witness_lock+0x697 > > _mtx_lock_spin_flags(c04b83c0,0,c041266b,caa,0) at _mtx_lock_spin_flags+0xd1 > > siocnputc(c0463280,d,5,d1d62b68,0) at siocnputc+0x81 > > cnputc(a,,1,c0415c53,c) at cnputc+0x56 > > putchar(a,d1d62b68,d1d62ab4,c0491d40,0) at putchar+0xcd > > kvprintf(c0415c52,c025eba0,d1d62b68,a,d1d62b88) at kvprintf+0x7d > > printf(c0415c52,c,c0415a4d,c03fe55b,c0489b20) at printf+0x57 > > This is the real panic below: > > > trap_fatal(d1d62c14,38,d1d62bf0,c0236c9d,38) at trap_fatal+0x76 > > trap(d1d60018,c0240010,c0470010,c11dcbe0,c0482280) at trap+0x123 > > calltrap() at calltrap+0x5 > > --- trap 0xc, eip = 0xc0253ec7, esp = 0xd1d62c54, ebp = 0xd1d62c68 --- > > sched_choose(c11dee40,c03fe7a6,28c,0,c11db668) at sched_choose+0x77 > > choosethread(c11dcbe0,2,c03fdb89,1dc,b6e81bd0) at choosethread+0x36 > > mi_switch(c047f820,0,c03fb1fd,224,c11db5ac) at mi_switch+0x200 > > ithread_loop(c11da180,d1d62d48,c03fb0ae,30c,55ff44fd) at ithread_loop+0x256 > > fork_exit(c022caf0,c11da180,d1d62d48) at fork_exit+0xc0 > > fork_trampoline() at fork_trampoline+0x1a > > --- trap 0x1, eip = 0, esp = 0xd1d62d7c, ebp = 0 --- > > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1; lapic.id = 0100 > > fault virtual address = 0x38 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc0253ec7 > > stack pointer = 0x10:0xd1d62c54 > > frame pointer = 0x10:0xd1d62c68 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process = 14 (swi7: tty:sio clock) > > kernel: type 12 trap, code=0 > > Stopped at sched_choose+0x77: movl0x38(%eax),%eax > > This is a ULE and SMP panic that Jeff keeps looking for. Seems to be a > NULL pointer deference of some sort. > > > I recall most if not all of these panics occuring when swi7: tty:sio clock > > is the current process. These are not completely repeatable, but if I > > simply reboot a couple of times, I can get the panic to occur while the > > rc scripts are being run. > > Can you do a 'l *sched_choose+0x77' in gdb on kernel.debug to get > the source line corresponding to this panic? (kgdb) l *sched_choose+0x77 0xc0253ec7 is in sched_choose (/usr/src/sys/kern/sched_ule.c:1042). 1037 * Remove this kse from this kseq and runq and then requeue 1038 * on the current processor. Then we will dequeue it 1039 * normally above. 1040 */ 1041ke = kseq_choose(kseq); 1042 runq_remove(ke->ke_runq, ke); 1043ke->ke_state = KES_THREAD; 1044kseq_rem(kseq, ke); 1045 1046ke->ke_cpu = PCPU_GET(cpuid); I'm currently trying to get a core, but with my latest kernel ddb is locking up before i get a prompt. I'll keep trying. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOR: sched lock vs. sio + panic in sched_choose()
I've been getting a lot of these for the last two weeks on my SMP box. This panic is on -CURRENT from earlier today. Scheduler is ULE. lock order reversal 1st 0xc047f820 sched lock (sched lock) @ /usr/src/sys/kern/kern_intr.c:548 2nd 0xc04b83c0 sio (sio) @ /usr/src/sys/dev/sio/sio.c:3242 Stack backtrace: backtrace(c0400378,c04b83c0,c0463120,c0463120,c041266b) at backtrace+0x17 witness_lock(c04b83c0,8,c041266b,caa,c11efc00) at witness_lock+0x697 _mtx_lock_spin_flags(c04b83c0,0,c041266b,caa,0) at _mtx_lock_spin_flags+0xd1 siocnputc(c0463280,d,5,d1d62b68,0) at siocnputc+0x81 cnputc(a,,1,c0415c53,c) at cnputc+0x56 putchar(a,d1d62b68,d1d62ab4,c0491d40,0) at putchar+0xcd kvprintf(c0415c52,c025eba0,d1d62b68,a,d1d62b88) at kvprintf+0x7d printf(c0415c52,c,c0415a4d,c03fe55b,c0489b20) at printf+0x57 trap_fatal(d1d62c14,38,d1d62bf0,c0236c9d,38) at trap_fatal+0x76 trap(d1d60018,c0240010,c0470010,c11dcbe0,c0482280) at trap+0x123 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0253ec7, esp = 0xd1d62c54, ebp = 0xd1d62c68 --- sched_choose(c11dee40,c03fe7a6,28c,0,c11db668) at sched_choose+0x77 choosethread(c11dcbe0,2,c03fdb89,1dc,b6e81bd0) at choosethread+0x36 mi_switch(c047f820,0,c03fb1fd,224,c11db5ac) at mi_switch+0x200 ithread_loop(c11da180,d1d62d48,c03fb0ae,30c,55ff44fd) at ithread_loop+0x256 fork_exit(c022caf0,c11da180,d1d62d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d62d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0253ec7 stack pointer = 0x10:0xd1d62c54 frame pointer = 0x10:0xd1d62c68 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 14 (swi7: tty:sio clock) kernel: type 12 trap, code=0 Stopped at sched_choose+0x77: movl0x38(%eax),%eax I recall most if not all of these panics occuring when swi7: tty:sio clock is the current process. These are not completely repeatable, but if I simply reboot a couple of times, I can get the panic to occur while the rc scripts are being run. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devfs and /dev/fd/3
On Wed, Jun 04, 2003 at 03:30:19PM +0200, Marc Olzheim wrote: > Hi. > > I've seen the question once before, but it was not answered (on-list ?), > so now that I run in on it, I'd like to know what to do: > > On FreeBSD 4.x, without devfs, the following worked: > ( echo foo | tee /dev/fd/3 | tr f F ) 3>&1 > > It should produce both "foo" and "Foo" > > FreeBSD 5 with devfs, however, does not create a /dev/fd/3 upon opening > filedescriptor 3 by the shell, so there's no device to write to... > > How can I fix or circumvent this, aside from mounting a ufs partition > with mknod-ed files over /dev/fd ? You want fdescfs(5). -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Wed, Jun 04, 2003 at 07:29:31AM +, Nicolas Souchu wrote: > On Tue, Jun 03, 2003 at 10:54:30AM -0700, David P. Reese Jr. wrote: > > [...] > > : The datasheet states that the command bits are RW but "fixed at 0". > > > > A snip of code from sys/dev/pci/pci.c:pci_enable_io_method(): > > > > pci_set_command_bit(dev, child, bit); > > command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); > > if (command & bit) > > return (0); > > device_printf(child, "failed to enable %s mapping!\n", error); > > return (ENXIO); > > > > Because the viapropm's command register bits will always read as zero, > > this code will always fail when trying to enable port mapping. > > > > Whatever problems viapropm may have, it is the new pci code that prevents it > > from attaching. It is not the fault of anything in sys/pci/viapm.c. > > And I personally don't know how to fix it except by an option with an > ifdef to workaround it. How about adding another flag to bus_alloc_resource() which would signal that we are not to check the value of the command register after calling pci_set_command_bit(). RF_WILLFAIL? After pci_enable_io_method() gets swallowed into pci_alloc_resource(), this would be pretty easy because the flag would be in scope when we check the value of the command register. I can do so this weekend if anyone thinks this is worthwhile. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libmap.conf has the bug or not work correct?
On Tue, Jun 03, 2003 at 03:50:00PM -0500, Jeremy Messenger wrote: > I am trying to get ggv link against libc_r instead libthr, but it doesn't > work as expect.. Maybe, I must have done something wrong? Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c. It fixes a bug in the libmap.conf parsing code. > > # cat /etc/libmap.conf > libc_r.so.5 libthr.so.1 > libc_r.so libthr.so > > [/usr/X11R6/bin/ggv] > libc_r.so.5 libc_r.so.5 > libc_r.so libc_r.so > > [ggv] > libc_r.so.5 libc_r.so.5 > libc_r.so libc_r.so > > > > # uname -a > FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun 2 > 20:23:45 CDT 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ i386 > > > I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv then > reinstall them, but no luck. The ggv is still linking to libthr instead > libc_r.. Also, ggv isn't only one app that I tried. I did tried with gst- > register and no luck to change the link to libc_r. > > > # ldd /usr/X11R6/bin/ggv | grep libc >libc.so.5 => /usr/lib/libc.so.5 (0x28a68000) >libc_r.so.5 => /usr/lib/libthr.so.1 (0x28b49000) > ==== > > Do anyone have any hint? > > Cheers, > Mezz > > > -- > bsdforums.org 's moderator, mezz. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Tue, Jun 03, 2003 at 01:54:36AM -0500, Conrad Sabatier wrote: > > On 02-Jun-2003 Nicolas Souchu wrote: > > On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote: > >> > >> viapropm is seriously broken for other reasons and needs professional > >> help. > > > > What kind of breakage? Setting resources in probe? Right. Anybody having > > the viapm driver loaded usually should please try the attached patch. > > I'm sorry to report that those patches didn't fix the problem for me. They > all applied cleanly, I built a new kernel, but I still see the same > messages at boot. Couldn't enable port mapping. The problem is a disagreement with the new io_method code and the viapropm chip. From Nicolas Souchu's previous email: : The datasheet states that the command bits are RW but "fixed at 0". A snip of code from sys/dev/pci/pci.c:pci_enable_io_method(): pci_set_command_bit(dev, child, bit); command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); if (command & bit) return (0); device_printf(child, "failed to enable %s mapping!\n", error); return (ENXIO); Because the viapropm's command register bits will always read as zero, this code will always fail when trying to enable port mapping. Whatever problems viapropm may have, it is the new pci code that prevents it from attaching. It is not the fault of anything in sys/pci/viapm.c. -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote: > "David P. Reese Jr." <[EMAIL PROTECTED]> writes: > > In rev 1.214 of sys/dev/pci/pci.c, we have started checking if a > > pci_set_command_bit() was successful with a subsequent PCI_READ_CONFIG > > and comparing the results. For some odd reason, this doesnt work when > > my viapropm tries to attach. > > viapropm is seriously broken for other reasons and needs professional > help. It will be hard for me to provide that professional help because the chipset docs require an NDA. > > pci_set_command_bit(dev, child, bit); > > command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); > > if (command & bit) > > return (0); > > It should allow the register to "settle" between write and read, which > may take some time (see chipset docs for timing details). DELAY(1000) > should be OK in an attach function. Well, using the following patch: Index: pci.c === RCS file: /home/daver/cvs-freebsd/src/sys/dev/pci/pci.c,v retrieving revision 1.214 diff -u -r1.214 pci.c --- pci.c 16 Apr 2003 03:15:08 - 1.214 +++ pci.c 1 Jun 2003 02:45:11 - @@ -606,6 +606,9 @@ break; } pci_set_command_bit(dev, child, bit); +#define PCI_CFG_DELAY 1000 + device_printf(dev, "delaying for %i microseconds\n", PCI_CFG_DELAY); + DELAY(PCI_CFG_DELAY); command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2); if (command & bit) return (0); I get: viapropm0: SMBus I/O base at 0x5000 viapropm0: port 0x5000-0x500f at device 7.4 on pci0 pci0: delaying for 1000 microseconds viapropm0: failed to enable port mapping! viapropm0: could not allocate bus space device_probe_and_attach: viapropm0 attach returned 6 This seems to imply that we don't have a timing problem. Instead it looks like the chip doesn't want reflect it's status in it's command register. Can someone with access to the docs give me a clue? -- David P. Reese Jr. [EMAIL PROTECTED] -- It can be argued that returning a NULL pointer when asked to allocate zero bytes is a silly response to a silly question. -- FreeBSD manual page for malloc(3) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
viapropm doesnt like sys/dev/pci.c rev 1.214
In rev 1.214 of sys/dev/pci/pci.c, we have started checking if a
pci_set_command_bit() was successful with a subsequent PCI_READ_CONFIG
and comparing the results. For some odd reason, this doesnt work when
my viapropm tries to attach. Allocating its port resources fails in
pci_enable_io_method(). The code in question is:
sys/dev/pci/pci.c:pci_enable_io_method()
[snip]
pci_set_command_bit(dev, child, bit);
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
if (command & bit)
return (0);
device_printf(child, "failed to enable %s mapping!\n", error);
return (ENXIO);
What is annoying is that by changing the last line to return a zero instead
of ENXIO, the viapropm successfully attaches. The smbus interface even works.
Everything else that tries to claim port resources succeeds.
Is it my chipset's fault for not reading back the correct register value?
The board is a SOYO K7VTAPRO-2AA6. What other info would be helpful in
this situation?
[EMAIL PROTECTED]:7:4: class=0x068000 card=0x30571106 chip=0x30571106 rev=0x40
hdr=0x00
vendor = 'VIA Technologies Inc'
device = 'VT82C686A/B ACPI Power Management Controller'
class= bridge
subclass = PCI-unknown
--
David P. Reese Jr. [EMAIL PROTECTED]
--
It can be argued that returning a NULL pointer when asked to allocate
zero bytes is a silly response to a silly question.
-- FreeBSD manual page for malloc(3)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pam is chatty when logging in via ssh
On Mon, Feb 03, 2003 at 06:13:03AM -0600, Jacques A. Vidrine wrote:
> On Mon, Feb 03, 2003 at 01:54:45AM -0800, David P. Reese Jr. wrote:
> > On current as of about four hours ago, sshd spits the following to the console
> > after a successful login:
> >
> > Feb 3 01:41:29 metropolis sshd[550]: in _openpam_check_error_code():
>pam_sm_setcred(): unexpected return value 24
> >
> > It seems harmless, but pam doesnt sound happy. I did notice that mergemaster
> > updated /etc/pam/sshd by adding some krb5 lines.
>
> That's odd. Assuming that pam_krb5 is the module which is returning
> `24', I fixed that 4 days ago (Wed Jan 29 21:20:38 2003 UTC). Are you
> certain you have rebuilt pam_krb5? What is the output of `ident
> /usr/lib/pam_krb5.so' (should show revision 1.13 or later).
I cvsuped again to get des's recent changes and built world. After a fresh
install, when trying to ssh in i get:
Feb 3 05:02:36 metropolis sshd[3695]: in openpam_load_module(): no pam_krb5.so found
Feb 3 05:02:36 metropolis sshd[3695]: fatal: PAM: initialisation failed
It seems that {build,install}world forgot about pam_krb5.
[daver@metropolis:~]$ ll /usr/lib/pam_krb5*
ls: /usr/lib/pam_krb5*: No such file or directory
[daver@metropolis:~]$ cd /usr/src/lib/libpam/modules/pam_krb5/
[daver@metropolis:/usr/src/lib/libpam/modules/pam_krb5]$ sudo make clean obj all
install
...
[snip]
...
[daver@metropolis:/usr/src/lib/libpam/modules/pam_krb5]$ ll /usr/lib/pam_krb5*
lrwxr-xr-x 1 root wheel 13 Feb 3 05:05 /usr/lib/pam_krb5.so@ -> pam_krb5.so.2
-r--r--r-- 1 root wheel 19432 Feb 3 05:05 /usr/lib/pam_krb5.so.2
Then we try to ssh into the machine and,
Feb 3 05:08:14 metropolis sshd[3750]: in openpam_load_module(): no pam_krb5.so found
Feb 3 05:08:14 metropolis sshd[3750]: fatal: PAM: initialisation failed
[daver@metropolis:~]$ ident /usr/lib/pam_krb5.so|grep pam_krb5
/usr/lib/pam_krb5.so:
$FreeBSD: src/lib/libpam/modules/pam_krb5/pam_krb5.c,v 1.15 2003/02/03 09:45:41
des Exp $
> The `four hours' does indeed correspond to DES's enabling of pam_krb5
> by default in etc/pam.d/sshd.
As a workaround, i can disable krb5 by commenting out the two lines in
/etc/pam.d/sshd which contain pam_krb5.so. Then ssh works just fine.
--
David P. Reese Jr. [EMAIL PROTECTED]
--
C
You shoot yourself in the foot.
Assembler
You try to shoot yourself in the foot, only to discover you must first
invent the gun, the bullet, the trigger, and your foot.
How to Shoot Yourself in the Foot
<http://www.m5p.com/~pravn/foot.html>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
pam is chatty when logging in via ssh
On current as of about four hours ago, sshd spits the following to the console after a successful login: Feb 3 01:41:29 metropolis sshd[550]: in _openpam_check_error_code(): pam_sm_setcred(): unexpected return value 24 It seems harmless, but pam doesnt sound happy. I did notice that mergemaster updated /etc/pam/sshd by adding some krb5 lines. -- David P. Reese Jr. [EMAIL PROTECTED] -- C You shoot yourself in the foot. Assembler You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot. How to Shoot Yourself in the Foot <http://www.m5p.com/~pravn/foot.html> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
trouble building XFree86-4-Server under yesterday's current
Current as of yesterday
[daver@metropolis:/usr/ports/sysutils/xmbmon]$ uname -a
FreeBSD metropolis.gomerbud.com 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sun Sep 22
10:42:53 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/METROPOLIS
i386
The XFree86 server build dies with an odd compiler message. I have no clue
what it means.
[snip]
LD_LIBRARY_PATH=/usr/ports/x11-servers/XFree86-4-Server/work/xc/exports/lib cc -O
-pipe -march=pentium2 -march=pentium2 -ansi -pedantic -Dasm=__asm -Wall
-Wpointer-arith -fno-merge-constants -I. -I../include
-I/usr/ports/x11-servers/XFree86-4-Server/work/xc/exports/include/X11
-I../../../include
-I/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/include
-I/usr/ports/x11-servers/XFree86-4-Server/work/xc
-I/usr/ports/x11-servers/XFree86-4-Server/work/xc/exports/include
-I/usr/X11R6/include -DCSRG_BASED -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP
-DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER
-DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension
-DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE
-DBUILDDEBUG -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO
-DIN_MODULE -DXFree86Module-c miPck1Prim.c
miPck1Prim.c: In function `CheckFAreaPick1':
miPck1Prim.c:337: unable to find a register to spill in class `FLOAT_REGS'
miPck1Prim.c:337: this is the insn:
(insn 275 273 277 (set (subreg:SF (reg/v:DI 29 rmm0 [64]) 0)
(float:SF (mem/s/j:HI (reg/v/f:SI 2 ecx [61]) [0 .x+0 S2 A16]))) 167
{floathisf2} (insn_list 271 (nil))
(nil))
miPck1Prim.c:337: confused by earlier errors, bailing out
*** Error code 1
Stop in
/usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/PEX5/ddpex/mi/level1.
*** Error code 1
Stop in /usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver/PEX5.
*** Error code 1
Stop in /usr/ports/x11-servers/XFree86-4-Server/work/xc/programs/Xserver.
*** Error code 1
Stop in /usr/ports/x11-servers/XFree86-4-Server.
[daver@metropolis:/usr/ports/x11-servers/XFree86-4-Server]$
--
David P. Reese Jr. [EMAIL PROTECTED]
--
C
You shoot yourself in the foot.
Assembler
You try to shoot yourself in the foot, only to discover you must first
invent the gun, the bullet, the trigger, and your foot.
How to Shoot Yourself in the Foot
<http://www.m5p.com/~pravn/foot.html>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Cant see ACPI thermal zones on a Supermicro P6DBU
Does anyone know a reason why i should not see any info about the thermal zones on a Supermicro P6DBU in sysctl? I'm not even seeing the acpi_tz's in dmesg. As far as i know, the board does have thermal sensors. I can check the cpu temperatures in bios. If it would help, i could also provide the output of acpidump. dmesg: FreeBSD 5.0-CURRENT-20020917-JPSNAP #0: Sat Sep 21 22:08:13 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/METROPOLIS Preloaded elf kernel "/boot/kernel/kernel" at 0xc04a3000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04a30a8. Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbff real memory = 201195520 (196480K bytes) avail memory = 190021632 (185568K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 IOAPIC #0 intpin 16 -> irq 11 IOAPIC #0 intpin 18 -> irq 5 IOAPIC #0 intpin 19 -> irq 10 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-safe" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 pcib1: port 0xcf8-0xcff on acpi0 pci0: on pcib1 agp0: mem 0xf800-0xfbff at device 0.0 on pci0 pcib2: at device 1.0 on pci0 pci1: on pcib2 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: port 0xef80-0xef9f irq 10 at device 7.2 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered Timecounter "PIIX" frequency 3579545 Hz pci0: at device 7.3 (no driver attached) ahc_pci0: port 0xe800-0xe8ff mem 0xfebff000-0xfebf irq 11 at device 14.0 on pci0 aic7890/91: Ultra2 Wide Channel A, SCSI Id=7, 32/253 SCBs xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem 0xfebfef80-0xfebfefff irq 5 at device 18.0 on pci0 xl0: Ethernet address: 00:50:da:05:a6:62 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 fdc0: cmd 3 failed at out byte 1 of 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 fdc0: cmd 3 failed at out byte 1 of 3 orm0: at iomem 0xc8800-0xc8fff,0xc8000-0xc87ff,0xc-0xc7fff on isa0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 acpi_cpu: CPU throttling enabled, 8 steps from 100% to 12.5% ad0: 9787MB [19885/16/63] at ata0-master UDMA33 acd0: CDROM at ata1-master PIO4 Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! -- David P. Reese Jr. [EMAIL PROTECTED] -- C You shoot yourself in the foot. Assembler You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot. How to Shoot Yourself in the Foot <http://www.m5p.com/~pravn/foot.html> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
