Re: unknown PNP hardware
Ok, this is the 3rd revised patch for PnP. I think it works
fairely well.
I may not invest further time on this, now that ACPI is
taking over device configuration business... :-)
Kazu
>> I once wrote the following patch to deal with this problem by
>> probing ISA devices in the following order.
>>
>> 1. sensitive ISA devices described in device.hints
>> 2. PnP BIOS ISA devices
>> 3. other ISA devices described in device.hints
>> 4. PnP ISA devices
>
>This order is still slightly wrong. You need to do:
>
> 0. Disable ALL PnP devices which can be disabled.
> 1. PnP devices (of any kind) which cannot be disabled, or which only
>have a single configuration. These devices which cannot be disabled
>need a placeholder attached to them if a driver doesn't claim them,
>or some other mechanism so that their resources are never used.
> 2. Sensitive hinted ISA devices.
> 3. Other ISA devices.
> 4. Other PnP devices.
begin 666 isapnp.diff3.gz
M'XL("*O(C3L VES87!N<"YD:69F,P"]66USVD@2_HQ_1:]3ZQ)&&(D7@[&3
M#0&R2RTQ/D-B7/P^O]_'5SWI[!P5ZP+M3!P:OV;*?\,'\-:
M?C[]X2!@4>"R!]>[@P _0M?WP#RI-P[F[F(!U2U4 _H*&3>KU>J.[Z6Z89@U
MHU,S#3#:W9;1-9LE;JE2J>R7;J!TL]MJ= WCX.U;J#;;=1TM5)KM4[UU"F_?
M'D!I$3"F.8L['3Y8L^&'J_+Y >!P[?B@6H)CN&2?(M@$_BT#>[4"S_>J&V\#
M\8T) X[O+=R[;6!'N*#Z7A]VIP?4
MKN&[NP#MUO>C!Q;<^B$KH]G2)G"]:*$=TD+R>"UGZ:[F ?.Z/'[:Q"OO*O99
MV]AA"&;Y']XA+EFEM$!?-1=>@W$.+ER I]3Q:Z52AO_0)$+9BH _1&$E]*?[
M3S)2"J-@ZT0\(80L'+OX#TH.AC>SR6C:T[@*34GRM6,([]U-?E].3DXH4A2@
M4'^:]4;COUGO1]?3F79$]JIOW+DEEC$L\_!+^"URO2V+#=,[+O:4S$=+-Y2V
M 2VZ$6U69J=L;RZV:NT'3*KBKGBT:]D-.Q%/$^^TG$>6'44!' $&VW__:V\V
MN[8N)P/\]FX\+,/1$=?'UTL4I[/>;-1/:SV]%O#3ZZS@N%ZA3 JUZ>HQ-PC'P0IW/9DY5C[?JV,Q+PH>25,YP#V0
M22>2&O>)ELEVEM()C!@,X;U*SY!%E'U82J%T54<195)D!NUOG]>:[3W"UD-P
M\!T[PDQ(JB[RX9ZQ#?A8CH%24O6S"/PU;$,J*WR\/I'/>5J4IN/1=&:]GUP/
M>_W?-(Q'AV"EP\KU[M6BB=S!1]4W.&,\6L(JAL"EVA+/W/FY?))=*^ZP1E;1
M(UT4HBXE10)P_>AQP[+#[EMAIL PROTECTED]+H\%_\,^4JT? 7_L'?Z>T+7SN^@2^S%W2$SE26PU
M8/ 7M^CX 2;(QO?F6:37!4_/
M\]!1! AYI2*WOR0P^ (00I#>LZ
M:2),G"),M%(P\2P;R>-$BN9())#53X6+%&-._,/U^!-.](#'GV# UQ&,SY\5
M _@*?I$H/<,O7G\O?O$*(S-RU460$D;8A5-E-9AB<+.KZ^%T>#G;L2*W1.J[
M(5((SN<4*.W,RA ?%UC6\")V ]_ ;O;I9-@-[QXO:1_?EP$!]PZ!!KZ% 5%9
MM)L=_10JG7J;FJBHBF-4V*XB7)!4'JPWR);G?#EN V;?BTIP;&QPF'_6Z*9W
M;?4GE^]'/!&[Y'ZAG3AQ^7)(4Y4=4X/^9>_#,&=&VR+P;*+ BLHY8,X: URW
MA8TZ77(73[W;P(/AY00S3L SC_RLSB-OGR61[\2+DS[8*U[W+X^[L$QC0R^,
M.A<@18_F0L)#.X#C^
M*MU?DNTO8':RT+$L*-RSMDG[;!H8KZ"'O&]Y&^&0%C<:SKNS;0?)5M)E2 4S
M @_ (2X'S?$5+:A22N^>2EDB0,2YU/^N"%+LAHKK 3'.1Y)?+DAF'F!'!M@Q
M=%,18-'ULY1SY=^YCKVBK*:2#'&0(N+B^/K\>;?>LY(IMAJPQ8HYD6I]1.5B
M/BKS-=4$:"2#@A1T5B1%/=/=A$<0XR[.8O'$U\BBSM=.AT-UZC_4$<*IITE=
M?CQ"$B=23!W)Y*12*>-6LKQ_'TW.U9E)-9D7>K-8V7>A="4%Y8+PY/.<"\<<
MMGP>5Z-:]3D+'5E]F?((G83YIB2% 1D&3CR\=VYNZQ#1DG
M"ZX>EW29:-2,5JU^"D:]:S2[]7:)[!3
MZM9V[F&Q]1RZ>A)Z#[X[+V7D[>#NO)16P('M&OF&/(=[$25)MIN6[TF7$[ 3P0J
MNS8I%1^=^=)\X7"HYHXQ%37*)4TKN)LLIQ'%?;"#D N7[]99(?1/;8 7?
M5>JS5<@(-?Q@SHBG$!N97 ^&N,57P_[',6[SS5!T?'46>_=Q:O4& ZO_VV@\
MP.,='LL0^;@!'1(P%'WO)3ITT1#KB 8H]3B QHV/-TK<<(Z!3M)6Q*R2(V :
M!I% 6\#,VWKR2S8),#M^& [RN?;_ &-D?X Q('8OE0%\0*"?:=;P"&MTNF:C
MVVB4N(54 L22*>BKF]VZ^-'%K#>(_M&') LQ_;P97@XFUZ.!GAZ<#J]'O7%F
M:#SY==3OC4FP6DJQX ]7F"L#W**=,3T[J.AR9EB07U7UDKV9K28G-ZU3259)
MO-?O#Z?3R;46LL"U5SI('_'4'95S(C'IT2%QNTA041X=8J>%6"4G1N!&\$J"
M<2!%HB)!=1"!Z9#A[Q0C^T0]A%2#M1W>6P+,W.!?UH;Q>S^->@-EM93DK6+W
MVB7#8Q.^F<6\9AVD@SS=1J]\PM85LSM+ LT
M[*3./<,3NC@,MCJ\L5=:G49\S2F.I,7]-VGVZ+OJPU53=&'9:-4!E-_HPV9>
M?4,QS#,R,C?YZ;(PM?@Q;]\6)3V.$$+S_?HRKZ^JZB
M&']:-_9S5ST;PEX+B@GL&E!/GM;?^$&TJTNC3^OALGS#6HETY8JX*4H]261=
M7?!#*HQT'7+3\HX#,O?O=^JF01RB@)O)W4*@L
*_C]V:P\F!R4 (X#
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
>> I once wrote the following patch to deal with this problem by
>> probing ISA devices in the following order.
>>
>> 1. sensitive ISA devices described in device.hints
>> 2. PnP BIOS ISA devices
>> 3. other ISA devices described in device.hints
>> 4. PnP ISA devices
>
>This order is still slightly wrong. You need to do:
>
> 0. Disable ALL PnP devices which can be disabled.
Ya, the patch disables PnP devices (if they can be disabled) before it
starts probing devices. It enables each PnP device only when it is
about to be probed...
> 1. PnP devices (of any kind) which cannot be disabled, or which only
>have a single configuration. These devices which cannot be disabled
>need a placeholder attached to them if a driver doesn't claim them,
>or some other mechanism so that their resources are never used.
> 2. Sensitive hinted ISA devices.
> 3. Other ISA devices.
> 4. Other PnP devices.
Ok, revised patch is attached.
Kazu
begin 666 isapnp.diff2.gz
M'XL(")RZC#L VES87!N<"YD:69F,@"]6%%SVD80?I9_Q2:=>L (D# 86VXR
MID :9HAQ@?BE[6B$.,R-A41/@L3327][=^].( %VF*039A#HM'N[M_OMMW?J
MA5/VV0$>>ZX?+1916/%/WGS_YV38'L&,!\R!:BS\:OM^)'_CI[B*MJI9>^;Z
M1+!$<+;FX0,(_(EY%()=J9V?3/EL!N45E 7=YMTLE\NY :-F67;5NJS:%EA-
MIV$Y=MV0LY1*I<.2M2NP+IQZW;&MDYL;*->;MGD%I7JS:38LN+DY@1,P9H*Q
M@C][,.&#.^Y^N"M>XW#)J)[A!<[@3D03!LMP"5-TW64"8Q!'*T%3S;B(DXH4K^*5
MSZ PB:)DS<0DBED1AXREX&$R*[RF!2[)%]>?\V J6.@ W5-0[\*[U+L_P]>X
M@)(QBP04.+P!ZQHX_ )AJH6WI5(1_J&YE8Z;@'R(PJG0'_POFL2($['R$QE<
M)0MG'/^@9*=[/Q[T1JV"5"&3)%_%53_R)8116,Z$K%*IJ 7*%;X:MWK]W]UW
MO>%H7#BE^/A=1'C!$(D"#@1PGV6X?D3 TQNG$#'B>''25[).C%,7\(W4VJ=9QTX-/ IH_E
MA' F HSLUO)&^?I9'9>%B7@BS=0!Z8%.K,*+%TY=+TD\?ZZ=P!6#I;Q/(1"S
MA#*,*(VUJR:*I%/*6C (TVT)8R]\@E7H!4'D>PF;9@"=1/#(V!(BRE*JE!;.
M3$0+6,6$6'R\J.CG,D_&J-\;C=UW@V&WU7Y?P/68( (3 AX^ID%3Z,%'Y;=H
M<3-J8(& X(1?]8Q/K_63?*RDPP6:%3TR%=A-+:D (/63IR7+#Y_BE/D1RX1_
M\6OK*-'P%_DCKW3!+Y(+1JY,(;AEGQ-9KHC<(-BMCV>I0BD?Y(NO3%E!XQ1:
MV"<5.(Y4:,(]8I$L>GENVC4H-#)XV"A*/
M$'H+!G/TV$3T,.!)IK8W1J8^B:6@.,2D&[#KU1,(=%)!?EXK;*9U($W"S[3R
MO-RNS>O=NCM43;M*VJ5,- @W@!DW7J[>ZW3I>^N;K&+W@85,<%^M466UL$5[
M,<-21W $G)[N^2TM?84U0*YDB_YWG,CB"10I;ID:V2);!>B$!G1*#R_K"K;P
M>$@I>VF6[ZV#PS5P=67:-M; !=: +6O@R.:6+P%0)2 ;T!F,MBTNK8!/6 [2
MLZE1!2B=\2[E876&"JL@P8!DX+18XE9S*L,Q$1'W)6YO?O6T.VT;UL?N@ZYOIVCL$+(+Q/A)L6=TI8!T9-1!J=LYJ&.0S9P
M![\2(71O!P@/5>#2W:N:=/>BN75WSTDTNO8"B?;CG-WQBYQ&;,6T3?4$G!7U
M;%_UMJ#<+6[]O6S6S":4KAJV>:G=5SQW/TT= Z!EE'=%A=5 C!
MWM[);_Z#3W[S9T]^S=S!KYEW?JV-=H$DCQVE0YSYQJ,OMY8QO':\!="?44?93P@H2)$+&\QJ)5S62K
MZT^PO#:Z>"NU?:SWB><_PFP5^G0H5'KKB$^-G+PG'JZ-K (.K!9(9HJWM\!7
M6KI42>/P'DG:^2(1\Q/6!,>3T>:LAAI%HU X<*HK0J8W\+4G8BEC(
M%P9X3>F-!3&C$HO$E ED)N*OP;#3';JCNV[[8[\U[MUW%4>DA^I?/X[<5J?C
MMM_W^IW"$D^NM).5$Y@R;[BM#7DB2>,HG=N/_;X)95L2&Y&"UI)DLJ$_FHY2
M+"E%HB8E%+UI!5D*GDCD6P*\\:-5J&^V:4?U]DY=\765OW=,[E
MC>(+VZ[6&F!=.O:Y3O:'GRX0W1T,"U[8V9V4'7"M(B1RJ5;C3J1
MF-UH:!8C\5:[W1V-!L-"C'M^#\^UVAG<"B;%'9$@>N#(,7B0A:U_AP33MFW"
MQCLE5LJ)*4B9H+PU(=>AR7$\GB)IDJI8>/&CJPB'B[_=)0NGF-L"D2'A4$M*
5;MS?B:<]-"&*0O'_ \7R/73%
end
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Mike Smith <[EMAIL PROTECTED]> wrote: > > It's written for 4.X, but might work for -current (you'll have to > > disable the checks for 4.X, at the very least). You use it like this: > > > > dmesg | scanirq > > It's completely obsoleted by devinfo and pciconf's '-v' flag. > > Sorry. 8) Cool! I didn't want to support it, anyway. ;-) -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> I remember an ACER system with a bus mouse on the motherboard > which was unknown to the PnP BIOS, and Windows 95 trying to > be a "PnP OS" used to always do what above looks to be the > "PnP ISA devices" phase of things, and gave IRQ 12 to the > second IDE disk interface, instead of the on-board mouse... > which would exactly fit this bill. See my immediately preceeding message for how this has to be worked around. It's doable. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> I once wrote the following patch to deal with this problem by > probing ISA devices in the following order. > > 1. sensitive ISA devices described in device.hints > 2. PnP BIOS ISA devices > 3. other ISA devices described in device.hints > 4. PnP ISA devices This order is still slightly wrong. You need to do: 0. Disable ALL PnP devices which can be disabled. 1. PnP devices (of any kind) which cannot be disabled, or which only have a single configuration. These devices which cannot be disabled need a placeholder attached to them if a driver doesn't claim them, or some other mechanism so that their resources are never used. 2. Sensitive hinted ISA devices. 3. Other ISA devices. 4. Other PnP devices. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Warner Losh wrote: > : Whether it's perfect or not, making the device.hints "go away" > : in the presents of PnP BIOS on the machine would seem to be > : able to address the issue of doubled entries... right? > > Not entirely. There are ISA devices in devices.hints that aren't plug > and play and aren't in the PnP BIOS list. That's a worse problem than > the minor printf :-). Ouch. [ ... ] > What we'd like to happen: > > PnP BIOS devices > device.hints > PnP ISA devices > > What we do now > > device.hints > PnP BIOS devices > PnP ISA devices Let me ask one more question... you want this reordering to ensure that you can handle the PnP BIOS cases where some legacy device *is* known to the PnP BIOS, vs. where the legacy device is _NOT_ known to the PnP BIOS, so that the device.hints can find it if it's there, before we fall into the PnP ISA ["Plug-N-Play OS"] game, right? I remember an ACER system with a bus mouse on the motherboard which was unknown to the PnP BIOS, and Windows 95 trying to be a "PnP OS" used to always do what above looks to be the "PnP ISA devices" phase of things, and gave IRQ 12 to the second IDE disk interface, instead of the on-board mouse... which would exactly fit this bill. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> > > Then go look them up. I'm not about to stuff the entire PnP device > > database into the kernel just to satisfy your curiosity. 8( > > I was going to ask where, but I see they are in > /usr/src/sys/boot/common/pnpdata. That's a useful subset that I keep forgetting about; thanks for reminding me. Google is also remarkably good at finding these things (it's how I've found most of the databases I have). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
>: Whether it's perfect or not, making the device.hints "go away"
>: in the presents of PnP BIOS on the machine would seem to be
>: able to address the issue of doubled entries... right?
>
>Not entirely. There are ISA devices in devices.hints that aren't plug
>and play and aren't in the PnP BIOS list. That's a worse problem than
>the minor printf :-).
>
>: Is there something I'm not seeing here from Kazutaka's posting,
>: or am I being misled?
>
>Yes. Yes. :-)
>
>What we'd like to happen:
>
> PnP BIOS devices
> device.hints
> PnP ISA devices
>
>What we do now
>
> device.hints
> PnP BIOS devices
> PnP ISA devices
>
>Note, I tried making the simple changes to make this work, but it
>failed in subtle ways that I didn't have time to trackdown...
>
>Warner
I once wrote the following patch to deal with this problem by
probing ISA devices in the following order.
1. sensitive ISA devices described in device.hints
2. PnP BIOS ISA devices
3. other ISA devices described in device.hints
4. PnP ISA devices
I am not entirely happy with the patch, though.
Kazu
begin 666 isapnp.diff.gz
M'XL("(-]B3L VES87!N<"YD:69F +U8ZW/:1A#_+/Z*;3+-@"59#UXV;CJA
M0%JF!+M _*7M:&3I@)N 1$_"C:>3_[V[=P))&!+2SL0SD:SSOO>WC\LP"MG'
M#O#$M_"?%\3K=1Q=!I77__^G,NE-84S#1-\YGMFFO;CF5?68X-=KO3M#M.
M0Y.2=%T_3>TVP&EV7*=CMRIOWH#9:+M&_1IT>C<<>/.F MI<,%8-Y@L#WGFS
MP;N[VDT%\-BZJ)@:7,"8?4QA(^('!OYJ!5$H#?Z>;Q%2Q0C
MQB864.7P&NP;X/ #1#L"_-3U&OR#-)I2YJ6*&XEW1+_S/TF(EJ1B&Z0RR8H6
M+CC^@I3]P?WL=CCM5B6+C#QZ2M[/NL/1;][;X60ZJ[XB:O-''F*"HSE?)#49
M$ V_4AYMF731N@ _2?@B*@0]C<&'/!X46_TL\>@8$DK*[\AL)=G;2\[LK4FJ
MLAV?E ]94%2P_2CT_#3U@^7>41,)E=6H!!&3!6_I)VAR9B["*4D@\M<,EI@_
M [8) YX6W-A;'@9$5K2[!!]IYMXDB07\,M2Y!O+GQ38A&."YTDLJX7O"4)GN
M4.?-7F6F(&&IMY.B_#6>,9V.W*[NWO(($?ETF%3*:;'^,+19)6$0UY>2U\+G
M?ZV@9]5CGE$$YI>*P#Q2!!=PJ@CT$QE\V";>@D5,\$!E4=DO4PD%YB]A;U]D
MWWUUE1T!';QZE44,C4N])/53EJF"U^C=U!O?SNXF@^E@/%-^? 8GX_>C4='"
MSQ6? OMYU8Q=:)>!G1QOQ1.L);'"%.1,>RTW)WD\%J7BB3A99NF7JUT*0VC3
M"\'=DX/"CYY@2RB/ XQ96&Y<'QC;0(R@%CNF'>3G(EZ#*E:%>9IL[<:5T0*]
MW;0-')%RL&D7*'"[2M&_0DS6&S_EH?3N03#_ [F@:X&/K04QZ WONQ.OWQMW
MWPTZ%-Y<1G6+B-NDPDMK!PB0R,B$Z2@X9',?>3JD S> K8A@,+[%])/63\K<
M:U>:>WV5F_O,2%3ZZ*\(>6<:>XA,-!I!D%!1^@(N:IFT+UI;5>;6E+V5X=%]
M:OF-]ZGER7VJ75JGVE R\L@VM:3]R+;LIN6VP'8[=J/CMC62?"##S#?1D%*[DN^QYB'6HG>%XL;K 4CQ\"-')^[1L!6":-BC$7(!-8P5?KMI#^8>-.[0>_]J#L;W@]4Y]T-VY_>
M3[UNO^_U?AF.^M6-CW,7UR4IP) YQ-TIXJD!ME'V4((#:^64>1ND[?SNSR[Q&UC*N\#[60@Q0
M\G',84V&?V,V: @&RQBW'R![&.4G'Y&71&OEQ5@ R6 \'1)$-)LZQHHM_. )
M$A8EG#I-+I_VQ"/L.<8TIR" KE9G"[D;WVF:*]O=:KLP<2,P-RO_J<2F?\9T
MXI?*$2"?JGW<" 4Y;#:9MQ-<\32 NW;_H9OPW]E(_@K4?
M^0LF<^ZX=9P9NN,V,/>RY/?#_'XP[M].AGVC>#@=3(;=4>EH=/OSL-<=$:&9
MG_9NW]VATWTLRV=G1O%0[0R[AHX>2+.:#1IH3K.5330B[_9Z@^GT=E)-<.WV
M5P9DQ@ VM=H!R2I><)PW'.L_M^\8X6[!,6!OG2+32V2JI1B@K#6@M,N0X>PC
M#5!B%6L_^>"IX?7G^K^]D+3*6]-]:N6)1\/
M/$Z^P8 ZT'>R137*,ZKA0F:@;% '4O:MQ[VF)E6O=YI-3HX=0LG%:U&
M+E%GV\X5=2KU(G2\I!#/-42E_-\BZ(:AO,AGLU]>3''@TXT]*=2$O)VJB]_Q
M"50JP-(DTL_D*[:1PU&63:M'-#X6/+L[;D+S1S([+-'LX7R,B+1-!S,LK_';
MX<\>8GWT4[?WZ]X:Q1)M**I2FMK+#)R?Q(Y_\61T"M
Re: unknown PNP hardware
> Then go look them up. I'm not about to stuff the entire PnP device > database into the kernel just to satisfy your curiosity. 8( I was going to ask where, but I see they are in /usr/src/sys/boot/common/pnpdata. thanx, brad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> I think the reason the hints are not just ignored is to allow > people to fix "rogue" hardware. I'm willing to be corrected, Good. It's like it is right now because the PnP stuff was bolted on as an afterthought. > since this looks like about 12 lines of code would make it > ignore device.hints in the "PnP BIOS present" case. We don't want to ignore the hints either; we just want them to take lower precedence than the PnP BIOS data. Hints can be perfectly valid and relevant in either the "broken BIOS" or "non-PnP device" cases. Basically, the problem we have is that we don't have the developer bandwidth to catch up with what has to be done, let alone fix the bandaids that were applied years ago. This results in suboptimal situations like this, something that's only going to be exacerbated as fully funded developer time for FreeBSD-mainline work doesn't seem to be increasing. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
In message <[EMAIL PROTECTED]> Terry Lambert writes: : Warner Losh wrote: : > Since that's not how it works, the solution is a non-starter. : > : > We just need to carefully order the ISA code probing sections to get : > the desired effects. We haven't done that yet. All PnP devices are : > probed together at the end, which isn't quite right. : : The problem was presented as "we are getting two entries for : the devices: one for the PnP BIOS, one for the device.hints". That's a useful high level abstraction of what's happening. However, it isn't completely accurate either. : Whether it's perfect or not, making the device.hints "go away" : in the presents of PnP BIOS on the machine would seem to be : able to address the issue of doubled entries... right? Not entirely. There are ISA devices in devices.hints that aren't plug and play and aren't in the PnP BIOS list. That's a worse problem than the minor printf :-). : Is there something I'm not seeing here from Kazutaka's posting, : or am I being misled? Yes. Yes. :-) What we'd like to happen: PnP BIOS devices device.hints PnP ISA devices What we do now device.hints PnP BIOS devices PnP ISA devices Note, I tried making the simple changes to make this work, but it failed in subtle ways that I didn't have time to trackdown... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Warner Losh wrote: > Since that's not how it works, the solution is a non-starter. > > We just need to carefully order the ISA code probing sections to get > the desired effects. We haven't done that yet. All PnP devices are > probed together at the end, which isn't quite right. The problem was presented as "we are getting two entries for the devices: one for the PnP BIOS, one for the device.hints". Whether it's perfect or not, making the device.hints "go away" in the presents of PnP BIOS on the machine would seem to be able to address the issue of doubled entries... right? Is there something I'm not seeing here from Kazutaka's posting, or am I being misled? Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Mike Smith wrote: > > So, you are saying that this is because there is not a seperate > > "No BIOS" and "BIOS" section (or entry prefix) in the hints file, > > so that in a non-PnP system, both the "No BIOS" and "BIOS" > > entries will be examined, whereas on a PnP system, only the "BIOS" > > entries will be examined? > > This would be an unnecessary complication. I think the reason the hints are not just ignored is to allow people to fix "rogue" hardware. I'm willing to be corrected, since this looks like about 12 lines of code would make it ignore device.hints in the "PnP BIOS present" case. > > PS: The "BIOS" section could be shipped non-empty, if it had > > a "per-rogue" setion or prefix... then known broken PnP BIOS > > systems would "just work". > > The amount of work involved in making this "just work" would be pretty > enormous, and most of the applicable systems are approaching "relic" > status, making it hard to find them in order to debug. I wasn't suggesting that the work be done up front! This would have to be handled on a case-by-case basis, by the people having the problems with the defaults sending in their identifying information and the fix that works for them. It would only accumulate the knowledge of the rogues over an extended period of time, on an as-needed basis. Regards, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
In message <[EMAIL PROTECTED]> Terry Lambert writes: : So, you are saying that this is because there is not a seperate : "No BIOS" and "BIOS" section (or entry prefix) in the hints file, : so that in a non-PnP system, both the "No BIOS" and "BIOS" : entries will be examined, whereas on a PnP system, only the "BIOS" : entries will be examined? : : It seems an obvious enhancement to me that there be seperate : sections, where the "BIOS" section is shipped empty, and is only : consulted to override broken PnP BIOS contents on PnP BIOS : systems... : : PS: The "BIOS" section could be shipped non-empty, if it had : a "per-rogue" setion or prefix... then known broken PnP BIOS : systems would "just work". Since that's not how it works, the solution is a non-starter. We just need to carefully order the ISA code probing sections to get the desired effects. We haven't done that yet. All PnP devices are probed together at the end, which isn't quite right. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Warner Losh wrote: > : Shouldn't we just take the Linux/NetBSD information, and > : actually identify the things instead of saying "Unknown", > : instead, and leave them printing to encourage someone the > : messages annoy to do the work? > > I'd guess that's too much work. Maybe someone can prove me wrong with > trivial patches. I think that the correct fix is to deal with the device hints differentially in the "PnP BIOS present" case, per other posts. Would you accept patches against 4.4-RELEASE? I don't run -current these days, since I need my machines to boot reliably and do real work, other than FreeBSD hacking... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> So, you are saying that this is because there is not a seperate > "No BIOS" and "BIOS" section (or entry prefix) in the hints file, > so that in a non-PnP system, both the "No BIOS" and "BIOS" > entries will be examined, whereas on a PnP system, only the "BIOS" > entries will be examined? This would be an unnecessary complication. > PS: The "BIOS" section could be shipped non-empty, if it had > a "per-rogue" setion or prefix... then known broken PnP BIOS > systems would "just work". The amount of work involved in making this "just work" would be pretty enormous, and most of the applicable systems are approaching "relic" status, making it hard to find them in order to debug. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> > >: unknown: can't assign resources > > >: unknown: can't assign resources > > >: unknown: can't assign resources > > >: unknown: can't assign resources > > >: unknown: can't assign resources > > >: unknown: can't assign resources > > > > > >Don't worry about these. > > > > Shouldn't we just suppress the message? It just confuses users. > > Shouldn't we just take the Linux/NetBSD information, and > actually identify the things instead of saying "Unknown", > instead, and leave them printing to encourage someone the > messages annoy to do the work? We don't need to "take" the information from anywhere; I've had most of the comprehensive databases for a while now. The problem with simply stuffing them into the kernel is that they're big, and I tend to agree with folk that we don't really want large single-use string tables in the kernel. This is why the PCI code that identifies unattached drivers reads the strings from a loadable file; once we can safely throw away loaded files, we can load the file at boot/install/whenever time and then throw it away once we're not interested anymore. However, the real reason that most of these strings are being printed is that the ISA probe order is bass-ackwards. The strings are printed because we have good PnP information that tells us a device is present, but we've already gone and believed the ISA hints and stuck a driver in that's claiming some or all of these resources. The messages should be silenced for 4.4, but the deeper problem needs to be addressed as well. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Kazutaka YOKOTA wrote: > Um, we see these messages not only because our ISA PnP driver needs > some update, but also because we create ISA device instances TWICE for > each motherboard ISA devices, such as sio and atkbdc, due to > /boot/device.hints. > > We need to have /boot/device.hints for those systems without PnP BIOS. > On the system with the PnP BIOS, we shall have one ISA device instance > (say, sio0) created by the isahint driver based on hints described in > /boot/device.hints, and the pnpbios driver will create another > instance (sio%d) for the very same device, based on information from > the PnP BIOS. Then, we will see "unknown: can't assing > resources" when the second device instance is probed. This happens > even if the device driver understands PnP IDs. So, you are saying that this is because there is not a seperate "No BIOS" and "BIOS" section (or entry prefix) in the hints file, so that in a non-PnP system, both the "No BIOS" and "BIOS" entries will be examined, whereas on a PnP system, only the "BIOS" entries will be examined? It seems an obvious enhancement to me that there be seperate sections, where the "BIOS" section is shipped empty, and is only consulted to override broken PnP BIOS contents on PnP BIOS systems... PS: The "BIOS" section could be shipped non-empty, if it had a "per-rogue" setion or prefix... then known broken PnP BIOS systems would "just work". -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Thus spake Warner Losh ([EMAIL PROTECTED]): > I'd guess that's too much work. Maybe someone can prove me wrong with > trivial patches. Maintaining the device-table is probably the most work (since we already have the PNP string and most lists are sortedc by this string as well). Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
In message <[EMAIL PROTECTED]> Terry Lambert writes: : Shouldn't we just take the Linux/NetBSD information, and : actually identify the things instead of saying "Unknown", : instead, and leave them printing to encourage someone the : messages annoy to do the work? I'd guess that's too much work. Maybe someone can prove me wrong with trivial patches. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Kazutaka YOKOTA wrote: > >: I'm running -current as of an hour ago. I've gotten this since I've > >: been running 4.2-stable, any ideas on how I can find out what it > >: belongs to? > >: > >: unknown: can't assign resources > >: unknown: can't assign resources > >: unknown: can't assign resources > >: unknown: can't assign resources > >: unknown: can't assign resources > >: unknown: can't assign resources > > > >Don't worry about these. > > Shouldn't we just suppress the message? It just confuses users. Shouldn't we just take the Linux/NetBSD information, and actually identify the things instead of saying "Unknown", instead, and leave them printing to encourage someone the messages annoy to do the work? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
In message <[EMAIL PROTECTED]> Wilko Bulte writes: : They are also in RELENG_4.. Those should be hidden by -v then :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> > >: unknown: can't assign resources > >: unknown: can't assign resources > >: unknown: can't assign resources > >: unknown: can't assign resources > >: unknown: can't assign resources > >: unknown: can't assign resources > > > Shouldn't we just suppress the message? It just confuses users. > > I would be satisfied just knowing what devices these messages > correspond to. I suspect this the sentiment of the original poster > as well. Then go look them up. I'm not about to stuff the entire PnP device database into the kernel just to satisfy your curiosity. 8( -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
>In message <[EMAIL PROTECTED]> Kazutaka YOK >OTA writes: >: Shouldn't we just suppress the message? It just confuses users. >: >: The attached patch will print this message only when we boot >: the kernel by 'boot -v'. > >They are there to remind certain folks that the ISA PnP code is broken >slightly and to please fix :-). If we get closer to 5.0 RC1, then >yes. > >Warner Um, we see these messages not only because our ISA PnP driver needs some update, but also because we create ISA device instances TWICE for each motherboard ISA devices, such as sio and atkbdc, due to /boot/device.hints. We need to have /boot/device.hints for those systems without PnP BIOS. On the system with the PnP BIOS, we shall have one ISA device instance (say, sio0) created by the isahint driver based on hints described in /boot/device.hints, and the pnpbios driver will create another instance (sio%d) for the very same device, based on information from the PnP BIOS. Then, we will see "unknown: can't assing resources" when the second device instance is probed. This happens even if the device driver understands PnP IDs. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
On Sun, Aug 26, 2001 at 09:51:57AM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Kazutaka YOKOTA >writes: > : Shouldn't we just suppress the message? It just confuses users. > : > : The attached patch will print this message only when we boot > : the kernel by 'boot -v'. > > They are there to remind certain folks that the ISA PnP code is broken > slightly and to please fix :-). If we get closer to 5.0 RC1, then > yes. They are also in RELENG_4.. Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.3-STABLE #2: Mon Jul 30 20:35:10 CEST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/FREEBIE Timecounter "i8254" frequency 1193182 Hz ... unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
>: unknown: can't assign resources >: unknown: can't assign resources >: unknown: can't assign resources >: unknown: can't assign resources >: unknown: can't assign resources >: unknown: can't assign resources > Shouldn't we just suppress the message? It just confuses users. I would be satisfied just knowing what devices these messages correspond to. I suspect this the sentiment of the original poster as well. brad To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
In message <[EMAIL PROTECTED]> Kazutaka YOKOTA writes: : Shouldn't we just suppress the message? It just confuses users. : : The attached patch will print this message only when we boot : the kernel by 'boot -v'. They are there to remind certain folks that the ISA PnP code is broken slightly and to please fix :-). If we get closer to 5.0 RC1, then yes. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
>In message <[EMAIL PROTECTED]> "David W. Chapman
> Jr." writes:
>: I'm running -current as of an hour ago. I've gotten this since I've
>: been running 4.2-stable, any ideas on how I can find out what it
>: belongs to?
>:
>: unknown: can't assign resources
>: unknown: can't assign resources
>: unknown: can't assign resources
>: unknown: can't assign resources
>: unknown: can't assign resources
>: unknown: can't assign resources
>
>Don't worry about these.
>
>Warner
Shouldn't we just suppress the message? It just confuses users.
The attached patch will print this message only when we boot
the kernel by 'boot -v'.
Kazu
Index: isa_common.c
===
RCS file: /src/CVS/src/sys/isa/isa_common.c,v
retrieving revision 1.23
diff -u -r1.23 isa_common.c
--- isa_common.c2001/08/10 07:50:14 1.23
+++ isa_common.c2001/08/26 10:24:03
@@ -416,10 +416,11 @@
/*
* Disable the device.
*/
- bus_print_child_header(device_get_parent(child), child);
- printf(" can't assign resources\n");
- if (bootverbose)
- isa_print_child(device_get_parent(child), child);
+ if (bootverbose) {
+ bus_print_child_header(device_get_parent(child), child);
+ printf(" can't assign resources\n");
+ isa_print_child(device_get_parent(child), child);
+ }
bzero(cfg, sizeof (*cfg));
if (idev->id_config_cb)
idev->id_config_cb(idev->id_config_arg, cfg, 0);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> Going off on a slight tangent, I wrote a perl script months ago > that parsed the output of dmesg, and tried to determine which IRQs were > used, and for what. One of the side-effects of this script is that it > also tried to identify unknown PCI devices (but *only* if an IRQ is > used), using an (old) hard-coded table originally obtained from: > > http://www.yourvote.com/pci/pcidev.csv > > You can get the script from: > > ftp://ftp.sonic.net/pub/users/darrylo/freebsd/scanirq.gz > > It's written for 4.X, but might work for -current (you'll have to > disable the checks for 4.X, at the very least). You use it like this: > > dmesg | scanirq It's completely obsoleted by devinfo and pciconf's '-v' flag. Sorry. 8) -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
In message <[EMAIL PROTECTED]> "David W. Chapman Jr." writes: : I'm running -current as of an hour ago. I've gotten this since I've : been running 4.2-stable, any ideas on how I can find out what it : belongs to? : : unknown: can't assign resources : unknown: can't assign resources : unknown: can't assign resources : unknown: can't assign resources : unknown: can't assign resources : unknown: can't assign resources Don't worry about these. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Alexander Langer <[EMAIL PROTECTED]> wrote: > Thus spake David W. Chapman Jr. ([EMAIL PROTECTED]): > > > I'm running -current as of an hour ago. I've gotten this since I've > > been running 4.2-stable, any ideas on how I can find out what it > > belongs to? > > Statically wired ISA devices. > > > unknown: can't assign resources > > unknown: can't assign resources > > 501 are the sio ports for example. > > Look up some PNP devices listings, they're probably all listed > in your device.hints. Going off on a slight tangent, I wrote a perl script months ago that parsed the output of dmesg, and tried to determine which IRQs were used, and for what. One of the side-effects of this script is that it also tried to identify unknown PCI devices (but *only* if an IRQ is used), using an (old) hard-coded table originally obtained from: http://www.yourvote.com/pci/pcidev.csv You can get the script from: ftp://ftp.sonic.net/pub/users/darrylo/freebsd/scanirq.gz It's written for 4.X, but might work for -current (you'll have to disable the checks for 4.X, at the very least). You use it like this: dmesg | scanirq -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
Thus spake David W. Chapman Jr. ([EMAIL PROTECTED]): > I'm running -current as of an hour ago. I've gotten this since I've > been running 4.2-stable, any ideas on how I can find out what it > belongs to? Statically wired ISA devices. > unknown: can't assign resources > unknown: can't assign resources 501 are the sio ports for example. Look up some PNP devices listings, they're probably all listed in your device.hints. Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
"David W. Chapman Jr." <[EMAIL PROTECTED]> is believed to have written: > On Fri, Aug 24, 2001 at 01:13:36AM +0200, Salvo Bartolotta wrote: > > > I'm running -current as of an hour ago. I've gotten this since I've > > > > been running 4.2-stable, any ideas on how I can find out what it > > > belongs to? > > > > > unknown: can't assign resources > > > unknown: can't assign resources > > > unknown: can't assign resources > > > unknown: can't assign resources > > > unknown: can't assign resources > > > unknown: can't assign resources > > > > > > > > This harmless message has been known for a good number of months. > There is > > nothing to worry about. > > > > Now before someone flames both of us -- me for responding and you for > not > > first searching the archives, where discussions about this topic took > place > > countless times -- could you please go there and retrieve this > information? > > :-)) > > > > By the way, you can also find freebsd posts on http://www.google.com > and > > http://www.geocrawler.com. > > > I have no problem with that, last time I asked this wasn't in the > archives and I didn't get a response. I am in a good mood tonight. :-) http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=351737+353670+/usr/local/www/db/text/2000/freebsd-current/2507.freebsd-current http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=272660+274467+/usr/local/www/db/text/2001/freebsd-current/20010304.freebsd-current http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=82781+85574+/usr/local/www/db/text/2000/freebsd-current/20001001.freebsd-current . . . http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#PNP-RESOURCES -- Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
On Fri, Aug 24, 2001 at 01:13:36AM +0200, Salvo Bartolotta wrote: > > I'm running -current as of an hour ago. I've gotten this since I've > > been running 4.2-stable, any ideas on how I can find out what it > > belongs to? > > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > unknown: can't assign resources > > > > This harmless message has been known for a good number of months. There is > nothing to worry about. > > Now before someone flames both of us -- me for responding and you for not > first searching the archives, where discussions about this topic took place > countless times -- could you please go there and retrieve this information? > :-)) > > By the way, you can also find freebsd posts on http://www.google.com and > http://www.geocrawler.com. > I have no problem with that, last time I asked this wasn't in the archives and I didn't get a response. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. [EMAIL PROTECTED] FreeBSD Committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown PNP hardware
> I'm running -current as of an hour ago. I've gotten this since I've > been running 4.2-stable, any ideas on how I can find out what it > belongs to? > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources > unknown: can't assign resources This harmless message has been known for a good number of months. There is nothing to worry about. Now before someone flames both of us -- me for responding and you for not first searching the archives, where discussions about this topic took place countless times -- could you please go there and retrieve this information? :-)) By the way, you can also find freebsd posts on http://www.google.com and http://www.geocrawler.com. HTH, Salvo To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
