Re: question abt top...
Joy wrote: what does CPU0 in the STATE field of "top" mean. i am running a SMP kernel. a process utilizes 99% of cpu and shows CPU0 in its STATE field. It states that the process in question is running on CPU0. If it were running on the second processor, it would say CPU1, etc. - Kris Kirby, KE4AHR | TGIFreeBSD... 'Nuff said. [EMAIL PROTECTED]| --- "Fate, it seems, is not without a sense of irony." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
routing bug(?) persists (PR 16318)
3.4-STABLE still seems to contain the annoying routing bug that prevents the correct initialization of a default route with the gateway being in a non-local network, i.e. like this: ifconfig_vr0="195.58.183.77 netmask 255.255.255.248" static_routes="0 1" route_0="-net 195.58.161.96 -netmask 255.255.255.240 -iface vr0" route_1="default 195.58.161.97" (the error message is "network unreachable" while the default route is being set) I have been using William Carrel's bugfix for several months without problems, but for some reason it isn't in the main source tree yet, so cvsup overwrites the patched net/route.c sometimes. Does the bugfix break something? If not, why isn't it in 3.4-STABLE yet? It is necessary for the above configuration (or isn't it? I couldn't find another way to treat this topology). Regards, -mjy -- ***== Marinos J. Yannikos [EMAIL PROTECTED] ***== http://pobox.com/~mjy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu 2000-06-15 (13:50), Marinos J . Yannikos wrote: I have been using William Carrel's bugfix for several months without problems, but for some reason it isn't in the main source tree yet, so cvsup overwrites the patched net/route.c sometimes. Does the bugfix break something? If not, why isn't it in 3.4-STABLE yet? It is necessary for the above configuration (or isn't it? I couldn't find The PR number might be useful, if you have it. If it's not in the PR database, then you should submit it. That way we get to lay blame *grin*. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu, Jun 15, 2000 at 01:47:17PM +0200, Neil Blakey-Milner wrote: The PR number might be useful, if you have it. If it's not in the PR database, then you should submit it. That way we get to lay blame *grin*. Sorry... It was in the subject: PR 16318. I must add that I'm not altogether certain that there isn't a way to circumvent the problem by initialising the network differently, but I tried ... Regards, Marinos -- ***== Marinos J. Yannikos [EMAIL PROTECTED] ***== http://pobox.com/~mjy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu 2000-06-15 (14:03), Marinos J . Yannikos wrote: On Thu, Jun 15, 2000 at 01:47:17PM +0200, Neil Blakey-Milner wrote: The PR number might be useful, if you have it. If it's not in the PR database, then you should submit it. That way we get to lay blame *grin*. Sorry... It was in the subject: PR 16318. I must add that I'm not altogether certain that there isn't a way to circumvent the problem by initialising the network differently, but I tried ... erk, my apologies. My mind tends to forget the subject line by the time the body appears. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
3.4-STABLE still seems to contain the annoying routing bug that prevents the correct initialization of a default route with the gateway being in a non-local network, i.e. like this: ifconfig_vr0="195.58.183.77 netmask 255.255.255.248" static_routes="0 1" route_0="-net 195.58.161.96 -netmask 255.255.255.240 -iface vr0" route_1="default 195.58.161.97" (the error message is "network unreachable" while the default route is being set) The error message is correct. Does the bugfix break something? If not, why isn't it in 3.4-STABLE yet? It is necessary for the above configuration (or isn't it? I couldn't find another way to treat this topology). The above network configuration is incorrect - you need a gateway that is directly reachable. If you want to use the above default route, you need to give your machine an address on the same network as your gateway, most trivially by aliasing it onto the vr0 interface. -- \\ 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-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu, Jun 15, 2000 at 07:33:36AM -0700, Mike Smith wrote: [mjy] ifconfig_vr0="195.58.183.77 netmask 255.255.255.248" static_routes="0 1" route_0="-net 195.58.161.96 -netmask 255.255.255.240 -iface vr0" route_1="default 195.58.161.97" The above network configuration is incorrect - you need a gateway that is directly reachable. The gateway is physically connected to the same network, the physical network contains 2 (or more) distinct subnets. If you want to use the above default route, you need to give your machine an address on the same network as your gateway, most trivially by aliasing it onto the vr0 interface. I don't see why that should be necessary - my ISP doesn't either, since he'd have to part with another IP address. My ISP claims and I've verified that the configuration above works trivially under Linux and Windows NT, and as far as I can tell, the submitted patch does nothing more than to allow the specified interface to be taken into consideration when "connectedness" is determined (i.e. it allows the gateway to be in a different subnet as long as it is physically connected). Regards, Marinos -- ***== Marinos J. Yannikos [EMAIL PROTECTED] ***== http://pobox.com/~mjy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu, Jun 15, 2000 at 07:33:36AM -0700, Mike Smith wrote: [mjy] ifconfig_vr0="195.58.183.77 netmask 255.255.255.248" static_routes="0 1" route_0="-net 195.58.161.96 -netmask 255.255.255.240 -iface vr0" route_1="default 195.58.161.97" The above network configuration is incorrect - you need a gateway that is directly reachable. The gateway is physically connected to the same network, the physical network contains 2 (or more) distinct subnets. Correct. You are not, however, logically connected to the network on which your gateway resides. If you want to use the above default route, you need to give your machine an address on the same network as your gateway, most trivially by aliasing it onto the vr0 interface. I don't see why that should be necessary - my ISP doesn't either, since he'd have to part with another IP address. My ISP claims and I've verified that the configuration above works trivially under Linux and Windows NT, and as far as I can tell, the submitted patch does nothing more than to allow the specified interface to be taken into consideration when "connectedness" is determined (i.e. it allows the gateway to be in a different subnet as long as it is physically connected). I would suggest you go find an introductory IP networking book, and get two copies (one for yourself, and one for your ISP). What you're trying to do is a fundamental violation of the way that IP routing works, and this is what the network stack is trying to tell you. The fundamental problem is that when you send a datagram to your gateway, you can't put a valid return address on it (because you don't have an appearance on its network). If you've put the interface's real address in the datagram, you'll never get a reply because your gateway has no idea how to route back to you. If you can't get an IP on your gateway's network, alias another address on your private network onto the gateway system's interface and use that as your default route. If your gateway is too lame to support multiple addresses on an interface, use another system that does have a real appearance on the gateway's network to route for you. And read that book - it'll save you a lot of agony in the future. -- \\ 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-hackers" in the body of the message
Anybody working on FreeBSD BIOS?
Hi, I read an article about Linux BIOS project on Slashdot.org. Is there anybody working on FreeBSD BIOS? I really like to see something like 'boot net - install' or serial console. It would be cool to have dignostics routine, too. Jung-uk Kim Jung-uk Kim: Unix System Programmer E-mail: [EMAIL PROTECTED] Today's fortune cookie: Finagle's First Law: If an experiment works, something has gone wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu, 15 Jun 2000, Mike Smith wrote: [snip] I don't see why that should be necessary - my ISP doesn't either, since he'd have to part with another IP address. No he wouldn't, he's already connected to you through your vr0 interface network range: 195.58.183.77 netmask 255.255.255.248 or is he? Why are you trying to use a gateway of a non directly connected network? What are you trying to do? Is your ISP running any Interior gateway protocols that you can take advantage of? My ISP claims that the configuration above works trivially under Linux and Windows NT, I would like to see that. Mr. Smith is correct. Why not set your gateway as the next-hop address to your ISP upstream within the 195.58.183.77 network? Another option would to run an IP tunnel between your network and the gateway using gif or nos-tun. The whole question is, What are you trying to accomplish? Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu, 15 Jun 2000, Marinos J . Yannikos wrote: route_0="-net 195.58.161.96 -netmask 255.255.255.240 -iface vr0" What IP is that network reachable through? WHat does your routing table look like before this route gets added? after it gets added? Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Remote DoS exploit on natd.
The other day I was testing various exploits that I have accumulated over time against my firewall. I had always used these to test any new boxes I brought online. All was fine, until I tried it from the internet side of the firewall. I have found that boink.c, the old exploit from 98, when used against a 3.3-STABLE, or 3.4-STABLE natd box that has rdr's setup with IPFILTER to cause it to panic, and reboot. I have tested this with 3 different machines, all with the same effect. I have not been able to test it on a 4.0-STABLE as of yet.I did search the mailing list archives on boink, and found nothing pertaining to this problem. It would be really nice to be able to patch this. If you need any information, or have any corrections for this, please respond to my email address at [EMAIL PROTECTED] Thanks! __ Do You Yahoo!? Yahoo! Photos -- now, 100 FREE prints! http://photos.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Why? PXE will allow net installs, or diskless. And Serial Console is already supported. ( On some high end machines serial console works in the prom as well). Stefan On Thu, 15 Jun 2000, Jung-uk Kim wrote: Hi, I read an article about Linux BIOS project on Slashdot.org. Is there anybody working on FreeBSD BIOS? I really like to see something like 'boot net - install' or serial console. It would be cool to have dignostics routine, too. Jung-uk Kim Jung-uk Kim: Unix System Programmer E-mail: [EMAIL PROTECTED] Today's fortune cookie: Finagle's First Law: If an experiment works, something has gone wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Thus spake Stefan Molnar ([EMAIL PROTECTED]): is already supported. ( On some high end machines serial console works in the prom as well). Also on low-end machines... Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu, Jun 15, 2000 at 11:44:14AM -0600, Nick Rogness wrote: route_0="-net 195.58.161.96 -netmask 255.255.255.240 -iface vr0" What IP is that network reachable through? vr0 has only one IP - 195.58.183.77 WHat does your routing table look like before this route gets added? after it gets added? Before, it (probably) only contains the localhost route, afterwards it looks like this: DestinationGatewayFlags Refs Use Netif Expire default195.58.161.97 UGSc0 192 vr0 127.0.0.1 127.0.0.1 UH 0 209212 lo0 195.58.161.96/28 link#1 UCSc00 vr0 195.58.183.72/29 link#1 UC 00 vr0 195.58.183.77 0:50:ba:c5:6e:77 UHLW0 80 lo0 WRT your other e-mail, The whole question is, What are you trying to accomplish? For some reason, there are 2 (actually more) distinct subnets within one physical network. Only one system has an outwards connection, but its internal IP lies in the other subnet and has no IP alias in "my" subnet. The idea is to set up a static route between the 2 subnets and then use the IP in the other subnet as the default gateway. This is how a Linux box is set up in another connected subnet using the same default gateway (not that I consider Linux to be a reference for a correct implementation, but it seems that most/all boxes in that server room are connected in a similar way): Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 195.58.161.48 0.0.0.0 255.255.255.240 U 0 00 eth0 195.58.161.96 0.0.0.0 255.255.255.240 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 195.58.161.97 0.0.0.0 UG0 00 eth0 Regards, Marinos -- ***== Marinos J. Yannikos [EMAIL PROTECTED] ***== http://pobox.com/~mjy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu, 15 Jun 2000, Alexander Langer wrote: Thus spake Stefan Molnar ([EMAIL PROTECTED]): is already supported. ( On some high end machines serial console works in the prom as well). Also on low-end machines... According to pxeboot(8) from 5.0 snapshot: pxeboot is a modified version of the system third-stage bootstrap loader(8) configured to run under Intel's Preboot Execution Environment (PXE) system. PXE is a form of smart boot ROM, built into Intel EtherExpress Pro/100 and 3Com 3c905c Ethernet cards, and Ethernet-equipped Intel motherboards. Which means I cannot use it since I don't have the NIC and I don't want to buy the hardware for this. I want 'PXE' from BIOS so that I can keep my cards. :) Second, the motherboard I have doesn't support serial console. I couldn't find any BIOS update for the mobo. Jung-uk Kim Alex -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
MOXA A50/A51
HI! Could you tell how to setup PPP over 2-wire LL with MOXA A50/51 interface convertor. Thanks in advance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Two words: "forget it". I read an article about Linux BIOS project on Slashdot.org. Is there anybody working on FreeBSD BIOS? I really like to see something like 'boot net - install' or serial console. It would be cool to have dignostics routine, too. Jung-uk Kim Jung-uk Kim: Unix System Programmer E-mail: [EMAIL PROTECTED] Today's fortune cookie: Finagle's First Law: If an experiment works, something has gone wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- \\ 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-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
My ISP claims that the configuration above works trivially under Linux and Windows NT, I would like to see that. Mr. Smith is correct. Why not set your gateway as the next-hop address to your ISP upstream within the 195.58.183.77 network? Another option would to run an IP tunnel between your network and the gateway using gif or nos-tun. The whole question is, What are you trying to accomplish? I spent some more time thinking about this, and I think the deal is that if you do this on both sides, you achieve the result where you can crosstalk between the two networks without requiring a gateway. It's kinda ugly, but it's basically what route add -iface is there for, and it makes sense that if ARP is happy ARPing for these hosts, the route code should also consider these hosts as directly connected. -- \\ 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-hackers" in the body of the message
Re: routing bug(?) persists (PR 16318)
On Thu, 15 Jun 2000, Marinos J . Yannikos wrote: On Thu, Jun 15, 2000 at 11:44:14AM -0600, Nick Rogness wrote: route_0="-net 195.58.161.96 -netmask 255.255.255.240 -iface vr0" What IP is that network reachable through? vr0 has only one IP - 195.58.183.77 That's not likely unless you are dialed up (with your net interface that's not likely) or running some type of bridge, like a cable modem or a DSL bridge. Your IP is actually part of some subnetwork, more than likely. Otherwise how does your upstream provider route packets to you through their network...static routes??? maybe, if their idiots. That would mean that every machine on that net would have to have a static route to your machine right? What is the network topology like? BUT if you think that is how you are setup you can use ipfw to accomplish your task: ipfw add 450 allow ip from any to any in via vr0 ipfw add 500 fwd 195.58.161.97 ip from any to any Then: route add -net 195.58.161.96 -netmask 255.255.255.240 -interface vr0 Doesn't that basically setup a default route? How they get to your machine is their problem. WHat does your routing table look like before this route gets added? after it gets added? Before, it (probably) only contains the localhost route, afterwards it looks like this: DestinationGatewayFlags Refs Use Netif Expire default195.58.161.97 UGSc0 192 vr0 127.0.0.1 127.0.0.1 UH 0 209212 lo0 195.58.161.96/28 link#1 UCSc00 vr0 195.58.183.72/29 link#1 UC 00 vr0 195.58.183.77 0:50:ba:c5:6e:77 UHLW0 80 lo0 WRT your other e-mail, The whole question is, What are you trying to accomplish? For some reason, there are 2 (actually more) distinct subnets within one Probably VLAN's or they are trying to save IP space. physical network. Only one system has an outwards connection, but its internal IP lies in the other subnet and has no IP alias in "my" subnet. The idea is to set up a static route between the 2 subnets and then use the IP in the other subnet as the default gateway. There should be an IP on your subnet that you can reference their network with...unless they have a messy static routing table. Ask them how they are routing your IP to you? This is how a Linux box is set up in another connected subnet using the same default gateway (not that I consider Linux to be a reference for a correct implementation, but it seems that most/all boxes in that server room are connected in a similar way): Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 195.58.161.48 0.0.0.0 255.255.255.240 U 0 00 eth0 195.58.161.96 0.0.0.0 255.255.255.240 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 195.58.161.97 0.0.0.0 UG0 00 eth0 hmmm. OK. THis just makes no sense to do it this way. Static routes are the only thing besides some bizarre VLAN setup that could work. I would look at your arp table, possible run tcpdump to see if these guys are setup the way they say they are. If they are on the same physical network, then you should be able to ping there machine without any default gateway and just that 1 static route out the interface. I would like to know how, and why, they are doing this. If it is to conserve IP space, NAT is a far better solution. Nick Rogness - Speak softly and carry a Gigabit switch. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Hi, its for you !
Hi! We are Russian girls - Natali, Alla, Vika. We would like to correspond with you. Visit our site and see our photos. http://www.russiangirls.narod.ru/ With interest, Natali,Alla, Vika. P.S. (This is not spam. You can unsubscribe at any time by sending an email to [EMAIL PROTECTED] with the subject UNSUBSCRIBE.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu, 15 Jun 2000, Stefan Molnar wrote: Why? PXE will allow net installs, or diskless. And Serial Console is already supported. ( On some high end machines serial console works in the prom as well). well, now you see why i'm not pushing linuxbios too hard in the freebsd world. If you think PXE and serial consoles fix your cluster problems, then you haven't build anything really big. PXE is not a good design. But I'm not interested in arguing ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
well linuxbios is what I started here, and I pinged some folks on this list about supporting freebsd as well as linux, and got a 'no interest' back from some folks. I'm still up for it. I think it's easy. I'd suggest you go talk to Parag Patel, who's just wasted about three months of his life trying to make SmartFirmware run on _one_ supposedly well-documented board. Parag is nobody's fool, and I consider his results pretty representative of the issue. -- \\ 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-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
[EMAIL PROTECTED] said: :- and got a 'no interest' back from some folks. I'm interested, since from reading the linixboot page it seems like you can get, essentially, and instant-on rommable FreeBSD if this were done, and I can think of lots of things to do with that! Don't know how much help I can offer, though. So my opinion is pretty much worthless. ;-) -- Robert Withrow -- (+1 978 288 8256) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
[EMAIL PROTECTED] said: :- and got a 'no interest' back from some folks. The response was not "no interest", it was "you're totally nuts - this is not a usefully solvable problem". I'm interested, since from reading the linixboot page it seems like you can get, essentially, and instant-on rommable FreeBSD if this were done, and I can think of lots of things to do with that! You can come fairly close to this already with the right approach, it's just expensive. -- \\ 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-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Mike Smith wrote: well linuxbios is what I started here, and I pinged some folks on this list about supporting freebsd as well as linux, and got a 'no interest' back from some folks. I'm still up for it. I think it's easy. I'd suggest you go talk to Parag Patel, who's just wasted about three months of his life trying to make SmartFirmware run on _one_ supposedly well-documented board. Parag is nobody's fool, and I consider his results pretty representative of the issue. Maybe I'm completely mistunderstanding the subject, but what about EFI (Extendable Firmware Interface) ? It's the new Intel's proposal for BIOS. It's the only thing that will be (and is) on IA-64, and also will be retrofitted on the 32-bit machines. It's a very flexible thing including extensive API, OS-independent loadable drivers, networking, serial console, etc. I'm in progress of reading the specs (avaliable from the Intel's developer web site), so I don't know more detail yet. The spec says that the full source code of reference implementation is available for free. By the way, they used FreeBSD as the base of their EFI API implementation (libc, networking and other). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
freebsd bios.
So, I repeat: easily done, not acceptable to freebsd core. I think this situation reflects on the freebsd community and not in a positive way. If you care, sometime this year you'll be able to buy motherboards that boot Linux from flash. SiS is working hard on this and has committed people and hardware. So if you want that capability, you'll get it with Linux, not FreeBSD. Not because it's not doable, it's because people don't seem to get it. It's kind of a shame. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu, 15 Jun 2000, Sergey Babkin wrote: Mike Smith wrote: I'd suggest you go talk to Parag Patel, who's just wasted about three months of his life trying to make SmartFirmware run on _one_ supposedly well-documented board. Parag is nobody's fool, and I consider his results pretty representative of the issue. I just mentioned to mike that parag has been talking to me for the last while, and in fact is encouraged enough by recent results that he's taking another look. Maybe I'm completely mistunderstanding the subject, but what about EFI (Extendable Firmware Interface) ? It's the We're looking at it. Do you really believe in reference implementations? I don't. I sure hope they've stopped zeroing memory on reset ... this is one of the drivers for linuxbios. But it is still interesting. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
I'm confused. Acceptable to freebsd core isn't really the issue here. FreeBSD is a volunteer project. If you do the work and submit the code then 'core' has the option of deciding not to include it but if its useful people will use it anyway regardless if its 'Official' or not. If enough people use it or want it, 'core' will rethink their option. I don't think people are unreasonable. I haven't heard any lack of interest in this thread... just some questions on how easily it can really be done... a question you should be able to answer easily since you've already stated (twice) that it _IS_ easily done... just throw in a 'how' also. So, I repeat: easily done, not acceptable to freebsd core. I think this situation reflects on the freebsd community and not in a positive way. If you care, sometime this year you'll be able to buy motherboards that boot Linux from flash. SiS is working hard on this and has committed people and hardware. So if you want that capability, you'll get it with Linux, not FreeBSD. Not because it's not doable, it's because people don't seem to get it. It's kind of a shame. ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
In message [EMAIL PROTECTED], Ronald G Minnich writes: So, I repeat: easily done, not acceptable to freebsd core. Uhm, Ron, I have not seen freebsd core take a stand on this, and I'm a core team member, so I'm pretty sure they havn't. I also doubt that they ever would do so. Remember: Nobody carries so much weight in the FreeBSD project that they can *prevent* somebody from doing something like this. If you or others feel this is worthwhile and interesting, you should just go work on it. You don't need to get "permission" from anybody. Don't get all upset because one or two people come across a bit grumpy on email. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
Ronald G Minnich wrote: So, I repeat: easily done, not acceptable to freebsd core. If you can easily do it, why aren't you? I had thought someone was actively working on this (because it is SO obviously useful to have fast reboots in an HA environment). It's kind of a shame. Sure is. What are we going to do about it? -- Jack Rusher, Senior Engineer | mailto:[EMAIL PROTECTED] Integratus, Inc. | http://www.integratus.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
I have not built clusters over 200 nodes, but I almost never go into the BIOS for configurations. And the systems that I have used, include serial access within the BIOS. And adding PXE roms will make things nicer on the install front. But my current system is a single floppy, and that works well. The best people to determin if it is nessesary is Yahoo and Hotmail. Since they have worked with these issues in the thousands of machines. On Thu, 15 Jun 2000, Ronald G Minnich wrote: On Thu, 15 Jun 2000, Stefan Molnar wrote: Why? PXE will allow net installs, or diskless. And Serial Console is already supported. ( On some high end machines serial console works in the prom as well). well, now you see why i'm not pushing linuxbios too hard in the freebsd world. If you think PXE and serial consoles fix your cluster problems, then you haven't build anything really big. PXE is not a good design. But I'm not interested in arguing ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
I'd suggest you go talk to Parag Patel, who's just wasted about three months of his life trying to make SmartFirmware run on _one_ supposedly well-documented board. Parag is nobody's fool, and I consider his results pretty representative of the issue. Maybe I'm completely mistunderstanding the subject, but what about EFI (Extendable Firmware Interface) ? It's the new Intel's proposal for BIOS. It's the only thing that will be (and is) on IA-64, and also will be retrofitted on the 32-bit machines. It's a very flexible thing including extensive API, OS-independent loadable drivers, networking, serial console, etc. I'm in progress of reading the specs (avaliable from the Intel's developer web site), so I don't know more detail yet. The spec says that the full source code of reference implementation is available for free. By the way, they used FreeBSD as the base of their EFI API implementation (libc, networking and other). It's still entirely useless without the _board_specific_ initialisation code, which vendors typically aren't going to just hand out. EFI can layer over an existing PC BIOS (ie. you still need a BIOS), or it will require board-specific code if it's going to be the native firmware. The real issue with replacing a system's BIOS is not the top layer (services etc.), it's initialisation and random magic that is entirely specific to the board's actual implementation details. -- \\ 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-hackers" in the body of the message
Re: freebsd bios.
So, I repeat: easily done, not acceptable to freebsd core. And again I tell you, no. Quite acceptable, not easily done. If someone does it, we'll happily play along. I don't understand why you don't understand this. -- \\ 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-hackers" in the body of the message
Fixit - Recover Disk
Hi, guys... I'm new at this mailling list. Sorry for my english, I'm a brazilian. I'd like to know one thing about this disk. How the guys from Berkeley did that disk? This is because of the files at /stand directory of the disk. There are 54 files of 1.1MB at the /stand and this files fill only 1142 KB of the disk. How is it possible? (Fill 62MB inside a room of 1142KB) I think is the command 'dd' with some kind of conversion over the device, in this case converting about 60x less than the original file size. But I think not, cause the files at /etc and /.profile are ok. My FreeBSD version is 3.2-Release. It's old. Anybody could answer to me? Thanx and regards. -- Gustavo Pamplona - [EMAIL PROTECTED] Linux User: 137471 - FreeBSD User: FBSD042237 Slackware 7.0 | Debian 2.1 | FreeBSD 3.2-R | NetBSD 1.3.2 (i386) -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fixit - Recover Disk
I'm new at this mailling list. Sorry for my english, I'm a brazilian. I'd like to know one thing about this disk. How the guys from Berkeley did that disk? They didn't. This is because of the files at /stand directory of the disk. There are 54 files of 1.1MB at the /stand and this files fill only 1142 KB of the disk. How is it possible? (Fill 62MB inside a room of 1142KB) Quantum compression. 8) Anybody could answer to me? Actually, if you look you'll see that there are 54 links to one single 1.1MB file. Look at the crunchgen manpage. -- \\ 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-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu, 15 Jun 2000 14:47:32 PDT, Mike Smith wrote: I'd suggest you go talk to Parag Patel, who's just wasted about three months of his life trying to make SmartFirmware run on _one_ supposedly well-documented board. Parag is nobody's fool, and I consider his results pretty representative of the issue. Thanks, but I think I'm a fool for even *attempting* this project. :) That said, I'm trying to get a SuperMicro P6DGE going right now. I toasted my L440GX+ or I'd probably be further along. I *think* I can talk to the ISA bus but am not yet sure. I can't seem to wake up the Winbond 977TF ISA I/O chip. The L440GX uses the same GX and PIIX4 chipset but a different I/O chip. The problem, as Mike said, is the magic goo hidden away in the BIOS ROMs that actually initializes parts and patches around some most *interesting* bugs in the hardware. Each chipset and motherboard seem to have their own sets of bugs and workarounds. None of the motherboard or chipset vendors (except for SiS) are even slightly interested in talking to us. I've even resorted to diassembling the BIOS ROM to try to figure out what's going on. This is another exercise in frustration, but we did manage to find some magic undocumented ISA ports being initialized. We have no idea what it's initializing. My current plan of action is to plug in a vanilla ISA card and use another serial port to see if I can get something out of it. This has lead to another comedy of errors as there's isn't enough room in the rackmount case to plugin an ISA card *with connectors*. Sigh. I'm remounting the motherboard in a vanilla cheapie ATX case right now... Anyway, if I can get something out a serial port, I can start dumping registers, and then hopefully make some progress. Lots of "if"s... Unfortunately, all this work will have to be done all over again for the next motherboard, and the next, and the next... -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
The best people to determin if it is nessesary is Yahoo and Hotmail. Since they have worked with these issues in the thousands of machines. Actually, Yahoo is basically who funded the PXE development as their employees did most of the development and testing with PXE and now use it in production, IIRC. On Thu, 15 Jun 2000, Ronald G Minnich wrote: On Thu, 15 Jun 2000, Stefan Molnar wrote: Why? PXE will allow net installs, or diskless. And Serial Console is already supported. ( On some high end machines serial console works in the prom as well). well, now you see why i'm not pushing linuxbios too hard in the freebsd world. If you think PXE and serial consoles fix your cluster problems, then you haven't build anything really big. PXE is not a good design. But I'm not interested in arguing ... PXE is simply a layer over the network card, it's not ACPI or EFI. ron -- John Baldwin [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
here's what we can. Somebody send a kernel for an L440GX+ that has pretty minimal stuff. I'd prefer it to have IDE, no networking, no SCSI, i.e. a pretty small thing. I'll try to use it as the payload for linuxbios and see if it boots. The key is that freebsd may need to change a few things to make it bootable from cold hardware. I don't think this is for sure, but it may happen. I hope the team is receptive to such changes ... ron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Mike Smith wrote: I'd suggest you go talk to Parag Patel, who's just wasted about three months of his life trying to make SmartFirmware run on _one_ supposedly well-documented board. Parag is nobody's fool, and I consider his results pretty representative of the issue. Maybe I'm completely mistunderstanding the subject, but what about EFI (Extendable Firmware Interface) ? It's the new Intel's proposal for BIOS. It's the only thing that will be (and is) on IA-64, and also will be retrofitted on the 32-bit machines. It's a very flexible thing including extensive API, OS-independent loadable drivers, networking, serial console, etc. I'm in progress of reading the specs (avaliable from the Intel's developer web site), so I don't know more detail yet. The spec says that the full source code of reference implementation is available for free. By the way, they used FreeBSD as the base of their EFI API implementation (libc, networking and other). It's still entirely useless without the _board_specific_ initialisation code, which vendors typically aren't going to just hand out. Right, but why would you want to replace the existing BIOS ? You get it with the board anyway. And the EFI spec requires such things as serial port console support, so they should not be much of issue for EFI-compliant boards. EFI can layer over an existing PC BIOS (ie. you still need a BIOS), or it will require board-specific code if it's going to be the native firmware. The real issue with replacing a system's BIOS is not the top layer (services etc.), it's initialisation and random magic that is entirely specific to the board's actual implementation details. I think it depends mostly on the chipset used, hardly the board manufacturers add much or anything at all. And there are not that many modern chipsets on the market, and seems like their number is reducing over time as Intel gets more involved. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Mike Smith wrote: I'd suggest you go talk to Parag Patel, who's just wasted about three months of his life trying to make SmartFirmware run on _one_ supposedly well-documented board. Parag is nobody's fool, and I consider his results pretty representative of the issue. Maybe I'm completely mistunderstanding the subject, but what about EFI (Extendable Firmware Interface) ? It's the new Intel's proposal for BIOS. It's the only thing that will be (and is) on IA-64, and also will be retrofitted on the 32-bit machines. It's a very flexible thing including extensive API, OS-independent loadable drivers, networking, serial console, etc. I'm in progress of reading the specs (avaliable from the Intel's developer web site), so I don't know more detail yet. The spec says that the full source code of reference implementation is available for free. By the way, they used FreeBSD as the base of their EFI API implementation (libc, networking and other). It's still entirely useless without the _board_specific_ initialisation code, which vendors typically aren't going to just hand out. Right, but why would you want to replace the existing BIOS ? That's more or less my point - I think the only argument for it so far is sheer masochism. 8) The real issue with replacing a system's BIOS is not the top layer (services etc.), it's initialisation and random magic that is entirely specific to the board's actual implementation details. I think it depends mostly on the chipset used, hardly the board manufacturers add much or anything at all. And there are not that many modern chipsets on the market, and seems like their number is reducing over time as Intel gets more involved. Actually, general experience suggests that's not the case at all. -- \\ 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-hackers" in the body of the message
Re: PCI Wavelan adapter timeouts
At Wed, 14 Jun 2000 10:19:36 -0600, Warner Losh [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] Tatsumi Hosokawa writes: : At Wed, 14 Jun 2000 09:36:47 -0600, : Warner Losh [EMAIL PROTECTED] wrote: : : In message [EMAIL PROTECTED] Julian Elischer writes: : : well I'm typing this across the following: : : : : pccard: card inserted, slot 0 : : wi0: WaveLAN/IEEE 802.11 at port 0x240-0x27f irq 9 slot 0 on pccard0 : : wi0: Ethernet address: 00:60:1d:1e:42:6c : : I'm not seeing problems there.. : : (though dhclient doesn't seem to work on it for some reason) : : Maybe wi doesn't support broadcasts? : : I'm using dhclient on wi in infrastructure mode. OK. Is this with the PCI addapter or with another adapter? It's PCMCIA model on my laptop (WaveLAN IEEE Turbo). -- --- Tatsumi Hosokawa [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
here's what we can. Somebody send a kernel for an L440GX+ that has pretty minimal stuff. I'd prefer it to have IDE, no networking, no SCSI, i.e. a pretty small thing. I'll try to use it as the payload for linuxbios and see if it boots. GENERIC should work, presuming that the hardware's being set up correctly. The key is that freebsd may need to change a few things to make it bootable from cold hardware. I don't think this is for sure, but it may happen. I hope the team is receptive to such changes ... ie. "LinuxBIOS won't initialise the system correctly, so you'd better clean up after it"? -- \\ 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-hackers" in the body of the message
Re: freebsd bios.
On Thu, 15 Jun 2000 18:37:51 PDT, Mike Smith wrote: ie. "LinuxBIOS won't initialise the system correctly, so you'd better clean up after it"? More like it ain't complete and is intended to boot Linux, so anything that Linux initializes but FBSD doesn't is probably SOL. :) I'm building a kernel and sending it to Ron. -- Parag To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Ronald G Minnich wrote: On Thu, 15 Jun 2000, Sergey Babkin wrote: Maybe I'm completely mistunderstanding the subject, but what about EFI (Extendable Firmware Interface) ? It's the We're looking at it. Do you really believe in reference implementations? I don't. I sure hope they've stopped zeroing memory on reset ... this is one of the drivers for linuxbios. Well, supposedly that reference implementation is what's inside the Itanium boxes (actually the box I have access too has version 0.92 while the latest one is 0.99). Though maybe the published code is not complete. But it is still interesting. As far as I understand the idea is that you won't need to replace the BIOS. It should have some limited pseudo-disk in flash memory with a FAT-32 partition on it where the drivers and loaders can be added as needed. Any kind of clustering initialization, or boot loaders can be written as applications in EFI API. If that's not enough then a special boot FAT-32 partition may be created on a disk (on any disk, may create one (or maybe many - not sure) on each disk) where the rest will be stored. BTW, EFI permits unlimited number of partitions on the disk with size limited by 64-bit sector number. Microsoft has contributed the FAT-32 code for the free reference implementation for free. For example, Linux-64 stores it kernel, boot loader and boot parameters file in this boot partition. EFI also has a mini-shell which gives some rudimentary control from the console, and yes, it supposedly supports the serial console. I don't quite understand it yet (one of the features is that the result of "help" command scrolls very fast, so only the last screen can be seen) but I plan to look closer at it. -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
On Thu, 15 Jun 2000 18:37:51 PDT, Mike Smith wrote: ie. "LinuxBIOS won't initialise the system correctly, so you'd better clean up after it"? More like it ain't complete and is intended to boot Linux, so anything that Linux initializes but FBSD doesn't is probably SOL. :) 8) Actually, the things that really bother me are eg. interrupt routing and the ACPI GPIO bits, since the former is board-specific and you *must* know about it to set PCI up, and the latter is often necessary to do important things like, eg. turn the CPU fan on. -- \\ 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-hackers" in the body of the message
Re: freebsd bios.
On Thu, 15 Jun 2000 18:49:23 PDT, Mike Smith wrote: 8) Actually, the things that really bother me are eg. interrupt routing and the ACPI GPIO bits, since the former is board-specific and you *must* know about it to set PCI up, and the latter is often necessary to do important things like, eg. turn the CPU fan on. Shouldn't be too bad to figure out actually. I've got register dumps when booting using the BIOS so simply setting most of the them back that way should handle the intr routing, or at least decode the intr routing. GPIO bits are going to be a problem if we can't read the settings. The boards I'm using always turn on the CPU fan at power-on. Which board doesn't do this? Seems like a disaster waitng to happen... Still, there's so much else to do in both LinuxBIOS and SmartFirmware... -- Parag To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Well, the main reason we're replacing the BIOS is that we've had several requests from people who want relatively sane firmware in their computers. :) One of our (potential) customers needs to completely manage their rack-mount systems remotely using the serial port without video and without a keyboard - something that few motherboards support. Another option is to create a custom ISA or PCI card with pretty much just a ROM on in, let the BIOS set things up, then completely take over control of the machine. This is a lot more work and more expensive, not to mention taking up one of the relatively few slots, but it would work in more computers. (Some BIOSes still refuse to run without video and keyboard though.) One problem with flash disks and such is that by the time the machine is ready to boot from one, it's already well past where you'd like to have control over the BIOS settings. Frankly, I'd just as soon support PowerPC or Alpha ATX motherboards with SmartFirmware. Anyone know of inexpensive ATX non-x86 boards? :) -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
On Thu, 15 Jun 2000 18:49:23 PDT, Mike Smith wrote:
8) Actually, the things that really bother me are eg. interrupt routing
and the ACPI GPIO bits, since the former is board-specific and you *must*
know about it to set PCI up, and the latter is often necessary to do
important things like, eg. turn the CPU fan on.
Shouldn't be too bad to figure out actually. I've got register dumps
when booting using the BIOS so simply setting most of the them back that
way should handle the intr routing, or at least decode the intr routing.
Uh. You're kidding me, right?
You need to know the interrupt routing to do PCI resource allocation. You
need the MP table to program the I/O APIC.
Both of these are specific to the actual, physical layout of the PCB. The
data is encoded in the BIOS - you will need to extract this information so
that your startup code can do resource allocation. Without this data,
you're completely screwed. You can't probe it, there are no conventions
at all on how it's laid out - just Have To Know it.
GPIO bits are going to be a problem if we can't read the settings. The
boards I'm using always turn on the CPU fan at power-on. Which board
doesn't do this? Seems like a disaster waitng to happen...
Lots of them do; go looking at the _PTS() ACPI method for example. Here's
one from an ASUS P2B - a *very* common single-CPU board:
Method(\_PTS, 1) {
If(LNot(LEqual(Arg0, 0x5))) {
Store(0x0, FANM)
Store(0x0, PLED)
}
If(LEqual(Arg0, 0x1)) {
Store(One, TO12)
}
If(LEqual(Arg0, 0x2)) {
}
Store(One, TO12)
Or(Arg0, 0xf0, Local2)
Store(Local2, DBG1)
}
Note that it's turning off the power LED and the CPU fan. Here's the
_WAK method:
Method(\_WAK, 1) {
Notify(\_SB.PWRB, 0x2)
Store(0x1, FANM)
Store(One, PLED)
Store(0xff, DBG1)
}
Now, you'll want to know where this is, right?
OperationRegion(GPOB, SystemIO, 0xe42c, 0x10)
Field(GPOB, ByteAcc, NoLock, Preserve) {
Offset(0x18),
TO12, 1,
Offset(0x40),
FANM, 1,
Offset(0x48),
PLED, 1,
Offset(0x4c),
Offset(0x4e),
Offset(0x5e),
MSG0, 1
}
So basically, unless your BIOS *specifically* knows that for this board
you need to set that bit in what turns out to be the ACPI GPIO registers
in the PIIX4 (the AML above is actually bogus - the OperationRegion()
should actually be a child of the PIIX4 which is declared elsewhere, but
it's easier to read like this), you're never going to get the CPU fan to
turn on and you'll toast.
You won't get the power LED either. You may not get eg. the SuperIO chip
either, especially if it's powered down (who knows what the TO12 bit
does?).
You can save yourself _some_ grief by stealing the AML from the board
that you're trying to convert, but there's not enough information in
there to initialise it properly either.
Still, there's so much else to do in both LinuxBIOS and SmartFirmware...
Sisyphean.
--
\\ 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-hackers" in the body of the message
Re: [Oz-ISP] FreeBSD and the forces of darkness. Real religious w ars! (fwd))
Warner Losh wrote: Tell them that it is a daemon, not a devil. A daemon isn't the devil, nor does it promote the worship of devilry. In Japan, the daemon is viewed as a nice, lovable creature. The Of course, they don't translate daemon as "akuma". :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Well, the main reason we're replacing the BIOS is that we've had several requests from people who want relatively sane firmware in their computers. :) One of our (potential) customers needs to completely manage their rack-mount systems remotely using the serial port without video and without a keyboard - something that few motherboards support. Intel are actually pretty aggressive on this (eg. EMP and IPMI), but the boards they offer it on aren't cost-effective. 8( Another option is to create a custom ISA or PCI card with pretty much just a ROM on in, let the BIOS set things up, then completely take over control of the machine. This is a lot more work and more expensive, not to mention taking up one of the relatively few slots, but it would work in more computers. (Some BIOSes still refuse to run without video and keyboard though.) It's actually not _that_ expensive, but you're right about interoperability. By now, based on the timeframe I've watched you through, I'd say that you should have a board that looks like a plain VGA framebuffer and has a keyboard cable hung out the back, and software up and running. Build cost at 100 off would probably be $100. One problem with flash disks and such is that by the time the machine is ready to boot from one, it's already well past where you'd like to have control over the BIOS settings. This is a problem, yes, but rewriting the BIOS, bootloader and parts of the kernel isn't the path of least resistance, IMO. 8) Frankly, I'd just as soon support PowerPC or Alpha ATX motherboards with SmartFirmware. Anyone know of inexpensive ATX non-x86 boards? :) Well, Alpha Processor now have SRM on the UP1000, but this isn't what you'd call "inexpensive", and the board's not very compact either (Slot B module mounted vertically). If your customer's not _desperate_ for a super-low-cost solution, I'd suggest any of the Intel boards that offer EMP (most of these also offer BIOS-over-serial support, actually - as do a number of other vendors, IIRC AMI do this on some of their boards as well). -- \\ 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-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
On Thu, 15 Jun 2000 19:29:53 PDT, Mike Smith wrote: By now, based on the timeframe I've watched you through, I'd say that you should have a board that looks like a plain VGA framebuffer and has a keyboard cable hung out the back, and software up and running. Build cost at 100 off would probably be $100. Yeah, if I were a hardware guy. :) Besides there are other people taking this approach like PC Weasel. This is a problem, yes, but rewriting the BIOS, bootloader and parts of the kernel isn't the path of least resistance, IMO. 8) Sure, I know that *now*... :) If your customer's not _desperate_ for a super-low-cost solution, I'd suggest any of the Intel boards that offer EMP (most of these also offer BIOS-over-serial support, actually - as do a number of other vendors, IIRC AMI do this on some of their boards as well). They're using the Intel boards right now, but with a Sun background they really really want Open Firmware in an x86 box. I think they may end up getting Sun hardware anyway. Anyway, I'd set myself with a 6-month time-limit (while also managing other ports and customer work). This time has pretty much run out, but I'm actually making some small progress for a change and am caught between contracts, so what the heck... -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
On Thu, 15 Jun 2000 19:24:28 PDT, Mike Smith wrote: Uh. You're kidding me, right? Well, maybe a little. The L440GX+ board is well-documented with a nice diagram documenting the IRQ swizzle. The SuperMicro board isn't, so I'm probably screwed there. I think it is possible to probe it by putting in a card in one slot at a time and seeing how their BIOS initializes the IRQ register in that card. The GPIOs and ACPI stuff are definitely going to be a problem though - one I hadn't fully considered before. Damn. We really were hoping we'd get some help from a motherboard vendor but that just hasn't been the case. No-one seems interested in the relatively low quantities of boards we'd move. -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: loading modules from within the kernel....
Matthew Jacob wrote: Of course, this brings to light the fact that I don't think we support "soft" dependancies, ie. load-this-if-you-can-but-don't-fail-if-you-can't. Oh, err, uh, that's gotta be fixed. Let the caller/invoker of a load action decide what the policy for failure is. That won't work on loader(8), since no code gets executed at that point. The current school of thought for solving this would be to have your firmware load as a plain container in a fashion similar to the way we load the MFS root image, and then use preload_search_by_type() to locate it. Does this approach use functions/APIs that are likely to not change for a while? AFAIK, they haven't changed since splash screen loader(8) were first introduced, back in... october or november 1998. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd bios.
Ronald G Minnich wrote: here's what we can. Somebody send a kernel for an L440GX+ that has pretty minimal stuff. I'd prefer it to have IDE, no networking, no SCSI, i.e. a pretty small thing. I'll try to use it as the payload for linuxbios and see if it boots. I'm cc'ing Mike here so he can correct me if I'm wrong, but... it seems loader(8) is actually what you need? If it can boot loader(8), and the storage where the rest of the system is located is BIOS-accessible, then that ought to be enough. I'd suggest taking a look at pxeloader, which is, to a certain extent, the same thing you are doing. The key is that freebsd may need to change a few things to make it bootable from cold hardware. I don't think this is for sure, but it may happen. I hope the team is receptive to such changes ... We have never been in a position where we can dictate what the hardware specifications we'll be booting from are. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody working on FreeBSD BIOS?
Parag Patel wrote: On Thu, 15 Jun 2000 19:29:53 PDT, Mike Smith wrote: By now, based on the timeframe I've watched you through, I'd say that you should have a board that looks like a plain VGA framebuffer and has a keyboard cable hung out the back, and software up and running. Build cost at 100 off would probably be $100. Yeah, if I were a hardware guy. :) Besides there are other people taking this approach like PC Weasel. I think I saw someone selling this kind of boards. For something like $100 or $200. I can look in my archives for URL if you're interested. This is a problem, yes, but rewriting the BIOS, bootloader and parts of the kernel isn't the path of least resistance, IMO. 8) Sure, I know that *now*... :) Would not it be simpler to slightly patch the existing BIOS ? Like cut out the parts you don't want to execute, and then later your customized board would fill them up. Now, with only 3 major generic BIOSes (AMI, Phoenix, Award) (well, also Compaq but who would buy Compaq hardware anyway ?) it might be simpler to find where it calls the parts you don't like and use this experience on any boards using this kind of BIOS to replace them with NOPs, than to figure out chipset-dependent parts for each particular board. The only catch would be to get the new ROM checksum right. If your customer's not _desperate_ for a super-low-cost solution, I'd suggest any of the Intel boards that offer EMP (most of these also offer BIOS-over-serial support, actually - as do a number of other vendors, IIRC AMI do this on some of their boards as well). Phoenix in high-end machines (such as Intel Saber architecture) has option of serial console. They're using the Intel boards right now, but with a Sun background they really really want Open Firmware in an x86 box. I think they may end up getting Sun hardware anyway. Eh ? I don't quite get how Sun could be associated with Open Firmware. It always looked quite proprietary to me. (My personal experience with both Sun workstations and SPARC-based ICL was not particularly pleasant). -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Oz-ISP] FreeBSD and the forces of darkness. Real religious w ars! (fwd))
Sergey Babkin wrote: "Daniel C. Sobral" wrote: Warner Losh wrote: Tell them that it is a daemon, not a devil. A daemon isn't the devil, nor does it promote the worship of devilry. In Japan, the daemon is viewed as a nice, lovable creature. The Of course, they don't translate daemon as "akuma". :-) I think the best explanation I saw was of the difference between "demon" and "daemon". Of which the first one is supposed to be associated with devil and the second with a good spirit.\ Can't remember where I have seen it. Maybe in the McKusick et. al book ? Daemon is the greek word for djinn. The expansion of Christianity absorbed all local myths into the Christian paradox, in one of several ways. "Pagan" feasts became Christian holidays. Supernatural beings became, by and large, devils. Daemon, in the Christian view, *IS* a Demon. Demon is a direct derivate of Daemon. The trick here, thus, is saying "Daemon" refers to the meaning before Christianism absorbed it and turned it into Demon. This only works nowadays, when Christians are more willing to accept other religions rights to existance (though, of course, they are still wrong :). And, then, it doesn't *really* work. :-) Language is always a problem, really. A number of Japanese words that are translated as god/goddess just have no equivalent in romantic (Christian-influenced) languages. The language shapes the mind. shrugs -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "He is my minion, so he doesn't need a name." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Subject: Re: Drivers collection (was:Arlan 655 driver for FreeBSD)
Has anyone done anything with the Arlan 655? There is GNU code at http://www.ylenurme.ee/~elmer/655/, I bought some 630's and was wondering if anyone has tried writing drivers for the ISA 655 card. -piet Re: Drivers collection (was:Arlan 655 driver for FreeBSD) To: Boris Popov [EMAIL PROTECTED] Subject: Re: Drivers collection (was:Arlan 655 driver for FreeBSD) From: Warner Losh [EMAIL PROTECTED] Date: Mon, 03 May 1999 23:07:54 -0600 Cc: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] In-reply-to: Your message of "Thu, 29 Apr 1999 12:25:24 +0700." [EMAIL PROTECTED] References: [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] In message [EMAIL PROTECTED] Boris Popov writes: : Any opinions ? I'm surprised no one has followed up on this. I think this is an excellent idea. It will allow an easy way for GPL'd things to be included in a system by the end user. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IOCTL to the character driver is failing
Hi, Thanks for that suggestions. I changed my character driver a little bit to take care of the more than 4K IOCTLs. My firmware download needs more than 4K size of IOCTL since i have to download a file of around 1MB. Regards Nandan --- Mike Smith [EMAIL PROTECTED] wrote: [moved to -hackers; this is an in-depth technical question] On Friday, 9 June 2000 at 0:28:04 -0700, NandaKumar P.K. wrote: Hi, I am in the process of debugging my character driver interface to the RAID controller card. Lots of my IOCTLs i sent from the user code works with the driver but some IOCTLs are not reaching the driver. I found that one of the IOCTL that failed is having a size of data as 8096 bytes. Does FreeBSD has got any size restriction in IOCTL data size ? I know that there is no problem with Linux and Windows NT. Indeed, you're limited to 4096 bytes. From sys/ioccom.h: #define IOCPARM_MASK0x1fff /* parameter length, at most 13 bits */ #define IOCPARM_MAX PAGE_SIZE /* max size of ioctl, mult. of PAGE_SIZE */ From sys/param.h: #define PAGE_SHIFT 12 /* LOG2(PAGE_SIZE) */ #define PAGE_SIZE (1PAGE_SHIFT) /* bytes/page */ Even that is probably too big. What are you trying to transfer that's so big? NB. if you want to move more than 4k, you should pass a pointer to the buffer in userspace and use copyin/copyout. -- \\ 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] __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Oz-ISP] FreeBSD and the forces of darkness. Real religious w ars! (fwd))
"Daniel C. Sobral" wrote: Warner Losh wrote: Tell them that it is a daemon, not a devil. A daemon isn't the devil, nor does it promote the worship of devilry. In Japan, the daemon is viewed as a nice, lovable creature. The Of course, they don't translate daemon as "akuma". :-) I think the best explanation I saw was of the difference between "demon" and "daemon". Of which the first one is supposed to be associated with devil and the second with a good spirit.\ Can't remember where I have seen it. Maybe in the McKusick et. al book ? -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
