Re: implementing idle-time networking
Hi, i believe there are two things here that you need to consider before you can see any queue build up in ipq: 1. you should generate packets (way) faster than the card is able to handle them; 2. the network card itself might be able to queue multiple packets in the "transmit ring"; to check if #2 is true you should either look at the driver, or trace how fast ipq is drained (e.g. take timestamps) and see if it happens faster than the packet transmission time. re. #1, remember that on a 100Mbit net a full-sized packet goes out in some 100us, which is fast. Maybe you have already done this, but just in case, you should run your tests preferably with reasonably long (that might mean some 50-100 packets if there is queueing in the card) bursts full-sized UDP packets and on a 10Mbit/s link to see queues build up in ipq. cheers luigi as part of my thesis research, I'm implementing something similar to the POSIX idle-time CPU scheduler for other resource types, one being network I/O. The basic idea is to substitute two-level queues for the standard ones. I'm seeing some unexpected things (explained below), but let me first outline what I'm doing exactly: 1. I extend the ifnet structure to contain a second ifqueue, for idle-time traffic; and also declare a new flag for mbufs, to indicate whether network idle-time processing should be done or not. 2. In sosend(), I check if the sending process is running at a POSIX idle-time priority. If so, I set the idle-time flag in the mbuf. 3. In ether_output_frame(), I check if the idle-time flag is set on an mbuf, and if so, enqueue it in the interface's idle-time queue (default queue otherwise.) 4. In xl_start() (my onboard chip happens to use the xl driver), I first check the default queue for any mbufs ready to send. If there are none, I try the idle-time queue. If an mbuf could be dequeued from either queue, I continue with normal outbound processing (have mbuf be picked up by NIC). Unfortunately, this scheme does not work. Some first experiments have shown that idle-time network performance is practically identical to regular-priority. I measured it going from a slower (10Mb/s) to a faster (100Mb/s) host through a private switch, so the NIC should be the bottleneck (the processors are both 800Mhz PIII). The new code is in fact executed, I have traced it heavily. Closer inspection revealed that both the ifnet ifqueues as well as the driver transmission chain are always empty upon enqueue/dequeue. Thus, even though my fancy queuing code is executed, it has no effect, since there never are any queues. Can someone shed some light on if this is expected behavior? Wouldn't that mean that as packets are being generated by the socket layer, they are handed down through the kernel to the driver one-by-one, incurring at interrupt for each packet? Or am I missing the obvious? Thanks, Lars -- Lars Eggert [EMAIL PROTECTED] Information Sciences Institute http://www.isi.edu/larse/University of Southern California Content-Description: S/MIME Cryptographic Signature [Attachment, skipping...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
Chris Csanady ([EMAIL PROTECTED]) wrote: Has this actually been merged to -stable yet? I can't find anything that actually reads the boot.nfsroot.* loader variables. Yes.. it was done more than a week ago. -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
Paul Saab ([EMAIL PROTECTED]) wrote: Chris Csanady ([EMAIL PROTECTED]) wrote: Has this actually been merged to -stable yet? I can't find anything that actually reads the boot.nfsroot.* loader variables. Yes.. it was done more than a week ago. Ugh.. I could have sworn I MFC'd this a week ago, but it turns out I did everything but the last part. *sigh*. I just MFC'd it. -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Device driver, memory map failing, and it is probably obvious
From [EMAIL PROTECTED] Sun Sep 17 20:03:11 2000
To: [EMAIL PROTECTED]
Subject: Re: Device driver, memory map failing, and it is probably obvious
Cc: [EMAIL PROTECTED]
Date: Sun, 17 Sep 2000 21:01:44 -0600
From: Warner Losh [EMAIL PROTECTED]
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes:
: I am making a driver for a VERY old PCI device.
:digic-digic_mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY,
:digic-digic_mem_rid,
:0, ~0, 256, RF_ACTIVE|RF_SHAREABLE);
: Could this be the problem?
Where do you initialize digic_mem_rid? You should set this equal to
the BAR offset in the PCI config space that corresponds to this
memory.
Warner
BINGO! I added the following:
/* now get the memory resources */
digic-digic_mem_rid = DIGI_LOMEM;
digic-digic_mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY,
digic-digic_mem_rid,
0, ~0, 256, RF_ACTIVE|RF_SHAREABLE);
By the way, from the bus_alloc_resource man page:
/* now get the memory resources */
digic-digic_mem_rid = DIGI_LOMEM;
digic-digic_mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY,
digic-digic_mem_rid,
0, ~0, 256, RF_ACTIVE|RF_SHAREABLE);
rid points to a bus specific handle that identifies the resource being
allocated. For ISA this is an index into an array of resources that have
been setup for this device by either the PnP mechanism, or via the hints
mechanism. For PCCARD, similar things are used as of writing, but that
may change in the future with newcard. For PCI it just happens to be the
offset into pci config space which has a word that describes the re-
source. The bus methods are free to change the RIDs that they are given
as a parameter. You must not depend on the value you gave it earlier.
I might suggest a small rewording:
rid points to a value that contains a bus specific handle
that identifies the resource being
allocated. For ISA this is an index into an array of resources that have
been setup for this device by either the PnP mechanism, or via the hints
mechanism. A value of 0 will use the first resource. See X for
more details. For PCCARD, similar things are used as of writing, but that
may change in the future with newcard. For PCI it is the
offset into pci config space which has a word that describes the re-
source. The bus methods are may change the values of the RIDs that they are given
as a parameter. You must not depend on the value you gave it earlier.
You might want to fill in X.
EXAMPLES
This is an example for an ISA bus interface. The values of portid and irqid
should be
saved in the softc of the device after these calls.
struct resource *portres, irqres;
int portid, irqid, value;
#define REG1_OFFSET 0
portid = 0;/* use the first port resource */
irqid = 0; /* use the first interrupt resource */
portres = bus_alloc_resource(dev, SYS_RES_IOPORT, portid,
0ul, ~0ul, 32, RF_ACTIVE);
irqres = bus_alloc_resource(dev, SYS_RES_IRQ, irqid,
0ul, ~0ul, 1, RF_ACTIVE | RF_SHAREABLE);
value = bus_space_read_1( rman_get_bustag(portres),
rman_get_bustag(portres), REG1_OFFSET
);
This is an example for a PCI bus interface. We assume that
for this particular device the device registers are available
through PIO instructions or have been mapped into the PCI
memory space. We can choose which method we want to use by
setting the rid value to the appropriate offset in the PCI
configuration that has the IO port or memory information.
struct resource *portres;
int portid, value;
#define REG1_OFFSET 0
#define LOMEM 0x10
#define LOIO 0x14
if( use_io ){
portid = LOIO;
} else {
portid = LOMEM;
}
portres = bus_alloc_resource(dev, SYS_RES_IOPORT, portid,
0ul, ~0ul, 32, RF_ACTIVE);
value = bus_space_read_1( rman_get_bustag(portres),
rman_get_bustag(portres), REG1_OFFSET
);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: device naming convention
Marc Tardif writes: What is slices content? s1 - almost right FreeBSD label s2 - not a right FreeBSD label but similar enough to label. s3 - no label or similar at all. How to do such a content that screw the system? This is my way for this test: - shorten s2 to 3 cilinder. - disklabel -w -r wd0s2 fd360 - restore s2 size. I don't understand this last part, probably because I don't have much experience with labelling and partitioning. Please excuse my questions if they seem basic, but I am fairly new to disks: - how can s2 be "similar enough to label" if it is recognised as "sysid 0,(unused)" by fdisk? sorry, content of s2 ... No, s2 has some bits at the begin that FreeBSD interpretes as label. "sysid 0,(unused)" has no sense - every sysid cant stop slice from been evaluated for label on it. - how did you create s2 exactly, in order to make it "similar enough to label" yet remain unused? in case I write about steps were: - fdisk -u wd0 create 3 slices of equal lenght 76 cylinders s1 - suid 165, s2 - suid 0, s3 - suid 165. - reboot - label s1 - I dont remember exact way, nothing special I believe. - fdisk -u wd0 change slice s2 with suid 0 and 3 cylinders (3*660 blocks) in size - disklabel -w -r wd0s2 fd360 - disklabel -e wd0s2 delete b:, mark a: unused and mark c: 4.2BSD - fdisk -u wd0 change size of s2 to 76 tracks. - reboot Now s2 has invalid (broken) label (or some bits that are similar to label) - how did you create s3 and s4 exactly? s3 above, s4 is suid 0 start 0 size 0 - why is s3 not similar at all if it is recognised as a FreeBSD slice by fdisk? s3 has some scrap that is not recognized by FreeBSD as "label" Again - sysid has no sense if not used in boot process or another system, FreeBSD seek every slice for label independantly of sysid. - what do you mean by shortening s2 to 3 cylinders? Do you mean s2 should start at the third cylinder? After first fdisk I change s2 size only, not any other s2 parameter - is there any reason you chose to label wd0s2 as fd360? It is the easyest way to write something to s2 that is similar to label. fd360 is first type in my /etc/disktypes - how should s2 size be restored? maybe: dd of=/dev/wd0s2 if=/dev/null bs=660b? No. change size wia fdisk How can you guarantee that occasionally some bits in slice do not fraud FreeBSD if used for arbitrary bits? Do not use slice begin at all. I also didn't quite understand what is wrong with using the slice begin. Your octal dump showed how the first 017343 bytes were not nulls, but why? Is there a fixed number of bytes that should be skipped, or should this number be system dependent and tested manually? If you use slice in such a way that in label area occur something that can be treated by OS as a FreeBSD label, then protection of label and boot area occur. label area IMHO 1K, boot area in any case ends before 32 block (first suberblock copy in ufs) As far as I understand (but I am not hard in this) just keep 4 bytes (addresses 0376, 00377, 00776, 00777) is sufficient To avoid using the slice begin, could the first label be defined at a proper offset to skip the slice begin? If NOT use FreeBSD label? How? If use FreeBSD label? just use FreeBSD partitions inside slice (M$ partiton)? May be. But I have example of misbehave such a conctruction in 2.2.X. Not tested in 4.1. Are you interested? 3.X not interesting at all. -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
traceroute using tcp to a port?
If I understand correctly, traceroute works by sending pings with ttl=1, ttl=2,ttl=3 etc and records the names of the routers where the ttl reaches zero. However, an increasing number of sites believes in security by obscurity, and blocks for pings. Would the same technique work for making a telnet to port 80 with ttl=1, ttl=2 etc? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: traceroute using tcp to a port?
On Tue, Sep 19, 2000 at 11:00:57AM +0200, Leif Neland wrote: If I understand correctly, traceroute works by sending pings with ttl=1, ttl=2,ttl=3 etc and records the names of the routers where the ttl reaches zero. However, an increasing number of sites believes in security by obscurity, and blocks for pings. traceroute doesn't use pings. mtr does. Would the same technique work for making a telnet to port 80 with ttl=1, ttl=2 etc? traceroute currently uses UDP in a similar way, and a SYN ping (like nmap does) should be possible too, yes. The problem is that those sites hinder traceroutes by blocking certain kinds of *outgoing* ICMP traffic, and there's no way we can work around that. Greetz, Peter. -- [ircoper][EMAIL PROTECTED] - Peter van Dijk / Hardbeat [student]Undernet:#groningen/wallops | IRCnet:/#alliance [developer] EFnet:#qmail _ [disbeliever - the world is backwards](__VuurWerk__(--*- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: traceroute using tcp to a port?
On Tue, 19 Sep 2000, Leif Neland wrote: If I understand correctly, traceroute works by sending pings with ttl=1, ttl=2,ttl=3 etc and records the names of the routers where the ttl reaches zero. However, an increasing number of sites believes in security by obscurity, and blocks for pings. Would the same technique work for making a telnet to port 80 with ttl=1, ttl=2 etc? Leif Of course it works, and very well. You should try hping (http://www.kyuzz.org/antirez/hping/) which is a _very cool_ tool developped by Antirez. With it you could do (among many things) traceroute over tcp. regards, -- Yann BERTHIER [EMAIL PROTECTED] Network Security Consultant Herve Schauer Consultant To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Serial port locks up 4.1
FYI: It seems that if you try to access the serial port on a MB with the port disabled, freebsd 4.1 will freeze up solid. Enabling the serial console will cause a lock up on boot, and any access to the port will do it as well. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
device timings
Considering the following disk configuration: *** Working on device /dev/rwd0 *** parameters extracted from in-core disklabel are: cylinders=256 heads=132 sectors/track=63 (8316 blks/cyl) parameters to be used for BIOS calculations are: cylinders=256 heads=132 sectors/track=63 (8316 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 63, size 1937565 (946 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 1; end: cyl 232/ sector 63/ head 131 The data for partition 2 is: sysid 0,(unused) start 1937628, size 58212 (28 Meg), flag 0 beg: cyl 233/ sector 1/ head 0; end: cyl 239/ sector 63/ head 131 ... Now considering the following timings done with dd, how come I get such different transfer rates (bytes/sec) for s1 and s2? I understand there should be a difference between the block and character interface, as shown in the first two timings, but why isn't the same difference shown for the last two timings? # dd if=/dev/wd0s1 of=/dev/null bs=8316b count=5 5+0 records in 5+0 records out 21288960 bytes transferred in 8.580486 secs (2481090 bytes/sec) # dd if=/dev/rwd0s1 of=/dev/null bs=8316b count=5 5+0 records in 5+0 records out 21288960 bytes transferred in 4.058639 secs (5245344 bytes/sec) # dd if=/dev/wd0s2 of=/dev/null bs=8316b count=5 5+0 records in 5+0 records out 21288960 bytes transferred in 6.066568 secs (3509226 bytes/sec) # dd if=/dev/rwd0s2 of=/dev/null bs=8316b count=5 5+0 records in 5+0 records out 21288960 bytes transferred in 6.015735 secs (3538879 bytes/sec) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
subscribe freebsd-hackers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: device timings
Modern disks pack different ammounts of data on different tracks.. (the outside tracks are longer right?) so at a constant speed (rpm) outside tracks have more data passing below the head per given time than teh inside tracks do... this seems pretty normal to me.. Marc Tardif wrote: Considering the following disk configuration: *** Working on device /dev/rwd0 *** parameters extracted from in-core disklabel are: cylinders=256 heads=132 sectors/track=63 (8316 blks/cyl) parameters to be used for BIOS calculations are: cylinders=256 heads=132 sectors/track=63 (8316 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 63, size 1937565 (946 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 1; end: cyl 232/ sector 63/ head 131 The data for partition 2 is: sysid 0,(unused) start 1937628, size 58212 (28 Meg), flag 0 beg: cyl 233/ sector 1/ head 0; end: cyl 239/ sector 63/ head 131 ... Now considering the following timings done with dd, how come I get such different transfer rates (bytes/sec) for s1 and s2? I understand there should be a difference between the block and character interface, as shown in the first two timings, but why isn't the same difference shown for the last two timings? # dd if=/dev/wd0s1 of=/dev/null bs=8316b count=5 5+0 records in 5+0 records out 21288960 bytes transferred in 8.580486 secs (2481090 bytes/sec) # dd if=/dev/rwd0s1 of=/dev/null bs=8316b count=5 5+0 records in 5+0 records out 21288960 bytes transferred in 4.058639 secs (5245344 bytes/sec) # dd if=/dev/wd0s2 of=/dev/null bs=8316b count=5 5+0 records in 5+0 records out 21288960 bytes transferred in 6.066568 secs (3509226 bytes/sec) # dd if=/dev/rwd0s2 of=/dev/null bs=8316b count=5 5+0 records in 5+0 records out 21288960 bytes transferred in 6.015735 secs (3538879 bytes/sec) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-fs" in the body of the message -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pty tcsetattr
I had some PPPoE issues so I did a cvsup of FreeBSD 3.4 to help fix them. An unfortunate consequence of this is that pty's seem to be broken now with respect to certain TERMIO operations, which breaks my VPN system completely (thus leaving the client in question with a partly broken WAN). This command line: pty-redir /usr/local/bin/ssh -e none -l toor -t -o 'BatchMode yes' la-gw echo hi returns the pty name string from pty-redir, and an error message from ssh (the /usr/ports/security/ssh version) which says: tcsetattr: Invalid argument This message comes from the enter_raw_mode() function in the clientloop.c module in the ssh-1.2.27 distribution. An attempt to substitute cfmakeraw() in the above function had no visible effect. I am not on your mailing list, so please direct any replies to hostmaster at gts.net - any assistance will be much appreciated. Thanks, Bruce BeckerNetwork Administration Toronto, Ont. Vox: +1 416 699 1868 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
pty tcsetattr
I had some PPPoE issues so I did a cvsup of FreeBSD 3.4 to help fix them. An unfortunate consequence of this is that pty's seem to be broken now with respect to certain TERMIO operations, which breaks my VPN system completely (thus leaving the client in question with a partly broken WAN). This command line: pty-redir /usr/local/bin/ssh -e none -l toor -t -o 'BatchMode yes' la-gw echo hi returns the pty name string from pty-redir, and an error message from ssh (the /usr/ports/security/ssh version) which says: tcsetattr: Invalid argument This message comes from the enter_raw_mode() function in the clientloop.c module in the ssh-1.2.27 distribution. An attempt to substitute cfmakeraw() in the above function had no visible effect. I am not on your mailing list, so please direct any replies to hostmaster at gts.net - any assistance will be much appreciated. Thanks, Bruce BeckerNetwork Administration Toronto, Ont. Vox: +1 416 699 1868 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: traceroute using tcp to a port?
Of course it works, and very well. You should try hping (http://www.kyuzz.org/antirez/hping/) which is a _very cool_ tool developped by Antirez. With it you could do (among many things) traceroute over tcp. Ah, you mean just like FreeBSD's "traceroute -P tcp" does? Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: traceroute using tcp to a port?
On Tue, 19 Sep 2000, [EMAIL PROTECTED] wrote: Of course it works, and very well. You should try hping (http://www.kyuzz.org/antirez/hping/) which is a _very cool_ tool developped by Antirez. With it you could do (among many things) traceroute over tcp. Ah, you mean just like FreeBSD's "traceroute -P tcp" does? No, I mean something like : # ./hping2 -S -p 80 -T -t 1 www.whatever.tld (with -S setting the syn flag, -t the initial ttl, -p the destination port, and -T for traceroute mode). For sure other tools could do the same, I talked about hping 'cause it's my ip swiss knife :) regards, Yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Installation problem
hello, allow me to introduce myself. i regard myself to be a well experienced computer user using many platforms. yet, when i tried to install freebsd, i found that i cannot, since just past the setupx configuration, the cpu halts. or gets stuck in a cyclic loop, wherei am unable to do anything, and the monitor seems to get itself into an unreachable mode, this is just after the x-setup, so when the computer goes back to the installation menus, but i dont get a chance to see any of them. any assisatnce is welcome. www: www.mp34me.orgemail: [EMAIL PROTECTED]icq uin: 21156382
Re: Installation problem
On Tue, Sep 19, 2000 at 10:24:47PM +0100, robert smith wrote: hello, allow me to introduce myself. i regard myself to be a well experienced computer user using many platforms. yet, when i tried to install freebsd, i found that i cannot, since just past the setupx configuration, the cpu halts. or gets stuck in a cyclic loop, where i am unable to do anything, and the monitor seems to get itself into an unreachable mode, this is just after the x-setup, so when the computer goes back to the installation menus, but i dont get a chance to see any of them. My experience in installing FreeBSD: - Do a minimal install first, and reboot the machine. Make sure you use the 'Options' menu to set debugging to 'yes'. This will assure: - that your installation media is OK. - that you don't have a messed up partition table, or an unbootable partition. - that core hardware (memeory, CPU. hard drive, etc.) works adequately. (memory failures can be a bit magical.) - Even better, do said minimal install via a serial port, from another machine running 'script'. This give a recorded log of your installation process, as well as any messages generated during the reboot. Everything after this point is stuff to be added on, and likely should be done in stages. (Setting a root password, installing packages/distributions/etc.) I've personally never tried to set up X from FreeBSD's installation disks. They just invoke utilities that come with the X distribution. Feel free to use the install disks to install the X distribution, but use the command-line tools to configure X. That way, you can use the man pages for the utilities to see what they are doing, and how they report errors. BTW - I suspect this should have gone to -questions... Good luck... any assisatnce is welcome. www: www.mp34me.org email: [EMAIL PROTECTED] icq uin: 21156382 -- Brian 'you Bastard' Reichert[EMAIL PROTECTED] 37 Crystal Ave. #303Daytime number: (603) 434-6842 Derry NH 03038-1713 USA Intel architecture: the left-hand path To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: diskless workstation
Mike Smith wrote: ok, once i compiled a kernel with options BOOTP things got better ;-) it worked several times, but now it boots ok, (pxe-dhcp-tftpboot-nfs) but after it re-configures the ethernet, the ethernet stops working! ponters anyone? You can't run dhclient (DHCP in any of the ifconfig lines in /etc/ rc.conf) if you have mounted / via NFS. If you're running -current or a very recent -stable, remove the 'BOOTP' options. The loader now passes all the DHCP information into the kernel. Then leave the interface configuration alone... Has this actually been merged to -stable yet? I can't find anything that actually reads the boot.nfsroot.* loader variables. Supposedly; Paul Saab did the merge. -- ... 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] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Mounting Solaris/x86 slices?
Are we able to mount Solaris/x86 disk slices? I'm thinking about trying use FreeBSD as an installation crutch to mirror a Solaris/86 installation to 60-odd PCs (I can have FreeBSD netbooted to a diskless workstation configuration by the time solaris is 1/2 way through reading its secondary bootstrap..). I'm just planning to dd an existing disk image onto the local disk. It would be nice to be able to mount the Solaris root partition touch a few configuration files... If anybody has done something similar and can offer advice, please ping me. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Running natd on more than one interface...
I have a home network that talks to the world-at-large using natd to do the address translation on my gateway machine. However, I've just started tunneling (over an encrypted link) to another place using the tun interface. I'd like to have it translated as well. Has anyone tried running natd on more than one interface? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
writing(2) to raw devices
From The Design and Implementation of the 4.4BSD Operating System, the write(2) system call must go through vn_write(), ffs_write(), ffs_balloc(), cluster(), bio() and finally dev() which performs the actual disk write. Considering all this block-oriented overhead, how can dd(1) which calls write(2), perform raw io on devices such as /dev/rwd0? Doesn't write(2) confine the process to block io by its very nature? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: writing(2) to raw devices
That is only if the write is to a file within a partition mounted as an FFS file system. vn_write() contains the VOP_WRITE switch, which will switch to the write implementation based on the vnode type. VOP_WRITE calls through the function hanging off the vnode in the vnode op vector at the offset specified by vop_write_desc (record defined in sys/compile/GENERIC/vnode_if.c -- generated by a perl script from sys/kern/vnode_if.src during kernel build). Finding out which write implementation is actually hanging off the vnode for the raw device is left as an exercise for the reader. -Chris On Tue, 19 Sep 2000, Marc Tardif wrote: From The Design and Implementation of the 4.4BSD Operating System, the write(2) system call must go through vn_write(), ffs_write(), ffs_balloc(), cluster(), bio() and finally dev() which performs the actual disk write. Considering all this block-oriented overhead, how can dd(1) which calls write(2), perform raw io on devices such as /dev/rwd0? Doesn't write(2) confine the process to block io by its very nature? 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: PnP 4.1 Release
Is it possible to stop any PnP operation (checking, seting) during boot? No. Could you describe your problem in more detail? -- ... 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] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: implementing idle-time networking
Closer inspection revealed that both the ifnet ifqueues as well as the driver transmission chain are always empty upon enqueue/dequeue. Thus, even though my fancy queuing code is executed, it has no effect, since there never are any queues. Can someone shed some light on if this is expected behavior? Wouldn't that mean that as packets are being generated by the socket layer, they are handed down through the kernel to the driver one-by-one, incurring at interrupt for each packet? Or am I missing the obvious? Packets are pushed down as far as they can go, ie. if the card has resources available to take another packet you'll go all the way into the device driver. It's not until you actually run the card out of resources that the various queues start to fill up. The actual interrupt rate depends on the specific card; many of the better cards have interrupt-reduction features that eg. only signal an interrupt when they have completed a set of transmitted packets, or no more than once every Nms, etc. Otherwise, you're going to take one interrupt per packet anyway. -- ... 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] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Device driver, memory map failing, and it is probably obvious
found 'Digi International PCI Classic 8 Serial Adapter'
my0: Digi International PCI Classic 8 Serial Adapter \
port 0xdc00-0xdcff,0xd800-0xd87f mem 0xea40-0xea4000ff,0xea402000-0xea40207f \
irq 12 at device 10.0 on pci0
digic_attach: unit 0, irq 12, slot 10, progif 0x0, iobase 0xd801, membase
0xea402000, irqline 0x10c
my0: couldn't map memory
device_probe_and_attach: my0 attach returned 6
So it found the card, discovered the vintage hardware id, and printed it out.
The we call the attach routine:
static int
digic_attach( device_t dev )
{
struct digic_softc *digic;
int unit;
int irq, slot, progif, iobase, membase, irqline;
int error = 0;
void *ih = 0;
/* get the sc structure */
digic = device_get_softc(dev);
bzero(digic,sizeof(digic[0]));
bzero(digic, sizeof(*digic))
unit = device_get_unit(dev);
Don't use this; use device_printf();
irq = pci_get_irq(dev);
slot = pci_get_slot(dev);
You don't need these.
progif = pci_get_progif(dev);
And you probably don't want that.
#define WB_PCI_LOMEM0x10
#define WB_PCI_LOIO 0x14
#define WB_PCI_INTLINE 0x3c
iobase = pci_read_config(dev, WB_PCI_LOIO, 4);
membase = pci_read_config(dev, WB_PCI_LOMEM, 4);
irqline = pci_read_config(dev, WB_PCI_INTLINE, 4);
You don't need these.
DPRINTF(("digic_attach: unit %d, irq %d, slot %d, progif 0x%x, iobase 0x%x,
membase 0x%x, irqline 0x%x\n",
unit, irq, slot, progif, iobase, membase, irqline ));
Use device_printf().
switch( pci_get_device(dev) ){
case PCI_CLASSIC_4: digic-digic_ports = 4; break;
case PCI_CLASSIC_8: digic-digic_ports = 8; break;
default:
device_printf(dev,"digic_attach: bad device id! %d",
pci_get_device(dev));
goto fail;
}
/* now get the memory resources */
digic-digic_mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY,
digic-digic_mem_rid,
0, ~0, 256, RF_ACTIVE|RF_SHAREABLE);
You have to initialise digic-digic_mem_rid first. Looking at the above,
I'd guess it should be initialised to WB_PCI_LOMEM, which should actually
be PCIR_MAPS.
if (!digic-digic_mem_res) {
device_printf(dev, "couldn't map memory\n");
goto fail;
}
Now, I am SURE that I must be doing something stupid here - but I snipped this code
right out of the code for another driver, and this one works.
The only puzzle is:
my0: Digi International PCI Classic 8 Serial Adapter \
port 0xdc00-0xdcff,0xd800-0xd87f mem 0xea40-0xea4000ff,0xea402000-0xea40207f \
irq 12 at device 10.0 on pci0
Note that the diagnostic output indicates some VERY strange ranges.
Could this be the problem?
I wouldn't say that any of these ranges are strange at all. You have a
256-byte and a 128-byte window in each of I/O and memory space. Looks
fine to me.
--
... 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]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
csa sound card not generating interrupt?
I have an IBM Thinkpad T20 and, after a snificant amount of pain, have been
able to get everything working under FreeBSD except for sound. The laptop
contains a CS4264 chip with a CS4297A AC97 codec, both of which detects
fine as csa0 and pcm0. The memory range and irq in the pci config all
appear to be set correctly. The problem is the the sound chip never once
generated an interrupt, which results in "pcm0: {play,record} interrupt
timeout, channel dead" every time I attempt to play/record. This error
does not appear when playing short sound clips, but no sound is heard
nonetheless. Upon further poking around, I confirmed that the card did not
even attempt to generate an interrupt (interrupt status bit is low, but
interrupt enable bit remains high). I've also tried Linux on the same
computer (with their alsa sound driver), and sound works under
Linux. Comparing the freebsd/alsa driver reveals that the attach routine
of the two drivers does the same things! Yet, remarkably, one works and
the other doesn't. Does anyone have any suggestions or pointers for this
problem before I go crazy pulling all my hair out?
Thanks.
--
(o_ 1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2-1-2 _o)
\\\_\Jonathan Chen [EMAIL PROTECTED] /_///
) No electrons were harmed during production of this message (
~
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
