Re: Hi,All

[Maxim Sobolev]

Liu Siwei wrote:
> 
> Hi,All:
>I love FreeBSD! But.. Can it support CD-RW disc and Simplie Chinese
> Filename? A lot of files in CD-ROM that have Chinese name, how can i open it
> under FreeBSD? Oh...Oh

What is the official name for Simplie Chinese codepage? If it is a
1-byte charset, then I could probably add support for it into
cd9660_unicode ports, which would allow accessing files with such
filenames on them.

-Maxim

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

Re: Motion for removal of xargs(1) from base system

[Ruslan Ermilov]

On Mon, Dec 10, 2001 at 02:13:35PM -0800, Jackie 'business-first' Cook wrote:
> There are days when people get tired with the lagacy code in the system - when
> things of the past just have to go. Recently I got sick and tired with one of
> those things. The command is, as you could have guessed from the subject,
> xags(1) aka /usr/bin/xargs. It is buggy and cluttered piece of code. Faulty and
> hard to use command. It's idiosyncratic syntax makes people dizzy everytime they
> use/or just try to use it.
> 
It's also a part of just ratified POSIX.1-2001 standard.


-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

XF86 with agp.ko and mga.ko

[Jun Kuriyama]

I'm using XFree86-Server-4.1.0_2 and drm-kmod-0.9.4 with

-
module_path="/;/boot;/modules;/usr/local/lib/drm"
agp_load="YES"
mga_load="YES"
linux_load="YES"
-

lines in /boot/loader.conf.

World at 2001/12/10 is fine for me, but after installworld'ing of
today's world (2001/12/12) my X server is slowed down.

My kernel shows too many lines to console like this:

-
Dec 12 17:06:03 waterblue kernel: error: [drm:mga_dma_flush] *ERROR* mga_dma_flush 
called without lock held
Dec 12 17:06:03 waterblue kernel: error: [drm:mga_dma_reset] *ERROR* mga_dma_reset 
called without lock held
-

I re-installed XFree86-Server and drm-kmod but X is still really slow.
I'm using X without mga.ko (this shows reasonable speed).

Does anyone know any hints about this?


-- 
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
 <[EMAIL PROTECTED]> // FreeBSD Project

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

[OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Andrew Kenneth Milton]

+---[ Terry Lambert ]--
|
| RMS has indicated a willingness to sue people distributing bipartite
| distributions, where the linking is delayed until installation to
| work around the letter of the GPL.  Given his religious convictions,
| I can't see him *not*.  Factor that into your decision.

Just to balance this point out;

Only the copyright holder can do this, what code of any significance has 
RMS contributed recently to this or any other project where this would be 
a consideration?

Not everyone has the religious conviction of RMS. In 1983 RMS promised a
kernel for GNU too, it hasn't arrived yet. He talks a lot. Remeber to 
factor that into your decisions d8)

-- 
Totally Holistic Enterprises Internet|  | Andrew Milton
The Internet (Aust) Pty Ltd  |  |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| 

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

Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Andrew Kenneth Milt
on writes:
>+---[ Terry Lambert ]--
>|
>| RMS has indicated a willingness to sue people distributing bipartite
>| distributions, where the linking is delayed until installation to
>| work around the letter of the GPL.  Given his religious convictions,
>| I can't see him *not*.  Factor that into your decision.
>
>Just to balance this point out;
>
>Only the copyright holder can do this, what code of any significance has 
>RMS contributed recently to this or any other project where this would be 
>a consideration?

Uh, people have been signing their copyright over to FSF for a long
time...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Hiten Pandya]

hi,
why would RMS sue, lets say me, for porting IBM's
piece of GPL'ed code to FreeBSD src/gnu.

What i will be doing (if the votes come out positive),
will be exactly as how his law says...


--- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message
> <[EMAIL PROTECTED]>,
> Andrew Kenneth Milt
> on writes:
> >+---[ Terry Lambert ]--
> >|
> >| RMS has indicated a willingness to sue people
> distributing bipartite
> >| distributions, where the linking is delayed until
> installation to
> >| work around the letter of the GPL.  Given his
> religious convictions,
> >| I can't see him *not*.  Factor that into your
> decision.
> >
> >Just to balance this point out;
> >
> >Only the copyright holder can do this, what code of
> any significance has 
> >RMS contributed recently to this or any other
> project where this would be 
> >a consideration?
> 
> Uh, people have been signing their copyright over to
> FSF for a long
> time...
> 
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be
> explained by incompetence.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of
> the message


=
-Hiten,

Thank You,
Yours Sincerely,
Hiten Pandya,
<[EMAIL PROTECTED]>


__
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com

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

pam_ssh support for static PAM library

[Ruslan Ermilov]

Hi!

There's a number of build problems exists with libssh, pam_ssh,
and libpam triple.  The major issue being that the static PAM
library, libpam.a, doesn't currently support pam_ssh.

There have been a semi-private discussion taking place between
me and Mark Murray on the subject, and I've prepared a set of
patches to address these issues.

First approach proposed was to make libssh a "standard" FreeBSD
library, in that sense that it has its name in bsd.libnames.mk
namespace, and is installable under /usr/lib, and is available
for dynamic linking.  This approach was rejected, because
libssh is believed to be of no common interest to be available
under /usr/lib, in that sense when we call such a library
"internal".

The latest patch on the subject is believed to fix all these
issues, while still preserving libssh from being visible under
/usr/lib.

I've already sent a notification to Mark, and he promised to
look into my patch during the next week or so.

For those also interested, I've put my patch and the detailed
log here:

http://people.FreeBSD.org/~ru/patches/libssh.patch
http://people.FreeBSD.org/~ru/patches/libssh.patch.log

In order to test it without a full "buildworld", you'll have
to proceed in this order:

1.  Install updated bsd.lib.mk and bsd.libnames.mk.
2.  Build secure/lib/libssh.
3.  Build and install lib/libpam.

Now you're ready to build/install any PAMified stuff
statically, and pam_ssh should be available.


Cheers,
-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age

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

Re: Hi,All

[Terry Lambert]

Maxim Sobolev wrote:
> Liu Siwei wrote:
> >I love FreeBSD! But.. Can it support CD-RW disc and Simplie Chinese
> > Filename? A lot of files in CD-ROM that have Chinese name, how can i open it
> > under FreeBSD? Oh...Oh
> 
> What is the official name for Simplie Chinese codepage? If it is a
> 1-byte charset, then I could probably add support for it into
> cd9660_unicode ports, which would allow accessing files with such
> filenames on them.

The most common character sets for Chinese are:

GB-2312 Simplified Chinese
EUC-TW  Traditional Chinese
Big-5   Traditional Chinese

The one in most common use is Big-5.

Unicode supports Chinese through its CJK unification, and can have
characters in it round-tripped into any of the above character set
standards.

All of these are multibyte character sets.  Unfortunately, UTF-7
and UTF-8 tend to be used with Unicode, which destroys fixed field
storage of data (since any character can take up to 5 bytes to
store, depending on its code point, when UTF encoding is used).

The answer to the original question is "it depends on how the
Chinese character data is stored on the CDROM".

If the storage is as multibyte, then decoding it is the job of the
rendering engine.  In other words, you leave it alone, and use a
Chinese display program and input method for X Windows, and it will
"just work".

If the storage is as Unicode code points, then, since tty interfaces
are currently single byte, then you would need to have a converter
program between the FS and the directory code, to convert it to
multibyte, so that when you list the directory, you get the multibyte
values out, and that, in turn, is rendered by the Chinese capable
multibyte program (xterm/etc.).

Right now, FreeBSD does not convert to/from Unicode 2/4 byte encoding
(Windows uses 2 byte encoding, as does Joliet, the Windows CDROM
standard, which *is* supported by FreeBSD); it merely masks off the
high byte of the two bytes, taking advantage of the fact that the
first 256 bytes of Unicode is identical to ISO 8859-1 (Latin-1).  You
would need to be able to throw down round trip tables (probably via
an ioctl() to load them) to the kernel (this is what Windows does).

Note that because of the expansion requirements, it's possible to
have 256 Unicode stored Chinese characters bloat to 1280 characters,
which exceeds both the maximum file name component length (256) and
path name length (1024) set by UNIX (and copied by FreeBSD).  It's
highly unlikely that anyone has encoded this type of data, but the
possibility is there.

Ignoring all that, you should be able to do a lookup from the
Unicode table to to, say, Big-5, and back, with one 64K table in
each direction, and EUC or otherwise multibyte encode the result
before returning it via getdirentries().  This will break under
Linux emulation (I believe), since it uses the directory lookup
restart code, which will be variant under multibyte translation.

-- Terry

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

Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Andrew Kenneth Milton wrote:
> +---[ Terry Lambert ]--
> | RMS has indicated a willingness to sue people distributing bipartite
> | distributions, where the linking is delayed until installation to
> | work around the letter of the GPL.  Given his religious convictions,
> | I can't see him *not*.  Factor that into your decision.
> 
> Just to balance this point out;
> 
> Only the copyright holder can do this, what code of any significance has
> RMS contributed recently to this or any other project where this would be
> a consideration?

I can't argue with that; historically, IBM has never sued anyone, and
they were oh so happy to consider another license for the year I tried
to push for it for use in a FreeBSD based IBM product.  Not.

8^p

-- Terry

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

buildworld broken on globaldata.h

[Poul-Henning Kamp]

My buildworld breaks:

[...]
/flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52: machine/globaldata.h: No 
such file or directory

Any workarounds/fixes ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

[Bernd Walter]

On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote:
> On Tuesday, 11 December 2001 at  3:11:21 +0100, Bernd Walter wrote:
> > striped:
> > If you have 512byte stripes and have 2 disks.
> > You access 64k which is put into 2 32k transactions onto the disk.
> 
> Only if your software optimizes the transfers.  There are reasons why
> it should not.  Without optimization, you get 128 individual
> transfers.

If the software does not we end with 128 transactions anyway, which is
not very good becuase of the overhead for each of them.
UFS does a more or less good job in doing this.

> > Linear speed could be about twice the speed of a single drive.  But
> > this is more theoretic today than real.  The average transaction
> > size per disk decreases with growing number of spindles and you get
> > more transaction overhead.  Also the voice coil technology used in
> > drives since many years add a random amount of time to the access
> > time, which invalidates some of the spindle sync potential.  Plus it
> > may break some benefits of precaching mechanisms in drives.  I'm
> > almost shure there is no real performance gain with modern drives.
> 
> The real problem with this scenario is that you're missing a couple of
> points:
> 
> 1.  Typically it's not the latency that matters.  If you have to wait
> a few ms longer, that's not important.  What's interesting is the
> case of a heavily loaded system, where the throughput is much more
> important than the latency.

Agreed - especially because we don't wait for writes as most are async.

> 2.  Throughput is the data transferred per unit time.  There's active
> transfer time, nowadays in the order of 500 µs, and positioning
> time, in the order of 6 ms.  Clearly the fewer positioning
> operations, the better.  This means that you should want to put
> most transfers on a single spindle, not a single stripe.  To do
> this, you need big stripes.

In the general case yes.

> > raid5:
> > For a write you have two read transactions and two writes.
> 
> This is the way Vinum does it.  There are other possibilities:
> 
> 1.  Always do full-stripe writes.  Then you don't need to read the old
> contents.

Which isn't that good with the big stripes we usually want.

> 2.  Cache the parity blocks.  This is an optimization which I think
> would be very valuable, but which Vinum doesn't currently perform.

I thought of connecting the parity to the wait lock.
If there's a waiter for the same parity data it's not droped.
This way we don't waste memory but still have an efect.

> > There are easier things to raise performance.
> > Ever wondered why people claim vinums raid5 writes are slow?
> > The answer is astonishing simple:
> > Vinum does striped based locking, while the ufs tries to lay out data
> > mostly ascending sectors.
> > What happens here is that the first write has to wait for two reads
> > and two writes.
> > If we have an ascending write it has to wait for the first write to
> > finish, because the stripe is still locked.
> > The first is unlocked after both physical writes are on disk.
> > Now we start our two reads which are (thanks to drives precache)
> > most likely in the drives cache - than we write.
> >
> > The problem here is that physical writes gets serialized and the drive
> > has to wait a complete rotation between each.
> 
> Not if the data is in the drive cache.

This example was for writing.
Reads get precached by the drive and have a very good chance of beeing
in the cache.
It doesn't matter on IDE disks, because if you have write cache enabled
the write gets acked from the cache and not the media.  If write cache
is disabled writes gets serialized anyway.

> > If we had a fine grained locking which only locks the accessed sectors
> > in the parity we would be able to have more than a single ascending
> > write transaction onto a single drive.
> 
> Hmm.  This is something I hadn't thought about.  Note that sequential
> writes to a RAID-5 volume don't go to sequential addresses on the
> spindles; they will work up to the end of the stripe on one spindle,
> then start on the next spindle at the start of the stripe.  You can do
> that as long as the address ranges in the parity block don't overlap,
> but the larger the stripe, the greater the likelihood of this would
> be. This might also explain the following observed behaviour:
> 
> 1.  RAID-5 writes slow down when the stripe size gets > 256 kB or so.
> I don't know if this happens on all disks, but I've seen it often
> enough.

I would guess it when the stripe size is bigger than the preread cache
the drives uses.
This would mean we have a less chance to get parity data out of the
drive cache.

> 2.  rawio write performance is better than ufs write performance.
> rawio does "truly" random transfers, where ufs is a mixture.

The current problem is to increase linear write performance.
I don't see a chance that rawio benefit of it, but ufs will.

Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Andrew Kenneth Milton]

+---[ Poul-Henning Kamp ]--
| In message <[EMAIL PROTECTED]>, Andrew Kenneth Milt
| on writes:
| >+---[ Terry Lambert ]--
| >|
| >| RMS has indicated a willingness to sue people distributing bipartite
| >| distributions, where the linking is delayed until installation to
| >| work around the letter of the GPL.  Given his religious convictions,
| >| I can't see him *not*.  Factor that into your decision.
| >
| >Just to balance this point out;
| >
| >Only the copyright holder can do this, what code of any significance has 
| >RMS contributed recently to this or any other project where this would be 
| >a consideration?
| 
| Uh, people have been signing their copyright over to FSF for a long
| time...

That still doesn't answer the question though. I'm pretty sure IBM didn't
sign *their* copyright over to the FSF.

-- 
Totally Holistic Enterprises Internet|  | Andrew Milton
The Internet (Aust) Pty Ltd  |  |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| 

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

Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Andrew Kenneth Milton]

+---[ Terry Lambert ]--
|
| > Only the copyright holder can do this, what code of any significance has
| > RMS contributed recently to this or any other project where this would be
| > a consideration?
| 
| I can't argue with that; historically, IBM has never sued anyone, and
| they were oh so happy to consider another license for the year I tried
| to push for it for use in a FreeBSD based IBM product.  Not.

Of course not, the GPL protects them from competitors taking and improving
their product and selling it at a profit without having to share. Ironic
isn't it, that the GPL has become a tool of the "oppressors" d8)

-- 
Totally Holistic Enterprises Internet|  | Andrew Milton
The Internet (Aust) Pty Ltd  |  |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| 

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

Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Hiten Pandya wrote:
> why would RMS sue, lets say me, for porting IBM's
> piece of GPL'ed code to FreeBSD src/gnu.

RMS wouldn't, not being directly involved.  IBM might.

I am a former IBM employee, of IBM GSB division (Global Small
Business).  I became an IBM employee when IBM bought Whistle
Communications, Inc., which produced a SOHO connectivity
product called the InterJet.  This became the basis of the IBM
Web Connections offering (the purchase of Whistle was portrayed
as a time-to-market decision).

The InterJet II product is what funded the Soft Updates port
to FreeBSD.  The idea was to get rid of the internal UPS that
was otherwise required, to reduce the COGS (Cost Of Goods Sold).
With Soft Updates, we were able to replace the UPS with a power
supply with a large DC holdup time, and AC fail notification.
This work occured mostly before the IBM acquisition.

When the GPL JFS was announced, I tried within IBM for a year
to get the code under other terms for use in an IBM GSB product,
specifically, the InterJet.  The people involved were on a
religious/marketing GPL crusade, however.

If we had been able to use a JFS, we would have been able to get
rid of the remainder of the extra cost in the power supply, and
get our costs down further, by using an off-the-shelf supply.


Despite the fact that this was costing another division of IBM
money, the people releasing the JFS refused to relicense, even
for internal use only, the JFS code that they were giving away to
the Linux community (I'm sure that, if the AIX people had the code,
that it was possible, were we to commit a large enough chunk of our
operating budget, to get the code from the AIX people, but the
amortized cost of this would not have reduced our COGS).

With JFS under non-GPL'ed terms, we wuld have been able to get
perhaps another $120 per unit out of the final end customer cost.
In the U.S., this would have let us drop our subscription cost
$10/month.  In Japan, it would have dropped ~20,000 Yen from the
total per unit cost.


Forgive me if I don't think that someone outside IBM is going to
have any better luck than a group of high band people inside IBM
who could demonstrate a business case pertinenet to IBMs financial
interests.

-- Terry

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

RE: buildworld broken on globaldata.h

[Alan Edmonds]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of 
> Poul-Henning Kamp
> Sent: 12 December 2001 11:43
> To: [EMAIL PROTECTED]
> Subject: buildworld broken on globaldata.h
> 
> 
> 
> My buildworld breaks:
> 
> [...]
> /flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52: 
> machine/globaldata.h: No 
> such file or directory
> 
> Any workarounds/fixes ?

Ditto here.  I just tried a rm -fr /usr/obj and then make buildworld. 
It's still running but it's a slow machine.

Alan Edmonds


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

Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Terry Lambert]

Andrew Kenneth Milton wrote:
> | I can't argue with that; historically, IBM has never sued anyone, and
> | they were oh so happy to consider another license for the year I tried
> | to push for it for use in a FreeBSD based IBM product.  Not.
> 
> Of course not, the GPL protects them from competitors taking and improving
> their product and selling it at a profit without having to share. Ironic
> isn't it, that the GPL has become a tool of the "oppressors" d8)

Perhaps you missed the fact that I was *ALSO* IBM at the time.

-- Terry

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

Re: [OT] RMS Suing was [SUGGESTION] - JFS for FreeBSD

[Andrew Kenneth Milton]

+---[ Terry Lambert ]--
| Andrew Kenneth Milton wrote:
| > | I can't argue with that; historically, IBM has never sued anyone, and
| > | they were oh so happy to consider another license for the year I tried
| > | to push for it for use in a FreeBSD based IBM product.  Not.
| > 
| > Of course not, the GPL protects them from competitors taking and improving
| > their product and selling it at a profit without having to share. Ironic
| > isn't it, that the GPL has become a tool of the "oppressors" d8)
| 
| Perhaps you missed the fact that I was *ALSO* IBM at the time.

I didn't. I wasn't saying you were a competitor, just that the GPL is a
convenient license for corporations to use. IBM are bigger than most 
governments, were you surprised that the bureaucracy is too?

-- 
Totally Holistic Enterprises Internet|  | Andrew Milton
The Internet (Aust) Pty Ltd  |  |
ACN: 082 081 472 ABN: 83 082 081 472 |  M:+61 416 022 411   | Carpe Daemon
PO Box 837 Indooroopilly QLD 4068|[EMAIL PROTECTED]| 

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

Re: buildworld broken on globaldata.h

[Harti Brandt]

On Wed, 12 Dec 2001, Poul-Henning Kamp wrote:

PK>
PK>My buildworld breaks:
PK>
PK>[...]
PK>/flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52: machine/globaldata.h: No
PK>such file or directory
PK>
PK>Any workarounds/fixes ?

This was broken by jhb's large commit yesterday to break globaldata in MI
and MD parts. The following patch to
gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c let's you compile gdb. Don't know
whether it works. Maybe there are other problems further down in the
buildworld (mine is still working)

harti

Index: kvm-fbsd.c
===
RCS file: /usr/ncvs/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c,v
retrieving revision 1.32
diff -r1.32 kvm-fbsd.c
52c52,53
< #include 
---
> #include 
> #include 
121c122
<   offsetof(struct globaldata, gd_ ## name)
---
>   offsetof(struct pcpu, pc_ ## name)
788,789c789,790
<   struct globaldata lgd;
<   struct globaldata *gd;
---
>   struct pcpu lgd;
>   struct pcpu *gd;
794c795
<   for (; gd != NULL; gd = SLIST_NEXT (&lgd, gd_allcpu))
---
>   for (; gd != NULL; gd = SLIST_NEXT (&lgd, pc_allcpu))
797c798
<   if (lgd.gd_cpuid == cpuid)
---
>   if (lgd.pc_cpuid == cpuid)

-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED]


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

Re: dhclient busted for -current?

[Edwin Culp]

This may explain my problem with the excite@home/attbi.com change over.
According to them it is pure dhcp.  Since it has always just worked when
I needed it, I haven't really tested.

ed

Quoting Warner Losh <[EMAIL PROTECTED]>:

> In message <[EMAIL PROTECTED]> "Pierre Y.
> Dampure" writes:
> : Are you asking for specific options (my dhclient.conf is empty)? are you
> using a reservation?
> 
> I'm 100% sure it worked before the upgrade. :-(.
> 
> Warner
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 




---

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

Re: buildworld broken on globaldata.h

[David Wolfskill]

>Date: Wed, 12 Dec 2001 13:50:48 +0100 (CET)
>From: Harti Brandt <[EMAIL PROTECTED]>

>PK>My buildworld breaks:
>PK>[...]

>This was broken by jhb's large commit yesterday to break globaldata in MI
>and MD parts. The following patch to
>gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c let's you compile gdb. Don't know
>whether it works. Maybe there are other problems further down in the
>buildworld (mine is still working)

Maybe I'm just lucky, but today's -CURRENT built just fine for me on my
build machine (without hand-patching of any kind):

Last login: Wed Dec 12 06:42:43 2001 from bunrab.catwhiske
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California.  All rights reserved.
FreeBSD 5.0-CURRENT (FREEBEAST) #6: Wed Dec 12 07:19:55 PST 2001
freebeast[1] uname -a
FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Wed Dec 12 
07:19:55 PST 2001 
[EMAIL PROTECTED]:/common/S4/obj/usr/src/sys/FREEBEAST  i386
freebeast[2] tail /var/log/cvsup-history.log
CVSup ended from cvsup14.freebsd.org at Sat Dec  8 03:53:49 PST 2001
CVSup begin from cvsup14.freebsd.org at Sun Dec  9 03:47:03 PST 2001
CVSup ended from cvsup14.freebsd.org at Sun Dec  9 03:53:45 PST 2001
CVSup begin from cvsup10.freebsd.org at Mon Dec 10 03:47:33 PST 2001
CVSup begin from cvsup13.freebsd.org at Mon Dec 10 04:04:34 PST 2001
CVSup ended from cvsup13.freebsd.org at Mon Dec 10 04:11:34 PST 2001
CVSup begin from cvsup14.freebsd.org at Tue Dec 11 03:47:02 PST 2001
CVSup ended from cvsup14.freebsd.org at Tue Dec 11 03:53:23 PST 2001
CVSup begin from cvsup14.freebsd.org at Wed Dec 12 03:47:02 PST 2001
CVSup ended from cvsup14.freebsd.org at Wed Dec 12 03:53:39 PST 2001
freebeast[3] 


(Still cranking away on the laptop)

Cheers,
david
-- 
David H. Wolfskill  [EMAIL PROTECTED]
I believe it would be irresponsible (and thus, unethical) for me to advise,
recommend, or support the use of any product that is or depends on any
Microsoft product for any purpose other than personal amusement.

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

Re: panic: kernel trap doesn't have ucred

[Bruce Evans]

On Tue, 11 Dec 2001, Georg-W Koltermann wrote:

> I get a panic "kernel trap doesn't have ucred" when I try to install
> Linux ORACLE 8.1.7.

Looks like the trap handling for invalid segment registers on return to
user mode is broken.

Bruce


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

Re: Junior Kernel hacker task: Floppy driver mode handling.

[Martin Heller]

Hello!
After a quick glance thru the TUHS.org archives, I found a quick & dirty 
hack for 4.0-Stable by Jason T. Miller <[EMAIL PROTECTED]>
The README for this thing is as follows:

 >This tarball contains a dumb hack to read and write DEC RX50 diskettes
 >under FreeBSD. It consists of two pieces, a kernel patch and a set of
 >filters. The kernel patch, which should be applied to SYS/isa/fd.c, >adds
 >the RX50 physical format to the FreeBSD floppy driver. The patch is >based
 >on FreeBSD 4.0-STABLE, your mileage may vary. However, it is >conceptually
 >simple and should be easy enough to apply by hand. Note that this >format
 >is identical to the 5.25" 800K format, but with only one side.

 >Also in the kernel/ directory is a patch for MAKEDEV which adds device
 >nodes for the new format, with the name fd[n].rx50. Note that using >this
 >node with a drive that is not a high-density 5.25" floppy results in a
 >"device not configured" error.
 >
 >The filters/ directory contains two filters, rx50in and rx50out, which
 >deal with the logical sector interleave performed by the RQDX >controllers
 >on the PDP-11 and VAX; ideally, this would be handled in the driver; >like
 >I said, this is a dumb hack. Note that the filters read or write the
 >_entire_ disk; short input results in null-padding. This shouldn't be a
 >big deal, but it does result in a bit of extra disk I/O. C'est la vie.
 >They use standard input and standard output, and no output (except for >an
 >error message on standard error) is created if the input exceeds the
 >capacity of an RX50. Also keep in mind that non-PDP, non-VAX
 >implementations of the RX50 used different layouts, so the filters are 
 >not
 >appropriate, for example, for DECmate or DEC Rainbow disks. The kernel
 >patch is, however, and this is the sole advantage of doing the >interleave
 >in userland.
 >
 >EXAMPLES:
 >
 >Create a tar archive of 'directory' on an RX50:
 >  tar cf- directory/ | rx50out >/dev/fd1.rx50
 >
 >Extract a tar archive from an RX50:
 >  rx50in 
 >Finally, you can try to format a disk as an RX50 with
 >  fdformat /dev/fd1.rx50
 >
 >I say 'try to format' because the diskettes I format in this fashion >are
 >prone to read/write errors on a real RX50. This is probably due to head
 >alignment issues, but it could, of course, be something else. I've had >no
 >problems reading and writing disks formatted in other ways (by DEC or
 >using custom hardware, in my case a Shaffstall 6000 media conversion 
 >unit)
 >Bear in mind that RX50s, though they are written at 96tpi and thus 
 >require
 >a high-density drive to read and write on a PC, are _not_ a >high-density
 >format, and using HD media will likely result in _lots_ of errors. I >use
 >96tpi double-density media myself, but good luck finding it. The best
 >substitute that is commonly available seems to be standard 360K
 >double-density media without hub rings. Once again, your mileage may 
 >vary.

 >Please send any questions or comments, bugfixes or patches to
 >[EMAIL PROTECTED]; once again, this is a dumb hack, written in an
 >evening, full of sound and fury, signifying nothing. The code is ugly, 
 >but
 >the results, I'm happy to report, are not.
 >
 >-Jason T. Miller
 > June 9, 2000

Hope this helps , Martin Heller


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

Re: Junior Kernel hacker task: Floppy driver mode handling.

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Martin Heller writes:
>Hello!
>After a quick glance thru the TUHS.org archives, I found a quick & dirty 
>hack for 4.0-Stable by Jason T. Miller <[EMAIL PROTECTED]>
>The README for this thing is as follows:

That is where I got the inspiration to clean up our floppy driver.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

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

Re: buildworld broken on globaldata.h

[John Baldwin]

On 12-Dec-01 Harti Brandt wrote:
> On Wed, 12 Dec 2001, Poul-Henning Kamp wrote:
> 
> PK>
> PK>My buildworld breaks:
> PK>
> PK>[...]
> PK>/flat/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c:52:
> machine/globaldata.h: No
> PK>such file or directory
> PK>
> PK>Any workarounds/fixes ?
> 
> This was broken by jhb's large commit yesterday to break globaldata in MI
> and MD parts. The following patch to
> gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c let's you compile gdb. Don't know
> whether it works. Maybe there are other problems further down in the
> buildworld (mine is still working)

You should only have to include  (it includes 
already), but that patch looks ok.  libkvm will need the same fix.  My bad, I
was so busy testing kernels and making sure they worked in various combinations
I didn't test a buildworld. :(

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: panic: kernel trap doesn't have ucred

[John Baldwin]

On 12-Dec-01 Bruce Evans wrote:
> On Tue, 11 Dec 2001, Georg-W Koltermann wrote:
> 
>> I get a panic "kernel trap doesn't have ucred" when I try to install
>> Linux ORACLE 8.1.7.
> 
> Looks like the trap handling for invalid segment registers on return to
> user mode is broken.

That would panic in that case, yes.  For now that KASSERT() can just be
commented out until I figure out how to make that a more proper assert.

> Bruce

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

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

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

[Greg Lehey]

On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote:
> On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote:
>> On Tuesday, 11 December 2001 at  3:11:21 +0100, Bernd Walter wrote:
>>> striped:
>>> If you have 512byte stripes and have 2 disks.
>>> You access 64k which is put into 2 32k transactions onto the disk.
>>
>> Only if your software optimizes the transfers.  There are reasons why
>> it should not.  Without optimization, you get 128 individual
>> transfers.
>
> If the software does not we end with 128 transactions anyway, which is
> not very good becuase of the overhead for each of them.

Correct.

> UFS does a more or less good job in doing this.

Well, it requires a lot of moves.  Vinum *could* do this, but for the
reasons specified below, there's no need.

>>> raid5:
>>> For a write you have two read transactions and two writes.
>>
>> This is the way Vinum does it.  There are other possibilities:
>>
>> 1.  Always do full-stripe writes.  Then you don't need to read the old
>> contents.
>
> Which isn't that good with the big stripes we usually want.

Correct.  That's why most RAID controllers limit stripe size to
something sub-optimal, because it simplifies the code to do
full-stripe writes.

>> 2.  Cache the parity blocks.  This is an optimization which I think
>> would be very valuable, but which Vinum doesn't currently perform.
>
> I thought of connecting the parity to the wait lock.
> If there's a waiter for the same parity data it's not droped.
> This way we don't waste memory but still have an efect.

That's a possibility, though it doesn't directly address parity block
caching.  The problem is that by the time you find another lock,
you've already performed part of the parity calculation, and probably
part of the I/O transfer.  But it's an interesting consideration.

>>> If we had a fine grained locking which only locks the accessed sectors
>>> in the parity we would be able to have more than a single ascending
>>> write transaction onto a single drive.
>>
>> Hmm.  This is something I hadn't thought about.  Note that sequential
>> writes to a RAID-5 volume don't go to sequential addresses on the
>> spindles; they will work up to the end of the stripe on one spindle,
>> then start on the next spindle at the start of the stripe.  You can do
>> that as long as the address ranges in the parity block don't overlap,
>> but the larger the stripe, the greater the likelihood of this would
>> be. This might also explain the following observed behaviour:
>>
>> 1.  RAID-5 writes slow down when the stripe size gets > 256 kB or so.
>> I don't know if this happens on all disks, but I've seen it often
>> enough.
>
> I would guess it when the stripe size is bigger than the preread cache
> the drives uses.
> This would mean we have a less chance to get parity data out of the
> drive cache.

Yes, this was one of the possibilities we considered.  

>> 2.  rawio write performance is better than ufs write performance.
>> rawio does "truly" random transfers, where ufs is a mixture.
>
> The current problem is to increase linear write performance.
> I don't see a chance that rawio benefit of it, but ufs will.

Well, rawio doesn't need to benefit.  It's supposed to be a neutral
observer, but in this case it's not doing too well.

>> Do you feel like changing the locking code?  It shouldn't be that much
>> work, and I'd be interested to see how much performance difference it
>> makes.
>
> I put it onto my todo list.

Thanks.

>> Note that there's another possible optimization here: delay the writes
>> by a certain period of time and coalesce them if possible.  I haven't
>> finished thinking about the implications.
>
> That's exactly what the ufs clustering and softupdates does.
> If it doesn't fit modern drives anymore it should get tuned there.

This doesn't have too much to do with modern drives; it's just as
applicable to 70s drives.

> Whenever a write hits a driver there is a waiter for it.
> Either a softdep, a memory freeing or an application doing an sync
> transfer.
> I'm almost shure delaying writes will harm performance in upper layers.

I'm not so sure.  Full stripe writes, where needed, are *much* faster
than partial strip writes.

Greg
--
See complete headers for address and phone numbers

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

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

[Bernd Walter]

On Thu, Dec 13, 2001 at 10:54:13AM +1030, Greg Lehey wrote:
> On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote:
> > On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote:
> >> On Tuesday, 11 December 2001 at  3:11:21 +0100, Bernd Walter wrote:
> >> 2.  Cache the parity blocks.  This is an optimization which I think
> >> would be very valuable, but which Vinum doesn't currently perform.
> >
> > I thought of connecting the parity to the wait lock.
> > If there's a waiter for the same parity data it's not droped.
> > This way we don't waste memory but still have an efect.
> 
> That's a possibility, though it doesn't directly address parity block
> caching.  The problem is that by the time you find another lock,
> you've already performed part of the parity calculation, and probably
> part of the I/O transfer.  But it's an interesting consideration.

I know that it doesn't do the best, but it's easy to implement.
A more complex handling for the better results can still be done.

> >>> If we had a fine grained locking which only locks the accessed sectors
> >>> in the parity we would be able to have more than a single ascending
> >>> write transaction onto a single drive.
> >>
> >> Hmm.  This is something I hadn't thought about.  Note that sequential
> >> writes to a RAID-5 volume don't go to sequential addresses on the
> >> spindles; they will work up to the end of the stripe on one spindle,
> >> then start on the next spindle at the start of the stripe.  You can do
> >> that as long as the address ranges in the parity block don't overlap,
> >> but the larger the stripe, the greater the likelihood of this would
> >> be. This might also explain the following observed behaviour:
> >>
> >> 1.  RAID-5 writes slow down when the stripe size gets > 256 kB or so.
> >> I don't know if this happens on all disks, but I've seen it often
> >> enough.
> >
> > I would guess it when the stripe size is bigger than the preread cache
> > the drives uses.
> > This would mean we have a less chance to get parity data out of the
> > drive cache.
> 
> Yes, this was one of the possibilities we considered.  

It should be measured and compared after I changed the looking.
It will look different after that and may lead to other reasons,
because we will have a different load characteristic on the drives.
Currently if we have two writes in two stripes each, all initated before
the first finished, the drive has to seek between the two stripes, as
the second write to the same stripe has to wait.

> >> Note that there's another possible optimization here: delay the writes
> >> by a certain period of time and coalesce them if possible.  I haven't
> >> finished thinking about the implications.
> >
> > That's exactly what the ufs clustering and softupdates does.
> > If it doesn't fit modern drives anymore it should get tuned there.
> 
> This doesn't have too much to do with modern drives; it's just as
> applicable to 70s drives.

One of softupdates job is to eliminate redundant writes and to do async
writes without loosing consistency of the on media structure.
This also means that we have a better chance that data is written in big
chunks.
In general the wire speed of data to the drive is increased with every new
bus generation but usually big parts of the overhead is keeped for
compatibility with older drives.
I agree that the parity based raid situation does depend more on principle
than on the age of the drive.

> > Whenever a write hits a driver there is a waiter for it.
> > Either a softdep, a memory freeing or an application doing an sync
> > transfer.
> > I'm almost shure delaying writes will harm performance in upper layers.
> 
> I'm not so sure.  Full stripe writes, where needed, are *much* faster
> than partial strip writes.

Hardware raid usually comes with NVRAM and can cache write data without
delaying the acklowledge to the initiator.
That option is not available to software raid.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


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

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

[Greg Lehey]

On Thursday, 13 December 2001 at  3:06:14 +0100, Bernd Walter wrote:
> On Thu, Dec 13, 2001 at 10:54:13AM +1030, Greg Lehey wrote:
>> On Wednesday, 12 December 2001 at 12:53:37 +0100, Bernd Walter wrote:
>>> On Wed, Dec 12, 2001 at 04:22:05PM +1030, Greg Lehey wrote:
 On Tuesday, 11 December 2001 at  3:11:21 +0100, Bernd Walter wrote:
 2.  Cache the parity blocks.  This is an optimization which I think
 would be very valuable, but which Vinum doesn't currently perform.
>>>
>>> I thought of connecting the parity to the wait lock.
>>> If there's a waiter for the same parity data it's not droped.
>>> This way we don't waste memory but still have an efect.
>>
>> That's a possibility, though it doesn't directly address parity block
>> caching.  The problem is that by the time you find another lock,
>> you've already performed part of the parity calculation, and probably
>> part of the I/O transfer.  But it's an interesting consideration.
>
> I know that it doesn't do the best, but it's easy to implement.
> A more complex handling for the better results can still be done.

I don't have the time to work out an example, but I don't think it
would change anything until you had two lock waits.  I could be wrong,
though: you've certainly brought out something here that I hadn't
considered, so if you can write up a detailed example (preferably
after you've looked at the code and decided how to handle it), I'd
certainly be interested.

>>> I would guess it when the stripe size is bigger than the preread
>>> cache the drives uses.  This would mean we have a less chance to
>>> get parity data out of the drive cache.
>>
>> Yes, this was one of the possibilities we considered.
>
> It should be measured and compared after I changed the looking.
> It will look different after that and may lead to other reasons,
> because we will have a different load characteristic on the drives.
> Currently if we have two writes in two stripes each, all initated before
> the first finished, the drive has to seek between the two stripes, as
> the second write to the same stripe has to wait.

I'm not sure I understand this.  The stripes are on different drives,
after all.

>>> Whenever a write hits a driver there is a waiter for it.
>>> Either a softdep, a memory freeing or an application doing an sync
>>> transfer.
>>> I'm almost shure delaying writes will harm performance in upper layers.
>>
>> I'm not so sure.  Full stripe writes, where needed, are *much* faster
>> than partial strip writes.
>
> Hardware raid usually comes with NVRAM and can cache write data without
> delaying the acklowledge to the initiator.
> That option is not available to software raid.

It could be.  It's probably something worth investigating and
supporting.

Greg
--
See complete headers for address and phone numbers

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

Re: Vinum write performance (was: RAID performance (was: cvs commit: src/sys/kern subr_diskmbr.c))

[Bernd Walter]

On Thu, Dec 13, 2001 at 12:47:53PM +1030, Greg Lehey wrote:
> On Thursday, 13 December 2001 at  3:06:14 +0100, Bernd Walter wrote:
> > Currently if we have two writes in two stripes each, all initated before
> > the first finished, the drive has to seek between the two stripes, as
> > the second write to the same stripe has to wait.
> 
> I'm not sure I understand this.  The stripes are on different drives,
> after all.

Lets asume a 256k striped single plex volume with 3 subdisks.
We get a layout like this:

sd1 sd2 sd3
256k256kparity
256kparity  256k
parity  256k256k
256k256kparity
... ... ...

Now we write on the volume the blocks 1, 10, 1040 and 1045.
All writes are initated at the same time.
Good would be to write first 1 then 10 then 1040 and finaly 1045.
What we currently see is write 1 then 1040 then 10 and finaly 1045.
This is because we can't write 10 unless 1 is finished but we already
start with 1040 because it's independend.
The result is avoidable seeking in subdisk 1.

Back to the >256k performance breakdown you described.
Because of the seeks we have not only unneeded seeks on the drive but
also have a different use pattern on the drive cache.

Once the locks are untangled it is required to verify the situation as
the drive cache may behave differently.

-- 
B.Walter  COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup   [EMAIL PROTECTED]


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

-current vs. -stable network performance

[Luigi Rizzo]

Hi,
I am testing the forwarding performance of CURRENT vs. STABLE
(both more or less up to date, unmodified, with the latest performance
patches to the "dc" driver, which I am using) and I am having some
surprises.
 
STABLE can forward approx 125Kpps, whereas CURRENT tops at approx 80Kpps.

This is on the same hardware, 750MHz Athlon, fastforwarding enabled,
a 4-port 21143 card, one input driven with a stream of up to 148Kpps
(64 bytes each).

Ability to transmit seems roughly the same (in both cases 138Kpps),
and lack of CPU does not seem to be the problem (at least for
CURRENT), so I am suspecting some difference in the initialization
of PCI parameters, such as burst size etc, but I am unclear on
where to look at.  Any ideas ?

cheers
luigi
--+-
 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-current" in the body of the message