Re: Anyone else seeing jumpy mice?
On Tue, 23 May 2000, Boris Popov wrote: > On Mon, 22 May 2000, Matthew Dillon wrote: > > > :> No, I don't mean rodents who've nibbled on chocolate-covered expresso > > :> beans, I mean PS/2 mice which fall victim to this new problem: > > : > > :> May 19 00:50:45 zippy /kernel: psmintr: out of sync (00c0 != ). > > : > > I got an email from Boris Popov in regards to getting more silo > > overflows after the SMP cleanup patch then before. > > > > One thing the patch removed was the hack that allowed certain interrupts > > (tty interrupts) to run in parallel with the supervisor. The patch seems to have completely broken fast interrupts. GET_FAST_INTR_LOCK is neither necessary nor sufficient as far as I can see. The necessary and sufficient locking is done by COM_LOCK() in individual drivers. The patch changed GET_FAST_INTR_LOCK from s_lock(&fast_intr_lock), which does nothing very well, to `sti(); get_mplock(); cli();', which essentially de-prioritizes "fast" interrupts from "higher than the highest" (higher than clock interrupts which are nominally highest) to "lower than the lowest" (lower than all normal interrupts, all software interrupts, and all MP-unsafe syscalls). > What is interesting in this case, is that this is the only active > serial port on this machine. And it is behind my understanding why PII-350 > can not process interrupts when the come at 11Khz rate max (and machine > idles most of the time). Some syscalls take more than 1 / 11000 seconds without blocking, and the interrupt handler is locked out while most syscalls are running. The necessary processing rate is actually only 5.5 KHz for 16550 UARTs with the default input fifo threshold of 2 below the fifo size. Untested fix: diff -c2 apic_vector.s~ apic_vector.s *** apic_vector.s~ Thu May 11 04:46:57 2000 --- apic_vector.s Tue May 23 16:37:52 2000 *** *** 10,24 #include "i386/isa/intr_machdep.h" - /* - * Interrupts must be enabled while waiting for the MP lock. - */ - - #define GET_FAST_INTR_LOCK\ - sti; call _get_mplock; cli - - #define REL_FAST_INTR_LOCK\ - movl$_mp_lock, %edx ; /* GIANT_LOCK */ \ - call_MPrellock_edx - /* convert an absolute IRQ# into a bitmask */ #define IRQ_BIT(irq_num) (1 << (irq_num)) --- 10,13 *** *** 49,55 FAKE_MCOUNT((5+ACTUALLY_PUSHED)*4(%esp)) ; \ pushl _intr_unit + (irq_num) * 4 ;\ - GET_FAST_INTR_LOCK ;\ call*_intr_handler + (irq_num) * 4 ; /* do the work ASAP */ \ - REL_FAST_INTR_LOCK ;\ addl$4, %esp ; \ movl$0, lapic_eoi ; \ --- 38,42 If this causes crashes, then try removing the INTR_FAST flag in sio.c so that normal interrupts are used. Normal interrupts are only blocked by certain other normal interrupts, and only a few devices and/or drivers are are broken enough to block interrupts for more than 1 / 5500 seconds. The main ones are IDE drives in PIO mode (or anything with large buffers in slow PIO mode), and keyboard LEDs (or anything that uses polled mode). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in advansys driver
At 11:52 +0400 23/5/00, Oleg Sharoiko wrote: >Hello! > >It seems that during porting to newbus architecture adv_attach was left >unchanged and current version (I mean the current version of -STABLE >sources, I didn't check -CURRENT) returns incorrect values (1 on success, 0 in >all other cases). FWIW -CURRENT is the same, but it looks like none of the calls check the return value anyway. -- Bob Bishop (0118) 977 4017 international code +44 118 [EMAIL PROTECTED]fax (0118) 989 4254 between 0800 and 1800 UK To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: cvs commit: src/sys/boot/i386/boot0 Makefile boot0.s boot0.m
On 23-May-00 John Baldwin wrote: > jhb 2000/05/23 05:18:49 PDT > > Modified files: > sys/boot/i386/boot0 Makefile boot0.s > sys/boot/i386/boot2 Makefile boot1.s > sys/boot/i386/btx/btx Makefile btx.s > sys/boot/i386/cdldr cdldr.s > sys/boot/i386/pxeldr pxeldr.s > Removed files: > sys/boot/i386/boot0 boot0.m4 > sys/boot/i386/boot2 boot1.m4 > sys/boot/i386/btx/btx btx.m4 > Log: > Clean up all of the 16-bit assembly code in the x86 bootstrap to work > with the new binutils. Now that we have a decent assembler, all the old > m4 macros are no longer needed. Instead, straight assembly can be used > since as(1) now understands 16-bit addressing, branches, etc. Also, > several bugs have been fixed in as(1), allowing boot0.s to be further > cleaned up. This should fix the world. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/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: Anyone else seeing jumpy mice?
On Tue, 23 May 2000, Bruce Evans wrote: > The patch seems to have completely broken fast interrupts. > GET_FAST_INTR_LOCK is neither necessary nor sufficient as far as I can see. > The necessary and sufficient locking is done by COM_LOCK() in individual > drivers. The patch changed GET_FAST_INTR_LOCK from s_lock(&fast_intr_lock), > which does nothing very well, to `sti(); get_mplock(); cli();', which > essentially de-prioritizes "fast" interrupts from "higher than the highest" > (higher than clock interrupts which are nominally highest) to "lower than > the lowest" (lower than all normal interrupts, all software interrupts, > and all MP-unsafe syscalls). Yes, this explains problems with sio. > Untested fix: Thank you. It works and no crashes experienced yet. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Detecting multiply function definitions
Why our ld is able to detect multiply defined functions only for static linking? What prevents us to use the same algorithm for shared linking too? It is very unsafe otherwise to do shared linking... -- Andrey A. Chernov <[EMAIL PROTECTED]> http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in advansys driver
On Tue, 23 May 2000, Bob Bishop wrote: BB> FWIW -CURRENT is the same, but it looks like none of the calls check the BB> return value anyway. Well. There was a message during the boot of kernel which notified that "adv0 device prove/attach returned 1" (or smt. like this). So I think the return code is checked somewhere and (what's more important) before the fix kernel seemed to hang at stage xpt_for_all_busses(xptconfigfunc, NULL); Just after displaying "Waiting 2 seconds for SCSI devices to settle" And I think that there should be no hangs even if attach failed so it's maybe good to check that code. (I was booting from atapi and adv was the only scsi adapter in the system) -- Oleg Sharoiko. Computer Center of Rostov State University. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in advansys driver
At 16:11 23/05/00 +0400, Oleg Sharoiko wrote: >On Tue, 23 May 2000, Bob Bishop wrote: > >BB> FWIW -CURRENT is the same, but it looks like none of the calls check the >BB> return value anyway. >Well. There was a message during the boot of kernel which notified that >"adv0 device prove/attach returned 1" (or smt. like this). So I think the >return code is checked somewhere and (what's more important) before the fix >kernel seemed to hang at stage xpt_for_all_busses(xptconfigfunc, NULL); You are on -STABLE, right? On -CURRENT it's been working fine for me, no complaining messages... >ed0: address 00:20:18:80:b4:6d, type NE2000 (16 bit) >adw0: port 0x6600-0x66ff mem >0xe000-0 >xe0ff irq 10 at device 12.0 on pci0 >adw0: SCSI ID 7, High & Low SE Term Enabled, LVD Term Enabled, Queue Depth 253 >fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 ... because the return value apparently isn't checked; which is why I posted (and included -current) in the first place. -- Bob Bishop +44 118 977 4017 [EMAIL PROTECTED]fax +44 118 989 4254 (0800-1800 UK) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[dickey@herndon4.his.com: Re: Incorrect exporting of trace() function (with patch)]
Peter, do you plan to commit official fix instead of mine one? I can try to do this by myself too. Forwarded message from "Thomas E. Dickey" <[EMAIL PROTECTED]> - Date: Tue, 23 May 2000 12:37:48 -0400 (EDT) From: "Thomas E. Dickey" <[EMAIL PROTECTED]> Subject: Re: Incorrect exporting of trace() function (with patch) To: "Andrey A. Chernov" <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED], [EMAIL PROTECTED] On Tue, 23 May 2000, Andrey A. Chernov wrote: > There is a namespace pollution preventing lots of application linking with I already addressed this in a patch a month or so ago. -- T.E.Dickey <[EMAIL PROTECTED]> http://dickey.his.com ftp://dickey.his.com - End forwarded message - -- Andrey A. Chernov <[EMAIL PROTECTED]> http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
:The patch seems to have completely broken fast interrupts. :GET_FAST_INTR_LOCK is neither necessary nor sufficient as far as I can see. :The necessary and sufficient locking is done by COM_LOCK() in individual :drivers. The patch changed GET_FAST_INTR_LOCK from s_lock(&fast_intr_lock), :which does nothing very well, to `sti(); get_mplock(); cli();', which :essentially de-prioritizes "fast" interrupts from "higher than the highest" :(higher than clock interrupts which are nominally highest) to "lower than :the lowest" (lower than all normal interrupts, all software interrupts, :and all MP-unsafe syscalls). It isn't quite that bad. Remember that interrupts are vectored to the cpu already running in supervisor mode, and the MP lock is recursive. So GET_FAST_INTR_LOCK will generally not block against MP-unsafe syscalls or anything else. It will still operate as a high-priority interrupt. I understand the point about COM_LOCK, and agree - but I also never trusted the MP-safeness of the fast-interrupt code hack so lets not commit this until we have a chance to audit the entire fast-interrupt path. Frankly, I would much rather see MP-safe NIC interrupt code then MP-safe serial interrupt code. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
Not to change the subject ,but mptable causes a panic on my machine running current. If I revert back to a kernel compiled on the 13th of May everything works fine. I think there were some changes made to the SMP code on the 14th or 15th also the binutils were upgraded and I'm not sure what caused it. With a current kernel I get this when booting: Programming 24 pins in IOAPIC #0 AP #1 (PHY# 12) failed! panic y/n [y] panic: bye-bye mp_lock = 0001; cpuid = 0; lapic.id = Uptime: 0s I'm going to check out a sys tree from the 14th and try rebuilding a kernel and see if that works. The kernel I have >>> Sun May 14 15:39:19 PDT 2000 works fine 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: Anyone else seeing jumpy mice?
On Tue, May 23, 2000 at 11:06:38AM -0700, Manfred Antar <[EMAIL PROTECTED]> wrote: > Not to change the subject ,but > mptable causes a panic on my machine running current. > If I revert back to a kernel compiled on the 13th of May everything works > fine. I think there were some changes made to the SMP code on the 14th or 15th > also the binutils were upgraded and I'm not sure what caused it. > With a current kernel I get this when booting: > > Programming 24 pins in IOAPIC #0 > AP #1 (PHY# 12) failed! > panic y/n [y] panic: bye-bye > mp_lock = 0001; cpuid = 0; lapic.id = > Uptime: 0s I've just completed world and compiled new kernel and found that my system reboots right after showing about seven lines of usual boot messages. I've found that UP GENERIC works and UP custom kernel works but SMP is broken. It has to do something with last three days of commits, because my last working SMP kernel is from Friday 19'th. Running mptable on the UP kernel doesn't cause crash for my system. Reboot is totally silent so I don't have any other info, sorry, I've only thought it happens about same time as the APIC probe. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Anyone else seeing jumpy mice?
At 09:00 PM 5/23/2000 +0200, Vallo Kallaste wrote: >On Tue, May 23, 2000 at 11:06:38AM -0700, Manfred Antar <[EMAIL PROTECTED]> wrote: > >> Not to change the subject ,but >> mptable causes a panic on my machine running current. >> If I revert back to a kernel compiled on the 13th of May everything works >> fine. I think there were some changes made to the SMP code on the 14th or 15th >> also the binutils were upgraded and I'm not sure what caused it. >> With a current kernel I get this when booting: >> >> Programming 24 pins in IOAPIC #0 >> AP #1 (PHY# 12) failed! >> panic y/n [y] panic: bye-bye >> mp_lock = 0001; cpuid = 0; lapic.id = >> Uptime: 0s > >I've just completed world and compiled new kernel and found that my >system reboots right after showing about seven lines of usual boot >messages. I've found that UP GENERIC works and UP custom kernel works >but SMP is broken. It has to do something with last three days of >commits, because my last working SMP kernel is from Friday 19'th. >Running mptable on the UP kernel doesn't cause crash for my system. >Reboot is totally silent so I don't have any other info, sorry, I've >only thought it happens about same time as the APIC probe. >-- I'm backing out to kernel sources as of the 13th and am building a kernel now. I'm running SMP. It's funny I had a kernel from Sunday 5/21 and it boot's fine and works in the SMP mode but mptable causes a panic. I just booted one from sources from the 13th same thing. I think this has something to do with the new binutils as a kernel built on the 14th and restored via tape works fine but if i check out the sys tree from the 14th and build a kernel it panics at the APIC probe. Or maybe I need to rebuild some library too from the 14th, I'm not sure if the kernel links to any library. I guess a good test would be to make world from before the binutil change and try a kernel built from that Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
> jake2000/05/23 13:41:02 PDT > Log: > Change the way that the queue(3) structures are declared; don't assume that > the type argument to *_HEAD and *_ENTRY is a struct. > > Suggested by: phk > Reviewed by:phk > Approved by:mdodd > HEADS UP Possible action required! Some drivers use headers from the installed system during the kernel build, and a make world, or at least make includes, is necessary before a new kernel can be built. LINT is affected by this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/boot/i386/boot0 Makefile boot0.s boot0.m
On Tue, May 23, 2000 at 08:20:48AM -0400, John Baldwin wrote: > This should fix the world. Whistler: I want peace on earth and good will toward man. Bernard Abbott: Oh this is ridiculous. Martin Bishop: He's serious. Whistler: I want peace on earth and good will toward man. Bernard Abbott: We are the United States Government. We don't do that sort of thing. Martin Bishop: You're just gonna have to try. Bernard Abbott: Ok, I'll see what I can do. Whistler: Thank you very much. That's all I ask. -- from the movie Sneakers -- Bill Fumerola - Network Architect / Computer Horizons Corp - CVM e-mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mpboot.s patch
> >> With a current kernel I get this when booting: > >> > >> Programming 24 pins in IOAPIC #0 > >> AP #1 (PHY# 12) failed! > >> panic y/n [y] panic: bye-bye > >> mp_lock = 0001; cpuid = 0; lapic.id = > >> Uptime: 0s [...] > I think this has something to do > with the new binutils as a kernel built on the 14th and restored via tape works fine >but if i > check out the sys tree from the 14th and build a kernel it panics at the APIC probe. Try the enclosed patch. - Tor Egge Index: sys/i386/i386/mpboot.s === RCS file: /home/ncvs/src/sys/i386/i386/mpboot.s,v retrieving revision 1.13 diff -u -r1.13 mpboot.s --- sys/i386/i386/mpboot.s 2000/01/29 13:51:17 1.13 +++ sys/i386/i386/mpboot.s 2000/05/24 01:28:53 @@ -165,20 +165,15 @@ BOOTMP1: NON_GPROF_ENTRY(bootMP) + .code16 cli CHECKPOINT(0x34, 1) /* First guarantee a 'clean slate' */ - data32 xorl%eax, %eax - data32 movl%eax, %ebx - data32 movl%eax, %ecx - data32 movl%eax, %edx - data32 movl%eax, %esi - data32 movl%eax, %edi /* set up data segments */ @@ -188,17 +183,18 @@ mov %ax, %fs mov %ax, %gs mov %ax, %ss - mov $(boot_stk-_bootMP), %sp + mov $(boot_stk-_bootMP), %esp /* Now load the global descriptor table */ addr32 data32 - lgdtMP_GDTptr-_bootMP + /* XXX: sigh: lgdt MP_GDTptr-_bootMP GAS BUG! */ + .byte 0x0f, 0x01, 0x15/* XXX hand assemble! */ + .long MP_GDTptr-_bootMP /* XXX hand assemble! */ /* Enable protected mode */ data32 movl%cr0, %eax - data32 orl $CR0_PE, %eax data32 movl%eax, %cr0 @@ -207,13 +203,11 @@ * make intrasegment jump to flush the processor pipeline and * reload CS register */ - data32 pushl $0x18 - data32 pushl $(protmode-_bootMP) - data32 - lret + lretl + .code32 protmode: CHECKPOINT(0x35, 2)
IP Filter 3.4.4 imported.
Greetings, I've updated IP Filter in the FreeBSD-current sources to Version 3.4.4 (which isn't yet released, now that I think about it :*) I would apprecate some feedback from people who are able to run and test this so its suitability for importing onto the 4.0_STABLE branch can be determined. Cheers, Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.csrc/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
On Tue, 23 May 2000, Jake Burkholder wrote: > > jake2000/05/23 13:41:02 PDT > > Log: > > Change the way that the queue(3) structures are declared; don't assume that > > the type argument to *_HEAD and *_ENTRY is a struct. > > > > Suggested by: phk > > Reviewed by: phk > > Approved by: mdodd > > > > HEADS UP > > Possible action required! > > Some drivers use headers from the installed system during the kernel build, > and a make world, or at least make includes, is necessary before a new kernel > can be built. > > LINT is affected by this. Is anyone else having trouble compiling the libpam things, because of this? I couldn't compile a kernel because of the the assembler changes, so I went to do a buildworld, and now I can't get thru a buildworld. I tried the suggestion above (do a make includes) but that didn't seem to do the trick. Here's about the first 5 of the 30 (or so) errors I see: cc -O -pipe -mpentium -Wall -I/usr/src/lib/libpam/modules/pam_ssh/../../../../cr ypto/openssh -c /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/p am_ssh/pam_ssh.c -o pam_ssh.o /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c :89: syntax error before `env_entry' /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c :93: syntax error before `env_entry' /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c : In function `env_new': /usr/src/lib/libpam/modules/pam_ssh/../../../../crypto/openssh/pam_ssh/pam_ssh.c :116: structure has no member named `slh_first' / It all seems to do with the new queue.h, which is indeed installed in my /usr/include/sys (newly installed, I checked, after the make includes). Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
$B2>EPO?$O#67n#5F|$^$G!*:#$J$iA@$((B$B$k7n<}#1#2#0#0K|(B
$B2>EPO?$O#67n#5F|$^$G!*:#$J$iA@$($k7n<}#1#2#0#0K|!*(B $BFMA3%a!<%k$rAw$i$;$FD:$$$?$3$H$r?<$/$*OM$S$$$?$7$^$9!#(B$B6=L#$N$J$$J}$O$*5v$7$/$@$5$$!#$3$N$^$^:o=|$7$F$/$@$5$$!#(B$B$?$$$X$s?=$7Lu$4$6$$$^$;$s$G$7$?!#(B $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B $B%$%s%?!<%M%C%H%S%8%M%9$G!"(B$B>o$K%"%a%j%+$KCY$l$r$H$C$F$$$?F|K\$G$b!"$D$$$K!"(B$B?.$8$i$l$J$$Bg4k6H$K$h$k;qK\!u5;=QDs7H$G@$3&@oN,$,%9%?!<%H$5$l$^$9!#(B $B$?$@$7>e5-$N;qK\;22C!u5;=QDs7H4k6HL>$O!"(B$B8=:_$O$^$@?eLL2<$N3hF0CJ3,$G$9$N$G!"@5<0$K$O30ItH/I=$5$l$F$$$^$;$s!#(B$B $B$=$7$F@oN,E*$KCmL\$9$Y$-$G$"$j!":#2s$*EA$($7$?$$$3$H$O!"(B$B$3$NATBg$J;v6H$,!"@$3&E*$J%l%Y%k$G$N;v6H3HBg%9%T!<%I$r:G=EMW;k$7!"(B$B$J$s$H!"#M#L#M%7%9%F%`$G$N $B$D$^$j;qK\NO$N$J$$8D?M$G$b!"(B$B$"$J$?$G$b!"$3$N;v6H$K;22C$9$k$3$H$,$G$-$k$N$G$9!*(B$B$b$A$m$sK!?M$G$N;v6H;22C$b2DG=$G$9!#%@%$%J%_%C%/$K3hF0$G$-$k$G$7$g$&!#(B $B?72q$O#S#T#A#R#W#E#B#2#1(B $B@5<0$J%S%8%M%9%9%?!<%H$O#2#0#0#0G/#77n#1F|$G$9!#(B $B8=:_$O>R2pEPO?$N $B$D$^$j:#$3$N>pJs$rCN$C$F$$$kJ}$O!"$^$5$K4q@W$N%?%$%_%s%0$J$N$G$9!#(B $B:#$J$i$"$J$?$b2>EPO?$K;22C$G$-$k!J#67n#5F|Kx!K%S%C%0%A%c%s%9$G$9(B! $B$$$^2>EPO?$r$G$-$l$P!"$[$\2q7k$N>uBV$G$"$k$3$H$r$*EA$($7$F$*$-$^$9!#(B $B8=:_!"2>EPO?$N$?$a$N%"%/%;%9=8Cf$,$9$4$$>uBV$K$J$C$F$$$^$9$N$G!"(B $B>/$7A0Kx$O!"$J$+$J$+7R$,$j$^$;$s$G$7$?$,!"5pBg%5!<%P!<$KJQ99$5$l!"(B $B8=:_$O2wE,$KEPO?$9$k$3$H$,$G$-$^$9!#:#$,2>EPO?3MF@$N%A%c%s%9!*$G$9!#(B $B#M#L#M$N>o<1$G$9$,!"(B$B@h$KEPO?$G$-$l$P!"$=$l$@$1B?$/>!$B:#$J$i$P!"$"$J$?$NEXNO $B$^$5$KAa$$$b$N>!$A$N>u67$G$9$N$G!"$_$J$5$sI,;`$G%"%/%;%9$5$l$F$$$^$9!#(B $B;d$NM'?M$O!"$3$N(B1$B=54V$@$1$G%@%&%s$,>!$r%*!<%P!<$7$^$7$?!#(B $BD>@\>R2p$7$?$N$O!"$[$s$N?tL>$G$"$k$N$K!&!&!&$G$9!#(B $B$^$5$K%$%s%?!<%M%C%H;~Be$N?7%S%8%M%9$G$9!#(B $B;d$O;v$B$A$J$_$K;d$O2a5n$K$*$$$F!"#M#L#M$K $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B$B#M#L#M$@$+$i$H8@$C$F!"@hF~4Q$r$b$?$J$$$h$&$K$7$F$/$@$5$$!#(B$B$1$C$7$F=>Mh$N7r9/?)IJ4XO"$J$I$K$"$j$,$A$J!"(B$B$$$+$,$o$7$$OC$H$O0l@~$r2h$7$?$b$N$G$"$k$3$H$r$4M}2r$/$@$5$$!#(B $B$H$O8@$$$D$D$b!";d$K$b#M#L#M$X$N@hF~4Q$O$"$j$^$7$?!#(B$BEvA3$J$,$iM'?M$+$iOC$r?.H>5?$G$7$?!#(B$B$7$+$7:#$O0c$$$^$9!#7r9/?)IJ$H#e%3%^!<%9$G$O!"A4$/;v>p$,JQ2=$7$^$9!#(B $B$h$/$*9M$($/$@$5$$!#(B$B;v6H3HBg%9%T!<%I$,A4$F$r@)$9$k%$%s%?!<%M%C%H$N@$3&$K$*$$$F!"(B$B@$3&Cf$N8D?M$r:GBg8B3hMQ$G$-$k#M#L#M$[$I9gCW$7$?$b$N$O$"$j$^$;$s!#(B $B$A$J$_$K#47n#2#6F|H/Gd$N!c#B!]#i#n#g!d$H!c$H$i$P!<$f!d(B $B$=$7$F!!#57n#1#0F|H/Gd$N!c#B!]#i#n#g!d$G$b5a?M9-9p$,7G:\$5$l$^$7$?!#(B $B$$$+$,$o$7$$CDBN$N%S%8%M%9$G$O@dBP$K$J$$$3$H$N>ZL@$G$b$"$j$^$9!#(B $B$3$N$B5a?M9-9p$N$B$h$[$I$N4k6H$G$J$1$l$P!"@dBP$KIT2DG=$J$3$H$@$H$$$&$3$H$G$9!#(B $B!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a!a(B$B$3$N$h$&$K8=:_$O!c#C#P>R2pEPO?4|4V!d$N$?$a!"(B $BHs>o$K8B$i$l$?>pJs$NCf$GH=CG$7$F$$$?$@$/$7$+$"$j$^$;$s!#(B $B$=$l$G$b2r$C$F$$$?$@$1$kJ}$K$7$+%A%c%s%9$O$3$J$$$H$$$&$3$H$G$9!#(B $BEvA3$J$,$i#67n#5F|$^$G$N2>EPO?4|4VCf$OEPO?HqMQ$O$+$+$j$^$;$s!#(B $BL5NA$G2>EPO?$r:Q$^$;$F$*$-!"#77n#1F|%9%?!<%H$7$F$+$i$b!"(B $B$b$7!"ITK~$,$"$l$P%/!<%j%s%0%*%U!J#8F|4V!K$b$G$-$^$9!#(B $B8=CJ3,$G$O<+:n%[!<%`%Z!<%8Ey$G$N@kEA$O6X;_$5$l$F$^$9$7(B $B%i%j!<$d%_!<%F%#%s%0$N$h$&$J3hF0$b8=:_9T$o$l$F$$$^$;$s!#(B $B$f$($K8XBg$JI=8=$N4+M6$,HEMt$7$F$$$^$9$,OG$o$5$l$J$$$G$/$@$5$$!#(B $B$7$+$7$J$,$i!"%S%C%0%A%c%s%9$G$"$k$3$H$K$O4V0c$$$"$j$^$;$s!#(B $B$3$N%a!<%k$r$BEXNO$7$@$$$G!"7n<}#1#2#0#0K|1_$O==J,$K2DG=$J$O$:$G$9!#(B $B4pK\E*$K$O#H#P%9%Z!<%9$N%l%s%?%k$r$O$8$a(B$B$"$j$H$"$i$f$k#e%3%^!<%9%S%8%M%9$r$B$=$l$,#M#L#M%7%9%F%`$G:FG[J,$5$l$k$H$$$&2h4|E*$J%S%8%M%9$G$9!#(B $B%*%s%i%$%s%^%H%j%C%/%9$G$9$+$i!"%@%&%s$,$+$C$F$K>e$+$i9_$j$F$-$^$9!#(B $BA4$/EXNO$;$:$K@.8y$9$k$[$I!"4E$/$O$J$$$G$7$g$&$,!&!&!&(B $B%$%s%?!<%M%C%H$K$D$J$,$k4D6-$5$(;}$C$F$$$l$P@$3&E*%S%8%M%9$,2DG=$G$9!#(B $B#H#P%9%Z!<%9%l%s%?%kHNGd$K4X$7$F$N%3%_%C%7%g%s$O=5J'$$$G#3#0#0K|1_$^$G!#(B $BJs=7$N;YJ'J}K!$O%P%$%J%j!]$H%^%H%j%C%/%9!"$5$i$K%*!<%S%C%HJ}<0$G$9!#(B $B$o$+$k$R$H$K$O$o$+$k!"9M$($&$k:G9b$N%7%9%F%`$G$9!#(B == $B%5!<%S%9$NFbMF$O(B $B%$%s%?!<%M%C%H=i?4e5i$B$3$l$@$1B7$C$FG/2qHq(B\10,000$B!JF~2qHq(B\1,550$BJL!K$G$9!#(B $B-!#2#0%a%,0J>e$N%[!<%`%Z!<%8(B $B-"4JC1$G$*$7$c$l$J:n@.%D!<%k(B $B-#(BE$B%3%^!<%9(B $B-$%W%m%P%$%@!<%5!<%S%9(B $B-%40`z$J%+%9%?%^!<%5!<%S%9Ey(B $B$5$^$6$^$J6HBV$r4^$`Am9g%S%8%M%9$G$9!#(B $B2?EY$b?=$7>e$2$^$9$,(B $B8=:_$^$@2>EPO?$NJg=8$J$N$G$*6b$O$+$+$j$^$;$s!#(B $B$*;YJ'$$$O#67nCf=\$G$9!#2q$B#77n$N@$3&0l@F%0%i%s%I%*!<%W%s;~$KEPO?$9$k$+$I$&$+7h$a$F2<$5$$!#(B $BK\EPO?$N:]$NEPO?HqMQ$O!o#1#1(B,$B#5#0#0$@$1!JG/4V!K0l?M0l8}8BDj$G$9!#(B $B$?$@$7!"2q5BzI,MW!K$NEPO?$b#O#K$G$9!#(B $B2>EPO?$GM-Mx$J%]%8%7%g%s$N3NJ]$r$7$F$*$$$FM_$7$$$N$G$9!#(B =
Re: HEADS UP Re: cvs commit: src/crypto/openssh/pam_ssh pam_ssh.c src/gnu/usr.bin/binutils/gdb freebsd-uthread.c src/include mpool.h src/lib/libc/net name6.c src/lib/libc_r/uthread pthread_private.h uthread_file.c src/lib/libncp ncpl_rcfile.c src/lib/libstand if_ether.h ...
>
> Is anyone else having trouble compiling the libpam things, because of
> this? I couldn't compile a kernel because of the the assembler changes,
> so I went to do a buildworld, and now I can't get thru a buildworld. I
> tried the suggestion above (do a make includes) but that didn't seem to do
> the trick. Here's about the first 5 of the 30 (or so) errors I see:
>
I've just built a fresh world here; if you use the cvs-crypto from
internat, it may be broken. I submitted a patch to Mark Murray which
should fix it, here it is again just in case:
Index: crypto/openssh/pam_ssh/pam_ssh.c
===
RCS file: /home/ncvs/src/crypto/openssh/pam_ssh/pam_ssh.c,v
retrieving revision 1.4
diff -u -r1.4 pam_ssh.c
--- crypto/openssh/pam_ssh/pam_ssh.c2000/03/29 08:24:37 1.4
+++ crypto/openssh/pam_ssh/pam_ssh.c2000/05/22 18:14:51
@@ -86,11 +86,11 @@
* environ at an array of one element equal to NULL).
*/
-SLIST_HEAD(env_head, env_entry);
+SLIST_HEAD(env_head, struct env_entry);
struct env_entry {
char*ee_env;
- SLIST_ENTRY(env_entry) ee_entries;
+ SLIST_ENTRY(struct env_entry)ee_entries;
};
typedef struct env {
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mpboot.s patch
At 04:33 AM 5/24/2000 +0200, [EMAIL PROTECTED] wrote: >> >> With a current kernel I get this when booting: >> >> >> >> Programming 24 pins in IOAPIC #0 >> >> AP #1 (PHY# 12) failed! >> >> panic y/n [y] panic: bye-bye >> >> mp_lock = 0001; cpuid = 0; lapic.id = >> >> Uptime: 0s > >[...] > >> I think this has something to do >> with the new binutils as a kernel built on the 14th and restored via tape works >fine but if i >> check out the sys tree from the 14th and build a kernel it panics at the APIC probe. > >Try the enclosed patch. > >- Tor Egge Tor Works great The patch didn't apply I think there is a "data32" in the patch that isn't in the mpboot.s file but when I applied the patch manually an added the data32 the kernel built fine and boots both cpu's without a problem. although mptable still causes a panic : panic: pmap_enter: attempted pmap_enter on 4MB page mp_lock = 0002; cpuid = 0; lapic.id = boot() called on cpu#0 Thanks 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: cvs commit: src/contrib/ncurses/include curses.h.in src/contrib/ncurses/ncurses/trace lib_trace.c
On Wed, May 24, 2000 at 02:09:24PM +1000, Bruce Evans wrote: > > Previously it breaks system's /bin/sh so sh's trace() was wrongly renamed to > > sh_trace() instead of fixing ncurses. > > FYI, it may also break ftp, but the problem is only visible when ftp is linked > static, due to the problem with dynamic linkage in ld: > > /usr/src/usr.bin/ftp/cmds.c:906: warning: initialization makes integer from >pointer without a cast > /usr/libexec/elf/ld: Warning: size of symbol `trace' changed from 4 to 5 in >lib_trace.o > /usr/libexec/elf/ld: Warning: type of symbol `trace' changed from 1 to 2 in lib_trace.o Yes, this bug is very dangerous and many places are affected so I fix it immediately. The fact our ld can't detect multiply definitions when linking shared is another issue - I recently send this to -current, but still got no reaction. -- Andrey A. Chernov <[EMAIL PROTECTED]> http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/contrib/ncurses/include curses.h.in src/contrib/ncurses/ncurses/trace lib_trace.c
"Andrey A. Chernov" wrote: > On Wed, May 24, 2000 at 02:09:24PM +1000, Bruce Evans wrote: > > > Previously it breaks system's /bin/sh so sh's trace() was wrongly renamed to > > > sh_trace() instead of fixing ncurses. > > > > FYI, it may also break ftp, but the problem is only visible when ftp is lin ked > > static, due to the problem with dynamic linkage in ld: > > > > /usr/src/usr.bin/ftp/cmds.c:906: warning: initialization makes integer from pointer without a cast > > /usr/libexec/elf/ld: Warning: size of symbol `trace' changed from 4 to 5 in lib_trace.o > > /usr/libexec/elf/ld: Warning: type of symbol `trace' changed from 1 to > 2 in lib_trace.o > > Yes, this bug is very dangerous and many places are affected so I fix > it immediately. > > The fact our ld can't detect multiply definitions when linking shared is > another issue - I recently send this to -current, but still got no reaction. This is by design. The symbol search order for dynamic linking is very clearly defined, and you *can* have lots of duplicate symbols. 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
