Date: Sun, 21 Jan 2001 00:45:38 +0000 (GMT+00:00) From: postmaster@another.com To: hackers@FreeBSD.ORG Subject: Your message has been bounced by another.com Message-ID: <1795842299.980037938705.JavaMail.root@mh-a03.dmz.another.com>
next in thread | raw e-mail | index | archive | help
--1162764539.980037938703.JavaMail.root.mh-a03.dmz.another.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Hello, this is an automated message from another.com. We have tried to send your email to the address below, but we cannot find a user with that address. Please check the address of the person you are emailing and try again. moneytalks@showmethemoney.co.uk If you need further help, email us at support@another.com and a real, live human being will be happy to assist you. If you want to open your own another.com account then go to http://www.another.com/ Thanks, The another.crew --1162764539.980037938703.JavaMail.root.mh-a03.dmz.another.com Content-Type: message/rfc822 X-FunMail-size: 51936 X-Envelope-To: moneytalks@showmethemoney.co.uk Received: (qmail 3218 invoked from network); 20 Jan 2001 23:43:26 -0000 Received: from mx1.freebsd.org (216.136.204.125) by mh-a02.dmz.another.com with SMTP; 20 Jan 2001 23:43:26 -0000 Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18])by mx1.FreeBSD.org (Postfix) with ESMTPid 702A36E2BF4; Sat, 20 Jan 2001 15:44:29 -0800 (PST) Received: by hub.freebsd.org (Postfix, from userid 538)id E392837B402; Sat, 20 Jan 2001 15:44:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org (Postfix) with SMTPid D1FB12E8191; Sat, 20 Jan 2001 15:44:28 -0800 (PST) Received: by hub.freebsd.org (bulk_mailer v1.12); Sat, 20 Jan 2001 15:44:28 -0800 From: owner-freebsd-hackers-digest@FreeBSD.ORG (freebsd-hackers-digest) To: freebsd-hackers-digest@FreeBSD.ORG Subject: freebsd-hackers-digest V5 #14 Reply-To: hackers@FreeBSD.ORG Sender: owner-freebsd-hackers-digest@FreeBSD.ORG Precedence: bulk Message-ID: <bulk.29171.20010120154428@hub.freebsd.org> Date: Sat, 20 Jan 2001 15:44:28 -0800 (PST) freebsd-hackers-digest Saturday, January 20 2001 Volume 05 : Number 014 In this issue: Re: Patch to fix "make buildkernel requires full obj directory" mistake (fwd) libh disk editor Re: startx /dev/mem problem RE: ISR not triggered upon the interrupts and OS hangs Re: ISR not triggered upon the interrupts and OS hangs Re: startx /dev/mem problem RE: ISR not triggered upon the interrupts and OS hangs Re: Protections on inetd (and /sbin/* /usr/sbin/* in general) Re: accessing an outside IP from inside a NAT net Re: Clustering FreeBSD Re: accessing an outside IP from inside a NAT net Re: accessing an outside IP from inside a NAT net Re: accessing an outside IP from inside a NAT net Re: accessing an outside IP from inside a NAT net Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Re: startx /dev/mem problem Does anyone know how to let fd0.1720 be bootable? Re: startx /dev/mem problem Re: scsi and PS2 mode parallel port programming odd result of pci_read_config Re: Does anyone know how to let fd0.1720 be bootable? building a fixit floppy? Re: building a fixit floppy? Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Re: Clustering FreeBSD Re: Does anyone know how to let fd0.1720 be bootable? Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) more info about: odd result of pci_read_config ---------------------------------------------------------------------- Date: Fri, 19 Jan 2001 15:34:33 -0800 From: Dima Dorfman <dima@unixfreak.org> Subject: Re: Patch to fix "make buildkernel requires full obj directory" mistake > Like lots of people who use FreeBSD rather than tinker with it, > I have never done "make any-kind-of-world" and never expect to. > I create a kernel config with my stuff in it, and do config, > make, make install. I trust this is not going to be broken? This is not broken, and will not be broken. Lots of people will scream if it is, myself included (this was discussed when buildkernel was first introduced, and the consensus was that the "old way" should/will always work). This thread is about not teaching two ways (buildkernel and make && make install) to new users who, as you described yourself, have never done make any-kind-of-world, and only want to build a kernel for whatever reason (hardware not in GENERIC, memory footprint, etc.). In other, shorter, words: both ways will work, we just don't want to confuse new users with two ways to achieve the same task. Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 01:00:34 +0100 From: Alexander Langer <alex@big.endian.de> Subject: (fwd) libh disk editor Hi! I'm forwarding this here for those of you who might have missed it on cvs-all/committers. This is libh's version of the disk-editor. Note that it is alpha-software, so be careful with use. Some dialogs (e.g. the "About"-dialog) just don't work, but you will notice this. At least, it is a nice example of what libh is able to do. - ----- Forwarded message from Alexander Langer <alex@big.endian.de> ----- From: Alexander Langer <alex@big.endian.de> Subject: libh disk editor To: Dag-Erling Smorgrav <des@ofug.org> Cc: Alfred Perlstein <bright@wintelcom.net>, Valentin Nechayev <netch@carrier.kiev.ua>, John Baldwin <jhb@freebsd.org>, cvs-committers@freebsd.org, cvs-all@freebsd.org Date: Sat, 20 Jan 2001 00:03:26 +0100 Thus spake Dag-Erling Smorgrav (des@ofug.org): > > I didn't try to edit a disk with it (because I lack a test-disk), but > > I might try. > Hey, I have disks. How do I obtain / build the code? Ok. I've statically linked a tcl interpreter with the libs. Note: -current's Disk_Names() from libdisk finds only ad0 here, though I have ad0 and ad2, so this is not a bug of libh :-) The files are on http://people.freebsd.org/~alex/libh/tclh.static.gz http://people.freebsd.org/~alex/libh/disk.tcl I'm actually rewriting disk.tcl, since some stuff in the User-Interface API changed. Alex - -- cat: /home/alex/.sig: No such file or directory - ----- End forwarded message ----- - -- cat: /home/alex/.sig: No such file or directory To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 19 Jan 2001 16:01:24 -0800 From: Dima Dorfman <dima@unixfreak.org> Subject: Re: startx /dev/mem problem > Fatal server error: > xf86OpenConsole: Server must be suid root As it says, the server must be run setuid to root. Old versions of XFree86 (3.x.y) installed all servers setuid to root by default. This is a security hazard. XFree86 4.0.x do not install them setuid to root. You either need to use xdm (or a compatible login manager), or run the server setuid to root. If you choose the latter, you may find the Xwrapper port (/usr/ports/x11/wrapper) may be of some assistance. It allows you not to have every server setuid to root, only itsself, which will run the appropriate server (in short). Dima Dorfman dima@unixfreak.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 19 Jan 2001 19:27:29 -0500 From: "Howie Xu" <hxu@rios.sitaranetworks.com> Subject: RE: ISR not triggered upon the interrupts and OS hangs Hi Mike et al., The bug was solved and it was because the BIOS advertises wrong interrupt line. It should be 5, not 12. So I registered ISR for line 12, of course never triggered. On the other hand, if no one registers for an interrupt line, how come the OS just hangs, is this a feature or bug? I know that Linux would disable that interrupt line if no driver ever registers a certain intr line when the first interrupt comes in. Thanks for your information! - -Howie > -----Original Message----- > From: Howie Xu [mailto:hxu@rios.sitaranetworks.com] > Sent: Wednesday, January 17, 2001 11:01 AM > To: Mike Smith > Cc: freebsd-hackers@freebsd.org > Subject: RE: ISR not triggered upon the interrupts and OS hangs > > > I am using FreeBSD 3.2, and all the sample drivers in > /usr/src/sys/pci/*.c uses pci_map_int(). > > How can I debug it in 3.2 to know what the OS thinks when the > interrupts come in and OS hangs? > > Thanks again, > > -Howie > > > -----Original Message----- > > From: Mike Smith [mailto:msmith@freebsd.org] > > Sent: Wednesday, January 17, 2001 2:20 AM > > To: Howie Xu > > Cc: freebsd-hackers@freebsd.org > > Subject: Re: ISR not triggered upon the interrupts and OS hangs > > > > > > > Dear Freebsd Hackers, > > > > > > Here is a question regarding my bsd device drivers: > > > > > > I used the pci_map_int() to register an interrupt handler for > > my PCI device > > > (intline = 12). But when the interrupt comes in, the handler > > (ISR) is not > > > triggered at all. But the OS hangs and I can see continuous interrupts > > > coming in on the PCI sniffer. > > > > You don't use pci_map_int() on any modern version of FreeBSD; you use > > bus_alloc_resource() and bus_setup_intr(). > > > > Since you don't mention which FreeBSD version you're using, > it's hard to > > be of any more assistance. > > > > -- > > ... 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 19 Jan 2001 17:03:25 -0800 From: Mike Smith <msmith@freebsd.org> Subject: Re: ISR not triggered upon the interrupts and OS hangs > The bug was solved and it was because the BIOS advertises wrong interrupt > line. It should be 5, not 12. So I registered ISR for line 12, of course > never triggered. Er, can you be more specific here? Where is the interrupt line "advertised"? Is the BIOS incorrectly populating the intline register? Are you certain that the BIOS is doing this? (It would completely violate the PCI specification and cause the system to fail under almost every OS in existence.) > On the other hand, if no one registers for an interrupt line, how come the > OS just hangs, is this a feature or bug? I know that Linux would disable > that interrupt line if no driver ever registers a certain intr line when the > first interrupt comes in. FreeBSD doesn't do this, so you get an interrupt storm (PCI interrupts are a persistent condition). It's a violation of the PCI specification for a device to interrupt until it's initialised, so it should be unncessary. Arguably, we could do this. - -- ... 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: 20 Jan 2001 01:51:43 +0100 From: Dag-Erling Smorgrav <des@ofug.org> Subject: Re: startx /dev/mem problem Chris Stenton <jacs@gnome.co.uk> writes: > Fatal server error: > xf86OpenConsole: Server must be suid root ^^^^^^^^^^^^^^^^^^^^^^^^ This is your clue. DES - -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 19 Jan 2001 21:07:10 -0500 From: "Howie Xu" <hxu@rios.sitaranetworks.com> Subject: RE: ISR not triggered upon the interrupts and OS hangs I am developing a device driver for a network processor. Using pci_cfgread(intline), I read intline 12, but after using DDB to debug the situation, I was convinced that the device actually generates inline 5. After registering my ISR with intline 5, everything is perfect now. Btw, the device was initialized, but I just didn't register the ISR on the right intline. Thanks, - -Howie > -----Original Message----- > From: Mike Smith [mailto:msmith@freebsd.org] > Sent: Friday, January 19, 2001 8:03 PM > To: Howie Xu > Cc: freebsd-hackers@freebsd.org > Subject: Re: ISR not triggered upon the interrupts and OS hangs > > > > The bug was solved and it was because the BIOS advertises wrong > interrupt > > line. It should be 5, not 12. So I registered ISR for line 12, of course > > never triggered. > > Er, can you be more specific here? Where is the interrupt line > "advertised"? Is the BIOS incorrectly populating the intline register? > Are you certain that the BIOS is doing this? (It would completely violate > the PCI specification and cause the system to fail under almost every OS > in existence.) > > > On the other hand, if no one registers for an interrupt line, > how come the > > OS just hangs, is this a feature or bug? I know that Linux would disable > > that interrupt line if no driver ever registers a certain intr > line when the > > first interrupt comes in. > > FreeBSD doesn't do this, so you get an interrupt storm (PCI interrupts > are a persistent condition). It's a violation of the PCI specification > for a device to interrupt until it's initialised, so it should be > unncessary. Arguably, we could do this. > > > -- > ... 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 14:16:03 +1100 (EST) From: Andy Farkas <andyf@speednet.com.au> Subject: Re: Protections on inetd (and /sbin/* /usr/sbin/* in general) I've said it before, and I'll say it again: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=13606 > Tony Finch <dot@dotat.at> writes: > > Apache itself has support for setting resource limits, although I > > agree that in many cases you may want them to be different between the > > httpd and the CGIs. > > You most emphatically do not want to do that. You want the CGI to run > with its owner's resource limits. > > > I expect chrooting was left out because people who have the wit to set > > up a chroot are capable of adding a couple of lines to a C program. > > Said program has a big fat warning at the top that says something like > "do not ever change this program, you'll only screw it up"... I'm > tempted to reply "not much more than it already is". Eivind and I > rewrote it for our previous employer, but the mod is part of a large > chunk of proprietary code, unfortunately. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > - -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 19 Jan 2001 21:32:23 -0800 (PST) From: Ian Kallen <spidaman@arachna.com> Subject: Re: accessing an outside IP from inside a NAT net Well, I've been fiddling with the ipfw syntax, I thought this would do it /sbin/ipfw add divert 80 all from 10.0.0.128/25 to 206.169.18.10 via ep0 but that ain't it. 10.0.0.128/25 has servers, 10.0.0.0/25 has clients, both gateways 10.0.0.1 and 10.0.0.129 run off ep0... yes, I've been reading the ipfw man page and the archives, yet even though the two nets can access each other directly, I haven't been able to get the clients to access any server resources via the 206.169.18.10 nat. Further suggestions? thanks, - -Ian - -- Ian Kallen <spidaman@arachna.com> | AIM: iankallen | efax: (415) 354-3326 On Fri, 19 Jan 2001, Nick Rogness wrote: > On Fri, 19 Jan 2001, Ian Kallen wrote: > > > > > I'd like a hand figuring out how to access resources on the internal side > > of a NAT net from within it without doing something kludgey with DNS. > > i.e. suppose I run natd with a configuration like this: > > > > # begin /etc/natd.conf > > use_sockets > > same_ports > > port 8668 > > deny_incoming no > > log > > redirect_port tcp 10.0.0.128:80 206.169.18.10:80 > > # end /etc/natd.conf > > > > Now if the DNS for the web server www.foo.com running on 10.0.0.128 > > directs a browser on the 10.0.0.0 net to 206.169.18.10, it doesn't get > > routed back to 10.0.0.128; it just hangs (I'm acutally not sure what's > > happening there, the connction never succeeds). Is there a nice way to > > handle this case without running a dummy DNS just for the 10.0.0.0 > > internal net? > > > Run a firewall rule for diverting packets on your inside > interface for that web server. > > > Nick Rogness > - Drive defensively. Buy a tank. > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 19 Jan 2001 22:42:11 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> Subject: Re: Clustering FreeBSD %> No it would not! Back in '94 I ported dmake to FreeBSD %> and built just about every numerics package out there %> on a 4 CPU cluster. Worked fine, but not much in overall %> speedup, because... tadum! Where do you get the source %> files, and how do you get the objs back :-) Not low %> latency, eh? F-Enet then, G-Enet now :) % %You need a better file server. My previous employer, where the software %staff recompiles 3 million lines of code 20 or 30 times a day, employs %pmake and a farm of Sun Ultra-5 workstations to parallelize their makes. %It allows them to complete a build in an hour that would take a single %Ultra-5 almost 20 hours to complete, even with 3 or 4 builds running in %parallel. The network is 100BaseTX to the workstations and 1000BaseSX %to the (NFS) fileserver. Cool! I'd like to learn more. Then... can you elaborate on the build structure a bit? Is it a single large dir (surely not), or how do the dependencies work? For instance, with ACE/TAO (many hours to build when including orbsvcs) there's only a few large directories that can be parallelized over say 10 cpus by gmake, at least. The rest have ten files or less where each file takes maybe 45s to compile on a 1GHz processor. There are quite a few of these. And directories are compiled sequentially. %> Nowadays, you'd want to "globus ify" things, rather than %> use use PVM. %> %> But critically, speedup would only happen if jobs were %> allocated at a higher level than they are now. %> %> Now for building something like a full version of TAO, %> why that might work. But even then, a factor of 2x is %> unlikely until the dependencies are factored out at %> the directory level. % %See the paper "Recursive Make Considered Harmful." Make is an amazing %tool when used correctly. That's not the problem, unfortunately. I've never had a problem rebuilding dependencies unnecessarily, or any of those other problems described. Well precompiled headers would be really really cool. The problem, again, is that parallelism is limited by the directory structure, and the directory structure is entirely rational. Thanks! Russell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 00:04:29 -0700 (MST) From: Nick Rogness <nick@rapidnet.com> Subject: Re: accessing an outside IP from inside a NAT net On Fri, 19 Jan 2001, Ian Kallen wrote: > Well, I've been fiddling with the ipfw syntax, I thought this would do it > /sbin/ipfw add divert 80 all from 10.0.0.128/25 to 206.169.18.10 via ep0 > but that ain't it. > > 10.0.0.128/25 has servers, 10.0.0.0/25 has clients, both gateways > 10.0.0.1 and 10.0.0.129 run off ep0... yes, I've been reading the ipfw man > page and the archives, yet even though the two nets can access each other > directly, I haven't been able to get the clients to access any server > resources via the 206.169.18.10 nat. Further suggestions? I have had this same problem before and have solved it when dealing with setup of a DMZ using FreeBSD. This is actually a pretty tricky ipfw setup to get it to work right (depending on network layout). Let me see if I can give you the details. But first I need a tad more details on how your network is laid out. Are 10.0.0.129 & 10.0.0.1 bound to the same ethernet card? Nick Rogness - - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 00:09:55 -0700 (MST) From: Nick Rogness <nick@rapidnet.com> Subject: Re: accessing an outside IP from inside a NAT net On Fri, 19 Jan 2001, Ian Kallen wrote: > Well, I've been fiddling with the ipfw syntax, I thought this would do it > /sbin/ipfw add divert 80 all from 10.0.0.128/25 to 206.169.18.10 via ep0 > but that ain't it. > > 10.0.0.128/25 has servers, 10.0.0.0/25 has clients, both gateways > 10.0.0.1 and 10.0.0.129 run off ep0... yes, I've been reading the ipfw man > page and the archives, yet even though the two nets can access each other > directly, I haven't been able to get the clients to access any server > resources via the 206.169.18.10 nat. Further suggestions? > thanks, > -Ian Also 10.0.0.128 is on a subnet boundary when used with a /25 netmask and therefore can not be used. how is the network clients and servers configured on the 10.0.0 network? Nick Rogness - - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 00:34:09 -0700 (MST) From: Nick Rogness <nick@rapidnet.com> Subject: Re: accessing an outside IP from inside a NAT net On Fri, 19 Jan 2001, Ian Kallen wrote: > Well, I've been fiddling with the ipfw syntax, I thought this would do it > /sbin/ipfw add divert 80 all from 10.0.0.128/25 to 206.169.18.10 via ep0 > but that ain't it. > > 10.0.0.128/25 has servers, 10.0.0.0/25 has clients, both gateways > 10.0.0.1 and 10.0.0.129 run off ep0... yes, I've been reading the ipfw man > page and the archives, yet even though the two nets can access each other > directly, I haven't been able to get the clients to access any server > resources via the 206.169.18.10 nat. Further suggestions? > thanks, > -Ian For the following solution, lets assume that you have 2 logical networks 10.0.0.0/25 and 10.0.0.128/25 both bound to the inside interface ep0 (which may or may not be true). Your outside interface we'll call fxp0. You server's inside address is 10.0.0.130 and outside address 206.169.18.10 In /etc/new.firewall.rules: # Divert outside packets in & out ipfw add 100 divert natd ip from any to any via fxp0 # Divert packets from the 10.0.0.0/25 network to the server going to # the public server address ipfw add 200 divert natd ip from 10.0.0.0/25 to 206.169.18.10 via ep0 # Divert packets from the server back to the 10.0.0.0/25 network ipfw add 300 divert natd ip from 10.0.0.130/32 to 10.0.0.0/25 via ep0 - ----- In /etc/natd.conf: use_sockets same_ports port 8668 deny_incoming no log redirect_port tcp 10.0.0.128:80 206.169.18.10:80 - ----- You could also run a seperate natd because you may run into problems with the alias address that is natd is using. In this case, a simple rule may do the trick: ipfw add 200 divert natd ip from any to any via ep0 Of course, I am making assumptions on how your network is layed out. Nick Rogness - - Drive defensively. Buy a tank. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 19 Jan 2001 23:49:58 -0800 (PST) From: Ian Kallen <spidaman@arachna.com> Subject: Re: accessing an outside IP from inside a NAT net Cool, thanks. Yes, there's now two subnets on the internal network. I changed the IP on the backend here's the config details: # /etc/rc.conf excerpt ifconfig_ed0="inet 206.169.18.10 netmask 255.255.255.0" ifconfig_ep0="inet 10.0.0.1 netmask 255.255.255.128" ifconfig_ep0_alias0="inet 10.0.0.129 netmask 255.255.255.128" # /etc/natd.conf use_sockets same_ports port 8668 deny_incoming no log redirect_port tcp 10.0.0.130:80 206.169.18.10:80 # /etc/rc.firewall /sbin/ipfw -f flush /sbin/ipfw add divert natd all from any to any via ed0 /sbin/ipfw add pass all from any to any So if you can suss the incantation that allows 10.0.0.0/25 hosts to access 10.0.0.130 via 206.169.18.10, I think I'd be all set! thanks, - -Ian - -- Ian Kallen <spidaman@arachna.com> | AIM: iankallen | efax: (415) 354-3326 On Sat, 20 Jan 2001, Nick Rogness wrote: > On Fri, 19 Jan 2001, Ian Kallen wrote: > > > Well, I've been fiddling with the ipfw syntax, I thought this would do it > > /sbin/ipfw add divert 80 all from 10.0.0.128/25 to 206.169.18.10 via ep0 > > but that ain't it. > > > > 10.0.0.128/25 has servers, 10.0.0.0/25 has clients, both gateways > > 10.0.0.1 and 10.0.0.129 run off ep0... yes, I've been reading the ipfw man > > page and the archives, yet even though the two nets can access each other > > directly, I haven't been able to get the clients to access any server > > resources via the 206.169.18.10 nat. Further suggestions? > > I have had this same problem before and have solved it when > dealing with setup of a DMZ using FreeBSD. > > This is actually a pretty tricky ipfw setup to get it to work > right (depending on network layout). Let me see if I can give you > the details. But first I need a tad more details on how your > network is laid out. > > Are 10.0.0.129 & 10.0.0.1 bound to the same ethernet card? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 10:53:25 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) On Fri 2001-01-19 (12:44), Matt Dillon wrote: > :I'm just editing the PR with the cron patches to "catch up" with > :OpenBSD in this respect (stating that it doesn't handle DST, but > :has benefits whenever one's clock is jumping or cron waking up > :too late and _could_ be extended to handle DST). Therein I > :suggest to > :- not touch current cron at all but switch to a different > : executable by means of the newly introduced rc.conf variables > : or to > :- modify cron but make the new code optional while defaulting to > : off > :(in this order). Although I cannot say which variant will happen > :driven by those with enough priviledges to decide and commit. As > :well as I cannot even tell you if something will be done at all > :in the near future regarding the fact that there's no DST > :solution available yet -- which was the actual reason for the > :wish to change something. > : > :virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 > :Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net > > In the second suggestion, I presume turned off by default > but can be turned on with a command-line option? (Verses > a make.conf compile-time variable). I like the idea of > a command-line option to turn on the 'new' code. That provides > a consistent, straightforward way of allowing developers to test > the code, making it available in releases with a simple rc.conf > twitch, and eventually (years later judging by the flame war:-)) > turning it on in /etc/defaults/rc.conf. There seems not to be a real argument against the algorithm, plenty of support for having it available as an option, and only an argument against it being default. I'm quite happy for it not to be default, as I'm sure Gerhard is. Thus, there's no reason not to add the ability (at least OpenBSD, Debian and HP-UX have similar behaviour), so we should proceed. All we need do is add the option to getopt, and turn the "optimisation check for the default 1 minute case" to check if the "new behaviour flag" is not checked. Ie: if (!bflag || (timeDiff == 1)) { virtualTime = timeRunning; find_jobs(virtualTime, &database, TRUE, TRUE); } else { wakeupKind = -1; if (timeDiff > -(3*MINUTE_COUNT)) wakeupKind = 0; ... It should work exactly like the old cron behaviour, unless the '-b' flag is given. Neil - -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 01:48:38 -0800 From: "Crist J. Clark" <cjclark@reflexnet.net> Subject: Re: startx /dev/mem problem On Sat, Jan 20, 2001 at 01:51:43AM +0100, Dag-Erling Smorgrav wrote: > Chris Stenton <jacs@gnome.co.uk> writes: > > Fatal server error: > > xf86OpenConsole: Server must be suid root > ^^^^^^^^^^^^^^^^^^^^^^^^ > This is your clue. He might also be running at elevated securelevel. - -- Crist J. Clark cjclark@alum.mit.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 20:24:05 +0900 From: ynishimura@home.nimc.go.jp Subject: Does anyone know how to let fd0.1720 be bootable? Dear sirs I have been developing many kinds of 1FD-applications( http://www.ryuchi.org/~iloved ) with FreeBSD2.2.8. 1FD-SQUID, 1FD-SAMBA, etc. Recently, I can use fd0.1720( 21 Sectors/track, 82 track), not fd0.1440(18 Sectors/track, 80 track). But, fd0.1720 cannot be bootable. I can see "boot: " message on screen, but it cannot load kernel because boot2 cannot access fd0.1720. I change RA_SECTORS from 18 to 21 in /sys/i386/boot/biosboot/disk.c. But, it could not boot. Does anyone know how to let fd0.1720 be bootable? Sincerely Y.NISHIMURA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: 20 Jan 2001 14:05:50 +0100 From: Dag-Erling Smorgrav <des@ofug.org> Subject: Re: startx /dev/mem problem "Crist J. Clark" <cjclark@reflexnet.net> writes: > On Sat, Jan 20, 2001 at 01:51:43AM +0100, Dag-Erling Smorgrav wrote: > > Chris Stenton <jacs@gnome.co.uk> writes: > > > Fatal server error: > > > xf86OpenConsole: Server must be suid root > > ^^^^^^^^^^^^^^^^^^^^^^^^ > > This is your clue. > He might also be running at elevated securelevel. He said he wasn't. DES - -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 15:55:01 +0100 From: Nicolas Souchu <nsouch@alcove.fr> Subject: Re: scsi and PS2 mode parallel port programming On Fri, Jan 12, 2001 at 10:41:29AM +0000, Nick Hibma wrote: > > > You've been speaking to Nicolas Souchu, right? He has written the > current driver and seems to know a fair bit about this topic. We've solved the problem. > > Nick > > > | I'll put this on my pile of things to and dig through the CAM changes to > > | find it. There weren't that many in the past year. > > > > I finally heard from the guy who noticed the change, and asked if he could > > help localize it. > > > > | I don't know much about the PS2 mode nor the parallel port driver > > | (allthough I've had my fingers in there, as you know). > > > > A parallel port in ECP mode should support PS2 without any problem, correct? > > And if I recall, it worked under 3.x, so that *should* rule out a buggy BIOS > > or hardware anomaly. I *hate* when problems only afflict my machine. > > > > > > jcm > > -- > > o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o > > | ~~~~~~~~~~~~ Jonathon McKitrick ~~~~~~~~~~~~~ | > > | "I prefer the term 'Artificial Person' myself." | > > o-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-o > > > > -- > Qube Software, Ltd. Private: > n_hibma@qubesoft.com n_hibma@webweaving.org > n_hibma@freebsd.org > http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message - -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 16:18:35 +0100 From: Nicolas Souchu <nsouch@alcove.fr> Subject: odd result of pci_read_config Hi folks, I have a problem with R4.2. The device driver I'm currently writing can't retrieve correctly the value from a PCI configuration register. What is strange is that when using the pciconf tool I get the result I expect, not with pci_read_config(). pciconf -r pci0:7:3: 0x48 returns 0x00006001 but value = pci_read_config(dev, 0x48, 4); returns 0x6 !!! The later is called from the attach routine of the driver which is detected like this: viapm0: <VIA VT82C586B Power Management Unit> at device 7.3 on pci0 My pci config is: chip0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x05971106 rev=0x04 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x00000000 chip=0x85981106 rev=0x00 hdr=0x01 isab0@pci0:7:0: class=0x060100 card=0x00000000 chip=0x05861106 rev=0x47 hdr=0x00 atapci0@pci0:7:1: class=0x01018a card=0x00000000 chip=0x05711106 rev=0x06 hdr=0x00 viapm0@pci0:7:3: class=0x060400 card=0x00000000 chip=0x30401106 rev=0x10 hdr=0x01 pcm0@pci0:8:0: class=0x040100 card=0x13191319 chip=0x08011319 rev=0xb1 hdr=0x00 none0@pci0:8:1: class=0x090410 card=0x13191319 chip=0x08021319 rev=0xb1 hdr=0x00 ahc0@pci0:9:0: class=0x010000 card=0x00000000 chip=0x81789004 rev=0x00 hdr=0x00 fxp0@pci0:10:0: class=0x020000 card=0x10c3103c chip=0x12298086 rev=0x05 hdr=0x00 none1@pci1:0:0: class=0x030000 card=0x00281002 chip=0x52461002 rev=0x00 hdr=0x00 So what may be the problem? Also, some PCI drivers allocate IOPORT resources by giving the PCI configuration register as the rid of the bus_alloc_resource call... how can it work? What are the magics in pci framework for this? Thanks, Nicholas - -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 10:34:31 -0500 From: "Donald J . Maddox" <dmaddox@sc.rr.com> Subject: Re: Does anyone know how to let fd0.1720 be bootable? I think this is a BIOS issue. I don't think any BIOS will let you boot from arbitrarily-formatted floppies :) On Sat, Jan 20, 2001 at 08:24:05PM +0900, ynishimura@home.nimc.go.jp wrote: > Dear sirs > > I have been developing many kinds of 1FD-applications( > http://www.ryuchi.org/~iloved ) with FreeBSD2.2.8. > > 1FD-SQUID, 1FD-SAMBA, etc. > > Recently, I can use fd0.1720( 21 Sectors/track, 82 track), not fd0.1440(18 > Sectors/track, 80 track). > > But, fd0.1720 cannot be bootable. > > I can see "boot: " message on screen, but it cannot load kernel because boot2 > cannot access fd0.1720. > > I change RA_SECTORS from 18 to 21 in /sys/i386/boot/biosboot/disk.c. But, it > could not boot. > > Does anyone know how to let fd0.1720 be bootable? > > Sincerely > Y.NISHIMURA > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 13:02:16 -0500 (EST) From: rt <rtecco@umich.edu> Subject: building a fixit floppy? i am having trouble building a fixit floppy - which is 2.88 M image. i can perform: dd if=fixit.flp of=/dev/fd0c (on my openbsd box) but it reaches the end of the device, writing 1.44 (obviously). when i try to use this disk, it looks like it works, but commands like 'ls' and 'mount' just print garbage to the screen. i don't know whether this is a corrupted binary or something else. thx in advance, rt - ------------- rt 734-332-4562 "Most people's lives are taken up with a great many trivial things that they don't really care about, but which they feel they have to do. I just don't do that." - esr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 13:09:00 -0500 From: "Donald J . Maddox" <dmaddox@sc.rr.com> Subject: Re: building a fixit floppy? I don't know where you came across a 2.88M fixit.flp... But, if you go to your friendly local ftp.freebsd.org mirror and look for: pub/FreeBSD/releases/i386/4.2-RELEASE/floppies/fixit.flp You will find a 1.44M version :) On Sat, Jan 20, 2001 at 01:02:16PM -0500, rt wrote: > > i am having trouble building a fixit floppy - which is > 2.88 M image. i can perform: > > dd if=fixit.flp of=/dev/fd0c (on my openbsd box) > > but it reaches the end of the device, writing 1.44 (obviously). > > when i try to use this disk, it looks like it works, but > commands like 'ls' and 'mount' just print garbage to the screen. > i don't know whether this is a corrupted binary or something > else. > > thx in advance, > rt > > ------------- > rt > 734-332-4562 > > "Most people's lives are taken up with > a great many trivial things that > they don't really care about, but > which they feel they have to > do. I just don't do that." > - esr > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 19:43:25 +0100 From: Gerhard Sittig <Gerhard.Sittig@gmx.net> Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) On Wed, Jan 17, 2001 at 18:48 +0100, Gerhard Sittig wrote: > > I'm just editing the PR with the cron patches [ ... ] So it finally happened. It's filed as "bin/24485: [PATCH] to make cron(8) handle clock jumps" and got archived at http://www.freebsd.org/cgi/query-pr.cgi?pr=24485 I don't see it as a ready solution but more as a basis for further discussion if needed or considered useful. Up to now there was only the reference to "cvs diff -r1.3 -r1.4 $OPENBSDTREE/cron.c". Now there's an isolated DST part of what's different between OpenBSD and FreeBSD. And the code turned out to not handle DST, but time(3) differences. In the course of this thread I got uncertain if this is the way to follow when talking about the DST issue. The PR's subject tries to demonstrate that I see the patch to serve a different purpose from what its manpage diff promises. As a consequence I try to discuss in the PR the enhancements the diff could be in need of as well as what other mechanisms could solve (or lower) the DST "problem". There's nothing new for those who followed the thread. But it might be pleasant to have them bundled and archived. (Sorry if I forgot something or didn't read it. It's no bad intent, I'm just not subscribed to - -hackers and the web frontend has some four days of delay. And I don't browse from where I do the mail, so something could get dropped "in transit". Feel free to followup to the PR in case there's something missing or wrong. But you surely do without me inviting you:) Combine this one with the "conf/24358: [PATCH] etc/rc variables for cron(8)" PR and everybody has the choice to - - do nothing and live unaffected - - create / get a port and switch over to it ('cd /usr/ports; make search key=cron' is empty at the moment) - - repo copy cron and fiddle in any way with the new instance - - locally patch the cron tree and leave others unaffected - - revive private implementations (? I heard mention of these) There should be no suspicion any longer of getting harmed for no other reason than lazy / unexperienced / misguided admins' wanting their computer to do things the way humans expect. :) I wouldn't think about make.conf switches, but rather handle it the rc.conf way. Have the one "stable" cron that's been there for good, leave it untouched and experiment in one of the above sketched ways. This should give the maximum in deterministic and expected behaviour for those wanting consistency with the current implementation as well as maximum flexibility for those who feel a change to be necessary for their own environments. The lesson I have learnt from the discussion is that there is no single cron that would be able to satisfy everyone. And since cron is an essential component of a UNIX machine concerns cannot be taken easily. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net - -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Fri, 19 Jan 2001 23:38:13 -0700 From: Wes Peters <wes@softweyr.com> Subject: Re: Clustering FreeBSD "Russell L. Carter" wrote: > > %> No it would not! Back in '94 I ported dmake to FreeBSD > %> and built just about every numerics package out there > %> on a 4 CPU cluster. Worked fine, but not much in overall > %> speedup, because... tadum! Where do you get the source > %> files, and how do you get the objs back :-) Not low > %> latency, eh? F-Enet then, G-Enet now :) > % > %You need a better file server. My previous employer, where the software > %staff recompiles 3 million lines of code 20 or 30 times a day, employs > %pmake and a farm of Sun Ultra-5 workstations to parallelize their makes. > %It allows them to complete a build in an hour that would take a single > %Ultra-5 almost 20 hours to complete, even with 3 or 4 builds running in > %parallel. The network is 100BaseTX to the workstations and 1000BaseSX > %to the (NFS) fileserver. > > Cool! I'd like to learn more. > > Then... can you elaborate on the build structure a bit? Is it > a single large dir (surely not), or how do the dependencies work? No, there were nearly a hundred directories scattered all over the place. It was actually quite a mess. There were also a couple of hand-enforced relationships that were quite messy. The entire mass was big enough that parallelizing was hugely beneficial even with the ugly mess the build system was. > For instance, with ACE/TAO (many hours to build when including > orbsvcs) there's only a few large directories that can > be parallelized over say 10 cpus by gmake, at least. These are the types of directories that can benefit easily. Ideally, with no overhead for job starting, you would be able to use n processors to compile n files all at the same time. Realistically you're quite limited by the network bandwidth and the speed of the file server, but since compiling is not a completely I/O bound process, you can do perhaps some- what better than just an obvious bandwidth multipler. For instance, if you have 100BaseTX on the build machines and 1000Base?? on the file server, you make actually be able to utilize 12 or 14 or maybe even 20 build machines before saturating the fileserver. > The rest have > ten files or less where each file takes maybe 45s to compile on a > 1GHz processor. There are quite a few of these. > And directories are compiled sequentially. If you replace your recursive Makefiles with a single dependency tree, it doesn't matter how many files are in a directory. You can launch enough compiles to complete the directory, building the executable or library or whatever is made there, because you can be sure that all if it's dependencies have already been built, and that nothing that depends on it will get touched until it has completed. There is a good discussion of this on the Perforce web pages, in their discussion of Jam/MR, a somewhat newer tool similar to Make. Jamfiles are never recursive; tools are provided for building Jamfiles that describe the entire project so the dependency tree is completely expressed. > %> Nowadays, you'd want to "globus ify" things, rather than > %> use use PVM. > %> > %> But critically, speedup would only happen if jobs were > %> allocated at a higher level than they are now. > %> > %> Now for building something like a full version of TAO, > %> why that might work. But even then, a factor of 2x is > %> unlikely until the dependencies are factored out at > %> the directory level. > % > %See the paper "Recursive Make Considered Harmful." Make is an amazing > %tool when used correctly. > > That's not the problem, unfortunately. I've never had a problem > rebuilding dependencies unnecessarily, or any of those > other problems described. Well precompiled headers would be > really really cool. The problem, again, is that parallelism > is limited by the directory structure, and the directory structure > is entirely rational. The directory structure has nothing to do with the Makefiles. To obtain the goal the paper suggests, you replace the recursive Makefiles with a single top-level Makefile that describes ALL of the targets and ALL of the dependencies. Note that this does not require a single mono- lithic Makefile; the top level Makefile can be a shell that includes per-directory Makefiles. The important part is to get a single dependency tree with no cycles in the graph. - -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 13:19:17 -0800 (PST) From: Luigi Rizzo <rizzo@aciri.org> Subject: Re: Does anyone know how to let fd0.1720 be bootable? > I think this is a BIOS issue. I don't think any BIOS will let you > boot from arbitrarily-formatted floppies :) the 1480 format works. luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 16:39:40 -0500 From: Sergey Babkin <babkin@bellatlantic.net> Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) All, I've committed these changes for cron to support DST change to -current (see PR bin/24494 for description of my tests). Everyone is welcome to test them out. Please let me know if you encounter any problems caused by them (and better do that before these changes would be MFCed to -stable in a few weeks). - -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sat, 20 Jan 2001 23:54:12 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> Subject: Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab) On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > All, > > I've committed these changes for cron to support DST change > to -current (see PR bin/24494 for description of my tests). > Everyone is welcome to test them out. > Please let me know if you encounter any problems caused by them > (and better do that before these changes would be MFCed to -stable > in a few weeks). I do believe this is premature. There really should at least be an option for the old behaviour, and there is a good argument for making the new behaviour optional dependent on a variable with the old behaviour default. _Especially_ if you intend to MFC this, since changing this behaviour in a minor release, without a way to have the old behaviour, is almost certainly wrong. Neil - -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ Date: Sun, 21 Jan 2001 00:43:49 +0100 From: Nicolas Souchu <nsouch@alcove.fr> Subject: more info about: odd result of pci_read_config On Sat, Jan 20, 2001 at 04:18:35PM +0100, Nicolas Souchu wrote: > Hi folks, > > I have a problem with R4.2. The device driver I'm currently > writing can't retrieve correctly the value from a PCI configuration > register. What is strange is that when using the pciconf tool I get > the result I expect, not with pci_read_config(). > > pciconf -r pci0:7:3: 0x48 returns 0x00006001 > > but > > value = pci_read_config(dev, 0x48, 4); returns 0x6 !!! > Here is some more testing: Reading any configuration register gives 0x6! But when creating a cfg structure with bus=0, slot=7 and func=3 in the attach routine then pass it to pci_cfgread(), it works. Also, when querying the pci bus with BUS_READ_IVAR() for BUS, SLOT and FUNC, I get 0,7,3. What is the hose field? Note also that I had to return NULL on the detection of the device 0x30401106 in pcisupport.c pcib_match() because it has a bridge class and the pcib driver was attached to it before viapm. Here is the piece of code: static int viapm_attach(device_t dev) { u_int32_t l, base_cfgreg; u_int16_t s; u_int8_t c; struct viapm_data *viapm; struct resource *res; device_t bitbang; pcicfgregs cfg; if (!(viapm = (struct viapm_data *)device_get_softc(dev))) return ENXIO; bzero(viapm, sizeof(struct viapm_data)); l = pci_read_config(dev, 0x8, 1); printf("%s: rev id 0x%x\n", __FUNCTION__, l); ## returns 0x6! Which is stupid switch (l) { case VIAPM_OEM_REV_E: base_cfgreg = VIAPM_CFG_3040E_BASE; /* Activate IO block access */ s = pci_read_config(dev, VIAPM_CFG_3040E_ACTIV, 2); pci_write_config(dev, VIAPM_CFG_3040F_ACTIV, s | VIAPM_ACTIV_E_MASK, 2); break; case VIAPM_OEM_REV_F: case VIAPM_PROD_REV_A: default: base_cfgreg = VIAPM_CFG_3040F_BASE; /* Activate IO block access */ c = pci_read_config(dev, VIAPM_CFG_3040F_ACTIV, 1); pci_write_config(dev, VIAPM_CFG_3040F_ACTIV, c | VIAPM_ACTIV_F_MASK, 1); break; } cfg.hose = -1; cfg.bus = 0; cfg.slot = 7; cfg.func = 3; l = pci_cfgread(&cfg, VIAPM_CFG_3040F_BASE, 4); printf("%s: base addr 0x%x\n", __FUNCTION__, l); ## return 0x6001! the correct value BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_BUS, &l); printf("bus=%d\n", l); BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_SLOT, &l); printf("slot=%d\n", l); BUS_READ_IVAR(device_get_parent(dev), dev, PCI_IVAR_FUNCTION, &l); printf("func=%d\n", l); ## return 0,7,3 if (!(res = bus_alloc_resource(dev, SYS_RES_IOPORT, &base_cfgreg, 0l, ~0l, 1, RF_ACTIVE))) { device_printf(dev, "could not allocate bus space\n"); return ENXIO; } viapm->st = rman_get_bustag(res); viapm->sh = rman_get_bushandle(res); printf("viapm: 0x%x and 0x%x\n", viapm->st, viapm->sh); VIAPM_OUTB(GPIO_DIR, VIAPM_INB(GPIO_DIR) | VIAPM_SCL | VIAPM_SDA); device_printf(dev, "attaching bitbanging...\n"); /* add generic bit-banging code */ if (!(bitbang = device_add_child(dev, "iicbb", -1))) return ENXIO; return (device_probe_and_attach(bitbang)); } - -- Nicolas.Souchu@alcove.fr Alcôve - Open Source Software Engineer - http://www.alcove.fr To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message ------------------------------ End of freebsd-hackers-digest V5 #14 ************************************ --1162764539.980037938703.JavaMail.root.mh-a03.dmz.another.com-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1795842299.980037938705.JavaMail.root>