Re: gif(4) question

[Jeroen Ruigrok/Asmodai]

[This question is more appropriate for -net IMHO]

-On [20010322 03:00], David E. Cross ([EMAIL PROTECTED]) wrote:
>I recently tried (for the first time) to get gif running under FreeBSD
>4.3-BETA (cvsup-ed yesterday).  I noticed the following:
>
>gifconfig gif0 inet 10.1.1.1 10.1.2.1
>ifconfig gif0 192.168.1.1 192.168.1.2 netmask 0xff00
>
>and then I 'ping 192.168.1.1' it will try to route the packet instead of 
>reply directly.  I need to 'route add 192.168.1.1 127.0.0.1' to have it
>reply to the packet directly.  I don't need to do this for other types
>of interfaces... did I mess something up, is this how it is supposed to 
>be (doesn't seem to be documented as such).

I think that's how it is supposed to be given that gif's main function
is to tunnel things and it works on a point-to-point basis.

I might be wrong, in which case I am sure UMEMOTO-san or ITOJUN-san will
correct me.

-- 
Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org]
Documentation nutter/C-rated Coder BSD: Technical excellence at its best  
  D78D D0AD 244D 1D12 C9CA  7152 035C 1138 546A B867
What is to be, will be.  And what isn't to be sometimes happens...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Routing latency

[Devin Butterfield]

On Monday 19 March 2001  4:36, Will Andrews wrote:
> On Mon, Mar 19, 2001 at 07:46:53PM -0500, Dennis wrote:
> > I never got an answer (as usual) from bill paul when I made the
> > suggestions, and noone seemed interested in getting it fixed. He seems to
> > get insulted when I infer that he did something wrong.
>
> It's like they say: "money talks".  Similarly, "patches talk".
> Suggestions don't really do that.

I'm not defending Dennis here, but this statement infers that nothing gets 
done unless maintainers are

a) paid

or 

b) someone else does the work for them.

I certainly hope this is not the case.
--
Regards, Devin.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: tuning a VERY heavily (30.0) loaded s cerver

[thinker]

On Wed, Mar 21, 2001 at 04:14:32PM -0300, Rik van Riel wrote:
> The (maybe too lightweight) structure I have in my patch
> looks like this:
> 
> struct pte_chain {
>   struct pte_chain * next;
>   pte_t * ptep;
> };
> 
> Each pte_chain hangs off a page of physical memory and the
> ptep is a pointer to a page table entry.
> 
> The page struct of the page table page itself is used to
> note down which address space and offset we have. This means
> that FreeBSD's pv_pmap, pv_va and pv_ptem are in the page
> table page and NOT in each pte_chain structure...
How about portability? It maybe efficient, but it is not easy
to port to other platforms.
-- 
[EMAIL PROTECTED]   Branda Open Site (BOS)
[EMAIL PROTECTED]  http://www.branda.to/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Help please (Server crash)

[Dmitry Samersoff]

I have server under FreeBSD 4.2 with apache fired simple  C++ CGI for
each connection.

Aproximately every 12H uptime server stop responding.

Kernel answers to ping, establish TCP connection but unable to fork
process.
(no messages in /var/log/messages)


This is statisitics (netstat -nm & top ) just before crash.

Any ideas?

Thank you!

# Thu Mar 22 00:50:00 MSK 2001
# 4945/6928/40960 mbufs in use (current/peak/max):
#2604 mbufs allocated to data
#2341 mbufs allocated to packet headers
# 2530/3804/10240 mbuf clusters in use (current/peak/max)
# 9340 Kbytes allocated to network (30% of mb_map in use)
# 0 requests for memory denied
# 0 requests for memory delayed
# 0 calls to protocol drain routines
# last pid: 44768;  load averages:  0.47,  0.38,  0.35  up 0+10:24:07   
00:50:00
# 175 processes: 1 running, 163 sleeping, 11 zombie

# Mem: 22M Active, 35M Inact, 42M Wired, 6516K Cache, 35M Buf, 144M Free
# Swap: 500M Total, 6220K Used, 494M Free, 1% Inuse

-- 
Dmitry Samersoff, [EMAIL PROTECTED], ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Help please (Server crash)

[David Malone]

On Thu, Mar 22, 2001 at 03:33:14PM +0300, Dmitry Samersoff wrote:

> Any ideas?

With hangs like this using the debugger to find out what the kernel
is doing is often the best bet. You'll need to compile the debugger
into the kernel and then leave the server on a vty that doesn't
have X running. When it hangs try breakin into the debugger
(ctl-alt-esc) and get a trace (type trace). You may need to do
this a few times to get an idea of what's going on.

The kernel debugging section of the handbook has more details on
this sort of thing.

David.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Attemt to compile with INVARIANTS failed

[Dmitry Samersoff]

root@ds101:DS101#make
linking kernel.debug
vm_zone.o: In function `zalloci':
/sys/compile/DS101/../../vm/vm_zone.h:81: undefined reference to
`zerror'
/sys/compile/DS101/../../vm/vm_zone.h:91: undefined reference to
`zerror'
vm_zone.o: In function `zfreei':
/sys/compile/DS101/../../vm/vm_zone.h:106: undefined reference to
`zerror'
vm_zone.o: In function `_zget':
/sys/compile/DS101/../../vm/vm_zone.c:380: undefined reference to
`zerror'
*** Error code 1

-- 
Dmitry Samersoff, [EMAIL PROTECTED], ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Remote boot, but not diskless operation

[Fred Clift]

> 
> they've done this, but their newest BIOS (8 days old) still has a 0.78
> PXE revision (I've seen more recent DELL machines with a 0.99 - I assume
> this is better)

I have many intel MBs with built-in fxp nics that have 0.78 that work with
4.2's pxeboot just fine - I'm not trying to boot kernel remotely for local
filesystesm, but I can't see why it wouldn't work.  Off hand I'd guess
that you have to put the right options in your dhcp server to tell it to
find a 'local' root disk.  Good luck.

Fred

--
Fred Clift - [EMAIL PROTECTED] -- Remember: If brute 
force doesn't work, you're just not using enough.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: tuning a VERY heavily (30.0) loaded s cerver

[Rik van Riel]

On Thu, 22 Mar 2001, thinker wrote:
> On Wed, Mar 21, 2001 at 04:14:32PM -0300, Rik van Riel wrote:
> > The (maybe too lightweight) structure I have in my patch
> > looks like this:
> > 
> > struct pte_chain {
> > struct pte_chain * next;
> > pte_t * ptep;
> > };
> > 
> > Each pte_chain hangs off a page of physical memory and the
> > ptep is a pointer to a page table entry.
> > 
> > The page struct of the page table page itself is used to
> > note down which address space and offset we have. This means
> > that FreeBSD's pv_pmap, pv_va and pv_ptem are in the page
> > table page and NOT in each pte_chain structure...
>
> How about portability? It maybe efficient, but it is not easy
> to port to other platforms.

IIRC the pmap layer is in the architecture-dependent code in
the BSDs.  For Linux we have forward pagetables in every
architecture, whether it be in software or hardware.  They
turn out to be quite adequate as an alternative to vnodes ;)

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

http://www.surriel.com/
http://www.conectiva.com/   http://distro.conectiva.com.br/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

question about BPF programming

[Andrey Simonenko]

Hi

I read bpf(4) man page and have one question about BPF.
Suppose I open one of free BPF devices /dev/bpf??. I can dup(2)
descriptor of opened BPF device and get so called shared interface.

Can I setup different filters on each descriptor for opened BPF device?
If I can do it, how can I do the same with pcap(3) library?

Thanks for answers.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Intel driver doc's Take 2.

[scanner]

I just got off the phone with Linda Sanchez at our favorite company 
Intel. She is a Sr. "Marketing Engineer" (What is a marketing
engineer?) for their LAN products. She is itnerested in helping us get the
information we need to write drivers for their cards. But she also knows
NDA's are not going away. She wants to meet us halfway in the short
term. Somewhere between a datasheet and a programming manual, that we can
get with no NDA. I know alot of you are totally fed up with Intel and at
this point couldnt give two hoots about Intel or their cards. But she is
willing to work with us to get us what we need. I told her it sounds like
an all or nothing proposition that we NEED the programming manuals. Not
datasheets, not fluffy reference drivers. But for the short term that is
not going to happen. Sigh. She does want to try and help us like I said.


She need's specific information that we need that we cant get
unless we sign NDA's for the doc's so she can try and get them merged into
a reference product somewhere between the datasheet (worthless) and the
programming manual (NDA). I know this is not ideal or what bill, jonathon,
or others want. They would rather Intel just get a friggin clue and stop
being anal. And while in the long term this may change it isn't going to
be soon. She is willing to compromise and try and get us doc's on the bits
we need. 

Is anyone willing to try and work on a middle of the road to keep
support current for Intel nic's? Or has everyone decided to just not waste
the effort or time on Intel idiocy anymore? Either way is fine. It's not
like we only support one brand of NIC's. I'm just making an offer, the
only offer from Intel, to help work with OS developers. I completely
understand everyone's attitude towards Intel and I think it's totally
justified. And I am usually an all or nothing person. I don't do middle of
the road. But thats the offer on the table. Try and get us what we need in
manual in between the datasheet and the programming doc's. But it will be
available without an NDA. This is the option we currently have. Any
takers? If there are she want's me to collect specific item's that are
needed. Like the recent PHY debacle. What item's do we need programming
doc's on? Specific parts? Etc. In the long term maybe Intel will get a
clue but I am not holding my breath. But this is a chance to try and get
what we need under a non-NDA arrangement. So if anyone has any care
whatsoever to make one last effort to support Intel hardware and wants to
work on getting the information we need. Let me know. I *think* we can get
her to piecemeal the info we need into a non NDA doc for us, piece by
piece that is as good or better as the programming doc's. Anyway if there
are any takers that want to work with me on getting the doc's required let
me know. Otherwise i'm just like everyone else I dont have a 50 megaton
nuclear device to beat Intel with to get them to do the right thing. And
Intel support can be dropped.

=
-Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek 
Work:  [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas
Home:  [EMAIL PROTECTED] | http://open-systems.net
=
WINDOWS: "Where do you want to go today?"
LINUX: "Where do you want to go tomorrow?"
BSD: "Are you guys coming or what?"
=
irc.openprojects.net #FreeBSD -Join the revolution!
ICQ: 20016186


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[John Gregor]

Random idea from the peanut gallery...

Find someone who is NDA'd and knows both the programming manual and the
needs of the device driver.  Have that person compose a list of those bits
of the manual most necessary for getting a working driver.  This would
be an explicit list of figures, diagrams, tables and text sections.  I
would assume that Intel legal would then go through the list and give a
yea/nay for each item requested.  For the contested items, perhaps a
redacted/simplified version could be proposed instead, but hopefully the
bulk of the request would accepted.

Just my $0.02

-JohnG  (neither NDA'd or working on the driver)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Daniel C. Sobral]

[EMAIL PROTECTED] wrote:
> 
> She need's specific information that we need that we cant get
> unless we sign NDA's for the doc's so she can try and get them merged into
> a reference product somewhere between the datasheet (worthless) and the
> programming manual (NDA). I know this is not ideal or what bill, jonathon,
> or others want. They would rather Intel just get a friggin clue and stop
> being anal. And while in the long term this may change it isn't going to
> be soon. She is willing to compromise and try and get us doc's on the bits
> we need.

Let me just pipe in a bit. Compromise seems just like the kind of thing
marketing or legal would want to do. The problem is that _we_ cannot
compromise because one cannot write a "half-way there" driver. It's a
technical impossibility.

Now, if Bill Paul, Jonathan Lemon or whoever can come up with a
"compromise" that would work, fine. But otherwise, and I think otherwise
is likely, please explain the above to this person.

-- 
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

It's a rewarding life, but hey, somebody has to have all the fun,
right?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Jonathan Lemon]

In article 
[EMAIL PROTECTED]> 
you write:
>   She need's specific information that we need that we cant get
>unless we sign NDA's for the doc's so she can try and get them merged into
>a reference product somewhere between the datasheet (worthless) and the
>programming manual (NDA).

Well, I applaud your effort, but I can't really think of how this
would work.  The information in the programming manual is required 
to program the chip.  It is already a fairly concise manual, and if
you axe anything out of it, it would mean that feature wouldn't be
supported.

A programming manual generally looks something like the following
(completely made up) example:

   control register:offset 0, length 2 words
  bit 31:MWI enable
  bit 29-30: duplex settings
  00 = full duplex
  01 = half duplex
  1x = auto negotiate
In order for duplex settings to take effect, the chip must
first be be reset to idle state, then the link settings changed 

  bit 28:receiver enable
  0 = disable
  1 = enable
before enabling the receiver, the receive control register
must be set up appropriately, as well as the receive ring 
base and length registers.

  

Exactly what in the above (fictional) example is it possible to axe
out and still come up with a functional driver?  Descriptions of each
bit and their position in the register?  The rules/caveats associated 
with each bit?

I hate to say it, but anything that gets axed out of the manual basically
means that those features of the chip will not be used.  I honestly don't
think that the marketer you talked to really understands this; I can't 
for the life of me see how anything less than the programming manual 
will be sufficient.
--
Jonathan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[scanner]

On Fri, 23 Mar 2001, Daniel C. Sobral wrote:

> Let me just pipe in a bit. Compromise seems just like the kind of thing
> marketing or legal would want to do. The problem is that _we_ cannot
> compromise because one cannot write a "half-way there" driver. It's a
> technical impossibility.

I agree 100%. I don't think this will fly either. I am just making the
effort to work with Intel to get what we need. It's not going to happen
overnight. Period. They are not going to change their NDA policy. In the
future maybe. Actually I will forward the email she sent me this last time
after I got off the phone with her an hour ago. I mentioned the problems
Jonathan had with the GigE card. That's why she refers to him. Anyway I
will forward it in a sec to the list.

> Now, if Bill Paul, Jonathan Lemon or whoever can come up with a
> "compromise" that would work, fine. But otherwise, and I think otherwise
> is likely, please explain the above to this person.

Well I have a feeling if bill even reads this, which he will probably see
Intel in the subject and delete it, or has a procmail filter for 'Intel'
:-) he will probably just get more frustrated then he is. Jonathan, I dont
know. He is probably as fed up as everyone else.

=
-Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek 
Work:  [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas
Home:  [EMAIL PROTECTED] | http://open-systems.net
=
WINDOWS: "Where do you want to go today?"
LINUX: "Where do you want to go tomorrow?"
BSD: "Are you guys coming or what?"
=
irc.openprojects.net #FreeBSD -Join the revolution!
ICQ: 20016186


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Help please (Server crash)

[Aleksandr A.Babaylov]

Dmitry Samersoff writes:
> I have server under FreeBSD 4.2 with apache fired simple  C++ CGI for
> each connection.
> 
> Aproximately every 12H uptime server stop responding.
> 
> Kernel answers to ping, establish TCP connection but unable to fork
> process.
> (no messages in /var/log/messages)
Looks like you reach some of limits,
may be maxproc for user httpd runs as.

-- 
@BABOLO  http://links.ru/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: information on Intel Fast Ethernet and Gigabit (fwd)

[scanner]

-- Forwarded message --

Hello Mr. Chris Watson

Thanks for taking the time to discuss with me your concerns.
Could you take the the time to forward me some sort of representative list
of the types of information that FreeBSD developers require to do driver
development?
Would like to focus on the pieces not covered by data sheet and non-NDA type
documentation that you are using today, as we discussed.

I would like to review this list and see if there's something that we can
do about this.

Also could you forward me more specific info on the issues with the FreeBSD
driver written by J. Lemon.  I would like to see what I can do to help out
with these
issues too.

In the meantime, if you have any questions, please do not hesitate to call
me.

Thanks
Linda P. Sanchez 
Sr. Product Marketing Engineer 
Network Communications Group 
LAN Access Division 



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Matthew Jacob]

For what it's worth, I believe I'm still committed to work on the GigE driver.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Matthew Jacob]

btw- *I* have no problem with an NDA as long as it includes a rider that says
what we could release as open source.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Jonathan Lemon]

In article 
[EMAIL PROTECTED]> 
you write:
>
>btw- *I* have no problem with an NDA as long as it includes a rider that says
>what we could release as open source.

Hah, me neither.  In fact, if you want to try out a binary of my
Intel GigE driver, it is at http://www.flugsvamp.com/~jlemon/fbsd/drivers
--
Jonathan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Matthew Jacob]

> [EMAIL PROTECTED] wrote:
> > 
> > She need's specific information that we need that we cant get
> > unless we sign NDA's for the doc's so she can try and get them merged into
> > a reference product somewhere between the datasheet (worthless) and the
> > programming manual (NDA). I know this is not ideal or what bill, jonathon,
> > or others want. They would rather Intel just get a friggin clue and stop
> > being anal. And while in the long term this may change it isn't going to
> > be soon. She is willing to compromise and try and get us doc's on the bits
> > we need.
> 
> Let me just pipe in a bit. Compromise seems just like the kind of thing
> marketing or legal would want to do. The problem is that _we_ cannot
> compromise because one cannot write a "half-way there" driver. It's a
> technical impossibility.

No, no, no, no, no.

You can write an open source driver that contains all the basic features one
would want (i.e., Networking works). But advanced features in the manuals that
a company considers valuable IP might not be open sourced (e.g., vlan tagging,
teaming, crc offloading). Frankly, that's dumb, but as long as the basic
reasonable support for a NIC is there I believe that meets a reasonable
'support' test.

> 
> Now, if Bill Paul, Jonathan Lemon or whoever can come up with a
> "compromise" that would work, fine. But otherwise, and I think otherwise
> is likely, please explain the above to this person.
> 
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Matthew Jacob]

> 
> I hate to say it, but anything that gets axed out of the manual basically
> means that those features of the chip will not be used.  I honestly don't
> think that the marketer you talked to really understands this; I can't 
> for the life of me see how anything less than the programming manual 
> will be sufficient.

You should be allowed the whole manual, but some list of what can be made
visible should not be all that hard to do- certainly after you've looked over
the manual and you work with Intel to figure what is and isn't releasable.

I have a personal contact with a manager in the LAN group at Intel who I'm
visiting this weekend. We'll see if he has some influence in this matter.

-matt



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Jonathan Lemon]

On Thu, Mar 22, 2001 at 10:39:58AM -0800, Matthew Jacob wrote:
> > 
> > I hate to say it, but anything that gets axed out of the manual basically
> > means that those features of the chip will not be used.  I honestly don't
> > think that the marketer you talked to really understands this; I can't 
> > for the life of me see how anything less than the programming manual 
> > will be sufficient.
> 
> You should be allowed the whole manual, but some list of what can be made
> visible should not be all that hard to do- certainly after you've looked over
> the manual and you work with Intel to figure what is and isn't releasable.

Sure.  If intel would simply say:

   " we don't want the driver to support cisco ISL, checksum offloading,
 VLAN, or Wake On Lan features "

I suppose I could work with that. 
--
Jonathan

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: 4.3-BETA world crashing 4.2-RELEASE kernel ?

[Matt Simerson]

> -Original Message-
> From: David O'Brien [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, March 21, 2001 8:41 PM
> To: Matt Simerson
> Cc: [EMAIL PROTECTED]
> Subject: Re: 4.3-BETA world crashing 4.2-RELEASE kernel ?
>  
> First let me say to anyone reading the email I am replying to: 
> 
> don't do this
>
> On Wed, Mar 21, 2001 at 12:58:04PM -0700, Matt Simerson wrote:
> >   # cd /usr/src
> >   # make buildkernel KERNEL= 
> >   # cd /usr/src; make buildworld
> >   # make installworld
> >   # make installkernel
> >   # mergemaster
> >   # reboot
> 
> The order or "make buildworld" and "make buildkernel" are 100% totally
> BACKWARDS.

Actually, they aren't backwards. You've gone and snipped the parts of my
original message that show that the commands are being executed at the same
time. If either fails (for one reason or another as may happen) then I'll be
able to plainly see why the build failed and correct it or go about fixing
it manually.

> Lets explain why:  There are times when the kernel source is changed to
> use constructs of newer compiler/assembler/linker tools. Thus the kernel
> will not build with an older set of tools.  The what "make buildkernel"
> does is use the tools (ie, those built from the most up to date sources)
> that are built during "make buildworld" to compile a new kernel.  Thus
> "make buildworld" must PROCEED "make buildkernel".

Maybe I'm understanding you incorrectly here but according to what you just
said, a "make buildkernel" will fail unless you have a set of
compiler/assembler/linker tools in /usr/obj that were built from the make
buildworld process. This is inaccurate at best and I suspect it's just plain
wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make
buildkernel KERNEL=" and it will succeed and build a happy little
fully functionaly kernel. I've done this hundreds of times with success.

So, I guess I'm not understanding your logic here. Would you care to explain
further why this doesn't work?

> Second, the install order above is not the conservative, careful
> approach.  One should issue "make installkernel && reboot" after the
> "make buildkernel" to ensure the new kernel works 
> sufficiently well. 

Maybe that's _YOUR_ method for installing but it's not necessarily the best
one. Kernel's are not guaranteed to be backwards compatible and I've
installed a shiny new kernel that worked just fine and allowed my machine to
come up single user but because of some rude change in /etc/rc, ipfw, or any
of a number of places the machine couldn't make it to multi-user and allow
me to get back in (via the network). When most of your servers are in a
data-center 50 miles away and the rest are thousands of miles away, you'd
rather not spend the next two hours talking a NOC monkey through a 10 minute
process (if you have console). I prefer to do everything possible to make
sure the system is going to boot correctly the first time and let me regain
access. Success at building and installing the kernel, world, AND running
mergemaster gives me a reasonably good chance that when I issue the reboot,
it'll come up nice and happy.

Second, if I'm going through the bother of compiling a buildworld it's
because I want the latest version of world on my system. If there are some
problems with the new kernel, I'm not going to revert back to world.old.
I'll fix whatever is screwed up with kernel and proceed.

Last, but not least, is that I don't have a warm body near all of my
servers. I often want to do the make buildworld & kernel, installworld &
kernel, and mergemaster and NOT reboot. Then I'll pop an email off to a warm
body nearby and, at his leisure, have him give it a CTRL-ALT-DEL on the
console and watch it to make sure it comes back up.

> If not, one can always fall back to ``kernel.old''. 

One can fall back to kernel.old regardless. Even if I happen to have
world.new installed, kernel.old will still work. There may be issues but if
there is, they are surely no worse than running kernel.new with world.old.
So, which is worse, the cart without a horse or a horse without a cart? 

> Since there is no
> ``world.old''; after one does the "make installworld" backup tapes are
> the only way of taking the system back to its previous state.

I don't know many people who do buildworlds just for fun. If I'm doing a
buildworld it's because I want the newer world installed. If I'm doing it on
a server, it's because I've tested it on a dev box and I know it works the
way I want. At that point, I have no reason to fall back to the previous
world.

Matt

> -- 
> -- David  ([EMAIL PROTECTED])
>   GNU is Not Unix / Linux Is Not UniX


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 4MB pages

[Alfred Perlstein]

* Terry Lambert <[EMAIL PROTECTED]> [010322 11:47] wrote:
> I know that this is going to look like I should have posted it
> on the "-arch-questions" list, but there isn't one, and it
> involves future work (I think), so here goes...
> 
> 
> Has anyone tried playing with 4MB pages for doing other things?
> 
[snip]

> As usual, I'm playing with 4.x, not 5.x, so feel free to tell
> me that this has already been thought of, and therefore is not
> an issue for -arch.

I think -hackers is more appropriate.

As far as using 4MB pages, it would be nice to be able to add
it for:

1) shm segements
2) mlock'd regions.

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Represent yourself, show up at BABUG http://www.babug.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: Attemt to compile with INVARIANTS failed

[John Baldwin]

On 22-Mar-01 Dmitry Samersoff wrote:
> 
> root@ds101:DS101#make
> linking kernel.debug
> vm_zone.o: In function `zalloci':
> /sys/compile/DS101/../../vm/vm_zone.h:81: undefined reference to
> `zerror'
> /sys/compile/DS101/../../vm/vm_zone.h:91: undefined reference to
> `zerror'
> vm_zone.o: In function `zfreei':
> /sys/compile/DS101/../../vm/vm_zone.h:106: undefined reference to
> `zerror'
> vm_zone.o: In function `_zget':
> /sys/compile/DS101/../../vm/vm_zone.c:380: undefined reference to
> `zerror'
> *** Error code 1

INARIANTS requires INVARIANT_SUPPORT, there is a note to this effect in LINT.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: tuning a VERY heavily (30.0) loaded s cerver

[Michael C . Wu]

Just an update on the lovely loaded BBS server. 
We made our record-breaking number of users last night.

After implementing the changes suggested, and kqueue'ifying 
the BBS daemon.  We saw a dramatic increase in server power.

Top number of users was 4704 users.  Serving SSH, HTTP, SMTP, innd, BBSD
with no delays.  (Meanwhile, we had kernel profiling ON :) )
We had peak load averages of 100.0, read: no delay.  I am certain
that we could taken on 6000 users had we had that many users.
(It died due to unrelated reason, not because of the load since the
number of users had gone down to 4400.)   iostat became a fraction of what
it used to be before we set vfs.vmiodirenable=1.

(Why is vfs.vmiodirenable=1 not enabled by default?)

We used to die at about 4200 users with average loads of 200.0 even 300.0
For those still interested in kq'ed BBSD stats:
http://zoo.ee.ntu.edu.tw/~keichii

I'm ponder if this should have been posted to FreeBSD-Advocacy. :^)

-- 
+---+
| [EMAIL PROTECTED] | [EMAIL PROTECTED]   |
| http://iteration.net/~keichii | Yes, BSD is a conspiracy. |
+---+

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: tuning a VERY heavily (30.0) loaded s cerver

[Alfred Perlstein]

* Michael C . Wu <[EMAIL PROTECTED]> [010322 12:29] wrote:
> Just an update on the lovely loaded BBS server. 
> We made our record-breaking number of users last night.
> 
> After implementing the changes suggested, and kqueue'ifying 
> the BBS daemon.  We saw a dramatic increase in server power.
> 
> Top number of users was 4704 users.  Serving SSH, HTTP, SMTP, innd, BBSD
> with no delays.  (Meanwhile, we had kernel profiling ON :) )
> We had peak load averages of 100.0, read: no delay.  I am certain
> that we could taken on 6000 users had we had that many users.
> (It died due to unrelated reason, not because of the load since the
> number of users had gone down to 4400.)   iostat became a fraction of what
> it used to be before we set vfs.vmiodirenable=1.
> 
> (Why is vfs.vmiodirenable=1 not enabled by default?)

It's not a good thing for boxes with < 128megs of ram IMO.
It wastes a bunch of ram.

When I get a chance I'm going to look at having FreeBSD auto tune
such things as maxusers and things like vfs.vmiodirenable for 
large installs.

Actually, i'm tempted to change the defaults for large installs
then leave the "optimizations" for small machines to the people
who have small machines. :)

> We used to die at about 4200 users with average loads of 200.0 even 300.0
> For those still interested in kq'ed BBSD stats:
> http://zoo.ee.ntu.edu.tw/~keichii
> 
> I'm ponder if this should have been posted to FreeBSD-Advocacy. :^)

Why not write up an article about this BBS scene and get it posted
to slashdot or daemonnews?  It would really make good press:

  "FreeBSD community responds to BBS problem with spectacular results."

or something. :)

-- 
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Intel driver doc's Take 2.

[Mike Smith]

> On Fri, 23 Mar 2001, Daniel C. Sobral wrote:
> 
> > Let me just pipe in a bit. Compromise seems just like the kind of thing
> > marketing or legal would want to do. The problem is that _we_ cannot
> > compromise because one cannot write a "half-way there" driver. It's a
> > technical impossibility.
> 
> I agree 100%. I don't think this will fly either. I am just making the
> effort to work with Intel to get what we need. It's not going to happen
> overnight. Period. They are not going to change their NDA policy. In the
> future maybe. Actually I will forward the email she sent me this last time
> after I got off the phone with her an hour ago. I mentioned the problems
> Jonathan had with the GigE card. That's why she refers to him. Anyway I
> will forward it in a sec to the list.

[Speaking here from some experience with this set of issues.]

The compromise that you want to strike, and really the *only* compromise 
that is going to work, is that the *documents* will remain undisclosed, 
but information from the documents that is necessary to produce a 
functional, high-performance driver may be disclosed, but *only* through
the source code of the driver.

Thus one or a small group of people sign the NDA, and keep the
documentation.  The driver is then developed and maintained by this team, 
who also have the opportunity to interact with Intel's engineering 
people.  The source code resulting from this effort is then released 
publically.  Intel should probably retain the right to veto code that you 
might want to put in the driver if they feel that it risks disclosure 
they don't want, but you don't have to suggest this to them unless you 
feel you need it as a bargaining chip.

This would put them in the same situation as they are already in with 
their source-available Linux driver; it should not present any more 
intellectual property risks than they already face, and as a bonus, it 
gets us a better-supported driver.

Regards,
Mike


-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: 4.3-BETA world crashing 4.2-RELEASE kernel ?

[John Baldwin]

On 22-Mar-01 Matt Simerson wrote:
>> Lets explain why:  There are times when the kernel source is changed to
>> use constructs of newer compiler/assembler/linker tools. Thus the kernel
>> will not build with an older set of tools.  The what "make buildkernel"
>> does is use the tools (ie, those built from the most up to date sources)
>> that are built during "make buildworld" to compile a new kernel.  Thus
>> "make buildworld" must PROCEED "make buildkernel".
> 
> Maybe I'm understanding you incorrectly here but according to what you just
> said, a "make buildkernel" will fail unless you have a set of
> compiler/assembler/linker tools in /usr/obj that were built from the make
> buildworld process. This is inaccurate at best and I suspect it's just plain
> wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make
> buildkernel KERNEL=" and it will succeed and build a happy little
> fully functionaly kernel. I've done this hundreds of times with success.
> 
> So, I guess I'm not understanding your logic here. Would you care to explain
> further why this doesn't work?

Hmm, maybe because you've been lucky to have done it wrong?  Case in point: for
4.1 release, we upgraded to a new set of binutils (assembler, linker, etc.). 
Because the old asssembler was so broken, the new assembler could not compile
the old code that had hacks in it to work around the bugs in the old assembler.
Thus, if you tried to build a kernel without building world with the new
assembler, the compile would fail.  Thus, one needs to do the buildworld first
to ensure the tools to compile the kernel are up to date.  Please go read the
archives if you want more of the hairy details.  The process David described
(which is the one that is in src/UPDATING) is the one that is supported.  Other
methods may work some of the time, but they won't work all of the time, and if
it breaks for you it is your fault for not following the rather clear
instructions that have been provided. :)

>> Second, the install order above is not the conservative, careful
>> approach.  One should issue "make installkernel && reboot" after the
>> "make buildkernel" to ensure the new kernel works 
>> sufficiently well. 
> 
> Maybe that's _YOUR_ method for installing but it's not necessarily the best
> one. Kernel's are not guaranteed to be backwards compatible and I've

Breakges of this time or very rare, and only in -current that I can remember. 
In fact, the only bad ones I've seen are when struct ucred changes causing
mountd to start doing stupid things, but that has been permamently fixed in
-current.  However, as other people have pointed out, it is much easier to boot
kernel.old if your new kernel is hosed and use that stable kernel to fix either
the new kernel or the new world as appropriate.  Really, if you wish to blow
your own foot off that is fine, but do be aware that a) you shouldn't tell
others to blow their feet off, and b) if you blow your own feet off it's your
fault. :)

In fact, if you are careful, you will note that src/UPDATING recommends that
you do the installworld and /etc update in single user mode, not multiuser,
which would avoid the problems you have seen with new kernels and old worlds.

>> If not, one can always fall back to ``kernel.old''. 
> 
> One can fall back to kernel.old regardless. Even if I happen to have
> world.new installed, kernel.old will still work. There may be issues but if
> there is, they are surely no worse than running kernel.new with world.old.
> So, which is worse, the cart without a horse or a horse without a cart?
> 
>> Since there is no
>> ``world.old''; after one does the "make installworld" backup tapes are
>> the only way of taking the system back to its previous state.
> 
> I don't know many people who do buildworlds just for fun. If I'm doing a
> buildworld it's because I want the newer world installed. If I'm doing it on
> a server, it's because I've tested it on a dev box and I know it works the
> way I want. At that point, I have no reason to fall back to the previous
> world.

You don't run -current much it seems. :)  (Not that I blame you, it is not for
production machines.)  The procedure described is the most robust one that has
been come up with thus far.  It has the greatest chance of success, though it
is also somewhat painful (installworld in single user for example).  You can do
it differently if you wish (I do), but realize that if you do, you are on your
own.

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: 4.3-BETA world crashing 4.2-RELEASE kernel ?

[David O'Brien]

On Thu, Mar 22, 2001 at 12:51:00PM -0700, Matt Simerson wrote:
> Actually, they aren't backwards. You've gone and snipped the parts of my
> original message that show that the commands are being executed at the same
> time.

I read you message twice and came away with the same idea.  You should
write more clearly.


> Maybe I'm understanding you incorrectly here but according to what you just
> said, a "make buildkernel" will fail unless you have a set of
> compiler/assembler/linker tools in /usr/obj that were built from the make
> buildworld process. This is inaccurate at best and I suspect it's just plain
> wrong. I can "rm -r /usr/obj/*", "cd /usr/src; make clean", and then "make
> buildkernel KERNEL=" and it will succeed and build a happy little
> fully functionaly kernel. I've done this hundreds of times with success.

The ability to do a `make buildkernel' with an empty /usr/obj is a new
feature.  But back to your misunderstanding.  What part about "if the
kernel source is changed to use language features not supported by the
existing installed tools, you cannot build a kernel with them" do you not
understand??

You obviously was not active when 4.x upgraded Binutils from 2.9.1 to
2.10.0 and the many of the asm bits were changed at the same time to
remove work arounds and bogusness done to satisfy Binutils 2.9.1.


> > Second, the install order above is not the conservative, careful
> > approach.  One should issue "make installkernel && reboot" after the
> > "make buildkernel" to ensure the new kernel works 
> > sufficiently well. 
> 
> Maybe that's _YOUR_ method for installing but it's not necessarily the best
> one. Kernel's are not guaranteed to be backwards compatible and I've
> installed a shiny new kernel that worked just fine and allowed my machine to
> come up single user but because of some rude change in /etc/rc, ipfw, or any
> of a number of places the machine couldn't make it to multi-user and allow
> me to get back in (via the network).

That you're doing this remotely is your problem.  Ask any of the
developers living on -CURRENT where often one wants to back out of a
newly compiled world.  The method I gave is the most sure and careful
way.  That you don't have consoles on your machines so you could do this
properly doesn't mean what I posted isn't the safest and should be
followed unless has special needs.


> Success at building and installing the kernel, world, AND running
> mergemaster gives me a reasonably good chance that when I issue the reboot,
> it'll come up nice and happy.

I'm happy for you.  But you have major flaws in your method where
problems can bite you hard.  As I said, I want users to know and use the
safest method.  I've seen enough email from users that were all confused
about the right steps -- often getting confused from posts such as yours
where you [hopefully] understand the consequences of your method and can
deal with them.  Many do not want to or cannot.


> Second, if I'm going through the bother of compiling a buildworld it's
> because I want the latest version of world on my system.

Want != ability.  I want a latest version of 5-CURRENT on my laptop, but
CardBus is broken right now, so I am living with a Dec world.  Such is
life.


> If there are some problems with the new kernel, I'm not going to revert
> back to world.old.  I'll fix whatever is screwed up with kernel and
> proceed.

Oh!  Want a job as a kernel hacker then?  I'd like to have my CardBus
working again (in current).  Also my AHA-2930u2 on a K6-2 machine...
 
-- 
-- David  ([EMAIL PROTECTED])
  GNU is Not Unix / Linux Is Not UniX

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: tuning a VERY heavily (30.0) loaded s cerver

[Alexey V. Neyman]

hello there!

On Thu, 22 Mar 2001, Michael C . Wu wrote:

>(Why is vfs.vmiodirenable=1 not enabled by default?)
By the way, is there any all-in-one-place description of sysctl tuneables?
Looking all the man pages and collecting notices about MIB variables seems
rather tiresome and, I think, pointless. I doubt if they are all
documented in man pages.

# Alexey



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: tuning a VERY heavily (30.0) loaded s cerver

[Matt Dillon]

:(Why is vfs.vmiodirenable=1 not enabled by default?)
:

The only reason it isn't enabled by default is some unresolved
filesystem corruption that occurs very rarely (with or without
it) that Kirk and I are still trying to nail down.  I want to get
that figured out first.

It is true that some people have brought up memory use issues, but
I don't consider memory use to really be that much of an issue.  This is
a cache, after all, so the blocks can be reused at just about
any time.  And directory blocks do not get cached
well at all with vmiodirenable turned off.  So the net result
should be an increase in performance even on low-memory boxes.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

The "right" way to build a new world WAS: 4.3-BETA worldcrashin g 4.2-RELEASE kernel ?

[Matt Simerson]

OK, let's approach this from a little different angle:

Below is the appropriate entries from /usr/src/UPDATING on a FreeBSD
4-stable machine. As of 2/2/2001, the most correct and safest method for
updating your FreeBSD machine is as follows:

   cd /usr/src
   make buildworld
   make kernel KERNCONF=
   reboot (single user)
   make installworld
   mergemaster
   reboot

I have found that there IS a variety of reasons NOT to do it that way. The
most obvious is that you might not have console access, thus making it
pretty hard to access the machine while it's in single user mode. I can also
think of a couple instances where this method could cause pain. 

The first is changing of any of the files used at boot time. I don't allow
telnet access to any of my machines so SSH is often as close as I can get to
console. If anything changes enough that we don't cleanly make it through rc
and friends, processing stops, sshd won't be running and I can't get in. The
one time this happened the machine didn't make it multi user. Fortunately
that machine was in my basement so I walked down, looked at the errors on
the console and finished the upgrade.

IPFW changes. This one isn't quite obvious but if you don't compile your
kernel with IPFW_DEFAULT_TO_ACCEPT and changes are made to the kernel or
userland portions and not the other (as will happen in the above scenario)
then upon reboot, if your ruleset doesn't get applied, you won't be able to
access your machine via the network. Ouch. I always compile in the
DEFAULT_TO_ACCEPT for this reason and then add a default deny rule to the
IFPW ruleset. Even so, I find it's best to get my kernel, world, and config
files synced before rebooting.

Changes like that aren't terribly infrequent and if you aren't paying
attention, can bite you. This (and a few other things) have prompted me to
completely skip the first reboot. Also, I tend to keep everything I use in a
location (/usr/local) other than the default places installworld wants to be
touching. So, I can almost always get away with doing an installworld
without changing my runlevel. The last thing, which is seldom mentioned but
which I habitually do is another make installkernel after the system comes
back up and is happy. The reason(s) should be obvious. So, my procedure
looks a lot like this:

   cd /usr/src
   make buildworld
   make kernel KERNCONF=
   make installworld
   mergemaster
   reboot
   cd /usr/src
   make installkernel KERNEL=
 
One can also often get away with making a new kernel without first building
world but do so at your own peril (as I often do). :-)  I often issue the
buildkernel and buildworld at the same time and then leave for the day. My
reasons for doing this are: laziness, impatience, and wanting to have the
entire compilation done when I return. Doing so can be risky but in my
experience, works just fine with the -stable tree. Others have been quick to
point out the possible hazards of doing so but they mostly apply when
playing with -current.

Matt


>From /usr/src/UPDATING (on FreeBSD 4-STABLE):
  
COMMON ITEMS:

To build a kernel
-
cd /usr/src
# If you have not already done so, please buildworld here
# You will also need to update your config file to 4.x.  Usually
# people tend to start with GENERIC from 4.x and hack from there.
make buildkernel KERNCONF=
make installkernel  KERNCONF=
# Verify that the new kernel works, it will be installed as
# /kernel

To rebuild disk /dev entries

MAKEDEV should be copied from src/etc/MAKEDEV to /dev before
starting the following:

For N in the list of disks
MAKEDEV N   # eg ad0
for M in the list of slices
MAKEDEV NsMa# eg ad0s1a


To rebuild everything
-
make world

Except when it doesn't work :-)

   

To update from 4.0-RELEASE or later to the most current
4.x-STABLE
--
make buildworld
make buildkernel KERNCONF=YOUR_KERNEL_HERE
make installkernel KERNCONF=YOUR_KERNEL_HERE
reboot  (in single user) [1]
make installworld
mergemaster
reboot

[1] You can often get away without doing this step as the
system will be properly updated.  During the running of the
installworld, however, system components may break and other
oddities may happen.  Don't do this on systems that aren't
otherwise quiet as unpredictable results may happen.  If in
doubt, reboot into single user.  For remote installs, keep
a separate kernel around and use a serial console if at all
possible.




> -Original Message-
> From: David O'Brien [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 22, 2001 12:

Re: Intel driver doc's Take 2.

[Sergey Babkin]

Jonathan Lemon wrote:
> 
> In article 
>[EMAIL PROTECTED]>
> you write:
> >   She need's specific information that we need that we cant get
> >unless we sign NDA's for the doc's so she can try and get them merged into
> >a reference product somewhere between the datasheet (worthless) and the
> >programming manual (NDA).
> 
> Well, I applaud your effort, but I can't really think of how this
> would work.  The information in the programming manual is required
> to program the chip.  It is already a fairly concise manual, and if
> you axe anything out of it, it would mean that feature wouldn't be
> supported.

How about meeting half-way in a different way ? Suppose they provide
the manual with NDA but in the NDA agreement they state that
the source code of the driver developed using this manual may
be published. To reiterate, the manual itself would still be their
trade secret but the results of development done based on this
manual would be free. 

-SB

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

RE: The "right" way to build a new world WAS: 4.3-BETA world cra

[John Baldwin]

On 23-Mar-01 Matt Simerson wrote:
> OK, let's approach this from a little different angle:
> 
> Below is the appropriate entries from /usr/src/UPDATING on a FreeBSD
> 4-stable machine. As of 2/2/2001, the most correct and safest method for
> updating your FreeBSD machine is as follows:
> 
>cd /usr/src
>make buildworld
>make kernel KERNCONF=
>reboot (single user)
>make installworld
>mergemaster
>reboot
> 
> I have found that there IS a variety of reasons NOT to do it that way. The
> most obvious is that you might not have console access, thus making it
> pretty hard to access the machine while it's in single user mode. I can also
> think of a couple instances where this method could cause pain. 

All of the ones you list below are not a problem if one has a serial console
(single user implies console access). :)  It _is_ the safest and most correct
way, but it's not always convenient and/or feasible.  And while you can deviate
from it, you should only do so once you are comfortable with the process and
know how to get yourself out of a jam if it blows up in your face.  New users
don't have all this background yet, so following the directions above is the
best thing for them to do.  Make sense?

-- 

John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: SCSI-over-* hacks

[John Polstra]

In article ,
Max Khon  <[EMAIL PROTECTED]> wrote:
> hi, there!
> 
> On Tue, 20 Mar 2001, Mike Smith wrote:
> 
> > > Has anyone implemented/thought of implementing:
> > >   - a CAM transport for ATAPI devices;
> > 
> > Yes.  It's not a lot of work.
> 
> that would be GREAT for cd recording on IDE CD-RW (one will be able to
> use cdrdao and cdrecord instead of burncd)

Yes!  It would definitely be nice if cdrecord worked with ATAPI
CD-RW drives on FreeBSD.

John, who just bought an ATAPI CD-RW drive
-- 
  John Polstra   [EMAIL PROTECTED]
  John D. Polstra & Co., Inc.Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message