Re: UDI environment now released.
On Wed, 14 Feb 2001, Robert Lipe wrote: Grard Roudier wrote: Being smart with kernel interface is important for drivers to be fast and reliable. Puting some stinky layer between native kernel interfaces and drivers looks horrible to me. Fast and reliable are both covered. For example, the specification (though not the current reference implementation) allows things like having different drivers and even different instances of the same driver in separate address spaces. Want to debug your driver in user space? It could happen. Reliability can be realized by making it impossible for a driver to panic the system. (And I do realize that flies directly in the face of fast. :-) Certainly not full impossible. DMA at some wrong place or not handling properly level-triggerred interrupt, for example ... A more recognizable reliabilty improvement is the more unified and constitent programming interface. No more "you can't call malloc with WAIT_OK while holding a spin lock on another processor at an elevated PL" bugs. This looks like matter of taste to me. Unless all O/S architects since day one until UDI have been incompetent idiots. :-) Why isn't UDI proposed as a native kernel interface, instead? In at least three OSes, it will be a native kernel interface in versions shipping this year. How the 'open-ness' of UDI is guaranteed? As a corollary: - Are these three mysterious O/Ses using some vendor-specific extensions or undocumented differences in their UDI stuff? - What the risk of UDI getting steered by some coalition of vendors? - Finally, as some large collection od UDI drivers may well exist, how can I download the source and how FreeBSD is intended to gain adavantage of this driver collection in the future ? The current "UDI Demarcation Point" isn't fixed. It can be moved to suit the needs of the host OS. As a practical matter, the thickness of that "layer" is very slim at runtime, so the potential gains aren't as large as some imagine they are. I want to beleive you here. In its early life, a very natural way to bring up the UDI interface (remember, we were developing spec, drivers, and environment simultaneously) was to do it in terms of existing kernel interfaces. UDI and the existing interfaces could be implemented side-by-side. In many cases, you could even make UDI the primary interface and implement another interface -perhaps the current interface for compatibility- in terms of UDI. I'm looking at doing exactly this in some of my OSes. Was the main point of my question. Thanks for the reply. Besides, if I walked into this crowd and said, "Here's a new driver interface and a megabyte of patches to /usr/src/sys. Whaddya think?", how quickly would you have thrown me out? That's what I thought. :-) A mega-byte large patch is not that unusual nowadays. :-) Now repeat that exercise for a dozen or so OSes... Only. :-) Grard. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: can't get iicbus working - ARRGH!
On Wed, Feb 14, 2001 at 02:26:25AM -0500, Mike Nowlin wrote:
I messed around with this about a year ago, and now I'm messing around with
it again.
In a nutshell, I can NOT figure out how to get iic with lpbb working. I
have tried all sorts of combinations of config file parameters from LINT,
man pages, etc.
Is your parallel port peripheral 100% compatible with the one described in
lpbb(4)?
My current config file has something like:
# Parallel port
device ppc0at isa? port 0x3bc flags 0x28 irq 7 drq 3
#device ppc0at isa? port 0x3bc flags 0x20 irq 7
device ppbus # Parallel port bus (required)
device lpt # Printer
device ppi # Parallel port interface device
#device vpo # Requires scbus and da
#device plip# TCP/IP over parallel
# I2C stuff
device iicbus
device iic
#device ic
#device iicsmb
device iicbb
device lpbb
#
device smbus
device intpm
The only boot messages I get that are related to this section are:
ppc0: Parallel port at port 0x3bc-0x3bf irq 7 drq 3 flags 0x20 on isa0
ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
lpt0: Printer on ppbus0
lpt0: Polled port ppi0: Parallel I/O on ppbus0
When I added the last two lines (smbus, intpm), I did get the following:
intpm0: Intel 82371AB Power management controller port 0x5000-0x500f irq 9
at device 7.3 on pci0
intpm0: I/O mapped 5000
intpm0: intr IRQ 9 enabled revision 0
smbus0: System Management Bus on intsmb0
intpm0: PM I/O mapped 4000
...which is closer to any I2C or SMB references I've gotten to date.
Without smb(4) in your config, you'll do nothing with this. intpm is only
smbus compatible.
There's some detection process in the lpbb driver. You should first
check if your parallel i2c interface is correctly detected.
#define ALIM0x20
#define I2CKEY 0x50
static int lpbb_detect(device_t dev)
{
device_t ppbus = device_get_parent(dev);
if (ppb_request_bus(ppbus, dev, PPB_DONTWAIT)) {
device_printf(dev, "can't allocate ppbus\n");
return (0);
}
/* reset bus */
setSDA(ppbus, 1);
setSCL(ppbus, 1);
if ((ppb_rstr(ppbus) I2CKEY) ||
((ppb_rstr(ppbus) ALIM) != ALIM)) {
ppb_release_bus(ppbus, dev);
return (0);
}
[...]
Your interface must be compliant with this.
Does anyone have this working?
I did.
If so, could you send me your config file to look through?
device ppc0 at...
device ppbus
device lpbb
device iicbb
device iicbus
device iic
Should do the job. Then if you want SMBus over parallel I2C, add
device iicsmb
device smb
Thanks - Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
[EMAIL PROTECTED]
Alcve - Open Source Software Engineer - http://www.alcove.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Cannot create raw socket connections
On Thu, 15 Feb 2001, Dale Chulhan - Home wrote: I have a pal trying to do a tool for measurement of bandwidth on a bsd machine. He says: Everytime I open a raw socket connection ( send FIN to expect RST or something like that ). There should be no problem with sending a TCP FIN on a raw socket. But the returning RST will be eaten by the TCP protocol. Your raw socket will not receive it. (ref: Stevens UNP v1, p 659) The socket is killed. That is most strange... You mean to say that the next sendto() or recvfrom() returns EBADF? What version of FreeBSD is this? He concluded that the router he is going through is dropping the packets some how on their way out or the connection is being killed on the way back in. The router could be dropping packets. If you have access, it should not take much time to add a specific access list rule to log those packets to see if they are going through. He says there is a third possibility that the kernel actually discards the packets. Said he found it in a man page some where? Unless you have a firewall installed, the kernel should send all packets from a raw socket, and pass all incoming packets to your socket, except UDP, TCP, and ICMP echo/timestamp/mask. -Richard --- Richard Hodges | Matriplex, inc. title | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDI environment now released.
Grard Roudier wrote: A more recognizable reliabilty improvement is the more unified and constitent programming interface. No more "you can't call malloc with This looks like matter of taste to me. Unless all O/S architects since day one until UDI have been incompetent idiots. :-) Well, OK. If you don't mind, for example, having a different buffer model for network devices than you do for storage devices, it is a matter of taste. Why isn't UDI proposed as a native kernel interface, instead? In at least three OSes, it will be a native kernel interface in versions shipping this year. How the 'open-ness' of UDI is guaranteed? * The specification is open and freely available for download and use. (www.projectudi.org) * No royalties, membership fees, or initiation rites to contribute or use the spec. * Multiple implementations (including one with source under a BSD license) are available for interop testing. - Are these three mysterious O/Ses using some vendor-specific extensions or undocumented differences in their UDI stuff? I didn't mean to be mysterious: * SCO UnixWare 7 has a vendor (that's me) supported UDI environment available now as download.The next version will have it integrated into the base OS. * SCO OpenServer 5 will have a supported UDI environment in the first half of this year as a download. The next version will have it integrated. * AIX/5L has a supported UDI environment in the current prereleases. UDI will be available in the product at launch. If there are driver-visible differences, they are bugs and will be treated as such. And in some environments, we enforce things like accessing no symbols other than what's in the spec. Name your driver functions "lbolt", "kmem_alloc", "main" or anything else you like; you're not getting to the non-UDI symbols in the kernel of the same name. :-) - What the risk of UDI getting steered by some coalition of vendors? If you want to help steer, come aboard. We'd welcome it. Since we didn't start with some existing driver interface, it's not self-serving to assert any undue influence on things. There's enough architectural differences represented to keep things pretty neutral. You can see minutes of the (open) meetings and calls on the web site. - Finally, as some large collection od UDI drivers may well exist, how can I download the source and how FreeBSD is intended to gain adavantage of this driver collection in the future ? We're providing a few drivers on projectudi.sourceforge.net as samples. It will be, as always, up to the driver owners to decide how and where to distribute their drivers. If someone contributes a driver to the project, I'll gladly drop it in the tree. Now that the 1.01 specification is finalized and UDI is shipping as a final supported product one OS (UnixWare 7) with two more soon (OpenServer, AIX I expect IHVs many cases, you could even make UDI the primary interface and implement another interface -perhaps the current interface for compatibility- in terms of UDI. I'm looking at doing exactly this in some of my OSes. Was the main point of my question. Thanks for the reply. Good. Besides, if I walked into this crowd and said, "Here's a new driver interface and a megabyte of patches to /usr/src/sys. Whaddya think?", how quickly would you have thrown me out? That's what I thought. :-) A mega-byte large patch is not that unusual nowadays. :-) Perhaps not, but if I had carved up gensetdefs to allow builds outside the kernel source tree, changed the klm code to recognize .udiprops sections in an executable, and made newbus a little more forthcoming with information, don't you agree it would have been met with more skepticism? I just really didn't want to debug the host OS and the UDI environment at the same time. I didn't do it when I did UDI for the OSes in my day job, either. Maybe I'm a coward. Now repeat that exercise for a dozen or so OSes... Only. :-) Hey, I've gotta sleep once in a while. :-) Speaking of not sleeping, I had a major cvs commit party last night. I think I have all the FreeBSD code checked ito the udiref tree now. I fixed a binary incompatibility problem and have now successfully kldloaded UDI modules that were built on a UnixWare system. (The Linux/OpenServer/UnixWare interoperability has already been demonstrated.) RJL To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Staticaly allocated buffers in library. Is it correct?
I patched some library files and noted that some functions, which parse some configuration files, use staticaly allocated buffers. Sizes of such staticaly allocated buffers are 8k, 10k and so on. These buffers are used to hold one line from parsed file. Usually it is enough for one line, but really this is error (I think). So, here is my question. Is it a tradition of library functions to use statically allocated buffers for parsing configuration files? I made my patch (for my purpose) and additionally remove code with staticaly allocated buffers and add code with malloc()+realloc() implementation. I think that one malloc() call which allocates 1k will be enough to hold one line of a configuration file, but if it is not enough I call realloc() and reallocates buffer to bigger size. What do you think about my question? ps: I understand that I can use buffer with max size equal to max value of int, unsigned int, size_t, etc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cannot create raw socket connections
Can you further assist me by expanding your reference to help me locate it? There should be no problem with sending a TCP FIN on a raw socket. But the returning RST will be eaten by the TCP protocol. Your raw socket will not receive it. (ref: Stevens UNP v1, p 659) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Apology to Robert Lipe [ UDI ]
Robert Lipe wrote: Matthew Jacob wrote: I've been giving myself some embarrassing soul searching, and I'm forced to come to the conclusion that I've acted like a complete idiot and jerk. Robert- please accept my sincere apologies for my ill-mannered reaction and words. Whatever my opinions avbout UDI, whether in or out of FreeBSD are, I did not react in the positive manner that your mail deserved. Well, I had come to the same conclusion, but now you've made me reverse my conclusion, too. :-) Your apology is humbly accepted. Similarly, I hope I didn't come off too strong in my enthusiasm. UDI isn't the answer to everything. It solves some problems for some people. The offer is out there that I have a "proof of concept" port knocked out for FreeBSD and will gladly work with anyone interested in championing it to the next stage. Thanx, Matthew. Gentlemen, we should have this message and response cast in bronze and attached to the Monument to the Unknown Hacker. Or at least make it mandatory reading by including it in the email send to new subscribers to the -hackers list. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
still getting unexpected netgraph version
this is a 3.5s machine, I cvsuped, made world, and configed/made depend the kernel and then reboot and I am still getting the same error message. any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cannot create raw socket connections
That reference is the network programming BIBLE! Richard Stevens, "Unix Network Programming Volume 1" Run, don't walk, to the nearest on-line bookstore and get the whole series (Vols 1 and 2). You should also get "Advanced Programming in the Unix Environment". -A. On Fri, 16 Feb 2001, Dale Chulhan - Work wrote: Can you further assist me by expanding your reference to help me locate it? There should be no problem with sending a TCP FIN on a raw socket. But the returning RST will be eaten by the TCP protocol. Your raw socket will not receive it. (ref: Stevens UNP v1, p 659) 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: Cannot create raw socket connections
On Fri, 16 Feb 2001, Dale Chulhan - Work wrote: Can you further assist me by expanding your reference to help me locate it? There should be no problem with sending a TCP FIN on a raw socket. But the returning RST will be eaten by the TCP protocol. Your raw socket will not receive it. (ref: Stevens UNP v1, p 659) Sure, the title is "Unix Network Programming" volume 1, second edition by W. Richard Stevens. ISBN 0-13-490012-X (US$ 52.95 www.bookpool.com) As another fellow mentioned earlier, this is where the collective wisdom of network programming is kept :-) When you get ready for kernel level network programming, get "TCP/IP Illustrated, Volume 2". There is no substitute. -Richard --- Richard Hodges | Matriplex, inc. title | 769 Basque Way [EMAIL PROTECTED] | Carson City, NV 89706 775-886-6477| www.matriplex.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
MAKEDEV: 609: sysntax error
Hello I cann't install FreeBSD in a box with main board Mega Trends and Pentium II. I have tried installing FreeBSD 4.0, but it has an error when it is finishing the instalation. sysinstall showed: MAKEDEV returned non-zero status. The comit operation completed with errors no updating /etc files. On console: 8386 blocks DEBUG: kget mib1 has length of 0. MAKEDEV: 609: sysntax error: ";;" unexpected (expecting "done") The computer has a 3Gb IDE disk Samsung SV0644A. Thanks. Yonny Cardenas [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Handspring.
Wasn't it 9-Feb-2001, at 11:17PM, when Kenny Drobnack said: As far as syncing a Handspring Visor with FreeBSD - dunno. Tried using the coldsync program which was meant for syncing Palm Pilots, and the coldsync web page claims that it works with Visors too. When I run coldsync, I get a message "Please press the hotsync button" and when I hit the button I get the message two more times, and then either it locked up or the whole system locks up. Same results using a serial cradle instead of the USB cradle that came with it. I noticed Linux has a Handspring Visor driver, not sure what's up with that. I'm successfully sync'ing my Visor using FreeBSD. I'm using the cold-sync port to do this. I needed to modify /etc/usbd.conf to recognise the Visor when the hot-sync button is pressed. 'usbd' then runs 'coldsync' under my account and does the right thing. You specify the generic USB driver (/dev/ugen0) to communicate with the Visor. A warning: If you pull the Visor from the cradle before 'usbd' has completed its USB disconnect cycle, the driver shuts itself down. The only way to recover (that I've seen) is to reboot. There is a USB driver for the Visor in OpenBSD. I pulled over the source file to try to build it, though I haven't had the chance to actually incorpoarte it into the kernel (I still need to find out how to add a USB driver to the kernel source tree, what changes need to be made to support FreeBSD, etc.) Anyways, it's nice being able to sync the Visor without having to log in or out... -- Rich Neswold efax: 1.240.536.7092 web: www.enteract.com/~rneswold/ PGP signature
Re: qmail IO problems
Ok to finish this off. dmesg da0 at sym0 bus 0 target 1 lun 0 da0: IBM DDRS-39130D DC1B Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8715MB (1785 512 byte sectors: 255H 63S/T C) da1 at sym0 bus 0 target 2 lun 0 da1: IBM DDRS-39130D DC1B Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8715MB (1785 512 byte sectors: 255H 63S/T C) da2 at sym0 bus 0 target 4 lun 0 da2: IBM DDRS-39130D DC1B Fixed Direct Access SCSI-2 device da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 8715MB (1785 512 byte sectors: 255H 63S/T C) 3 drives in there as of 3 min ago. just want to take these 3 and raid0 then together as /var. what was recommendation ccd or venim? and has anyone done this before...could walk me through setting these up quickly maybe? Regards, Dan On Mon, 5 Feb 2001, Matt Dillon wrote: Date: Mon, 5 Feb 2001 17:01:35 -0800 (PST) From: Matt Dillon [EMAIL PROTECTED] To: Alfred Perlstein [EMAIL PROTECTED] Cc: Jos Backus [EMAIL PROTECTED], Dan Phoenix [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: qmail IO problems I think before you guys go off wandering you need some definitive information on the rate of incomming and outgoing mail, number of simultanious connections being handled, and so forth. On the face of it, high disk transaction rates, low transfer rates, and idle cpu implies either lots of paging I/O or softupdates isn't actually turned on. Lots of paging I/O implies, potentially, lots of connections. So you need a couple of stats in-hand to figure out what is going on: * How many mail-related processes are running, and by inference how many simultanious connections are being handled?. 'ps axlww' while the heavy I/O is going on would help a lot here. * Is the sytem paging? 'systat -vm 1' will give you a good indication. * 'vmstat 1' output also helps If the system is running too many processes then some messing around with qmail's configuration options should solve the problem. Also, nowhere did I read how much memory this machine had. This will give us useful information on that front: * cat /var/run/dmesg.boot (And, for gods sake, DON'T screw around with sysctl vfs.write_behind! I should probably just rip that sysctl out. The default heuristic handles all the cases already). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO problems
:... :da2: IBM DDRS-39130D DC1B Fixed Direct Access SCSI-2 device :da2: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing :Enabled :da2: 8715MB (1785 512 byte sectors: 255H 63S/T C) : :3 drives in there as of 3 min ago. :just want to take these 3 and raid0 then together as /var. :what was recommendation ccd or venim? : :and has anyone done this before...could walk me through setting these up :quickly maybe? : :Regards, : :Dan If all you are doing is striping them together for a test, just use CCD. 'man ccdconfig' contains some good examples. I'd use an interleave of 1152. First disklabel each disk, then use ccdconfig to stripe the partition you've configured on each disk all together. You might want to use postfix rather then qmail, but it's up to you. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[moebius@bitstream.net: 4.1.1-release ldconfig issue]
I installed libiconv-1.5.1 on my 4.1.1-release system with the following results: -rw-r--r-- 1 root wheel 452 Feb 16 09:05 libiconv.la lrwxr-xr-x 1 root wheel 15 Feb 16 09:05 libiconv.so - libiconv.so.2.2 -rw-r--r-- 1 root wheel 646265 Feb 16 09:05 libiconv.so.2.2 Once finished I run 'ldconfig -m /usr/local/lib /usr/lib'. No errors to this point. Once done I run 'ldconfig -r | grep icon' and nothing is there. The library is not making it into the hints file. Running file on the .so.2.2 file I get the following: libiconv.so.2.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped Obviously I'm missing something. What? Any pointer would be appreciated. At the minimum, where would I find the source for ldconfig? Which package? Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO problems
Thanks for that urlalong with that and Chris Watson's help :) was able to get then up running vinum...thanks again. On Sat, 17 Feb 2001, Dan Langille wrote: Date: Sat, 17 Feb 2001 13:58:42 +1300 From: Dan Langille [EMAIL PROTECTED] To: Dan Phoenix [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: qmail IO problems On 16 Feb 2001, at 16:34, Dan Phoenix wrote: 3 drives in there as of 3 min ago. just want to take these 3 and raid0 then together as /var. what was recommendation ccd or venim? and has anyone done this before...could walk me through setting these up quickly maybe? perhaps http://freebsddiary.org/vinum.html -- Dan Langille pgpkey - finger [EMAIL PROTECTED] | http://unixathome.org/finger.php got any work? I'm looking for some. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO problems
vinum_drives="" # put in names of disks containing vinum drives # to start vinum on only specific disks. was this taken out in latest release of fbsd? On Sat, 17 Feb 2001, Dan Langille wrote: Date: Sat, 17 Feb 2001 13:58:42 +1300 From: Dan Langille [EMAIL PROTECTED] To: Dan Phoenix [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: qmail IO problems On 16 Feb 2001, at 16:34, Dan Phoenix wrote: 3 drives in there as of 3 min ago. just want to take these 3 and raid0 then together as /var. what was recommendation ccd or venim? and has anyone done this before...could walk me through setting these up quickly maybe? perhaps http://freebsddiary.org/vinum.html -- Dan Langille pgpkey - finger [EMAIL PROTECTED] | http://unixathome.org/finger.php got any work? I'm looking for some. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
boot1 changes and etherboot support
sorry if this is not the most appropriate forum to discuss this, redirects appreciated. I have spent some time trying to put etherboot[1] code onto the hard disk so that it can be selected using the FreeBSD boot manager. I ended up doing it with a small amt of modifications to the "boot1" code, for which a patch is attached. Maybe it could be interesting in applying this patch to the standard boot1 code (apart for the PRT_BSD change, which should be unmodified). While at it, i noticed that fdisk seems to be more "smart" than i'd like, and likes to move the begin and end of partition to align it to a track boundary. This is kind of annoying, 1) because if you change the geometry in a way that has no effect for the loading of the kernel, it can still screw up your partition, and 2) because i would like to squeeze the boot1+etherboot in the spare 62 sectors between the MBR (boot0) and the beginning of the first partition on the disk. Is there any bad side effect in having a slice which starts at sector 1 and is 62 sectors long ? cheers luigi [1] Etherboot code is basically a boot ROM image of reasonably small size (16 or 32K depending on card type), and as part of its standard distribution can be loaded from a floppy using a special-purpose boot sector which is prepended to the image itself. Unfortunately the loader that comes with etherboot assumes the use of a floppy and does not work from a hard drive. [2] The patch for boot1.s is below. --- boot1.s Fri Jul 7 14:12:32 2000 +++ boot1a.sFri Feb 16 18:39:20 2001 @@ -28,7 +28,7 @@ # Partition Constants .set PRT_OFF,0x1be # Partition offset .set PRT_NUM,0x4# Partitions - .set PRT_BSD,0xa5 # Partition type + .set PRT_BSD,0x1# Partition type # Flag Bits .set FL_PACKET,0x80 # Packet mode @@ -147,9 +147,18 @@ # when we use btxld create boot2, we use an entry point of 0x1000. That # entry point is relative to MEM_USR; thus boot2.bin starts at 0xb000. # main.5:mov %dx,MEM_ARG # Save args movb $0x10,%dh # Sector count callw nread # Read disk + cmpw $0xaa55, MEM_BUF+0x200 # rom signature ? + jnz load_btx + movb MEM_BUF+0x202,%dh # Sector count + incb %dh + mov $0x7e00, %bx + callw nreadbx # Read disk + ljmp $0x800,$6 # enter the rom code + +load_btx: mov $MEM_BTX,%bx# BTX mov 0xa(%bx),%si# Get BTX length and set add %bx,%si # %si to start of boot2.bin @@ -184,6 +193,7 @@ # Trampoline used to call read from within boot1. # nread: mov $MEM_BUF,%bx# Transfer buffer +nreadbx: # same but address is in bx mov 0x8(%si),%ax# Get mov 0xa(%si),%cx# LBA push %cs# Read from --+- Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa) http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704 Phone: (510) 666 2927 --+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: qmail IO problems
drive ibm1 device /dev/da0s1e drive ibm2 device /dev/da1s1e drive ibm3 device /dev/da2s1e volume stripe plex org striped 512s sd length 8714m drive ibm1 sd length 8714m drive ibm2 sd length 8714m drive ibm3 is this right? i did an rm -rf on 150megs and it is taking forever on this drive not sure how to calculate striped # 512s maybe is what is making it so slow? -- Dan +--+ | BRAVENET WEB SERVICES | | [EMAIL PROTECTED]| | make installworld| | ln -s /var/qmail/bin/sendmail /usr/sbin/sendmail | | ln -s /var/qmail/bin/newaliases /usr/sbin/newaliases | +__+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
