Re: SCSI hangs w/SuperMicro 6010H
John Baldwin wrote: > Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try > this: find the ahc driver's interrupt handler, and add a printf. > Then see if the printf fires while the machine is hung. Ok, I put a printf in ahc_handle_seqint() and ahc_handle_scsiint(). My current (freshly cvsupped sources) kernel with the printf()s in it is pretty consistent in it's behavior: with SMP it hangs soon after the 15 second SCSI delay and keystrokes will not cause it to continue to boot. The order that they print out on the screen is this: message "Waiting 15 seconds for SCSI devices to settle" (approximately 15 second delay) 26 times scsiint called with intstat = 0x4, status0 = 0, status = 0x88 (SELTO & BUSFREE?) 2 times seqint called with instat = 0x71 (BAD_STATUS?) 36 times seqint called with intstat = 0x61 (HOST_MSG_LOOP?) and then the system hangs. I have gone back to a SMP kernel from April 15th - using a GENERIC kernel with SMP enabled it exhibits the same problem. Will work my way back to -stable and see if anything changes... dave c -- Dave Cornejo @ Dogwood Media, Fremont, California (also [EMAIL PROTECTED]) "There aren't any monkeys chasing us..." - Xochi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal
I got same backtrace.
Additional daemons: syslogdlock order reversal
1st 0xc044fc80 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:1007
2nd 0xcb1ef8ac vnode interlock @ ../../ufs/ffs/ffs_vfsops.c:1016
Debugger("witness_lock")
Stopped at Debugger+0x44: pushl %ebx
db> trace
Debugger(c038c22e) at Debugger+0x44
witness_lock(cb1ef8ac,8,c03a86d9,3f8) at witness_lock+0x90d
ffs_sync(c10cca00,3,c0cd3e00,c9908dc0,c10cca00,2) at ffs_sync+0x175
sync_fsync(ca368f5c) at sync_fsync+0x18f
sched_sync(0,ca368fa8) at sched_sync+0x16c
fork_exit(c0226ef4,0,ca368fa8) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
db>
--
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
<[EMAIL PROTECTED]> // FreeBSD Project
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: CPUTYPE warning
"Karsten W. Rohrbach" wrote: > > btw, regarding gcc's -O2 optimization breakage on -2.95.x and improved > instrumentation of the new compiler kit, is there someone working on > getting gcc-3.0 into -current? > > ...yes *sigh* i know, 3.0 is _not_ stable, neither is -current ;-) Does it do tail-call optimization? Last I checked, this was only supported under i986. It would be a _SERIOUS_ win, for a lot of stuff. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
¶W¸£¤O¤ß´¼¬ì§Þ
¿Ë·RªºªB¤Í; ¦b¦¹´£¨Ñ2001¦~³Ì·s¸£¤O¶}µo§Þ³N
«e¨¥:
®Ú¾Ú¬ì¾Ç¬ã¨sÅã¥Ü¡A§Ṳ́HÃþ¤j¸£¥i§l¦¬°O¾Ð2000¸U¥»¹Ï®Ñ¤j·§10ӹϮÑÀ]
¤§¶q¡A¥un²ß±o¥¿½Tªº°O¾Ð¤èªk¡A¥²¯à±N§Ṳ́j¸£µo´§²OºvºÉP¡A¹ï¤H¡A¨Æ
¡Aª«¥t¦³¤@µf¤£¦P¨¤«×¨£¸Ñ¡AÂǦ¹½Òµ{¦@¦P±´¯Á¤j¸£¤F¯«©_¡C
¡·"§Ú̪º±M·~
§Ų́㦳¥¿²Îªº^°êMind Maps¤ß´¼Ã¸¹Ïªkªº±Â½ÒÃҮѡA±Ð±z¾Ç²ß±¹ï21¥@¬ö
ªºÄvª§¥²³Æªº§Þ¥©¡B±´¯ÁÁA¸Ñ§Ú̯«©_ªº¤j¸£¡A½Õ¾ã¾Ç²ßªº¹LÂo¾¹"¶W±j°O¾Ð"
¾Ç²ß¤ß´¼¹Ïªº³W«h¤Î¦p¦ó¹B¥Î¤ß´¼Ã¸¹Ï Mind Maps
ªº¤èªk¥´³y¤@Áûª÷ÀY¸£¥Hªï±µ21¥@¬öªº¬D¾Ô¡B°l¨D¥þ¤è¦ì¦¨¥\ªº¤H¥Í¡C
¡·"§Ú̪º¥Øªº
¬°±Ð¾É¥¿½Tªº¾Ç²ß°O¾Ð¤è¦¡¡A¨Ï©ÒŪªº¬ì¥Ø¥i§¹¥þªº°O¦í¤Î¹B¥Î¡A´î¤Ö¾Ç²ß¤§
®À§é·P¡A¨Ã´£°ª§A¾Ç²ßªº¿³½ì¡C
¤HÃþªº¤j¸£¥u¥Î¨ì3%~6%©|¦³94%¥H¤W³£¨S°V½m¶}µo¨Ï¥Î¡C
§Ú̹B¥Î¤@®M«e±Mªù°V½m±¡³ø¤Hûªº¤èªk¡A²×¥Í¨ü¥ÎµL½a¡A¦p°O¡G
©m¦W¡B¹q¸Ü¡(«P¶i¤H»ÚÃö«Y¡^¡BI³æ¦r¡B¾Ç»y¨¥¡B°O¤½¦¡¡B¾ú¥v¡B¦a²z µ¥
·Ó§Ú̱ЧAªº¤èªk¡A¥u»Ý30%ªº®É¶¡¡A¹F¦¨¦Ê¤À¤§¦Êªº¥\®Ä¡A¥un¦³¤ß¦¨ªø¡A
±q10·³¡ã75·³¬Ò «OÃÒ¼W¥[2~15¿¥H¤Wªº°O¾Ð¤O(°ò¦°V½m)¡C
§A·Q¾Ö¦³¶W±j¹L¤Hªº°O¾Ð¶Ü¡H
¹B¥Î¶W±j°O¾Ð°V½m¡B¤ß´¼ ¹Ï°V½m¤ÎÀu¶Õ¸£ªi°V½m¡A
¥i¥HÅý§Aªº°O¾Ð¤O¥ß¨è´£¤É2~15¿¡C§AÁÙ¦b¬Ý¶Ü¡H§OµS¿Ý»°§Ö¦æ°Ê
Åwªï¦³§Ó°l¨D¥þ¤è¦ì¦¨¥\¤§¦U¬ÉªB¤ÍÄâ®a(ªB)±a²²(¤Í)°Ñ¥[ª÷ÀY¸£°ò¦°V½m
½Òµ{¡A¸Ô²Ó±¡§Î½Ð¤Wºô¬d¸ß: http://98.to/super2100 ©ÎÀH«Hªþ¥ó
µ¹¦Û¤v·Q¤@Ó¨Ó¤W½Òªº²z¥Ñ:
¥Î³}®Ñ§½ªº®É¶¡¤Î¶R¤@¥»®Ñªº¿ú¡A°Ñ¥[§ÚÌÁ|¿ìªº°ò¦½Òµ{¡A
«OÃÒ±z°O¾Ð¤O´£¤É2-15¿¡A(±z¦h¤[¨S¤W®Ñ§½¶R®Ñ¤F©O?)µ´¹ïÅý±zª«¶W©ÒÈ¡C
¡@
§Ú̱N¤£©w´Á¦b¥x¥_¡A®ç¶é ¡A·s¦Ë¡A]®ß¡A¥x¤¤¡A°ª¶¯Á|¿ì¥Ü½d½Òµ{,Åwªï¨Ó¹q¹w¬ù
°ª¶¯:7¤ë¥÷¶}½Ò¤é´Á¤À§O¬°:7/4¬P´Á¤T¡A7/13¬P´Á¤¡A7/26¬P´Á¥|
¥x¤¤Á`¤½¥qTEL¡G04-23165310 FAX:04-23165315 ¬¢ÂŤp©j
°ª¶¯¤À¤½¥qTEL¡G07-38613730955045803 ¬¢ÂÅ¥ý¥Í
¥þ¬Ù¨ä¥L¦a°Ï ½Ð¬¢ 0965-129085
¥»°T®§¬O©e°Uµo°e¡A½Ð¤£nª½±µ¦^ÂÐ¥»«H¡A¦pªG±z¤£·Q¦A±µ¦¬
¥»°T®§¡A½Ð¦^«H¦Ü¥H¤U«H½cE-mail«H½c¡G:[EMAIL PROTECTED]::
¦p¦³¥´ÂZ±z¤§³B¡A½Ð¦h¦h¥]²[¡AÁÂÁ¡I¡I
Title: ·sºô¶9
½Ð±N¦¹ªí®æ¦C¦L塡¼g«á¶Ç¯u¦Ü04-23165315¥x¤¤Á`¤½¥q¹w¬ù,¥»¤½¥q±N¦w±Æ¤Î§iª¾°ò¦½Òµ{®É¶¡ªí»P¦U¿¤¥«¤W½Ò¦aÂI,»P±z±µ¬¢ªA°È.ÁÂÁÂ!
¡@
§Ún°Ñ¥[¦aÂI:
¥k¸£®Ä¯à°V½m°ò¦½Òµ{¡@
°ª¶¯ºô¯¸
¥x¥_¡A·s¦Ë¡A®ç¶é¡A¥x¤¤¡A°ª¶¯¨C³õ¤G¤Q¤H¡A¨C¬P´Á¥u¶}¤@¦¸¡A½Ð´£«e¹w¬ù¡AÁÂÁ¡I¡@
©m¦W;
Ápµ¸¹q¸Ü:¡@¡@
¡@
¡@
¦í§};
¤u§@©Ê½è
¾Ç¥Í¤½°Ó¡@
¤uªA°È·~¡@
¦~ÄÖ:¡@
³Æµù¡G¡@
¡@Àu´f½s¸¹¡G00560303¡@
1.¾Ì¦¹¤W½Òµýú¥æ350¤¸Á¿¸q¶O¡A³õ¦a¶O 2.µL¤W½ÒµýªÌ¤W½Ò«e»Ýú¥æ1500¤¸¬ã²ß¶O
¥x¤¤Á`¤½¥qTEL¡G04-23165310 FAX:04-23165315
¬¢ÂŤp©j
°ª¶¯¤À¤½¥qTEL¡G07-3861373
0955045803
¬¢ÂÅ¥ý¥Í
¥þ¬Ù¨ä¥L¦a°Ï½Ð¬¢ 0965-129085
ÂÅ¥ý¥Í ©Î¨Ó«H
Re: cannot print to remote printer
At 2:42 PM +0200 6/22/01, Georg-W. Koltermann wrote:
>Hi,
>
>with current as of June 20 I can no longer print to a remote printer.
>Syslog says "filter 'f' exited (retcode=108)".
Looking at that section of code, lpd is just doing:
if (ifilter < 0)
status.w_retcode = 100;
else
while ((pid = wait((int *)&status)) > 0 &&
pid != ifilter)
;
followed by some code which would not modify 'status', followed by:
switch (status.w_retcode) {
case 0:
break;
case 1:
unlink(tfile);
return(REPRINT);
case 2:
unlink(tfile);
return(ERROR);
default:
syslog(LOG_WARNING, "%s: filter '%c' exited"
" (retcode=%d)",
pp->printer, format, status.w_retcode);
unlink(tfile);
return(FILTERERR);
}
If you got 'retcode=108' (not 100), then lpd is just printing out
the status as returned by 'wait()'. I don't see any recent changes
to that section of code in lpd.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal
tacho> lock order reversal tacho> 1st 0xc03f0140 mntvnode @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1007 tacho> 2nd 0xcaec972c vnode interlock @ /usr/src/sys/ufs/ffs/ffs_vfsops.c:1016 matusita> Exactly the same kernel message was here. ddb trace output is as follows. db> trace Debugger(c02bd5ae) at Debugger+0x44 witness_lock(c5ce622c,8,c02cde39,3f8) at witness_lock+0x90d ffs_sync(c089f200,3,c05adc00,c5420200,c089f200,2) at ffs_sync+0x175 sync_fsync(c5831f5c) at sync_fsync+0x18f sched_sync(0,c5831fa8) at sched_sync+0x16c fork_exit(c01e839c,0,c5831fa8) at fork_exit+0xb4 fork_trampoline() at fork_trampoline+0x8 db> -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal
On 22-Jun-01 Makoto MATSUSHITA wrote: > > jhb> Can you turn on WITNESS_DDB in your kenrel config file (or set > jhb> the debug.witness_ddb loader tunable/sysctl before you get this > jhb> reversal) and get a backtrace from ddb? > > Yes; I turned 'debug.witness_ddb' on now. I'll send a ddb 'trace' > output if next time lock-order-reversal is happen. You will have to reboot for it to fire. We only report the first lock order found between two locks to avoid flooding the console. -- 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: lock order reversal
jhb> Can you turn on WITNESS_DDB in your kenrel config file (or set jhb> the debug.witness_ddb loader tunable/sysctl before you get this jhb> reversal) and get a backtrace from ddb? Yes; I turned 'debug.witness_ddb' on now. I'll send a ddb 'trace' output if next time lock-order-reversal is happen. -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with ata probing twice.
sos> Well, sortof, the ata driver doesn't allow for sharing irq14&15
sos> since lots of boards doesn't work that way. However if you need
sos> it you can try to add the shared flag in the driver and see if
sos> it works on yours.
I've changed src/sys/dev/ata/ata-pci.c with:
--- ata-pci.c.dist Sat Jun 23 02:19:58 2001
+++ ata-pci.c Sat Jun 23 02:20:26 2001
@@ -515,7 +515,7 @@
return BUS_ALLOC_RESOURCE(device_get_parent(dev), child,
SYS_RES_IRQ, rid,
- irq, irq, 1, flags & ~RF_SHAREABLE);
+ irq, irq, 1, flags);
#endif
}
else {
and reboot. At booting time, ata driver says:
atapci0: port 0xf000-0xf00f at device 7.1 on pci0
ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xf000
ata0: mask=03 ostat0=50 ostat2=00
ata0-slave: ATAPI probe 00 00
ata0-master: ATAPI probe 00 00
ata0: mask=03 stat0=50 stat1=00
ata0-master: ATA probe 01 a5
ata0: devices=01
ata0: at 0x1f0 irq 14 on atapci0
ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xf008
ata1: at 0x170 irq 15 on atapci0
it's as same as before. fxp driver says:
fxp0: port 0xe400-0xe43f mem
0xd242-0xd243,0xd244-0xd2440fff irq 15 at device 8.0 on pci0
fxp0: using memory space register mapping
fxp0: Ethernet address 00:10:f3:03:52:31, 10Mbps
fxp0: PCI IDs: 8086 1229 0009
fxp0: Chip Type: 0
bpf: fxp0 attached
fxp1: port 0xe800-0xe83f mem
0xd240-0xd241,0xd2441000-0xd2441fff irq 11 at device 9.0 on pci0
fxp1: using memory space register mapping
fxp1: Ethernet address 00:10:f3:03:52:32, 10Mbps
fxp1: PCI IDs: 8086 1229 0009
fxp1: Chip Type: 0
bpf: fxp1 attached
Yeah! Thank you for your advice ^_^/
sos> Hmm, maybe I should make this tunable...
It would be great if this is tunable for me.
It would also help other users who have small PCs, there are only one
IDE bus because of space (as said before, this machine is also small
PC, 13-PCs in 4U space).
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On 22-Jun-01 Bosko Milekic wrote: > > On Fri, Jun 22, 2001 at 10:35:32AM -0700, John Baldwin wrote: >> >> On 22-Jun-01 Alfred Perlstein wrote: >> > * Alexander N. Kabaev <[EMAIL PROTECTED]> [010622 10:46] wrote: >> >> UP kernel can not be compiled in -CURRENT after your changes because >> >> kern/subr_mbuf.c references mp_ncpus variable, which is defined only in >> >> SMP >> >> case. Should this variable be moved out of #ifdef SMP? >> > >> > Yes, I asked for this months ago, I thought it was already done. >> >> mp_npcus is not initialized, etc. in the UP case. I suppose it could be >> statically initialized to 1 and moved, but in that case it needs renaming, >> as >> mp_ncpus implies SMP (mp_ prefix). If you want to make it ncpus and move it >> to >> sys/systm.h and stick it somewhere MI initialized to 1 that is fine. Then >> hw.ncpus can reference that (well, it's called hw.ncpu right now, perhaps it >> should be renamed to match the variable *shrug*) and kern.smp.cpus can die >> as >> it won't be needed any longer. > > Note that we already have a (machdep, I think) sysctl exported ncpu > variable. We already have a hw.ncpu. machdep.* should not be used by anything that is supposed to be MI. Offline it seems you missed part of the point of my post though. :) -- 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: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 01:32:21PM -0400, Bosko Milekic wrote: > > mp_ncpus implies SMP (mp_ prefix). If you want to make it ncpus and move it to > > sys/systm.h and stick it somewhere MI initialized to 1 that is fine. Then > > hw.ncpus can reference that (well, it's called hw.ncpu right now, perhaps it > > should be renamed to match the variable *shrug*) and kern.smp.cpus can die as > > it won't be needed any longer. > > Note that we already have a (machdep, I think) sysctl exported ncpu > variable. Doh, I missed the fact that you mentionned this. :-) > > > -Alfred > > > > -- > > > > 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/ -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 10:35:32AM -0700, John Baldwin wrote: > > On 22-Jun-01 Alfred Perlstein wrote: > > * Alexander N. Kabaev <[EMAIL PROTECTED]> [010622 10:46] wrote: > >> UP kernel can not be compiled in -CURRENT after your changes because > >> kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP > >> case. Should this variable be moved out of #ifdef SMP? > > > > Yes, I asked for this months ago, I thought it was already done. > > mp_npcus is not initialized, etc. in the UP case. I suppose it could be > statically initialized to 1 and moved, but in that case it needs renaming, as > mp_ncpus implies SMP (mp_ prefix). If you want to make it ncpus and move it to > sys/systm.h and stick it somewhere MI initialized to 1 that is fine. Then > hw.ncpus can reference that (well, it's called hw.ncpu right now, perhaps it > should be renamed to match the variable *shrug*) and kern.smp.cpus can die as > it won't be needed any longer. Note that we already have a (machdep, I think) sysctl exported ncpu variable. > > -Alfred > > -- > > 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/ > -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CPUTYPE warning
On Fri, Jun 22, 2001 at 07:22:32PM +0200, Karsten W. Rohrbach wrote: > btw, regarding gcc's -O2 optimization breakage on -2.95.x and improved > instrumentation of the new compiler kit, is there someone working on > getting gcc-3.0 into -current? It will come with time. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On 22-Jun-01 Alfred Perlstein wrote: > * Alexander N. Kabaev <[EMAIL PROTECTED]> [010622 10:46] wrote: >> UP kernel can not be compiled in -CURRENT after your changes because >> kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP >> case. Should this variable be moved out of #ifdef SMP? > > Yes, I asked for this months ago, I thought it was already done. mp_npcus is not initialized, etc. in the UP case. I suppose it could be statically initialized to 1 and moved, but in that case it needs renaming, as mp_ncpus implies SMP (mp_ prefix). If you want to make it ncpus and move it to sys/systm.h and stick it somewhere MI initialized to 1 that is fine. Then hw.ncpus can reference that (well, it's called hw.ncpu right now, perhaps it should be renamed to match the variable *shrug*) and kern.smp.cpus can die as it won't be needed any longer. > -Alfred -- 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: CPUTYPE warning
btw, regarding gcc's -O2 optimization breakage on -2.95.x and improved instrumentation of the new compiler kit, is there someone working on getting gcc-3.0 into -current? ...yes *sigh* i know, 3.0 is _not_ stable, neither is -current ;-) /k Dag-Erling Smorgrav([EMAIL PROTECTED])@2001.06.21 00:37:00 +: > In recent versions of -CURRENT, gcc built with CPUTYPE set to k6-2 > will dump core when compiling specific source files (crt1.c at least), > and in the very latest -CURRENT, when compiling anything at all. So > far, gcc built with CPUTYPE set to i586 seem to work fine. > > DES > -- > Dag-Erling Smorgrav - [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- > Q: What do you get when you cross Dracula with a used car dealer? > A: autoexec.bat KR433/KR11-RIPE -- WebMonster Community Founder -- nGENn GmbH Senior Techie http://www.webmonster.de/ -- ftp://ftp.webmonster.de/ -- http://www.ngenn.net/ karsten&rohrbach.de -- alpha&ngenn.net -- alpha&scene.org -- [EMAIL PROTECTED] GnuPG 0x2964BF46 2001-03-15 42F9 9FFF 50D4 2F38 DBEE DF22 3340 4F4E 2964 BF46 Please do not remove my address from To: and Cc: fields in mailing lists. 10x PGP signature
Re: [HEADS-UP]: Mbuf allocator changes
* Alexander N. Kabaev <[EMAIL PROTECTED]> [010622 10:46] wrote: > UP kernel can not be compiled in -CURRENT after your changes because > kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP > case. Should this variable be moved out of #ifdef SMP? Yes, I asked for this months ago, I thought it was already done. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: lock order reversal
On 22-Jun-01 Makoto MATSUSHITA wrote: > > kuriyama> I got message below with WITNESS option. Is this safe to ignore? > > I've found another WITNESS message (5-current CVSuped Jun/18/2001): > > lock order reversal > 1st 0xc5d2043c process lock @ ../../vm/vm_glue.c:487 > 2nd 0xc05a9ec0 lockmgr interlock @ ../../kern/kern_lock.c:239 Can you turn on WITNESS_DDB in your kenrel config file (or set the debug.witness_ddb loader tunable/sysctl before you get this reversal) and get a backtrace from ddb? -- 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: cannot print to remote printer
At 2:42 PM +0200 6/22/01, Georg-W. Koltermann wrote: >Hi, > >with current as of June 20 I can no longer print to a remote printer. >Syslog says "filter 'f' exited (retcode=108)". > >I added a "set -x" to the filter which is a shell program, and sure >enough the last action it does is an "exit 0". So the problem must >be somewhere in lpd. Hmm. I assume you're using "stock lpd" (the standard system version), and not some port like lprNG? Which platform are you running on? (i386 or Alpha) Is the filter one that you wrote, or is it from one of the ports? What does the filter do? When was the last time you had sync'ed up with current? While there have been some changes to lpd in the past month, there shouldn't be any that would alter this section of the code. The big one was the cleanup/ansi-fication one, but that did not change the object code at all. What does the printcap entry for your printer look like? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: picobsd and mdconfig
> Luigi, you cannot run dead air. Makefile.conf only handles that
> if the variable does not exist, not if the variable is empty.
ok my fault :)
luigi
> > > CONFIG=${CONFIG:-config}
> >
> > cheers
> > luigi
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-current" in the body of the message
>
> --
> Omachonu Ogali
> [EMAIL PROTECTED]
> http://www.informationwave.net
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-small" in the body of the message
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: SCSI hangs w/SuperMicro 6010H
On 22-Jun-01 Dave Cornejo wrote: > John Baldwin wrote: >> Actuually, KTR is your friend here. :) Read the ktr(4) manpage, then >> compile a >> kernel with KTR_MASK and KTR_COMPILE set to KTR_INTR|KTR_PROC. Then when it >> hangs, break into DDB and look at the longs via 'show ktr' to see if you can >> locate any interrutps coming in from ahc0 or ahc1. > > Okay - fired up the box, built a kernel off of a 6/18 source snapshot, > and it hangs in about the same place - however what I get that as soon > as I touch a key to invoke the debugger from the console, it continues > merrily booting and I can't break into DDB until way past the > problem. In my mind this kind of confirms something is busted in the > interrupts. Hrmm, perhaps you are getting an interrupt storm from ahc. Ok, try this: find the ahc driver's interrupt handler, and add a printf. Then see if the printf fires while the machine is hung. > Tried looking back through the show ktr output and I'm not 100% clear > on what it all means - I guess I'm interested in the ithread stuff and > the only thing I ever see is swi6: tty:sio+ in the trace buffer > besides what appears to be normal process rescheduling (?) which is > mostly idle task time... Unfortunately, clock interrupts can fill the trace buffer up, yes. :( If rolling back the source tree gets you a working kernel, then you might want to do a binary search using date tags to narrow down what commit actually broke things on your box. -- 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: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 01:52:01AM -0500, Alfred Perlstein wrote: > If you want accurate stats you should be able to lock the per-cpu > stats areas all at once as long as you always do it in a certain > order, basically, lock CPU 0, then 1, then 2, then 3, sum then > unlock. If correctness doesn't matter you can just walk the > per cpu stats locking each (or not) and assumulating the info. I don't need to lock the per-CPU locks to merely read the stats (unless I'm reall obsessed with getting consistent stats at the cost of performance every time a person issues `netstat -m' or, even worse, runs `systat -mbufs'). The main issue with the mbtypes stats, as I've previously mentionned, was that it is difficult to *update* them consistently. However, I think I have devised a way. I'll keep you posted if you're interested in reviewing it. > -Alfred Cheers, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with ata probing twice.
It seems Makoto MATSUSHITA wrote: > > sos> Thats because of the runtime attach/detach code in current, if the > sos> channel HW is there, its attached so you can add a device later > sos> with atacontrol without having to boot. In -stable the channel is > sos> not attached if no devices are present at probe time. > > Thanks for your clear explanation, I just understand what and why. OK, glad to be of help.. > > If it's true that this machine has _actually_ two ata buses, I'll > > try to change irq of fxp0 (hope BIOS menu helps me...) > > sos> It does, most ATA chips does not allow to disable only one of the > sos> channels. > > Hmm, maybe this problem (fxp0 doesn't attach) comes from that the > driver doesn't allow to use shared IRQ. Anybody knows why? is it by > hardware itself? Well, sortof, the ata driver doesn't allow for sharing irq14&15 since lots of boards doesn't work that way. However if you need it you can try to add the shared flag in the driver and see if it works on yours. Hmm, maybe I should make this tunable... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current kernel compile broken...
Oh. oops... pointed hit poked in my for me I tested your stuff on a completely different tree, so, well, do, the conf/files stuff would have been the same. And Alpha has SMP on by default. It's okay! Nobody got killed! On Fri, 22 Jun 2001, Bosko Milekic wrote: > > On Fri, Jun 22, 2001 at 09:03:43AM -0700, Matthew Jacob wrote: > > > > Fixed temporarily at least. > > > > It seems that the stuff checked in last night is a fair amount different from > > the patches I was given to test on alpha. If this is so, this is really not > > right or fair. > > No, it's the same code. The only thing changed is that I've removed > the silliness in if_vx (because that's been fixed with the m_devget patch > committed earlier) and merged changes to netstat(1) and updated systat(1) > so as to not break world. Other than that, the changes are identical. In fact, > subr_mbuf.c is identical modulo one of the lines in the copyright. > > > -matt > > -- > Bosko Milekic > [EMAIL PROTECTED] > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current kernel compile broken...
On Fri, Jun 22, 2001 at 09:03:43AM -0700, Matthew Jacob wrote: > > Fixed temporarily at least. > > It seems that the stuff checked in last night is a fair amount different from > the patches I was given to test on alpha. If this is so, this is really not > right or fair. No, it's the same code. The only thing changed is that I've removed the silliness in if_vx (because that's been fixed with the m_devget patch committed earlier) and merged changes to netstat(1) and updated systat(1) so as to not break world. Other than that, the changes are identical. In fact, subr_mbuf.c is identical modulo one of the lines in the copyright. > -matt -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 08:51:55AM -0700, Matthew Jacob wrote: > > I would think not. > > Bosko might be gone now. I'll look at this as soon as a CVS update continues. > > It's odd, though. A GENERIC kernel built for me yesterday w/o problems. Nah, don't worry. I'm still here (and plan to remain until I'm sure to have knocked out the initial problems). When I leave (tomorrow night) and once I get settled in, I will get a dialup and be in the vincinity to commit emergency changes (such as this) if necessary. As for this, I'm in the process of fixing it immediately. Sorry! Cheers, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current kernel compile broken...
Fixed temporarily at least. It seems that the stuff checked in last night is a fair amount different from the patches I was given to test on alpha. If this is so, this is really not right or fair. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [HEADS-UP]: Mbuf allocator changes
On Fri, Jun 22, 2001 at 11:45:50AM -0400, Alexander N. Kabaev wrote: > UP kernel can not be compiled in -CURRENT after your changes because > kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP > case. Should this variable be moved out of #ifdef SMP? It turns out that it should stay under SMP ifdef. I'll fix this another way immediately. Please allow an hour or so for testing. Thanks! Oh, would somebody please pass the Pointy Hat this way? > > E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]> > Date: 22-Jun-2001 > Time: 11:41:47 > Regards, -- Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [patch] netinet6/ip6_fw.c: use syslog for logging
>>> Fri, 22 Jun 2001 20:06:34 +0900,
>>> Jun Kuriyama <[EMAIL PROTECTED]> said:
kuriyama> I found logs from ipfw(8) and ip6fw(8) are stored to different place.
kuriyama> Former one is into via syslog(3) but latter one is
kuriyama> into via kernel printf().
kuriyama> The reason of this difference is came from missing "merge from
kuriyama> ip_fw.c". And I hope this patch will be first step to synchronize
kuriyama> ip_fw.c and ip6_fw.c.
kuriyama> So, I made a patch to merge the difference revision 1.117 and 1.118 of
kuriyama> ip_fw.c into ip6_fw.c to use syslog(3) interface for ip6fw(8) logging.
kuriyama> Please review this patch carefully because I'm not kernel hacker.
Okay, I'll take a look this.
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: [HEADS-UP]: Mbuf allocator changes
I would think not. Bosko might be gone now. I'll look at this as soon as a CVS update continues. It's odd, though. A GENERIC kernel built for me yesterday w/o problems. On Fri, 22 Jun 2001, Alexander N. Kabaev wrote: > UP kernel can not be compiled in -CURRENT after your changes because > kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP > case. Should this variable be moved out of #ifdef SMP? > > > On 22-Jun-2001 Bosko Milekic wrote: > > > > Hi -current people, > > > > I have recently made some significant changes to the mbuf allocator. > > Although I have invested, along with several other developers, very > > significant > > time in testing the newly introduced code, should any problems arise, please > > let me know ASAP. > > One noticeable difference that I am aware of is that mbtypes statistics > > have been TEMPORARILY disabled. Please be patient. :-) > > > > Thank you for flying -CURRENT, > > -- > > Bosko Milekic > > [EMAIL PROTECTED] > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]> > Date: 22-Jun-2001 > Time: 11:41:47 > > > 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: [HEADS-UP]: Mbuf allocator changes
UP kernel can not be compiled in -CURRENT after your changes because kern/subr_mbuf.c references mp_ncpus variable, which is defined only in SMP case. Should this variable be moved out of #ifdef SMP? On 22-Jun-2001 Bosko Milekic wrote: > > Hi -current people, > > I have recently made some significant changes to the mbuf allocator. > Although I have invested, along with several other developers, very > significant > time in testing the newly introduced code, should any problems arise, please > let me know ASAP. > One noticeable difference that I am aware of is that mbtypes statistics > have been TEMPORARILY disabled. Please be patient. :-) > > Thank you for flying -CURRENT, > -- > Bosko Milekic > [EMAIL PROTECTED] > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message E-Mail: Alexander N. Kabaev <[EMAIL PROTECTED]> Date: 22-Jun-2001 Time: 11:41:47 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with ata probing twice.
sos> Thats because of the runtime attach/detach code in current, if the sos> channel HW is there, its attached so you can add a device later sos> with atacontrol without having to boot. In -stable the channel is sos> not attached if no devices are present at probe time. Thanks for your clear explanation, I just understand what and why. > If it's true that this machine has _actually_ two ata buses, I'll > try to change irq of fxp0 (hope BIOS menu helps me...) sos> It does, most ATA chips does not allow to disable only one of the sos> channels. Hmm, maybe this problem (fxp0 doesn't attach) comes from that the driver doesn't allow to use shared IRQ. Anybody knows why? is it by hardware itself? -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ucred.cr_gid
Hi!
The attached patch replaces ucred.cr_groups[0] with ucred.cr_gid.
This is mostly needed for POSIX alignment. setegid(2) etc. should
not change supplementary groups set.
Also, type of 's group.gr_gid changed to a more natural
gid_t (also as in POSIX).
getgrouplist(3)'s and initgroups(3)'s prototypes fixed.
getgrouplist(3) has been also fixed to not duplicate the
primary group, and always return number of suplementary
groups, even if ngroups is zero (similar to sysctl(3)).
Assorted changes:
cmsgcred.cmcred_egidNew
kproc_info.ki_gid New
portal_cred.pcr_gid New
xucred.cr_gid New
I'm not sure what to do with xucred.
Also, I'm not sure about KINFO_PROC_SIZE on ia64 and PowerPC.
Please review.
See also ChangeLog.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: include/grp.h
===
RCS file: /home/ncvs/src/include/grp.h,v
retrieving revision 1.3
diff -u -p -r1.3 grp.h
--- include/grp.h 1997/05/07 19:59:59 1.3
+++ include/grp.h 2001/06/22 14:50:40
@@ -48,7 +48,7 @@
struct group {
char*gr_name; /* group name */
char*gr_passwd; /* group password */
- int gr_gid; /* group id */
+ gid_t gr_gid; /* group id */
char**gr_mem; /* group members */
};
Index: include/unistd.h
===
RCS file: /home/ncvs/src/include/unistd.h,v
retrieving revision 1.41
diff -u -p -r1.41 unistd.h
--- include/unistd.h2001/05/27 19:57:36 1.41
+++ include/unistd.h2001/06/22 14:50:40
@@ -138,7 +138,7 @@ int ftruncate __P((int, off_t));
#endif
int getdomainname __P((char *, int));
int getdtablesize __P((void));
-int getgrouplist __P((const char *, int, int *, int *));
+int getgrouplist __P((const char *, gid_t, gid_t *, int *));
longgethostid __P((void));
int gethostname __P((char *, int));
int getlogin_r __P((char *, int));
@@ -151,7 +151,7 @@ int getresuid __P((uid_t *, uid_t *, ui
int getsid __P((pid_t _pid));
char *getusershell __P((void));
char *getwd __P((char *)); /* obsoleted by getcwd() */
-int initgroups __P((const char *, int));
+int initgroups __P((const char *, gid_t));
int iruserok __P((unsigned long, int, const char *, const char *));
int iruserok_sa __P((const void *, int, int, const char *, const char *));
int issetugid __P((void));
Index: lib/libc/gen/getgrent.3
===
RCS file: /home/ncvs/src/lib/libc/gen/getgrent.3,v
retrieving revision 1.15
diff -u -p -r1.15 getgrent.3
--- lib/libc/gen/getgrent.3 2000/11/20 16:18:45 1.15
+++ lib/libc/gen/getgrent.3 2001/06/22 14:50:41
@@ -78,7 +78,7 @@ file
struct group {
char*gr_name; /* group name */
char*gr_passwd; /* group password */
- int gr_gid; /* group id */
+ gid_t gr_gid; /* group id */
char**gr_mem; /* group members */
};
.Ed
Index: lib/libc/gen/getgrouplist.3
===
RCS file: /home/ncvs/src/lib/libc/gen/getgrouplist.3,v
retrieving revision 1.6
diff -u -p -r1.6 getgrouplist.3
--- lib/libc/gen/getgrouplist.3 2000/10/30 13:23:18 1.6
+++ lib/libc/gen/getgrouplist.3 2001/06/22 14:50:41
@@ -43,18 +43,18 @@
.Sh SYNOPSIS
.Fd #include
.Ft int
-.Fn getgrouplist "const char *name" "int basegid" "int *groups" "int *ngroups"
+.Fn getgrouplist "const char *name" "gid_t basegid" "gid_t *groups" "int *ngroups"
.Sh DESCRIPTION
The
.Fn getgrouplist
-function reads through the group file and calculates
+function reads through the group database and calculates
the group access list for the user specified in
.Fa name .
The
.Fa basegid
is automatically included in the groups list.
Typically this value is given as
-the group number from the password file.
+the group number from the password database.
.Pp
The resulting group list is returned in the integer array pointed to by
.Fa groups .
@@ -64,6 +64,8 @@ array in the integer pointed to by
.Fa ngroups ;
the actual number of groups found is returned in
.Fa ngroups .
+.Pp
+Duplicate group IDs will be suppressed from the result.
.Sh RETURN VALUES
The
.Fn getgrouplist
@@ -94,3 +96,11 @@ If the invoking program uses any of thes
the group structure will
be overwritten in the call to
.Fn getgrouplist .
+.Pp
+In the case where the group array is too small and duplicate GIDs
+have been suppressed, the returned
+.Fa ngroups
+will be too large by a factor of the differe
Re: picobsd and mdconfig
On Fri, Jun 22, 2001 at 12:26:39PM +0200, Luigi Rizzo wrote:
> > On line 336 of the script, you export dead air, resulting in
>
> and Makefile.conf handles that in a way
> similar to the one you show below.
Luigi, you cannot run dead air. Makefile.conf only handles that
if the variable does not exist, not if the variable is empty.
> > CONFIG=${CONFIG:-config}
>
> cheers
> luigi
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
--
Omachonu Ogali
[EMAIL PROTECTED]
http://www.informationwave.net
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: support Pentium3 SSE
Peter Wemm writes: > "Michael C . Wu" wrote: > > On Thu, Jun 21, 2001 at 04:07:25PM +0100, David Malone scribbled: > > | On Wed, Jun 20, 2001 at 05:39:55PM -0400, Andrew Gallatin wrote: > > | > While we're at it, I know that the AMD AthlonMP supports SSE, but I > > > > I think we already detect AthlonMP's SSE automatically. > > I recall reading Peter's dmesg of his Tyan board and seeing > > SSE in the config. > > CPU: AMD Athlon(tm) Processor (1194.43-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x661 Stepping = 1 > Features=0x383fbff MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE> > AMD Features=0xc044<,AMIE,DSP,3DNow!> > > Note the FXSR (fast context save and restore) and the SSE flag are there. Ah, Excellent! I was confused because the dmesg from the Athlon MP board that John Baldwin posted about had the only the FXSR flag but not the SSE flag set. Interestingly, its the same Id and stepping: CPU: AMD Athlon(tm) Processor (1194.68-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x661 Stepping = 1 Features=0x183fbff AMD Features=0xc044<,AMIE,DSP,3DNow!> I guess it must have been an early rev or something. Cheers, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cannot print to remote printer
Hi, with current as of June 20 I can no longer print to a remote printer. Syslog says "filter 'f' exited (retcode=108)". I added a "set -x" to the filter which is a shell program, and sure enough the last action it does is an "exit 0". So the problem must be somewhere in lpd. -- Regards, Georg. -- Who in the world needs 2000 Windows? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!! S/Key is ancient, OPIE is new
> Why? Better way will be rewritting ports to use good-new OPIE. > wi-ftpd already have OPIE hooks, but I not sure they works. Popper needs > modifications. Doesn't know, if other ports using Skey exists. I can do base software, but I haven't time to fill all ports. M -- 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
[patch] netinet6/ip6_fw.c: use syslog for logging
I found logs from ipfw(8) and ip6fw(8) are stored to different place. Former one is into via syslog(3) but latter one is into via kernel printf(). The reason of this difference is came from missing "merge from ip_fw.c". And I hope this patch will be first step to synchronize ip_fw.c and ip6_fw.c. So, I made a patch to merge the difference revision 1.117 and 1.118 of ip_fw.c into ip6_fw.c to use syslog(3) interface for ip6fw(8) logging. Please review this patch carefully because I'm not kernel hacker. -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project ip6_fw.c.diff
Re: picobsd and mdconfig
> On line 336 of the script, you export dead air, resulting in
and Makefile.conf handles that in a way
similar to the one you show below.
> CONFIG=${CONFIG:-config}
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: From -current to -stable?
On Thu, 21 Jun 2001 15:02:37 MST, "T.J. Kniveton" wrote: > Everything is working ok, but this is my development laptop, and it > would probably be wiser to track -stable so that things will still work. > I have grabbed the RELENG_4 source, but it is dying at unctrl.h. Is > there any way to go backward from an installed current build, to stable? A binary installation will work. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current kernel compile broken...
sos> make In current as of 5 mins ago: cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../.. -I../../dev -I../../contrib/dev/acpica -I../../contrib/ipfilter -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../kern/subr_mbuf.c ../../kern/subr_mbuf.c: In function `mb_init': ../../kern/subr_mbuf.c:382: `mp_ncpus' undeclared (first use in this function) ../../kern/subr_mbuf.c:382: (Each undeclared identifier is reported only once ../../kern/subr_mbuf.c:382: for each function it appears in.) ../../kern/subr_mbuf.c: In function `mb_alloc_wait': ../../kern/subr_mbuf.c:620: `mp_ncpus' undeclared (first use in this function) *** Error code 1 Stop in /u1/SRC/current/sys/compile/SOS. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!! S/Key is ancient, OPIE is new
Sudo also has a --with-opie option in configure. I don't remember why it isn't in the standard sudo port tho. Michael On Fri, Jun 22, 2001 at 01:14:41AM -0700, Gregory Neil Shapiro wrote: > ache> wi-ftpd already have OPIE hooks, but I not sure they works. Popper needs > ache> modifications. Doesn't know, if other ports using Skey exists. > > security/sudo uses it: > > > sudo ldd /usr/local/bin/sudo > Password [ s/key 135 ho9319 ]: > /usr/local/bin/sudo: > libmd.so.2 => /usr/lib/libmd.so.2 (0x28077000) > libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x2808) > libutil.so.3 => /usr/lib/libutil.so.3 (0x28095000) > libskey.so.2 => /usr/lib/libskey.so.2 (0x2809e000) > libc.so.4 => /usr/lib/libc.so.4 (0x280a5000) > > 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: Problems with ata probing twice.
It seems Makoto MATSUSHITA wrote: > > % atacontrol info 0 > Master: ad0 ATA/ATAPI rev 5 > Slave: no device present > % atacontrol info 1 > Master: no device present > Slave: no device present > % atacontrol info 2 > % > > Hmm, ata driver says there are two buses. But why? 4-stable kernel > doesn't recognize ata1. Thats because of the runtime attach/detach code in current, if the channel HW is there, its attached so you can add a device later with atacontrol without having to boot. In -stable the channel is not attached if no devices are present at probe time. > If it's true that this machine has _actually_ two ata buses, I'll try > to change irq of fxp0 (hope BIOS menu helps me...) It does, most ATA chips does not allow to disable only one of the channels. -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!! S/Key is ancient, OPIE is new
ache> wi-ftpd already have OPIE hooks, but I not sure they works. Popper needs ache> modifications. Doesn't know, if other ports using Skey exists. security/sudo uses it: > sudo ldd /usr/local/bin/sudo Password [ s/key 135 ho9319 ]: /usr/local/bin/sudo: libmd.so.2 => /usr/lib/libmd.so.2 (0x28077000) libcrypt.so.2 => /usr/lib/libcrypt.so.2 (0x2808) libutil.so.3 => /usr/lib/libutil.so.3 (0x28095000) libskey.so.2 => /usr/lib/libskey.so.2 (0x2809e000) libc.so.4 => /usr/lib/libc.so.4 (0x280a5000) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with ata probing twice.
mark> This looks right to me. One main PIIX4 ATA controller with two mark> independent IDE channels (usually referred to as a Primary and a mark> Secondary IDE controller). Usually the PC BIOS will allow you to mark> turn on/off these channels independently. Does your bios allow mark> you to turn off the Secondary? This machine has no BIOS setting menu to enable/disable 2nd IDE bus. There is only primary IDE bus configuration. mark> I don't think the HDD is being detected twice. Try this instead: mark> % sudo atacontrol info 0 mark> % sudo atacontrol info 1 Thanks you for your suggestion, gimme a chance to try again: % atacontrol info 0 Master: ad0 ATA/ATAPI rev 5 Slave: no device present % atacontrol info 1 Master: no device present Slave: no device present % atacontrol info 2 % Hmm, ata driver says there are two buses. But why? 4-stable kernel doesn't recognize ata1. If it's true that this machine has _actually_ two ata buses, I'll try to change irq of fxp0 (hope BIOS menu helps me...) -- - Makoto `MAR' MATSUSHITA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
