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!NYD:69F,P]66USVD@2_HQ_1:]3ZQ)(D7@[3
M#0R2RTQ/D-M[5WI9+%8%0B9.$-[Y+[K=?][SH#6$[N52H,IA1=T_W3/?3
MSPPC;\X^=$-[1K^68Z_7OOB7/P^O]_'5SWI[!P5ZP+M3!P:OV;*?\,'\-:
M?C[]X2!@4R!][@P _0M?WP#RI-P[F[F(!U2U4 _H*3KUJ.[Z6Z89@U
MHU,S#3#:W9;1-9LE;JE2JR7;J!TL]MJ= WCX.U;J#;;=1TM5)KM4[UUF_?
M'D!I$3F.8L['3Y8L^'J_+Y !P[?B@6H)CN2?(M@$_BT#[4S_JV\#
MPS'82$/D1+.\(W]@C.RG;7]*\;.6 A?XV(+F%X31R4%1J^XM;25OY:N
MLP3']CP_ GPVQVAN5VP.?@!+^X![ZT\8T) X[O+=R[;6!'N*#Z7A]VIP?4
MKN[NP#MUOC!Q;^B$KH]G2)G]:*$=TD+RUGZ:[F ?.Z/'[:QOO*O99
MV]AA;Y']XA+EFEM$!?-1=@W$.+ER I]3Q:Z52AO_0)$+9BH _1$E]*?[
M3S)2J-@ZT0\(80L'+OX#TH.ACSR6C: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%DI\N2Y;.NW# J
M7D0*CP0Q4]P[SXKS4ZA3 JUZHQ-PC'P0IW/9DY5C[?JV,Q+PH25,YP#V0
M222O)ELEVEM()C!@,X;U*SY!%E'U82J%T54195)D!NUOG]:[3WUD-P
M\!T[PDQ(JB[RX9ZQ#?A8CH%24O6S/PU;$,J*WR\/I'/5J4IN/1=:]GUP/
M_W?-(Q'AVEP\KU[M6BB=S!1]4W.,\6L(JALEVA+/W/FY?))=*^ZP1E;1
M(UT4HBXE10)P_AQP[+#[EMAIL PROTECTED]+H\%_\,^4JT? 7_L'?ZT+7SN^L]BJD!)
M6H=F(*7P1093$50AX 4+!PC%FTBGJ9M-J+0:3;U^)IH(=_4YE(%,@0V
MB-+3J7DN$0Z-8XI(CY9V+;(IZBX-EK!DM%QT3BA$Z)@2^S%W2$SE26PU
M8/ 7M^CX 2;(QO?F6:37!!R!)39*8N*3V[=B6)!R61LX7KSG9GCG)%!D^+6
MZ,8#+ 0+S^.Q[(64U BI\QWK-3R\9R@/)9S '\=BO)2;O$E@I\I'[)R4_/
M\]!1! AYI2*WOR0P^ (00I#LJ-/@-+@/.D*M[E]#H$03JQGA$)0F'=2Q
M1!$J_'E:-V!KV_5H09^RLI=B5+^:8BAF\8W4I%[^CH4/!=3D/91$PX39VZ
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((SN4*.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#CHUPK U$7Y;R#I^XV5,Y.VWI'QBVJ[JGBX5+?0)^
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)-9D7K-8V7A=4%Y8+PY/.\
MMGP5Z-:]3D+'5E]F?((G83YIB2% 1D3CJO'Q_N#+Q^7R\=VYNZQ#1DG
MZXEW29:-2,5JU^D:]:S2[]7:)[!3/[CFT\)KMKMGIUL]XS;3:5#+X
M;AJB8%*EG*(YI016S@SGIBV^(XGY8@%'M;( PLEQ4YTG5ML6TD#ZY-M;
MZM9V[FQ]1RZA)Z#[X[+V7D[#NO)16P('MOF/(=[$25)MIN6N[AF'N[
MC81SE5?85R/%5+,DF;Q07FJ9ARY])SC[Z@FE+9Y,K$]5PG[TF7$[ 3P0J
MNS8I%1^=^=)\X7HYHXQ%37*)4TKN)LLIQ'%?;#D N7V5 $_RPW@QV=X
M,.N9C#KD#B8RG\Q(O/YM(9BQEFW:70-L\1MI+(_(QI?NM[]99(?1/;8 7?
M5JS5@(-?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*?:=;PMTNF:C
MVVB4N(54 L22*BKF]VZ^-'%K#(_M') LQ_;P97@XFUZ.!GAZ#J]'O7%F
M:#SY==3OC4FP6DJQX ]7FL#W**=,3T[J.AR9EB07U7UDKV9K28G-ZU3259)
MO-?O#Z?3R;46LLU5SI('_'4'95S(C'IT2%QNTA041X=8J%64G1N!\$J
M2!%HB)!=1!Z9#A[Q0C^T0]A%2#M1W6P+,W.!?UH;QS^-@-EM93DK6+W
MVB7#8M)HCZIS7^=NOZX0\ O-Q\Q.^F6\9AVD@SS=U9D(IN4R)CRC4:W
MU2IQSSEBZ5CV#.1(8C[GQ;E$;ZW1J]CUGM9TSN%CC403;2^T!MS^PUR?+
M-T5/-XZ8(/LT77!OB+7F'L1$9$+6W7 [HH?2',@?R/M$%XWZ9@J %OUPZO+
M*]Z(WTTF,]G'+RZ:JHM3Z+/VS@_*-ZJ=YSD_WN)J[6XFLNOLGWGGO:+
M-W/)4?**U\,/DYMA/.EI.=7(T4C UOX#(_9 VM6\MB@;12,3X:Q5V;P!Y:.
M$H_)32Y'/^!0F8[H2K%LVGQ46[O%=*S4=1/2W9]0:3XJ]'PW' R7$K[;C
M9:J^:XV1+SNBV_XU,C5^_4_K3:\MG2\Z5D2TGV3^-.C\PM85LSM+ LT
M[*3./,3NC@,MCJ\L5=:G49\S2F.I,7]-VGVZ+OJPU53='9:-4!E-_HPV9
M?4,QS#,R,SNB4=.\%.(45WW'2OJ9XB J.XD5,W8'^4DAH4NGNL_/61;
MD3,BTB%OH=A$C?YZ;(PM?@Q;]\?*UHK:?#F5+#5C1^U^O_'N^%6#EO0T3
M6B_UJP*_LD!*RU*W,USE2*ZVS!)=W ;BB\9#]]\,JD ?_D)Q9C*%B$W=(IF
M7;K+;7=9CXS.UR6ORVJ_KN+S]PJ.QTC4\_?Z(?6)3V.$$+S_?HRKZ^JZB
M']:-_9S5ST;PEX+B@GLE!/GM;?^$TJTNC3^OALGS#6HETY8JX*4H]261=
M7?!#*HQT'7+3\HX#,O?O=^JF01RB@)O)W4*@LVCIE+78CC'PDZ$VD)!G!
*_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!NYD: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^NMXW#)J)[A![@3D03!LMP5-TW6Q?)IS?PYS;\T@H,G MO##PHW#'U;2W!MIM*,(TCF7H(7]@1^X/$%_48Q!'*T%3S;B(DXH4K^*5 MSZ PB:)DS0DBED1AXREX$R*[RF!2[)%]?\V J6.@ W5-0[\*[U+L_P]X M@)(QBP04.+P!ZQHX_ )AJH6WI5(1_JYE8Z;@'R(PJG0'_POFL2($['R$QE M)0MG'/^@9*=[/Q[T1JV53)%_%53_R)8116,Z$K%*IJ 7*%;X:MWK]W]UW MO%H7#BE^IO^=15(8R+M4WB4\7+=B5$?8R@8/A=1'C!$(R!6E4=2XR M!E^V!Z_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/(1S MA#*,*(VUJR:*I%/*6C (TVT)8R]\@E7H!4'DPF;9@=1/#(V!(BRE*JE!;. M3$0+6,6$6'R\J.CG,D_J-\;C=UW@VWU7Y?P/68( (3 AX^ID%3Z,%'Y;=H M3-J8( X(1?]8Q/K_63?*RDPP6:%3TR%=A-+:D (/63IR7+#Y_BE/D1RX1_ M\6OK*-'P%_DCKW3!+Y(+1JY,(;AEGQ-9KHC(-BMCVI0BD?Y(NO3%E!XQ1: MV5.(Y4:,(]8I$LGENVC4H-XMLW:1TN@1E29-'ZAL5=2:A.9#)XVA*/ M$'H+!G/TV$3T,.!)IK8W1J8^B:6@.,2D[#KU1,(=%)!?EXK;*9U($WS[3R MO-RNSO=NCM43;M*VJ5,- @W@!DW7J[ZW3I^N;K+W@85,%^M466UL$5[ M,-21W $G)[N^2TM?84U0*YDB_YWG,CB10I;ID:V2);!B$!G1*#R_KK;P M$@IVF6[ZV#PS5P=67:-M; !=: +6O@R.:6+P%0)2 ;T!F,MBTNK8!/6 [2 MLZEF,H1PSA'0BM-T?E)@,]Y*!6#*%IB%;1FE642'4GY0^8MCA!YL[DNC-R M;P?CNV%WU+T=[W4VO3:MSV-L.])FVM7V.B$U0GASKASJY3BC+Z)@Z^G^[ MI1!2B=\2[D7#7KE^8%EYMA)E876JL@P8!DX+18XE9S*L,Q$Q[5%#R M/1'W)6YO?O6T.VT;UL?N@ZYOIVCL$+(+Q/A)L6=TI8!T9-1!J=LYJ.0S9P M![\2(71O!P@/5#2W:N:=/BN75WSTDTNO8B?;CG-WQBYQ;,6T3?4$G!7U M;%_UMJ#+6[]O6S6S:4KAJV:G=5A^:A2*ESQW/TT= Z!EE'=%A=5 C! MWM[);_Z#3W[S9T]^S=S!KYEWN?-Z?3G%6UE7:U@UQZH[M:9!^P^^:Y M8Q]).?JV-=H$DCQVE0YSYQJ,OMY8QO':\!=?44?93P@H2)$+\QJ)5S62K MZT^PO#:ZNU?:SWB_PFP5^G0H5'KKB$^-G+PG'JZ-K (.K!9(9HJWM\!7 M6KI42/P'DG:^2(1\Q/6!,3T:LAAI%HU X*HK0J8W\+4G8BES,()O]A M;P^4L6!9-=R,+=Z-9!C1]UIS%Q4441Z\JI6XYEU)?HRGMH'.A=.H*C( M%P9X3F-!3C$HO$E ED)N*OP;#3';JCNV[[8[\U[MUW%4DA^I?/X[5J?C MMM_W^IW$D^NM).5$Y@R;[BM#7DB2,HG=N/_;X)95L2YUI)DLJ$_FHY2 M+E%HB8E%+UI!5D*GDCD6P*\\:-5J^V:4L_##FD+:?U]DY=\765OW=,[E MC(+VZ[6F!=.O:YWYN2V=\HU4GBRLILRX73NG%D$_ND5L6M1]][8S/8Z M9G9PU!WV6OW4'_P6Z_=ZI-@3O:'GRX0W1T,U[8V9V4'7M(B1RJ5;C3J1 MF-UH:!8C\5:[W1V-!L-C'M^#\^UVAGB;%'9$@N#(,7B0A:U_AP33MFW MQCLE5LJ)*4B9H+PU(=AR7$\GB)IDJI8/CJPB'B[_=)0NGF-LD2'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
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
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
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
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
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: PNP0303 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0401 can't assign resources
: unknown: PNP0700 can't assign resources
: unknown: PNP0f13 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
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
: unknown: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 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
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: PNP can't assign resources unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0501 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
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: PNPXXX 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
: unknown: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 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] 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
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: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 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] 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
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
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: PNPXXX 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
: unknown: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 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
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
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
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
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
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
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
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
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
: 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!NYD:69F +U8ZW/:1A#_+/Z*;3+-@59#UXV;CJA
M0%JF!+M _*7M:3I@)N 1$_C:3_[V[=P))!+2SL0SD:SSOOWC\LPMG'
M#O#$M_?%\3K=1Q=!I77__^G,NE-8Y7K -6(@*K=S^5[^0IL0[U8\5P5+!
MV2./%B#PE? X N?2K5=/I^#N053T4S#1-\YGMFFO;CF5?68X-=KO3M#M.
M0Y.2=%T_3TVPEV7*=CMRIOWH#9:+M_1ITC/.F MI,%8-Y@L#WGFS
MP;N[VDT%\-BZJ)@:7,8?4QA(^('!OYJ!5$F9MH RZ$[ $DAC2I9_B@SU!
ML/+YFG[E0C$+EL1;071S+I+TLJ+3Z6S)(J,@,UCR52A8=(EJX+)Y]#]2.
MTTF'N*$U5:MA$\2N?5%^2HY/5V?!TIBX),UMU%=SOK_HAH#?Z;Q%2Q0C
MQB864.7PNP;X/ #1#L_-3UOR#-)I2YJ6*XEW1+_S/TF(EJ1BZ0RR8H6
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@^741,)E=6H!!3!6_I)VAR9B[*4D@\M,EI@_
M [8) YX6W-A;'@9$5K2[!!]IYMXDB07\,M2Y!O+GQ38A.YTDLJX7O4)GN
M4.?-7F6F(IMY.B_#6,9V.W*[NWO(($?ETF%3*:;'^,+19)6$0UY2U\+G
M?ZV@9]5CGE$$YI*P#Q2!!=PJ@CT$QE\V;@D5,\$!E4=DO4PD%YB]A;U]D
MWWUUE1T!';QZE44,C4N])/53EJFU^C=U!O?SNXF@^E@/%-^? 8GX_C4='
MSQ6? OMYU8Q=:)!G1QOQ1.L);'%.1,RTW)WD\%J7BB3A99NF7JUT*0VC3
M\'=DX/CYY@2RB/ XQ96Y'QC;0(R@%CNF'3G(EZ#*E:%9IL[:5T0*]
MW;0-')%RLD7*'[2M_0DS6S_EH?3N03#_ [F@:X/K04QZ WONQ.OWQMW
MWPTZ%-Y1G6+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/CMC62V29RH@=UW(=
ML.M$[-1E#IMM2B$^VRJ!A0ZG2D]6BY97X@W@N*/FK;YQXTB9B##3CXAJM??D
MO,$#@F_/BY^2.\!J?##S#?1D%*[DN^QYB'6HG%XL;KB !]LU5JZ:GCDL
M%%9.(X/GREGD]R-7R)B.$1R_LVM2T:O7(FE,K=D;^Z(M$$M.($4*OME^
MKI2=!)/CEM#DN) ;6,2.LD6[1; ^SK3L/NV(XF91205)M6W8#[*M.XPHW
M 4CQ\-')^[1L!6:-BC$7(!-8P5?KMI#^8-.[0_]J#L;W@]4Y]T-VY_
M3[UNO^_U?AF.^M6-CW,7UR4IP) YQ-TIXJDCV?QT!PRP'1DZ 1DW'A$E#+
MP6)HW3+2281M)MCV68$LBQ\DKM 3^!ME'V4((#:^641ND[?SNSR[R
MO7F%_,N#K#4XEMNDG#KU3KVN20F%].\I,?L.$E,3:30[CQUC*N\#[60@Q0
M\G',84V?V,V: @RQBW'R![.4G'Y71OEQ5@ R6 \'1)$-)LZQHHM_. )
M$A8EG#I-+I_VQ/L.8TIR KE9G[D;WVF:*]O=:KLP2,P-RO_J2F?\9T
MXI?*XU?)ZC@A'N6$T$2?JGW 4Y;#:9MQ-\32 NW;_H9OPW]E(_@K4?
M^0LF^ZX=9P9NN,V,/RY/?#_'XP[M].AGVC#@=3(;=4EH=/OSL-=$:9
MG_9NW]VATWTLRV=G1O%0[0R[AHX2+.:#1IH3K.5330B[_9Z@^GT=E)-.WV
M5P9DQ@ VM=H!R2I)PW'.L_M^\8X6[!,6!OG2+32V2JI1B@K#6@M,N0XPC
M#5!B%6L_^IX/%7]Z12'6=94(_6AC%+.R?7G^K^]D+3*6]-]:N6)1\/
M/$Z^P8 ZT'R137*,ZKA0F:@;% '4O:MQ[VF)E6O=YI-3J03HX=0LG%:U
M+E%GV\X5=2KU(G2\I!#/-42E_-\BZ(:AO,AGLU]3''@TXT]*=2$O)VJB]_Q
M50JP-(DTL_D*[:1PU63:M'-#X6/+L[;D+S1S([+-'LX7R,B+1-!S,LK_';
MX\8GWT4[?WZ]X:Q1)M**I2FMK+#)R?Q(Y_\61TMZR?(J4Q/ZJ?^[_:=1
+J?P+D26VDX4 :
end
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: PNP0303 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0501 can't assign resources : unknown: PNP0401 can't assign resources : unknown: PNP0700 can't assign resources : unknown: PNP0f13 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
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
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: PNP0303 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0f13 can't assign resources dwcjr# pnpinfo Checking for Plug-n-Play devices... No Plug-n-Play devices were found dwcjr# pciconf -l hostb0@pci0:0:0:class=0x06 card=0x chip=0x03051106 rev=0x03 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x0080 chip=0x83051106 rev=0x00 hdr=0x01 isab0@pci0:7:0: class=0x060100 card=0x06861106 chip=0x06861106 rev=0x22 hdr=0x00 atapci0@pci0:7:1: class=0x01018a card=0x chip=0x05711106 rev=0x10 hdr=0x00 uhci0@pci0:7:2: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x10 hdr=0x00 uhci1@pci0:7:3: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x10 hdr=0x00 none0@pci0:7:4: class=0x0c0500 card=0x chip=0x30571106 rev=0x30 hdr=0x00 ahc0@pci0:12:0: class=0x01 card=0x78879004 chip=0x87789004 rev=0x01 hdr=0x00 bktr0@pci0:13:0:class=0x04 card=0x00011002 chip=0x036e109e rev=0x02 hdr=0x00 none1@pci0:13:1:class=0x048000 card=0x00011002 chip=0x0878109e rev=0x02 hdr=0x00 pcm0@pci0:14:0: class=0x040100 card=0x20601458 chip=0x13711274 rev=0x07 hdr=0x00 xl0@pci0:15:0: class=0x02 card=0x905510b7 chip=0x905510b7 rev=0x30 hdr=0x00 none2@pci1:0:0: class=0x03 card=0x400a1043 chip=0x010110de rev=0x10 hdr=0x00 Let me know if I need to provide anything else. Also I get this bktr0: Warning - card vendor 0x1002 (model 0x0001) unknown. this is an ATI TV Wonder. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org 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: PNP0303 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0f13 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
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: PNP0303 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0f13 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. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org 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: PNP0501 can't assign resources unknown: PNP0501 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
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: PNP0501 can't assign resources unknown: PNP0501 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...
IF and ONLY IF the PNPBIOS code is causing your machine to fail, do the following: - Send me FULL DETAILS; this will need to include the trap messages and, if the trap is in the kernel, a DDB traceback. The described situation actually occured to me tonight (5-28-2000) while trying to install. Rather than check the list for a solution, I went back to the 4.0 boot disks (which worked really well) and changed them to setup a snapshot (5.0-2528-CURRENT). If you so desire (which presumably is the case), I can just boot up the current floppies and try to send you the information you request. I can't imagine not being interested in working out what's going wrong, so please, if you could, do so. Let me know what your hardware is as well, please. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
IF and ONLY IF the PNPBIOS code is causing your machine to fail, do the following: - Send me FULL DETAILS; this will need to include the trap messages and, if the trap is in the kernel, a DDB traceback. The described situation actually occured to me tonight (5-28-2000) while trying to install. Rather than check the list for a solution, I went back to the 4.0 boot disks (which worked really well) and changed them to setup a snapshot (5.0-2528-CURRENT). If you so desire (which presumably is the case), I can just boot up the current floppies and try to send you the information you request. I apologize for being currently un-helpful, but I will try to help if you still need so. Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
It seems Mike Pritchard wrote: I did notice that I started getting all of the "unknown: PNPx" messages after the PNPBIOS option became default. On the machine I'm typing on this on, I used to see those messages if I defined PNPBIOS in my config file. PNPBIOS became default some time back, with no way (that I saw) to turn it off. You can turn it off in the loader, I have to on my laptop to get it to work proberly... I can't seem to find your bug report in my inbox; could you resend, please? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
It seems Mike Pritchard wrote: I did notice that I started getting all of the "unknown: PNPx" messages after the PNPBIOS option became default. On the machine I'm typing on this on, I used to see those messages if I defined PNPBIOS in my config file. PNPBIOS became default some time back, with no way (that I saw) to turn it off. You can turn it off in the loader, I have to on my laptop to get it to work proberly... Would that be in /boot/loader.conf? I've tried PNPBIOS="NO" in /boot/loader.conf, and I'm still getting the messages. [snip]dmesg plip0: PLIP network interface on ppbus0 unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources /dmesg If you're just complaining about the messages, don't do anything. They'll go away soon, and there are much better things to spend your time worrying about. IF and ONLY IF the PNPBIOS code is causing your machine to fail, do the following: - Send me FULL DETAILS; this will need to include the trap messages and, if the trap is in the kernel, a DDB traceback. - Read the loader's online help for details on disabling use of the PnP BIOS. Note - just turning it off and not letting us fix this is a Really Stupid Idea, and I'd hope that you can see why. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
On Wed, May 10, 2000 at 10:16:17AM -0400, Garrett Wollman wrote: On Wed, 10 May 2000 11:57:21 +0800, Trent Nelson [EMAIL PROTECTED] said: Something else I've noticed in the mean time is that PnP devices like my printer - that are also on buses that are probed for PnP devices - end up being probed twice at boot time. Delete the `at isa? port blah' cruft from your config file. For what devices? The only devices I have those on match what is in GENERIC. I did notice that I started getting all of the "unknown: PNPx" messages after the PNPBIOS option became default. On the machine I'm typing on this on, I used to see those messages if I defined PNPBIOS in my config file. PNPBIOS became default some time back, with no way (that I saw) to turn it off. Other than the annoying messages at boot, it never caused a problem that I saw, so I didn't really worry about it. If we aren't supposed to have "at isa? port ..." stuff in our config files, then someone should update GENERIC to reflect that. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
It seems Mike Pritchard wrote: I did notice that I started getting all of the "unknown: PNPx" messages after the PNPBIOS option became default. On the machine I'm typing on this on, I used to see those messages if I defined PNPBIOS in my config file. PNPBIOS became default some time back, with no way (that I saw) to turn it off. You can turn it off in the loader, I have to on my laptop to get it to work proberly... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
Soren Schmidt wrote: It seems Mike Pritchard wrote: I did notice that I started getting all of the "unknown: PNPx" messages after the PNPBIOS option became default. On the machine I'm typing on this on, I used to see those messages if I defined PNPBIOS in my config file. PNPBIOS became default some time back, with no way (that I saw) to turn it off. You can turn it off in the loader, I have to on my laptop to get it to work proberly... Would that be in /boot/loader.conf? I've tried PNPBIOS="NO" in /boot/loader.conf, and I'm still getting the messages. [snip]dmesg plip0: PLIP network interface on ppbus0 unknown: PNP0401 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources /dmesg - Donn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
On Fri, 12 May 2000 05:08:10 -0500, Mike Pritchard [EMAIL PROTECTED] said: [I wrote:] Delete the `at isa? port blah' cruft from your config file. For what devices? The only devices I have those on match what is in GENERIC. For those devices which are double-probed. (The fact that you need to do this is actually a bug.) If we aren't supposed to have "at isa? port ..." stuff in our config files, then someone should update GENERIC to reflect that. We need that stuff in order to cope with older hardware that doesn't implement PNPBIOS (or PNPanything, for that matter). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
On Wed, 10 May 2000 11:57:21 +0800, Trent Nelson [EMAIL PROTECTED] said: Something else I've noticed in the mean time is that PnP devices like my printer - that are also on buses that are probed for PnP devices - end up being probed twice at boot time. Delete the `at isa? port blah' cruft from your config file. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unknown: PNP...
I just updated an i386 machine after a month to the latest 5.0-CURRENT, and I now get some strange boot messages: isa0: too many memory ranges ... unknown0: PNP at port 0x20-0x21,0xa0-0xa1 irq 2 on isa0 unknown1: PNP0200 at port 0-0xf,0x81-0x83,0x87,0x89-0x8b,0x8f-0x91,0xc0-0xdf drq 4 on isa0 unknown2: PNP0100 at port 0x40-0x43 irq 0 on isa0 unknown3: PNP0b00 at port 0x70-0x71 irq 8 on isa0 unknown: PNP0303 can't assign resources unknown4: PNP0800 at port 0x61 on isa0 npxisa0: Legacy ISA coprocessor support at port 0xf0-0xff irq 13 on isa0 unknown5: PNP0c01 at iomem 0xf-0xf3fff,0xf4000-0xf7fff,0xf8000-0xf,0xcc800-0xc,0-0x9,0xfffe-0x,0xfec0-0xfec0,0xfee0-0xfee0 on isa0 unknown6: PNP0a03 at port 0x4d0-0x4d1,0xcf8-0xcff,0x480-0x48f on isa0 unknown7: PNP0c02 at port 0x208-0x20f on isa0 unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown8: PNP0401 at port 0x378-0x37b,0x778-0x77a irq 7 on isa0 unknown: PNP0501 can't assign resources Any comments? -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unknown: PNP...
Christian Weisgerber wrote: I just updated an i386 machine after a month to the latest 5.0-CURRENT, and I now get some strange boot messages: isa0: too many memory ranges ... unknown0: PNP at port 0x20-0x21,0xa0-0xa1 irq 2 on isa0 unknown1: PNP0200 at port 0-0xf,0x81-0x83,0x87,0x89-0x8b,0x8f-0x91,0xc0-0xdf drq 4 on isa0 Mike Smith wrote: Could someone please either take a look at this, or give an authoritative comment as to why it's happening. This is the ISA PnP code reporting devices enumerated via the PnP BIOS. At the moment, our support code isn't smart enough to use either the PnP interface or the resource manager, so the unknown device claims these resources to prevent anyone else trying to use them. It's quite harmless, and once things are cleaned up, you won't even see the messages. Something else I've noticed in the mean time is that PnP devices like my printer - that are also on buses that are probed for PnP devices - end up being probed twice at boot time. Can anyone give an ETA on when this "support code", as Mike puts it, will work properly? Christian "naddy" Weisgerber [EMAIL PROTECTED] Regards, Trent. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
