Re: devfs and /dev/fd/3

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Marc Olzheim writes:
>Hi.
>
>I've seen the question once before, but it was not answered (on-list ?),
>so now that I run in on it, I'd like to know what to do:
>
>On FreeBSD 4.x, without devfs, the following worked:
>( echo foo | tee /dev/fd/3 | tr f F ) 3>&1
>
>It should produce both "foo" and "Foo"
>
>FreeBSD 5 with devfs, however, does not create a /dev/fd/3 upon opening
>filedescriptor 3 by the shell, so there's no device to write to...
>
>How can I fix or circumvent this, aside from mounting a ufs partition
>with mknod-ed files over /dev/fd ?

 
mount fdescfs

-- 
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Doug Rabson]

On Wed, 2003-06-04 at 14:16, Paul Richards wrote:
> On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:
> 
> > Interfaces actually can be added at runtime. Existing objects (i.e.
> > objects instantiated before the new interface was added) will continue
> > to work as before. If methods from the new interface are called on old
> > objects, the default method will be called.
> 
> How can you add an interface at runtime?

By loading a kernel module. If I load e.g. the agp kernel module, I add
the agp_if interface to the kernel.

> 
> All of this runtime activity is theoretically possible, i.e. all
> these structures can be messed around with to add methods to existing
> objects etc. but wasn't kobj supposed to provide an OO type
> abstraction and therefore the interfaces and classes are determined
> at compile time.
> 
> I'm not aware of any actual code that changes interfaces or classes
> at runtime and if we added that functionality then I think it would
> break the abstraction and complicate the usage of kobj for no real
> gain.
> 
> Coming back to the central point, I don't understand why we need
> a cache at all. I don't see the reason for having to support the
> dispatching of anything other than the methods in the class that
> the object was instantiated into, so that means a relatively small
> fixed size method dispatch table.
> 
> The only argument for that not working is if the class gets extended
> after the object is created but I'm not convinced yet that that's
> something to worry about in practice at least at the moment since we
> don't extend classes anywhere.
> 
> Even if we added code to make that possible at runtime it would be
> simple enough to get a "miss" when looking that method up in older
> objects and to realloc the method table in the object to accomodate
> the new methods. Extending the class is something that is likely
> to be so rare that some performance penalty should that happen
> would be palatable.

The code which is doing the method dispatch has no real idea what
methods (or what interfaces for that matter) that the object's class
implements. You can't use the classes method table layout for the ops
table since the caller has no way of knowing that layout (and the layout
will be different for almost every class in the system).

One possible way of making this slightly simpler might be to make the
class point at a table indexed by interface ID, each entry of which is a
table indexed by a method ID from that interface. This sounds fine in
theory but in practice, it would end up slower due to the two memory
accesses.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: devfs and /dev/fd/3

[Harti Brandt]

On Wed, 4 Jun 2003, Marc Olzheim wrote:

MO>Hi.
MO>
MO>I've seen the question once before, but it was not answered (on-list ?),
MO>so now that I run in on it, I'd like to know what to do:
MO>
MO>On FreeBSD 4.x, without devfs, the following worked:
MO>( echo foo | tee /dev/fd/3 | tr f F ) 3>&1
MO>
MO>It should produce both "foo" and "Foo"
MO>
MO>FreeBSD 5 with devfs, however, does not create a /dev/fd/3 upon opening
MO>filedescriptor 3 by the shell, so there's no device to write to...
MO>
MO>How can I fix or circumvent this, aside from mounting a ufs partition
MO>with mknod-ed files over /dev/fd ?

You must

mount -tfdescfs fdesc /dev/fd

but your example doesn't work even then (although it gives no error).
Don't know why.

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
[EMAIL PROTECTED], [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: devfs and /dev/fd/3

[David P. Reese Jr.]

On Wed, Jun 04, 2003 at 03:30:19PM +0200, Marc Olzheim wrote:
> Hi.
> 
> I've seen the question once before, but it was not answered (on-list ?),
> so now that I run in on it, I'd like to know what to do:
> 
> On FreeBSD 4.x, without devfs, the following worked:
> ( echo foo | tee /dev/fd/3 | tr f F ) 3>&1
> 
> It should produce both "foo" and "Foo"
> 
> FreeBSD 5 with devfs, however, does not create a /dev/fd/3 upon opening
> filedescriptor 3 by the shell, so there's no device to write to...
> 
> How can I fix or circumvent this, aside from mounting a ufs partition
> with mknod-ed files over /dev/fd ?

You want fdescfs(5).

-- 

   David P. Reese Jr.  [EMAIL PROTECTED]
   --
   It can be argued that returning a NULL pointer when asked to allocate
   zero bytes is a silly response to a silly question.
 -- FreeBSD manual page for malloc(3)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

devfs and /dev/fd/3

[Marc Olzheim]

Hi.

I've seen the question once before, but it was not answered (on-list ?),
so now that I run in on it, I'd like to know what to do:

On FreeBSD 4.x, without devfs, the following worked:
( echo foo | tee /dev/fd/3 | tr f F ) 3>&1

It should produce both "foo" and "Foo"

FreeBSD 5 with devfs, however, does not create a /dev/fd/3 upon opening
filedescriptor 3 by the shell, so there's no device to write to...

How can I fix or circumvent this, aside from mounting a ufs partition
with mknod-ed files over /dev/fd ?

Zlo
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Wed, Jun 04, 2003 at 01:33:46PM +0100, Doug Rabson wrote:

> Interfaces actually can be added at runtime. Existing objects (i.e.
> objects instantiated before the new interface was added) will continue
> to work as before. If methods from the new interface are called on old
> objects, the default method will be called.

How can you add an interface at runtime?

All of this runtime activity is theoretically possible, i.e. all
these structures can be messed around with to add methods to existing
objects etc. but wasn't kobj supposed to provide an OO type
abstraction and therefore the interfaces and classes are determined
at compile time.

I'm not aware of any actual code that changes interfaces or classes
at runtime and if we added that functionality then I think it would
break the abstraction and complicate the usage of kobj for no real
gain.

Coming back to the central point, I don't understand why we need
a cache at all. I don't see the reason for having to support the
dispatching of anything other than the methods in the class that
the object was instantiated into, so that means a relatively small
fixed size method dispatch table.

The only argument for that not working is if the class gets extended
after the object is created but I'm not convinced yet that that's
something to worry about in practice at least at the moment since we
don't extend classes anywhere.

Even if we added code to make that possible at runtime it would be
simple enough to get a "miss" when looking that method up in older
objects and to realloc the method table in the object to accomodate
the new methods. Extending the class is something that is likely
to be so rare that some performance penalty should that happen
would be palatable.

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: libmap.conf has the bug or not work correct?

[Matthew N. Dodd]

On Tue, 3 Jun 2003, Jeremy Messenger wrote:
> 
> # ./test-libmap /usr/X11R6/bin/ggv libc_r.so.5
> Lookup of "libc_r.so.5" for "/usr/X11R6/bin/ggv" -> "libc_r.so.5"
> 

Looks like its working to me.

> 
> # ./test-libmap /usr/X11R6/bin/ggv libthr.so.1
> [...etmpy...]
> 

Right, there was on mapping found.

So this isn't a libmap.conf issue.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ACPI and PCI vs interrupt routing on Sony VAIO's

[Paul Richards]

On Wed, Jun 04, 2003 at 04:42:56AM -0700, Jun Su wrote:
> Good Explain.
> The same problem is in my PCG-R505DC.

Yes, it sounds exactly like the problem with my laptop too.

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Doug Rabson]

On Wed, 2003-06-04 at 13:24, Paul Richards wrote:
> On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote:
> > On Tuesday 03 June 2003 12:00 am, Paul Richards wrote:
> > > On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
> > > > In message: <[EMAIL PROTECTED]>
> > > >
> > > > Paul Richards <[EMAIL PROTECTED]> writes:
> > > > : The possible methods available in an interface are fixed, they're
> > > > : defined in the .m files.
> > > >
> > > > No it isn't.  One can add additional interfaces at any time without
> > > > breaking binary compatibility, so you don't know, a priori, the
> > > > number of methods in a given interface when you build a client of
> > > > that interface.
> > >
> > > I don't think that's true.
> > >
> > > The interface is defined in the .m file and it's created using
> > > makeobjs. You can't do that at runtime because it creates the
> > > kobj_desc struct that uniquely represents the existence of that
> > > method globally for the whole of the kobj subsystem. The set of all
> > > kobj_desc defines all possible methods that can be implemented by an
> > > object, and yes you can extend that interface later and previously
> > > built modules will still work because they only implement a subset of
> > > those possible methods, but the set of all methods that can exist is
> > > determined at compile time from the interface definitions
> > >
> > > A class is then defined which specifies the set of methods that
> > > objects instantiated into that class *can* implement (but are note
> > > required to). The set of methods in a class is also fixed, since it's
> > > basically the method table plus some class fields and the method
> > > table is created at compile time. Again though, if you later extend
> > > the class older compiled modules will still work because if the
> > > method doesn't exist in that older module the default from the
> > > kobj_desc will be used or the kobj_error_method will be called (which
> > > is safe).
> > >
> > > So yes you can extend the interface and the class and keep backwards
> > > compatibility but that all happens at compile time, and therefore at
> > > runtime when the object is instantiated you know the maximum number
> > > of methods that the object can possibly call.
> > 
> > It is true, I'm afraid. A class is can implement any number of 
> > interfaces so knowing the compile-time size of an interface doesn't 
> > help you reserve space for a class. The system is intended to have a 
> > robust ABI so that e.g. a class implementing an interface can be used 
> > safely by a kernel in which new methods have been added to that 
> > interface.
> 
> I though Warner meant adding interfaces at runtime, but he meant
> build time (I misread that).  My comments about interfaces where
> therefore in rebuttal of the possibility to extend them at runtime.
> So yes, what Warner asserted is true but as I did also point out
> above and you've confirmed below, it's the class that determines
> the methods for an object and that is fixed when the object is
> instantiated into that class.

Interfaces actually can be added at runtime. Existing objects (i.e.
objects instantiated before the new interface was added) will continue
to work as before. If methods from the new interface are called on old
objects, the default method will be called.

> 
> > The class is a concrete definition of a set of methods (at this level, 
> > the interfaces are mostly ignored). Objects instantiated in that class 
> > use exactly that set of methods, no more, no less. There is no choice 
> > involved. You appear to be confusing class and interface here.
> 
> Given that we agree that the method table is fixed at object
> instantiation time, why isn't allocating a fixed array appropriate?

Mainly because there isn't an easy way to decide how big the array
should be. The older version of this code reserved enough space for all
current interfaces. This ended up wasting a lot of space (per class, not
per object) and still ended up with a table size comparison in the
method dispatch since interfaces might get added after existing classes
had been initialised.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Wed, Jun 04, 2003 at 12:09:00PM +0100, Doug Rabson wrote:
> On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
> > On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
> > > 
> > > Notice how thread 1's _m gets set based on the results of the kobj
> > > lookup, and we have a race, even if thread1 and thread2 took out their
> > > driver instance locks.
> > 
> > That means we have to lock the dispatch table before every method is
> > looked up and hold it until the method returns (the alternative would be
> > to free it inside the method once it had been called but that'd be a
> > right mess).
> 
> Don't even think about trying to put a mutex into the kobj dispatch

I wasn't, I was just pointing out what would be necessary if the
cacheing problem wasn't resolved :-)

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Wed, Jun 04, 2003 at 10:01:07AM +0100, Doug Rabson wrote:
> On Tuesday 03 June 2003 12:00 am, Paul Richards wrote:
> > On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
> > > In message: <[EMAIL PROTECTED]>
> > >
> > > Paul Richards <[EMAIL PROTECTED]> writes:
> > > : The possible methods available in an interface are fixed, they're
> > > : defined in the .m files.
> > >
> > > No it isn't.  One can add additional interfaces at any time without
> > > breaking binary compatibility, so you don't know, a priori, the
> > > number of methods in a given interface when you build a client of
> > > that interface.
> >
> > I don't think that's true.
> >
> > The interface is defined in the .m file and it's created using
> > makeobjs. You can't do that at runtime because it creates the
> > kobj_desc struct that uniquely represents the existence of that
> > method globally for the whole of the kobj subsystem. The set of all
> > kobj_desc defines all possible methods that can be implemented by an
> > object, and yes you can extend that interface later and previously
> > built modules will still work because they only implement a subset of
> > those possible methods, but the set of all methods that can exist is
> > determined at compile time from the interface definitions
> >
> > A class is then defined which specifies the set of methods that
> > objects instantiated into that class *can* implement (but are note
> > required to). The set of methods in a class is also fixed, since it's
> > basically the method table plus some class fields and the method
> > table is created at compile time. Again though, if you later extend
> > the class older compiled modules will still work because if the
> > method doesn't exist in that older module the default from the
> > kobj_desc will be used or the kobj_error_method will be called (which
> > is safe).
> >
> > So yes you can extend the interface and the class and keep backwards
> > compatibility but that all happens at compile time, and therefore at
> > runtime when the object is instantiated you know the maximum number
> > of methods that the object can possibly call.
> 
> It is true, I'm afraid. A class is can implement any number of 
> interfaces so knowing the compile-time size of an interface doesn't 
> help you reserve space for a class. The system is intended to have a 
> robust ABI so that e.g. a class implementing an interface can be used 
> safely by a kernel in which new methods have been added to that 
> interface.

I though Warner meant adding interfaces at runtime, but he meant
build time (I misread that).  My comments about interfaces where
therefore in rebuttal of the possibility to extend them at runtime.
So yes, what Warner asserted is true but as I did also point out
above and you've confirmed below, it's the class that determines
the methods for an object and that is fixed when the object is
instantiated into that class.

> The class is a concrete definition of a set of methods (at this level, 
> the interfaces are mostly ignored). Objects instantiated in that class 
> use exactly that set of methods, no more, no less. There is no choice 
> involved. You appear to be confusing class and interface here.

Given that we agree that the method table is fixed at object
instantiation time, why isn't allocating a fixed array appropriate?

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: ACPI and PCI vs interrupt routing on Sony VAIO's

[Jun Su]

Good Explain.
The same problem is in my PCG-R505DC.

Jun Su
--- Iain Templeton <[EMAIL PROTECTED]>
wrote:
> Hi,
> 
> I have a Sony VAIO (PCG-R505TFP) which has an
> interrupts related problem (this
> problem was previous posted elsewhere as "Weird as*
> sound problem"). This problem
> has been confirmed on at least one other Sony VAIO
> model (I forget which).
> 
> They're both Intel i830M chipset based.
> 
> Basically, the LNKB interrupt configuration register
> is not being initialised,
> so the interrupt never gets routed, and so the
> interrupt never gets to the CPU.
> Result: Sound doesn't work.
> 
> A really hacky solution to this is to run the
> command:
>   pciconf -w -b pci0:31:0 0x61 9
> 
> which sets the i830's PCI routing register for LNKB
> to IRQ 9.
> 
> I did a bit of digging and found the following bits
> of information:
> 
> 1.  When the ACPI PCI bus starts up, it calls all
> the LNKx.CRS methods to
> get the current resources. LNKB (amongst others)
> returns 0.
> 
> 2.  The PCI configuration space register for IRQ
> contains the value 9.
> 
> 3.  If somebody calls the LNKB.SRS method, it would
> all work because that
> writes the PCI interrupt routing register thingy
> like pciconf does above.
> 
> But the acpi_pcib_route_interrupt() function is not
> being called because
> in pci_alloc_resource() there is a test that checks
> if the PCI config space
> register that contains the interrupt contains a
> valid number (which it does - 9).
> 
> So, basically I think there is something wrong here,
> which I think is that
> ACPI and the generic PCI code (in
> pci_alloc_resource()) don't agree when it comes
> to interrupt management.
> 
> 
> Other than saying "the BIOS is broken" (which it is,
> providing mislead information
> and all), is it a fair statement to say that the
> ACPI CRS method should be trusted
> more than the PCI configuration space registers?
> 
> If so, then if the PCI conf space register disagrees
> with the ACPI result, should
> the PCI conf space register be updated to show what
> the ACPI stuff shows?
> 
> 
> I'm happy to muddle up a patch that might do this,
> but I was hoping for a bit
> of a guide as to how to do it. I thought initially
> that I could update the PCI
> config space register at the time the LNKs CRS
> method was called, but quickly
> gave up on that because I don't know which device to
> update...
> 
> Could I instead perhaps implement the
> pci_alloc_resource() method in
> acpi_pcib_pci.c which inspects the existing PCI
> configuration and the ACPI LNK
> information and if they differ, put the ACPI value
> into the PCI configuration
> register, then call the pci_alloc_resource()
> function to finish off.
> 
> Then pci_alloc_resource() will see a bad value for
> the PCI config space IRQ,
> and call the PCIB_ROUTE_INTERRUPT method to do the
> routing.
> 
> 
> Or is there a better place (or way) to do this. (Can
> I even legally call
> pci_alloc_resource() from
> acpi_pcib_pci_alloc_resource()?).
> 
> For extra information, here is a rather verbose
> dmesg and AML dump:
> 
>   http://starbug.ugh.net.au/~iaint/vaio/dmesg.txt
>   http://starbug.ugh.net.au/~iaint/vaio/ruri.aml
> 
> Oh yeah, not using ACPI is not an option (panics in
> either PCI or PnP BIOS),
> also I think the same problem would exist then since
> it would still not
> try to route interrupts, but I could be wrong.
> 
> Iain
> 
> ___
> [EMAIL PROTECTED] mailing list
>
http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
"[EMAIL PROTECTED]"


__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Doug Rabson]

On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
> On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
> > 
> > Notice how thread 1's _m gets set based on the results of the kobj
> > lookup, and we have a race, even if thread1 and thread2 took out their
> > driver instance locks.
> 
> That means we have to lock the dispatch table before every method is
> looked up and hold it until the method returns (the alternative would be
> to free it inside the method once it had been called but that'd be a
> right mess).

Don't even think about trying to put a mutex into the kobj dispatch
sequence. That would make the call several thousand times slower. We
might as well write the kernel in Visual Basic. I've been thinking about
this problem for a long time and I'm certain there is a way to make this
safe without sacrificing performance.

I have an idea I'm working on right now which should work (at least I
haven't managed to disprove it so far) and which would have
approximately the same performance profile as the current mechanism.


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

ACPI and PCI vs interrupt routing on Sony VAIO's

[Iain Templeton]

Hi,

I have a Sony VAIO (PCG-R505TFP) which has an interrupts related problem (this
problem was previous posted elsewhere as "Weird as* sound problem"). This problem
has been confirmed on at least one other Sony VAIO model (I forget which).

They're both Intel i830M chipset based.

Basically, the LNKB interrupt configuration register is not being initialised,
so the interrupt never gets routed, and so the interrupt never gets to the CPU.
Result: Sound doesn't work.

A really hacky solution to this is to run the command:
pciconf -w -b pci0:31:0 0x61 9

which sets the i830's PCI routing register for LNKB to IRQ 9.

I did a bit of digging and found the following bits of information:

1.  When the ACPI PCI bus starts up, it calls all the LNKx.CRS methods to
get the current resources. LNKB (amongst others) returns 0.

2.  The PCI configuration space register for IRQ contains the value 9.

3.  If somebody calls the LNKB.SRS method, it would all work because that
writes the PCI interrupt routing register thingy like pciconf does above.

But the acpi_pcib_route_interrupt() function is not being called because
in pci_alloc_resource() there is a test that checks if the PCI config space
register that contains the interrupt contains a valid number (which it does - 9).

So, basically I think there is something wrong here, which I think is that
ACPI and the generic PCI code (in pci_alloc_resource()) don't agree when it comes
to interrupt management.


Other than saying "the BIOS is broken" (which it is, providing mislead information
and all), is it a fair statement to say that the ACPI CRS method should be trusted
more than the PCI configuration space registers?

If so, then if the PCI conf space register disagrees with the ACPI result, should
the PCI conf space register be updated to show what the ACPI stuff shows?


I'm happy to muddle up a patch that might do this, but I was hoping for a bit
of a guide as to how to do it. I thought initially that I could update the PCI
config space register at the time the LNKs CRS method was called, but quickly
gave up on that because I don't know which device to update...

Could I instead perhaps implement the pci_alloc_resource() method in
acpi_pcib_pci.c which inspects the existing PCI configuration and the ACPI LNK
information and if they differ, put the ACPI value into the PCI configuration
register, then call the pci_alloc_resource() function to finish off.

Then pci_alloc_resource() will see a bad value for the PCI config space IRQ,
and call the PCIB_ROUTE_INTERRUPT method to do the routing.


Or is there a better place (or way) to do this. (Can I even legally call
pci_alloc_resource() from acpi_pcib_pci_alloc_resource()?).

For extra information, here is a rather verbose dmesg and AML dump:

http://starbug.ugh.net.au/~iaint/vaio/dmesg.txt
http://starbug.ugh.net.au/~iaint/vaio/ruri.aml

Oh yeah, not using ACPI is not an option (panics in either PCI or PnP BIOS),
also I think the same problem would exist then since it would still not
try to route interrupts, but I could be wrong.

Iain

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: our compiler can't convert longlong to float? 5.1-RC1

[Kris Kennaway]

On Thu, Jun 05, 2003 at 09:44:38AM +0800, leafy wrote:
> On Tue, Jun 03, 2003 at 03:55:47PM -0700, Kris Kennaway wrote:
> > Post the code it's trying to run.  It's possible it's buggy.
> > 
> > Kris
> #include 
> typedef long long longlong;
> main()
> {
>   longlong ll=1;
>   float f;
>   FILE *file=fopen("conftestval", "w");
>   f = (float) ll;
>   fprintf(file,"%g\n",f);
>   close(file);
>   exit (0);
> }
> 
> this section of code is found in "configure" script in mysql323-client port.

It compiles and runs here without problems.

Kris


pgp0.pgp
Description: PGP signature

Re: SMBFS automounting broken?

[The Anarcat]

I have opened a PR with a cleaner patch:

http://www.freebsd.org/cgi/query-pr.cgi?pr=52959

A.

-- 
Seul a un caractère scientifique ce qui peut être réfuté. Ce qui n'est
pas réfutable relève de la magie ou de la mystique.
- Popper, Karl


pgp0.pgp
Description: PGP signature

Additions to sys/dev/usb/usbdevs

[Andre Guibert de Bruet]

Hi,

I've added definitions for a few of the devices that I have connected up
to my system at the moment.

Regards,

> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/>--- usbdevs.origWed Jun  4 18:10:45 2003
+++ usbdevs Wed Jun  4 18:40:29 2003
@@ -497,6 +497,7 @@
 product CANON N656U0x2206  CANOSCAN N656U
 product CANON S10  0x3041  PowerShot S10
 product CANON S100 0x3045  PowerShot S100
+product CANON S200 0x3065  PowerShot S200
 
 /* CATC products */
 product CATC NETMATE   0x000a  Netmate ethernet adapter
@@ -814,6 +815,7 @@
 product LOGITECH WMJOY 0xc281  WingMan Force joystick 
 product LOGITECH RK53  0xc501  Cordless mouse
 product LOGITECH RB6   0xc503  Cordless keyboard
+product LOGITECH MX700 0xc506  Cordless optical mouse
 product LOGITECH QUICKCAMPRO2  0xd001  QuickCam Pro
 
 /* Lucent products */
@@ -1038,6 +1040,7 @@
 product SHUTTLE EUSCSI_B   0x000b  eUSCSI Bridge
 product SHUTTLE EUSCSI_C   0x000c  eUSCSI Bridge
 product SHUTTLE CDRW   0x0101  CD-RW Device
+product SHUTTLE EUSBORCA   0x0325  eUSB ORCA Quad Reader
 
 /* Siemens products */
 product SIEMENS SPEEDSTREAM0x1001  SpeedStream USB
@@ -1155,6 +1158,7 @@
 product WACOM CT0405U  0x  CT-0405-U Tablet
 product WACOM GRAPHIRE 0x0010  Graphire
 product WACOM INTUOSA5 0x0021  Intuos A5
+product WACOM GD0912U  0x0022  Intuos 9x12 Graphics Tablet
  
 /* Xirlink products */
 product XIRLINK PCCAM  0x8080  IBM PC Camera
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Doug Rabson]

On Tuesday 03 June 2003 12:00 am, Paul Richards wrote:
> On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
> > In message: <[EMAIL PROTECTED]>
> >
> > Paul Richards <[EMAIL PROTECTED]> writes:
> > : The possible methods available in an interface are fixed, they're
> > : defined in the .m files.
> >
> > No it isn't.  One can add additional interfaces at any time without
> > breaking binary compatibility, so you don't know, a priori, the
> > number of methods in a given interface when you build a client of
> > that interface.
>
> I don't think that's true.
>
> The interface is defined in the .m file and it's created using
> makeobjs. You can't do that at runtime because it creates the
> kobj_desc struct that uniquely represents the existence of that
> method globally for the whole of the kobj subsystem. The set of all
> kobj_desc defines all possible methods that can be implemented by an
> object, and yes you can extend that interface later and previously
> built modules will still work because they only implement a subset of
> those possible methods, but the set of all methods that can exist is
> determined at compile time from the interface definitions
>
> A class is then defined which specifies the set of methods that
> objects instantiated into that class *can* implement (but are note
> required to). The set of methods in a class is also fixed, since it's
> basically the method table plus some class fields and the method
> table is created at compile time. Again though, if you later extend
> the class older compiled modules will still work because if the
> method doesn't exist in that older module the default from the
> kobj_desc will be used or the kobj_error_method will be called (which
> is safe).
>
> So yes you can extend the interface and the class and keep backwards
> compatibility but that all happens at compile time, and therefore at
> runtime when the object is instantiated you know the maximum number
> of methods that the object can possibly call.

It is true, I'm afraid. A class is can implement any number of 
interfaces so knowing the compile-time size of an interface doesn't 
help you reserve space for a class. The system is intended to have a 
robust ABI so that e.g. a class implementing an interface can be used 
safely by a kernel in which new methods have been added to that 
interface.

The class is a concrete definition of a set of methods (at this level, 
the interfaces are mostly ignored). Objects instantiated in that class 
use exactly that set of methods, no more, no less. There is no choice 
involved. You appear to be confusing class and interface here.

This incarnation of kobj uses a smallish fixed-size method dispatch 
table, with hashing. A previous version (embedded into 4.x's newbus) 
allocated space in the method dispatch table for every interface which 
was currently resident in the kernel. This was fine when the expected 
number of interfaces was small but as the number of interfaces 
increases, the wasted space per-class increases unacceptably. This is 
the sole reason for changing the method-dispatch algorithm for kobj.

The only valid objection to kobj at this point is that resolving hash 
collisions is not SMP safe. I believe that this is a limitation which 
can be overcome without pessimising the dispatch mechanism.

Performance is not an issue. The performance of method dispatch in kobj 
is very slightly slower than a vtable-style array of function pointers 
but the difference is barely measurable. Given the behaviour of modern 
caches, it is possible to make nearly as many kobj method calls per 
second as normal function calls.

-- 
Doug Rabson Mail:  [EMAIL PROTECTED]
Phone: +44 20 8348 6160


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Missing file geom_vol_ffs on buildkernel?

[Skip Ford]

Mike Loiterman wrote:
> 
> ===> geom/geom_vol_ffs
> I'm getting this error when I buildkernel:
> 
> cd: can't cd to /usr/src/sys/modules/geom/geom_vol_ffs
> *** Error code 2
>
> Google search just showed that this was added in the beginning of May
> '03.  Any ideas?

cvs update -d

-- 
Skip
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: phoenix crash in libc_r on sparc64

[Kris Kennaway]

On Mon, Jun 02, 2003 at 04:15:43PM -0700, Kris Kennaway wrote:
> phoenix on my sparc64 crashed while idle with the following:
> 
> Fatal error '_waitq_insert: Already in queue' at line 321 in file 
> /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 2)
> 
> Any ideas?
> 
> Kris

One of the libc_r tests seems to hang:

Test static library:
--
Test  c_user c_system c_total chng
 passed/FAILEDh_user h_system h_total   % chng
--
hello_d 0.00 0.020.02
 passed
--
hello_s 0.00 0.020.02
 passed
--
join_leak_d 0.77 0.180.95
 passed
--
mutex_d 9.0892.42  101.50
 passed
--
sem_d   0.01 0.020.02
 passed
--
sigsuspend_d0.00 0.020.02
 passed
--
sigwait_d   0.00 0.020.02
 *** FAILED ***
--
guard_s.pl

It's been sitting there for hours now.

Kris 

P.S. Why do 3 of the tests even fail on i386?



pgp0.pgp
Description: PGP signature

Re: viapropm doesnt like sys/dev/pci.c rev 1.214

[David P. Reese Jr.]

On Wed, Jun 04, 2003 at 07:29:31AM +, Nicolas Souchu wrote:
> On Tue, Jun 03, 2003 at 10:54:30AM -0700, David P. Reese Jr. wrote:
> 
> [...]
> > : The datasheet states that the command bits are RW but "fixed at 0".
> > 
> > A snip of code from sys/dev/pci/pci.c:pci_enable_io_method():
> > 
> > pci_set_command_bit(dev, child, bit);
> > command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
> > if (command & bit)
> > return (0);
> > device_printf(child, "failed to enable %s mapping!\n", error);
> > return (ENXIO);
> > 
> > Because the viapropm's command register bits will always read as zero,
> > this code will always fail when trying to enable port mapping.
> > 
> > Whatever problems viapropm may have, it is the new pci code that prevents it
> > from attaching.  It is not the fault of anything in sys/pci/viapm.c.
> 
> And I personally don't know how to fix it except by an option with an
> ifdef to workaround it.

How about adding another flag to bus_alloc_resource() which would signal
that we are not to check the value of the command register after calling
pci_set_command_bit().

RF_WILLFAIL?

After pci_enable_io_method() gets swallowed into pci_alloc_resource(),
this would be pretty easy because the flag would be in scope when we
check the value of the command register.

I can do so this weekend if anyone thinks this is worthwhile.

-- 

   David P. Reese Jr.  [EMAIL PROTECTED]
   --
   It can be argued that returning a NULL pointer when asked to allocate
   zero bytes is a silly response to a silly question.
 -- FreeBSD manual page for malloc(3)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Bryan Liesner]

On Tue, 3 Jun 2003, Robert Watson wrote:

>
> On Tue, 3 Jun 2003, Bryan Liesner wrote:
>
> > Actually, no it doesn't.  I was able to use kern_umtx v 1.3 only if I
> > removed atapicam from my kernel config.  These patches (now committed?)
> > panic the system whether I use atapicam or not.  With kern_umtx v1.2
> > there is no panic at all, with or without atapicam.
> >
> > Actually, I think it's cam in general that's causing the panic with
> > these changes.
>
> Bizarre.  Sounds like an errant pointer in some other code, and it's just
> a matter of the memory layout as to what gets stepped on.  Alternatively,
> it might be affected by the insertion of the MTX sysinit event.  Perhaps
> that revision rearranges memory a bit.

Even more bizarre.  I have cvsupped to the latest source, built a
kernel with DDB and it won't panic.  Without DDB, it panics.  But the
behavior has changed a bit. I now panics _without_ atapicam in the
build, at boot time.  With atapicam, it panics and dumps core if I do
an init 6.  Savecore refuses to grab the dump:

gravy savecore: first and last dump headers disagree on /dev/ad0s1b
gravy savecore: unsaved dumps found but not saved

I cleared the dump and tried again with the same results.

If I reboot with the USB drive mounted, it will panic on the init 6,
unmounted, it reboots without trouble.

Any hints on grabbing a dump without savecore complaining, please let
me know.  I don't have anything specific to report yet, when I have
time tomorrow I'll try to get more information out.

>
> Anyhow, here are some things you might consider, since this whole thing is
> so odd.  Try merging the addition of the struct mtx declaration from 1.3
> into 1.2 and see if you get the same panic.  If you don't, try merging the
> MTX_SYSINIT line and see if that triggers the panic.  The other changes
> probably wouldn't cause disruptive memory rearrangement, so see what
> happens.  If the panics appear with the addition of the variable, it
> probably is a memory stepping thing and a bug in some other piece of code
> (unfortunately, probably hard to track down).  If it's the addition of the
> initializer, it's a different class of problem.

Right now I'm at rev 1.4 of kern_umtx... I'll try reverting back and
trying this time permitting...


> I have to admit that I'm also fairly baffled: my current reading of the
> change suggests there won't be a specific bug in umtx, rather, the
> triggering of symptoms from another bug, but I guess we can only find out
> with a bit of experimentation.  You might also find the problem
> "disappears" if you remove INVARIANTS, although given that you can
> reproduce this nicely, I'm reluctant to have you do that for fear the bug
> will get away and not get fixed.

INVARIANTS wasn't in the picture to begin with.  If I put it in, it
will probably disappear, as with using DDB.  The code has changed
sufficiently now that I can't reproduce the original panic that's in
the PR, but it's still panicking...


-- 
=
= Bryan D. LiesnerLeezSoft Communications, Inc. =
= A subsidiary of LeezSoft Inc. =
= [EMAIL PROTECTED]   Home of the Gipper=
=
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Missing file geom_vol_ffs on buildkernel?

[Mike Loiterman]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

===> geom/geom_vol_ffs
I'm getting this error when I buildkernel:

cd: can't cd to /usr/src/sys/modules/geom/geom_vol_ffs
*** Error code 2

Stop in /usr/src/sys/modules/geom.
*** Error code 1

Stop in /usr/src/sys/modules.
*** Error code 1

Stop in /usr/obj/usr/src/sys/GENERIC.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
enola# cd /usr/src/sys/modules/geom/geom_vol_ffs
/usr/src/sys/modules/geom/geom_vol_ffs: No such file or directory.

Google search just showed that this was added in the beginning of May
'03.  Any ideas?
- --
Mike Loiterman
grantADLER Medical Corporation
Tel: 630-302-4944
Fax: 773-868-0071
Email: [EMAIL PROTECTED]
PGP Key 0xD1B9D18E

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2
Comment: This message has been digitally signed by Mike Loiterman

iQA/AwUBPt2RXGjZbUnRudGOEQLWhwCg/wp8qGM2ZLIOOBJpVFbO7Xx53OcAoIJs
uOG1MSRzudz8xa+lKvX0RLBT
=DeIi
-END PGP SIGNATURE-

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Jeff Roberson]

On Tue, 3 Jun 2003, Terry Lambert wrote:

> Scott Long wrote:
> > Bryan Liesner wrote:
> > It's very hard to imagine Jeff's patches causing a problem at the point
> > that the PR mentions.  Have you confirmed the problem in a kernel that
> > was build in a totally clean environment?
>
> The changed code is not protecting a traversal of a proc
> struct member with a proc lock in two places.  What's hard
> to imagine?
>

This is no longer the case with the latest revision.  Apparently the
panics in cam continue even after the proc lock issues were fixed.

> Even if it's weren't necessary to protect that FOREACH loop
> (it's necessary; but even if it weren't...), locking the
> proc could easily serialize a number of operations through
> that or other code which could save it from interference.
>
> -- Terry
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: A possible bug?

[Donn Miller]

Zbynek Houska wrote:
Dear all,

  when I tryied to mount an iso image over network (using samba) my computer
unexpectedly crashed.
 I issued this command : mdconfig -a -t vnode -f
/path/to/my/file/mounted/on-local-machine
 and since that kernel crashed, no ping response, nothing at all. I've been
connected to this machine via ssh.
I use 5.0 RELEASE with GENERIC kernel on P3/1 Ghz, 128 MB RAM.
It happens again when I issue same command and therefore I tryied to add
"dumpon=Yes" to my /etc/rc.conf, but nothing has been written to /var/crash.
So I enclose message from screen:
Fatal trap 12   : page fault while in kernel mode
faukt virtual address = 0x0
fault code= supervisor read, page not present
instruction pointer= 0x8:0xc1c50d4a
stack pointer   = 0x10:0xcd1b8718
frame pointer   = 0x10:0xcd1b8738
code segment = base 0x0, limit 0xf, type 0x1b
 = DPL 0, pres 1, def31 1, gran 1
processor eflags  = interrupt enabled,  resume,IOPL = 0
current proccess = 549 (mdconfig)
trap number= 12
panic:fault page
I'm seeing the same thing with 5.1-RC1.  Tried to mount an ISO image 
with mdconfig -a -t vnode -f isofile -u 0 and FreeBSD immediately 
panic-ed.  The iso file resided on a samba mount, which I had mounted 
with mount_smbfs.  I'll try cp-ing the file to my local UFS filesystem, 
and then try mdconfig, and see if I get the panic again.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Terry Lambert]

Scott Long wrote:
> Bryan Liesner wrote:
> It's very hard to imagine Jeff's patches causing a problem at the point
> that the PR mentions.  Have you confirmed the problem in a kernel that
> was build in a totally clean environment?

The changed code is not protecting a traversal of a proc
struct member with a proc lock in two places.  What's hard
to imagine?

Even if it's weren't necessary to protect that FOREACH loop
(it's necessary; but even if it weren't...), locking the
proc could easily serialize a number of operations through
that or other code which could save it from interference.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HD Speed Benchmark

[Terry Lambert]

"Sebastian Yepes [ESN]" wrote:
> I have made some  Benchmark on my inspiron 8500  (Intel 82801DB (ICH4) -
> UDMA100)
> and i am geting very Bad results on the 5.1, i have got beter results on 5.0
> 
> dmesg
> --
> 5.0R -->  http://www.x123.info/src/i8500/dmesg.5.0R
> 5.1B2 -->  http://www.x123.info/src/i8500/dmesg.5.1B2

ad0: 28615MB  [58140/16/63] at ata0-master BIOSDMA
ad0: 28615MB  [58140/16/63] at ata0-master UDMA100

Notice the firrence in DMA messages... probably has a little to
do with it, don't you think?

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Terry Lambert]

Paul Richards wrote:
> On Mon, Jun 02, 2003 at 09:04:11AM -0700, Hiten Pandya wrote:
> >   And how many times is vfc_register() called?  Its not in the
> >   patch of an I/O operation or anything.  Its just a mount time
> >   overhead which will go through -- a one time thing.
> >
> > On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote:
> > > Consider this going forward: someone adds a new VFSOP to the
> > > list of allowable VFSOPs, and the vfs_init() doesn't have any
> > > specific code for it.
> 
> You should look at kobj, it's precisely this sort of dynamic
> dispatching that it was designed to support.

I think it's inappropriate technology for the VFSOP and VOP
cases.  The real issue with VFSOP and VOP calls is that they
are call-by-descriptor, and the descriptor reference can be
proxied across a protection domain, no problem, as long as
there are not weird defaults.

For example, with a proxy in and out of the kernel of a top
and bottem end named pipe/socket/other datia serialization
interface, it's possible to do VFS stacking layer develeopement
in user space, where there are better debugging tools, and where
a failure is not fatal to the kernel.  That means that the
developement can proceed much rapidly from prototype to the
finished product.

It's also possible to proxy over a network; this provides a
means of implementing an extensible network file system
framework (like that which was prototyped by John Heidemann's
students) to implement operations, as needed.  One of the
widely acknowledged weaknesses of NFS is it's inability to
be meaningfully extended for things like extended attributes,
ACLs, mandatory access controls, etc. -- all things requiring
VFSOPs or VOPs to to b added to the protocol, structures
defined, agreed upon by both parties, etc., etc..

With the descriptor mechanism, I may pass from the system call
interface to a quiota stacking layer on a local machine, to a
crypto stacking layer on a border machine, over the Internet,
to a crypto layer on another border machine at the remote site,
to a local machine at the remote site, and then down to FFS and
from there to a local disk array.

Not only that, the middle layers don't have to know all the VOPs
descriptors, because they pass them through unmolested, and so
the border machines are unaware of how to decode the content
they are transiting.

I really can't do this with kobj; with kobj, I can only pass
the interface references around within a single protection
domain on a single machine.

-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: viapropm doesnt like sys/dev/pci.c rev 1.214

[Nicolas Souchu]

On Tue, Jun 03, 2003 at 10:54:30AM -0700, David P. Reese Jr. wrote:

[...]
> : The datasheet states that the command bits are RW but "fixed at 0".
> 
> A snip of code from sys/dev/pci/pci.c:pci_enable_io_method():
> 
> pci_set_command_bit(dev, child, bit);
> command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
> if (command & bit)
> return (0);
> device_printf(child, "failed to enable %s mapping!\n", error);
> return (ENXIO);
> 
> Because the viapropm's command register bits will always read as zero,
> this code will always fail when trying to enable port mapping.
> 
> Whatever problems viapropm may have, it is the new pci code that prevents it
> from attaching.  It is not the fault of anything in sys/pci/viapm.c.

And I personally don't know how to fix it except by an option with an
ifdef to workaround it.

-- 
Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Robert Watson]

On Tue, 3 Jun 2003, Bryan Liesner wrote:

> Actually, no it doesn't.  I was able to use kern_umtx v 1.3 only if I
> removed atapicam from my kernel config.  These patches (now committed?)
> panic the system whether I use atapicam or not.  With kern_umtx v1.2
> there is no panic at all, with or without atapicam. 
> 
> Actually, I think it's cam in general that's causing the panic with
> these changes. 

Bizarre.  Sounds like an errant pointer in some other code, and it's just
a matter of the memory layout as to what gets stepped on.  Alternatively,
it might be affected by the insertion of the MTX sysinit event.  Perhaps
that revision rearranges memory a bit.

Anyhow, here are some things you might consider, since this whole thing is
so odd.  Try merging the addition of the struct mtx declaration from 1.3
into 1.2 and see if you get the same panic.  If you don't, try merging the
MTX_SYSINIT line and see if that triggers the panic.  The other changes
probably wouldn't cause disruptive memory rearrangement, so see what
happens.  If the panics appear with the addition of the variable, it
probably is a memory stepping thing and a bug in some other piece of code
(unfortunately, probably hard to track down).  If it's the addition of the
initializer, it's a different class of problem. 

I have to admit that I'm also fairly baffled: my current reading of the
change suggests there won't be a specific bug in umtx, rather, the
triggering of symptoms from another bug, but I guess we can only find out
with a bit of experimentation.  You might also find the problem
"disappears" if you remove INVARIANTS, although given that you can
reproduce this nicely, I'm reluctant to have you do that for fear the bug
will get away and not get fixed.

Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED]  Network Associates Laboratories


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: libmap.conf has the bug or not work correct?

[Jeremy Messenger]

On Tue, 3 Jun 2003 22:51:59 -0400 (EDT), Matthew N. Dodd <[EMAIL PROTECTED]> 
wrote:

On Tue, 3 Jun 2003, Jeremy Messenger wrote:
It seems like the [/path/to/exec] and [exec] don't work?
ftp://ftp.jurai.net/users/winter/libmap-test.tar

Untar that in src/libexec/rtld-elf/
cd test/
make
./test-libmap /path/to/exec library-name

# ./test-libmap /usr/X11R6/bin/ggv libc_r.so.5
Lookup of "libc_r.so.5" for "/usr/X11R6/bin/ggv" -> "libc_r.so.5"


# ./test-libmap /usr/X11R6/bin/ggv libthr.so.1
[...etmpy...]


# cat /etc/libmap.conf
libc_r.so.5 libthr.so.1
libc_r.so   libthr.so
[/usr/X11R6/bin/ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so
[ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so

Cheers,
Mezz
--
bsdforums.org 's moderator, mezz.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: libmap.conf has the bug or not work correct?

[Matthew N. Dodd]

On Tue, 3 Jun 2003, Jeremy Messenger wrote:
> It seems like the [/path/to/exec] and [exec] don't work?

ftp://ftp.jurai.net/users/winter/libmap-test.tar

Untar that in src/libexec/rtld-elf/
cd test/
make
./test-libmap /path/to/exec library-name


-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: libmap.conf has the bug or not work correct?

[Jeremy Messenger]

On Tue, 03 Jun 2003 21:04:11 -0500, Jeremy Messenger <[EMAIL PROTECTED]> wrote:

On Tue, 3 Jun 2003 18:01:52 -0700, David P. Reese Jr. 
<[EMAIL PROTECTED]> wrote:

On Tue, Jun 03, 2003 at 03:50:00PM -0500, Jeremy Messenger wrote:
I am trying to get ggv link against libc_r instead libthr, but it 
doesn't work as expect.. Maybe, I must have done something wrong?
Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c.  It 
fixes a bug in the libmap.conf parsing code.
I downgrade from 1.7 -> 1.6 and the problem is still there. I CVSup'ed 
yesterday around 30 to 45 minutes before my 'uname -a' in the bottom.
Here's more info It works if my libmap.conf looks like:


# cat /etc/libmap.conf
libc_r.so.5		libc_r.so.5	# Before was libthr
libc_r.so		libc_r.so	# ^
   
   [/usr/X11R6/bin/ggv]
libc_r.so.5		libc_r.so.5
libc_r.so		libc_r.so

[ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so

Result:

# ldd /usr/X11R6/bin/ggv | grep libc
   libc.so.5 => /usr/lib/libc.so.5 (0x28a68000)
   libc_r.so.5 => /usr/lib/libc_r.so.5 (0x28b49000)

It seems like the [/path/to/exec] and [exec] don't work?

Cheers,
Mezz

# cat /etc/libmap.conf
libc_r.so.5 libthr.so.1
libc_r.so   libthr.so
[/usr/X11R6/bin/ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so
[ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so


# uname -a
FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon 
Jun 2 20:23:45 CDT 2003 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ  i386


I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv 
then reinstall them, but no luck. The ggv is still linking to libthr 
instead libc_r.. Also, ggv isn't only one app that I tried. I did tried 
with gst-register and no luck to change the link to libc_r.


# ldd /usr/X11R6/bin/ggv | grep libc
libc.so.5 => /usr/lib/libc.so.5 (0x28a68000)
libc_r.so.5 => /usr/lib/libthr.so.1 (0x28b49000)

Do anyone have any hint?

Cheers,
Mezz
-- bsdforums.org 's moderator, mezz.





--
bsdforums.org 's moderator, mezz.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: libmap.conf has the bug or not work correct?

[Jeremy Messenger]

On Tue, 3 Jun 2003 18:01:52 -0700, David P. Reese Jr. <[EMAIL PROTECTED]> 
wrote:

On Tue, Jun 03, 2003 at 03:50:00PM -0500, Jeremy Messenger wrote:
I am trying to get ggv link against libc_r instead libthr, but it 
doesn't work as expect.. Maybe, I must have done something wrong?
Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c.  It 
fixes a bug in the libmap.conf parsing code.
I downgrade from 1.7 -> 1.6 and the problem is still there. I CVSup'ed 
yesterday around 30 to 45 minutes before my 'uname -a' in the bottom.

Cheers,
Mezz

# cat /etc/libmap.conf
libc_r.so.5 libthr.so.1
libc_r.so   libthr.so
[/usr/X11R6/bin/ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so
[ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so


# uname -a
FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun 
2 20:23:45 CDT 2003 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ  i386


I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv then 
reinstall them, but no luck. The ggv is still linking to libthr instead 
libc_r.. Also, ggv isn't only one app that I tried. I did tried with 
gst-register and no luck to change the link to libc_r.


# ldd /usr/X11R6/bin/ggv | grep libc
libc.so.5 => /usr/lib/libc.so.5 (0x28a68000)
libc_r.so.5 => /usr/lib/libthr.so.1 (0x28b49000)

Do anyone have any hint?

Cheers,
Mezz
-- bsdforums.org 's moderator, mezz.



--
bsdforums.org 's moderator, mezz.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: s4bios

[Mark Santcroos]

On Tue, Jun 03, 2003 at 04:01:16PM -0700, Hiten Pandya wrote:
>   Hello Mark, I may not be totally correct, but it has always
>   helped me to check if a particular ACPI state was supported by
>   my system:
> 
>   # sysctl hw.acpi.supported_sleep_state
>   hw.acpi.supported_sleep_state: S1 S4 S5

Yeah, too tired right now to see where that gets decided in the code, but I 
knew/know that my laptop supports S4BIOS. (The S4BIOS_F flag in the FACS)

Mark

-- 
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: s4bios on Dell Latitude C640

[Mark Santcroos]

I gave it a final try and mounted an empty disk into my laptop.

Using the MKS2D.EXE found on the Dell support site I created a hibernation
partition on the beginning of the disk (It needs to be within 8 GB of the
start of the disk).

And guess what... I can now suspend to disk using "acpiconf -s 4", no more
shutting down for me! ;-)

I created a nice script that modifies boot0 before and after calling
"acpiconf -s 4" so that the suspend partition only shows when you are
rebooting after a suspend. I will post that later, it's on my other disk
that is not mounted now.

Happy, (Well, I still have to repartition my laptop, but ok ... )

Mark

-- 
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: s4bios

[The Anarcat]

On Tue Jun 03, 2003 at 06:17:10PM -0700, Kevin Oberman wrote:
> > Date: Tue, 3 Jun 2003 16:03:19 -0400
> > From: The Anarcat <[EMAIL PROTECTED]>
> > Sender: [EMAIL PROTECTED]
> > 
> > I put my test results in:
> > 
> > http://anarcat.ath.cx/acpi-test/
> > 
> > I have done other tests using a build made after the recent ACPI
> > import and bugfixes, and I will update the info there when completely
> > done.
> 
> Could you add the result of "sysctl hw.acpi"? As is, it's not clear that
> your platform supports S1. The output will also let you know about a
> number of other things.

Done!

More tests results underway, I'll just have to find some time to write
them down...

A.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker
http://www.ad-mad.co.uk/quotes/freespeech.htm


pgp0.pgp
Description: PGP signature

Re: fxp0: device timeout with 5.1BETA2

[Kevin Oberman]

> Date: Tue, 3 Jun 2003 23:00:21 +0200
> From: Tobias Roth <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> Hi
> 
> I still get a 
> 
> fxp0: device timeout
> 
> on my Thinkpad T30 with a newly installed 5.1BETA2. Browsing the
> archives showed that people had success with 
> 
> hint.fxp.0.prefer_iomap="1"
> 
> on a T30 and 5.1BETA1. Any ideas why this doesn't help in my case?

Odd. I have not seen this on my T30 running a CURRENT from May 29 (or
almost Beta2). I do not have any hint like you suggest, either. My fxp0
has been working very well.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: s4bios

[Kevin Oberman]

> Date: Tue, 3 Jun 2003 16:03:19 -0400
> From: The Anarcat <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
> I put my test results in:
> 
> http://anarcat.ath.cx/acpi-test/
> 
> I have done other tests using a build made after the recent ACPI
> import and bugfixes, and I will update the info there when completely
> done.

Could you add the result of "sysctl hw.acpi"? As is, it's not clear that
your platform supports S1. The output will also let you know about a
number of other things.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: libmap.conf has the bug or not work correct?

[David P. Reese Jr.]

On Tue, Jun 03, 2003 at 03:50:00PM -0500, Jeremy Messenger wrote:
> I am trying to get ggv link against libc_r instead libthr, but it doesn't 
> work as expect.. Maybe, I must have done something wrong?

Make sure that you have rev 1.6 of src/libexec/rtld-elf/libmap.c.  It fixes
a bug in the libmap.conf parsing code.

> 
> # cat /etc/libmap.conf
> libc_r.so.5   libthr.so.1
> libc_r.so libthr.so
> 
> [/usr/X11R6/bin/ggv]
> libc_r.so.5   libc_r.so.5
> libc_r.so libc_r.so
> 
> [ggv]
> libc_r.so.5   libc_r.so.5
> libc_r.so libc_r.so
> 
> 
> 
> # uname -a
> FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun  2 
> 20:23:45 CDT 2003 
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ  i386
> 
> 
> I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv then 
> reinstall them, but no luck. The ggv is still linking to libthr instead 
> libc_r.. Also, ggv isn't only one app that I tried. I did tried with gst- 
> register and no luck to change the link to libc_r.
> 
> 
> # ldd /usr/X11R6/bin/ggv | grep libc
>libc.so.5 => /usr/lib/libc.so.5 (0x28a68000)
>libc_r.so.5 => /usr/lib/libthr.so.1 (0x28b49000)
> 
> 
> Do anyone have any hint?
> 
> Cheers,
> Mezz
> 
> 
> -- 
> bsdforums.org 's moderator, mezz.

-- 

   David P. Reese Jr.  [EMAIL PROTECTED]
   --
   It can be argued that returning a NULL pointer when asked to allocate
   zero bytes is a silly response to a silly question.
 -- FreeBSD manual page for malloc(3)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RELENG_4 to RELENG_5_1

[Munish Chopra]

On 2003-06-04 10:15 +, Matthew Gardiner wrote:
> >>
> 
> Just a quick question, what version of GCC is going to appear in FreeBSD
> 5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its
> stability) will be used for 5.2. Could someone either confirm or correct me
> on this assumption?
> 
> Matthew Gardiner

According to the 5.2 TODO list it's GCC 3.3.

-- 
Munish Chopra
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RELENG_4 to RELENG_5_1

[Crist J. Clark]

On Wed, Jun 04, 2003 at 10:15:41AM +1000, Matthew Gardiner wrote:
> >>
> >> Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I
> >> have been getting the same failure originally quoted when building
> >> HEAD on RELENG_4 for several days now.
> >>
> >> I suggest that the original poster double-check that he has RELENG_5_1
> >> and not HEAD. And I do have buildworld logs. I'll send in a separate
> >> mail.
> >
> > No need that. This is a bug and it needs to be fixed. I am working on
> > this. Thanks for the reports.
> 
> Just a quick question, what version of GCC is going to appear in FreeBSD
> 5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its
> stability) will be used for 5.2. Could someone either confirm or correct me
> on this assumption?

gcc 3.2.2 is in RELENG_5_1.
-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: RELENG_4 to RELENG_5_1

[Matthew Gardiner]

>>
>> Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I
>> have been getting the same failure originally quoted when building
>> HEAD on RELENG_4 for several days now.
>>
>> I suggest that the original poster double-check that he has RELENG_5_1
>> and not HEAD. And I do have buildworld logs. I'll send in a separate
>> mail.
>
> No need that. This is a bug and it needs to be fixed. I am working on
> this. Thanks for the reports.

Just a quick question, what version of GCC is going to appear in FreeBSD
5.1? I heard that it maybe GCC 3.2.3 and that GCC 3.3 (depending on its
stability) will be used for 5.2. Could someone either confirm or correct me
on this assumption?

Matthew Gardiner

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: can't boot from 4.8-RELEASE distribution CD (and 5.1-BETA2)

[Guy Middleton]

I found the problem; it only occurs if I try to boot with my Palm cradle
attached to COM1.  Remove it, and everything works fine.

On Fri, May 30, 2003 at 11:20:27PM -0400, Guy Middleton wrote:
> I'm posting a follup to -current, since I get a similar but different problem
> with the 5.1-BETA2 CD.
> 
> With 5.1-BETA2, the boot gets a far as the "Probing devices, please wait"
> message, then hangs.  The last debug output on the console is:
> 
> 
> DEBUG: Loading module if_sf.ko (Adaptec AIC-6915 PCI ethernet card)
> module_register: module pci/sf already exists!
> Module pci/sf failed to register: 17
> module_register: module sf/miibus already exists!
> Module sf/miibus failed to register: 17
> 
> 
> 
> On Fri, May 30, 2003 at 09:23:25PM -0400, Guy Middleton wrote:
> > I have a FreeBSD 4.1 system, which I am trying to upgrade to 4.8-RELEASE.
> > 
> > Unfortunately, it can't boot from the 4.8 distribution CD.  When the
> > generic kernel boots, it hangs indefinitely after finding plip0.
> > 
> > I have also tried the 4.3 and 4.7 CDs, the same thing happens with them.
> > So something changed betweek 4.1 and 4.3 (I don't have a 4.2 CD to try).
> > Anybody have any ideas?
> > 
> > Here is dmesg output, on the system as booted with 4.1-RELEASE:
> > 
> > 
> > Copyright (c) 1992-2000 The FreeBSD Project.
> > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
> > The Regents of the University of California. All rights reserved.
> > FreeBSD 4.1-RELEASE #0: Fri Jul 28 14:30:31 GMT 2000
> > [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC
> > Timecounter "i8254"  frequency 1193182 Hz
> > CPU: Pentium III/Pentium III Xeon/Celeron (451.03-MHz 686-class CPU)
> >   Origin = "GenuineIntel"  Id = 0x672  Stepping = 2
> >   
> > Features=0x383f9ff
> > real memory  = 134205440 (131060K bytes)
> > avail memory = 126386176 (123424K bytes)
> > Preloaded elf kernel "kernel" at 0xc040d000.
> > Pentium Pro MTRR support enabled
> > md0: Malloc disk
> > npx0:  on motherboard
> > npx0: INT 16 interface
> > pcib0:  on motherboard
> > pci0:  on pcib0
> > pcib1:  at device 1.0 on pci0
> > pci1:  on pcib1
> > pci1: <3Dfx Voodoo 3 graphics accelerator> at 0.0 irq 11
> > isab0:  at device 4.0 on pci0
> > isa0:  on isab0
> > atapci0:  port 0xb800-0xb80f at device 4.1 on pci0
> > ata0: at 0x1f0 irq 14 on atapci0
> > ata1: at 0x170 irq 15 on atapci0
> > uhci0:  port 0xb400-0xb41f at device 4.2 
> > on pci0
> > uhci0: Invalid irq 255
> > uhci0: Please switch on USB support and switch PNP-OS to 'No' in BIOS
> > device_probe_and_attach: uhci0 attach returned 6
> > chip1:  port 0xe800-0xe80f at device 
> > 4.3 on pci0
> > ahc0:  port 0xb000-0xb0ff mem 
> > 0xdd80-0xdd800fff irq 9 at device 6.0 on pci0
> > ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs
> > fxp0:  port 0xa800-0xa81f mem 
> > 0xdd00-0xdd0f,0xe100-0xe1000fff irq 5 at device 7.0 on pci0
> > fxp0: Ethernet address 00:e0:18:98:3b:2f
> > pci0:  (vendor=0x1274, dev=0x5000) at 10.0 irq 5
> > dc0: <82c169 PNIC 10/100BaseTX> port 0xa000-0xa0ff mem 0xdc80-0xdc8000ff irq 
> > 10 at device 11.0 on pci0
> > dc0: Ethernet address: 00:a0:cc:3b:f9:c4
> > miibus0:  on dc0
> > ukphy0:  on miibus0
> > ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> > fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
> > fdc0: FIFO enabled, 8 bytes threshold
> > fd0: <1440-KB 3.5" drive> on fdc0 drive 0
> > atkbdc0:  at port 0x60,0x64 on isa0
> > atkbd0:  flags 0x1 irq 1 on atkbdc0
> > kbd0 at atkbd0
> > psm0:  irq 12 on atkbdc0
> > psm0: model MouseMan+, device ID 0
> > vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
> > sc0:  at flags 0x100 on isa0
> > sc0: VGA <16 virtual consoles, flags=0x300>
> > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
> > sio0: type 16550A
> > sio1 at port 0x2f8-0x2ff irq 3 on isa0
> > sio1: type 16550A
> > ppc0:  at port 0x378-0x37f irq 7 on isa0
> > ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
> > ppc0: FIFO with 16/16/9 bytes threshold
> > ppi0:  on ppbus0
> > lpt0:  on ppbus0
> > lpt0: Interrupt-driven port
> > plip0:  on ppbus0
> > acd0: CDROM  at ata0-master using PIO4
> > afd0: 239MB  [239/64/32] at ata1-master using PIO3
> > Waiting 15 seconds for SCSI devices to settle
> > Mounting root from ufs:/dev/da0s2a
> > cd0 at ahc0 bus 0 target 3 lun 0
> > cd0:  Removable CD-ROM SCSI-2 device 
> > cd0: 8.333MB/s transfers (8.333MHz, offset 31)
> > cd0: Attempt to query device size failed: NOT READY, Medium not present - tray 
> > closed
> > da1 at ahc0 bus 0 target 5 lun 0
> > da1:  Fixed Direct Access SCSI-2 device 
> > da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled
> > da1: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C)
> > da0 at ahc0 bus 0 target 4 lun 0
> > da0:  Fixed Direct Access SCSI-2 device 
> > da0: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled
> > da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C)

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Wed, 2003-06-04 at 00:03, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Paul Richards wr
> ites:
> >On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:
> 
> >> I thought the point in KOBJ was that it was extensible so you could
> >> KLD load stuff which added more methods ?
> >
> >Not exactly. It allows for dynamic binding of methods that implement a
> >specified interface. It gives you 2 things mainly:
> >
> >The possible methods available in an interface are fixed, they're
> >defined in the .m files.
> 
> Then I don't see the justification for the hashing & caching when it
> can be resolved at compile time...

kobj basically provides us with some OO type functionality. The linkage
can't be determined at compile time since you don't know what methods an
object is going to implement or what actual function implements a
particular method until the object is instantiated, it's sort of late
binding.

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fxp0: device timeout with 5.1BETA2

[Paul Richards]

On Tue, 2003-06-03 at 23:17, Tobias Roth wrote:
> On Mon, Jun 02, 2003 at 10:59:22PM +0100, Paul Richards wrote:
> > On Tue, 2003-06-03 at 22:00, Tobias Roth wrote:
> > > 
> > > fxp0: device timeout
> > > 
> > 
> > I get these as well. Is it on irq9 by any chance, along with acpi0 ?
> 
> No. It's on irc 11 device 8 (as dmesg states). All irqs in bios are
> set to 11 (factory default). ACPI is disabled.

Ok, well that's a useful data point (for me anyway) since it means
there's a problem with fxp losing interrupts that's not related to some
other ACPI problems I've experienced, suggesting that it's therefore a
fxp driver problem.

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Paul Richards wr
ites:
>On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:

>> I thought the point in KOBJ was that it was extensible so you could
>> KLD load stuff which added more methods ?
>
>Not exactly. It allows for dynamic binding of methods that implement a
>specified interface. It gives you 2 things mainly:
>
>The possible methods available in an interface are fixed, they're
>defined in the .m files.

Then I don't see the justification for the hashing & caching when it
can be resolved at compile 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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Tue, 2003-06-03 at 23:09, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Paul Richards <[EMAIL PROTECTED]> writes:
> : The possible methods available in an interface are fixed, they're
> : defined in the .m files.
> 
> No it isn't.  One can add additional interfaces at any time without
> breaking binary compatibility, so you don't know, a priori, the number
> of methods in a given interface when you build a client of that
> interface.

I don't think that's true.

The interface is defined in the .m file and it's created using makeobjs.
You can't do that at runtime because it creates the kobj_desc struct
that uniquely represents the existence of that method globally for the
whole of the kobj subsystem. The set of all kobj_desc defines all
possible methods that can be implemented by an object, and yes you can
extend that interface later and previously built modules will still work
because they only implement a subset of those possible methods, but the
set of all methods that can exist is determined at compile time from the
interface definitions

A class is then defined which specifies the set of methods that objects
instantiated into that class *can* implement (but are note required to).
The set of methods in a class is also fixed, since it's basically the
method table plus some class fields and the method table is created at
compile time. Again though, if you later extend the class older compiled
modules will still work because if the method doesn't exist in that
older module the default from the kobj_desc will be used or the
kobj_error_method will be called (which is safe).

So yes you can extend the interface and the class and keep backwards
compatibility but that all happens at compile time, and therefore at
runtime when the object is instantiated you know the maximum number of
methods that the object can possibly call.

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: s4bios

[Hiten Pandya]

On Tue, Jun 03, 2003 at 05:32:05PM +0200, Mark Santcroos wrote:
> Is there anyone that has succesfully used "acpiconf -s 4"?
> 
> I'm very interested in your reports. If you haven't tried yet, but are
> willing to help me, please report me your findings.

Hello Mark, I may not be totally correct, but it has always
helped me to check if a particular ACPI state was supported by
my system:

# sysctl hw.acpi.supported_sleep_state
hw.acpi.supported_sleep_state: S1 S4 S5

Cheers.

-- Hiten ([EMAIL PROTECTED])
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: our compiler can't convert longlong to float? 5.1-RC1

[Kris Kennaway]

On Tue, Jun 03, 2003 at 11:40:40PM +0800, leafy wrote:
> I got this strange message and a core dump after installing 
> 5.1-RC1 cdrom iso
> 
> checking if c++ supports bool types... yes
> checking if conversion of longlong to float works... Segmentation fault
> (core du
> mped)
> no
> configure: error: Your compiler cannot convert a longlong value to a float!
> If you are using gcc 2.8.# you should upgrade to egcs 1.0.3 or newer and try
> again
> 
> This happened when I tried to compile mysql-client

Post the code it's trying to run.  It's possible it's buggy.

Kris


pgp0.pgp
Description: PGP signature

Re: fxp0: device timeout with 5.1BETA2

[Tobias Roth]

On Mon, Jun 02, 2003 at 10:59:22PM +0100, Paul Richards wrote:
> On Tue, 2003-06-03 at 22:00, Tobias Roth wrote:
> > 
> > fxp0: device timeout
> > 
> 
> I get these as well. Is it on irq9 by any chance, along with acpi0 ?

No. It's on irc 11 device 8 (as dmesg states). All irqs in bios are
set to 11 (factory default). ACPI is disabled.

It's a fresh 5.1-BETA2 system with the following modifications:

hint.apm.0.disabled="0"
hint.acpi.0.disabled="1"
hint.fxp.0.prefer_iomap="1"
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Paul Richards <[EMAIL PROTECTED]> writes:
: The possible methods available in an interface are fixed, they're
: defined in the .m files.

No it isn't.  One can add additional interfaces at any time without
breaking binary compatibility, so you don't know, a priori, the number
of methods in a given interface when you build a client of that
interface.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: whats an UDMA ICRC error ?

[Dan Nelson]

In the last episode (Jun 03), Andreas Klemm said:
> On Tue, Jun 03, 2003 at 01:23:35AM -0500, Dan Nelson wrote:
> > In the last episode (Jun 03), Andreas Klemm said:
> > > ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying
> > > ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying
> > > 
> > > What exactly does an UDMA ICRC error mean ? I think this is
> > > simply a read error. AFAIK an IDE disk doesn't have spare sectors
> > > or am I wrong ? How severe is this error ? What do you think ??
> > 
> > An ICRC error is an error detected by the IDE controller.  It
> > usually means a cabling problem, as a disk error would be reported
> > by the drive, not the controller.  From the ATA spec:
> > 
> >   ICRC shall be set to one if an interface CRC error has occurred
> >   during an Ultra DMA data transfer.  The content of this bit is
> >   not applicable for Multiword DMA transfers.
> > 
> > There are other error bits that indicate uncorrectable media errors.
>^^
> Does this mean, that data corruption occurred ??

No; I'm just saying that the ATA spec has a lot of status/error bits :)
If you had physical data corruption you'd see something other than ICRC.
 
-- 
Dan Nelson
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: fxp0: device timeout with 5.1BETA2

[Paul Richards]

On Tue, 2003-06-03 at 22:00, Tobias Roth wrote:
> Hi
> 
> I still get a 
> 
> fxp0: device timeout
> 

I get these as well. Is it on irq9 by any chance, along with acpi0 ?

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: whats an UDMA ICRC error ?

[Andreas Klemm]

On Tue, Jun 03, 2003 at 11:32:06AM +0200, Stefan Bethke wrote:
> Am Dienstag, 03.06.03, um 07:57 Uhr (Europe/Berlin) schrieb Andreas 
> Klemm:
> 
> >ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 
> >retrying
> >ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 
> >retrying
> >
> >What exactly does an UDMA ICRC error mean ?
> >I think this is simply a read error.
> >AFAIK an IDE disk doesn't have spare sectors or am I wrong ?
> >How severe is this error ? What do you think ??
> 
> IDE disks have (hidden) spare sectors, and will transparently remap 
> sectors as long as they have spare ones left.
> 
> If the drive reports errors ("hard error reading fsbn..."), then it 
> likely has run out of spare sectors, and probably will die soon.

o.k., but this is luckily not the case now ;-)

On Tue, Jun 03, 2003 at 12:52:01PM +0200, Frank Nobis wrote:
> Andreas Klemm <[EMAIL PROTECTED]> writes:
> 
> Hallo Andreas,
> 
> > Hi,
> > 
> > my console today shows the following error message from
> > my disk:
> > 
> > ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying
> > ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying
> > 
> > What exactly does an UDMA ICRC error mean ?
> > I think this is simply a read error.
> > AFAIK an IDE disk doesn't have spare sectors or am I wrong ?
> > How severe is this error ? What do you think ??
> > 
> 
> ich hatte genau diese Fehler vor einiger Zeit, als ich auf ATA 100
> Platten umgestiegen bin. Die Fehler sind sofort verschwunden als ich
> mit richtigen UDMA100 Kabeln die Platten angeschlossen hatte.

Well, will have to check cabling, this was also an answer I 
got on this topic.

Thanks to you all

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 4.8-STABLE
Need a magic printfilter today ? -> http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Tue, 2003-06-03 at 22:36, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, John Baldwin writes:
> >
> >On 02-Jun-2003 Paul Richards wrote:
> >> On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
> >> 
> >>> 
> >>> The tradeoff with using an index into an array is that there'd be a
> >>> heavy penalty for growing the array if an extra method didn't fit, but
> >>> that would be exceptionally rare and with our present usage we'd never
> >>> have that happen.
> >> 
> >> I'm not sure this is actually a problem after all since the Interface
> >> doesn't change and therefore we know a-priori how many methods there can
> >> be so we can pre-allocate an array.
> 
> I thought the point in KOBJ was that it was extensible so you could
> KLD load stuff which added more methods ?

Not exactly. It allows for dynamic binding of methods that implement a
specified interface. It gives you 2 things mainly:

1) Not all the interface has to be implemented within a particular
object, and things will just work if unimplemented parts of the
interface are called on an object.
2) The actual functions called for a particular method can by
dynamically changed (or at least they could be, I don't think there's
actually any API that does this at the moment so in fact they just get
mapped the once when the object is instantiated).

The possible methods available in an interface are fixed, they're
defined in the .m files.

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: whats an UDMA ICRC error ?

[Andreas Klemm]

On Tue, Jun 03, 2003 at 01:23:35AM -0500, Dan Nelson wrote:
> In the last episode (Jun 03), Andreas Klemm said:
> > Hi,
> > 
> > my console today shows the following error message from my disk:
> > 
> > ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying
> > ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying
> > 
> > What exactly does an UDMA ICRC error mean ?
> > I think this is simply a read error.
> > AFAIK an IDE disk doesn't have spare sectors or am I wrong ?
> > How severe is this error ? What do you think ??
> 
> An ICRC error is an error detected by the IDE controller.  It usually
> means a cabling problem, as a disk error would be reported by the
> drive, not the controller.  From the ATA spec:
> 
>   ICRC shall be set to one if an interface CRC error has occurred
>   during an Ultra DMA data transfer.  The content of this bit is not
>   applicable for Multiword DMA transfers.
> 
> There are other error bits that indicate uncorrectable media errors.
   ^^

Does this mean, that data corruption occurred ??

Strange. Didn't touch the hardware since months...

One idea, the cables have been very short and have been
a little bit under tension after installation. Maybe this
is the result now, that I have problems with the cables or
contacts 

Thanks for the info, will check cabling.

Andreas ///

-- 
Andreas Klemm - Powered by FreeBSD 4.8-STABLE
Need a magic printfilter today ? -> http://www.apsfilter.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: raidframe

[Michael Sinatra]

On Mon, 2 Jun 2003, Simon L. Nielsen wrote:

> I have an asr based RAID controller (Adaptec 2400A), though it is an IDE
> RAID controller, it uses the "SCSI" asr driver.  My controller has
> worked very well with FreeBSD 5.x, and the server is currently running
> 5.1-BETA.  The only thing that doesn't work, is the userland utilities
> to control / get status from the card, but that's not so important.

I have an asr based SCSI RAID controller and I have been testing it with a
5.1 system.  So far it seems to be working just fine, and the performance
is generally good.  The system has been running for a few weeks while I
have been doing some random testing.  The latest make world and kernel
rebuild was a few days ago.

uname -a:

FreeBSD f4.berkeley.edu 5.1-BETA FreeBSD 5.1-BETA #2: Thu May 29
18:40:44 PDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/F4-SMP  i386

from dmesg:

asr0:  mem 0xfc00-0xfdff irq 16 at
device 3.0 on pci3
asr0: major=154
asr0: ADAPTEC 2110S FW Rev. 380E, 1 channel, 256 CCBs, Protocol I2O

michael

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, John Baldwin writes:
>
>On 02-Jun-2003 Paul Richards wrote:
>> On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
>> 
>>> 
>>> The tradeoff with using an index into an array is that there'd be a
>>> heavy penalty for growing the array if an extra method didn't fit, but
>>> that would be exceptionally rare and with our present usage we'd never
>>> have that happen.
>> 
>> I'm not sure this is actually a problem after all since the Interface
>> doesn't change and therefore we know a-priori how many methods there can
>> be so we can pre-allocate an array.

I thought the point in KOBJ was that it was extensible so you could
KLD load stuff which added more methods ?

-- 
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.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[John Baldwin]

On 02-Jun-2003 Paul Richards wrote:
> On Mon, 2003-06-02 at 21:04, Paul Richards wrote:
> 
>> 
>> The tradeoff with using an index into an array is that there'd be a
>> heavy penalty for growing the array if an extra method didn't fit, but
>> that would be exceptionally rare and with our present usage we'd never
>> have that happen.
> 
> I'm not sure this is actually a problem after all since the Interface
> doesn't change and therefore we know a-priori how many methods there can
> be so we can pre-allocate an array. I wonder why Doug didn't do this,
> perhaps he thought that there'd be very large interfaces and 255 was a
> reasonable compromise for a cache. However, in practice we'd save a lot
> of space per kobj by preallocating the actual number of entries we
> needed for the Interface instead and then we could do away with the _ce
> problem. This would actually speed up the dispatch a lot too since we
> wouldn't have to traverse a list looking for a matching method entry and
> could call the function directly from the method table.
> 
> Doug, am I missing something?

Well, it's dfr@ rather than doug@ :)  (dfr@ cc'd)

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Bryan Liesner]

On Tue, 3 Jun 2003, Scott Long wrote:

> It's very hard to imagine Jeff's patches causing a problem at the point
> that the PR mentions.  Have you confirmed the problem in a kernel that
> was build in a totally clean environment?
>
> Scott

If you mean a kernel build with standard optimizations, yes I have
seen it.  No local patches:

cc -O -pipe -mcpu=pentiumpro

The panic happens before running init.

Sometimes I'm "lucky" and the kernel doesn't panic during boot, but it
will panic shortly before or after login.  It locks up tight
afterwards, and doesn't do a dump.

All this happened after kern_umtx.c v1.2

When I revert back, no panic...

It won't panic if I turn off the USB drive, or compile a kernel
without atapicam.  Possible problem with EHCI?  The driver finds an OHCI
device, calls it umass0, detaches it, finds an EHCI device and calls it umass1.

I'm sure it's not Jeffs patches that are the problem, but other
potential problems are exacerbated by them.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Paul Richards <[EMAIL PROTECTED]> writes:
: Doug, am I missing something?

I think we can have more than 256 methods, en toto, since any object
can implement multiple interface types and we don't know, a-priori,
how many different interfaces a given object implements.  But I've not
studied things beyond a quick glance to make sure this is the case.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

libmap.conf has the bug or not work correct?

[Jeremy Messenger]

I am trying to get ggv link against libc_r instead libthr, but it doesn't 
work as expect.. Maybe, I must have done something wrong?


# cat /etc/libmap.conf
libc_r.so.5 libthr.so.1
libc_r.so   libthr.so
[/usr/X11R6/bin/ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so
[ggv]
libc_r.so.5 libc_r.so.5
libc_r.so   libc_r.so


# uname -a
FreeBSD personal.mezzweb.com 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun  2 
20:23:45 CDT 2003 
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/BSDRULZ  i386


I even rebuilt rtld-elf (WITH_LIBMAP=yes in /etc/make.conf) and ggv then 
reinstall them, but no luck. The ggv is still linking to libthr instead 
libc_r.. Also, ggv isn't only one app that I tried. I did tried with gst- 
register and no luck to change the link to libc_r.


# ldd /usr/X11R6/bin/ggv | grep libc
   libc.so.5 => /usr/lib/libc.so.5 (0x28a68000)
   libc_r.so.5 => /usr/lib/libthr.so.1 (0x28b49000)

Do anyone have any hint?

Cheers,
Mezz
--
bsdforums.org 's moderator, mezz.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

fxp0: device timeout with 5.1BETA2

[Tobias Roth]

Hi

I still get a 

fxp0: device timeout

on my Thinkpad T30 with a newly installed 5.1BETA2. Browsing the
archives showed that people had success with 

hint.fxp.0.prefer_iomap="1"

on a T30 and 5.1BETA1. Any ideas why this doesn't help in my case?

thx, t.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Mon, 2003-06-02 at 21:04, Paul Richards wrote:

> 
> The tradeoff with using an index into an array is that there'd be a
> heavy penalty for growing the array if an extra method didn't fit, but
> that would be exceptionally rare and with our present usage we'd never
> have that happen.

I'm not sure this is actually a problem after all since the Interface
doesn't change and therefore we know a-priori how many methods there can
be so we can pre-allocate an array. I wonder why Doug didn't do this,
perhaps he thought that there'd be very large interfaces and 255 was a
reasonable compromise for a cache. However, in practice we'd save a lot
of space per kobj by preallocating the actual number of entries we
needed for the Interface instead and then we could do away with the _ce
problem. This would actually speed up the dispatch a lot too since we
wouldn't have to traverse a list looking for a matching method entry and
could call the function directly from the method table.

Doug, am I missing something?


-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Scott Long]

Bryan Liesner wrote:
On Tue, 3 Jun 2003, Scott Long wrote:


Actually, I think it's cam in general that's causing the panic with
these changes.
Please see kern/52718
I didn't see a backtrace in the PR.  Is there one that you can share
with us?


It panics during boot and, unfortunately, no dump is produced.  The
best I could do is what's already there in the PR.  If there is
anything more I can do, just let me know.
I have (using cam) 2 atapi cdroms, a 100M zip disk, and a 40G USB hard
disk.

It's very hard to imagine Jeff's patches causing a problem at the point
that the PR mentions.  Have you confirmed the problem in a kernel that
was build in a totally clean environment?
Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: HD Speed Benchmark

[Simon L. Nielsen]

On 2003.06.03 22:20:56 +0200, Sebastian Yepes [ESN] wrote:
> 
> I have made some  Benchmark on my inspiron 8500  (Intel 82801DB (ICH4) - 
> UDMA100)
> and i am geting very Bad results on the 5.1, i have got beter results on 5.0

Beta2 still had all the debugging options in the kernel, so unless you
have removed them, and recompiled your kernel, thats what you are
seeing.

-- 
Simon L. Nielsen


pgp0.pgp
Description: PGP signature

HD Speed Benchmark

[Sebastian Yepes [ESN]]

I have made some  Benchmark on my inspiron 8500  (Intel 82801DB (ICH4) - 
UDMA100)
and i am geting very Bad results on the 5.1, i have got beter results on 5.0


dmesg
--
5.0R -->  http://www.x123.info/src/i8500/dmesg.5.0R
5.1B2 -->  http://www.x123.info/src/i8500/dmesg.5.1B2

Check out the output of bonnie++:
5.0R -->  http://www.x123.info/src/i8500/bonnie.5.0R
5.1B2 -->  http://www.x123.info/src/i8500/bonnie.5.1B2


-- 

/*
FingerPrint:
 5BF1 58B1 DE75 CBE3 6044
 7098 1246 1EF6 9E78 041C

 @@@   @@ @@@ 
 @@!  @@@ !@@ @@!  @@@
 @[EMAIL PROTECTED]@!@   !@@!!  @!@  [EMAIL PROTECTED]
 !!:  !!! !:! !!:  !!!
 :: : ::  ::.: :  :: :  : 
 The Power To Kill LinuX
*/

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: vmstat -s broken

[Bruce Evans]

On Tue, 3 Jun 2003, Pete Fritchman wrote:

> ++ 03/06/03 20:47 +0200 - Pawel Worach:
> | I don't know for how long this has been broken but vmstat
> | always reports 0 (zero) for the number of system calls
> | executed which is virtually impossible.
> |
> | This is on a system built
> | FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun  3 02:48:51
> | CEST 2003
> |
> | darkstar# vmstat -s | grep "system calls"
> |
> | 0 system calls
> | darkstar# uptime
>
> FWIW, I also see this behaviour on -current built Feb 13th:
>
> knap.sac(/home/sac1/petef) [258] > vmstat -s | grep system.calls
> 0 system calls
> knap.sac(/home/sac1/petef) [259] > uname -a
> FreeBSD knap.sac.fedex.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0:
> Thu Feb 13 16:26:14 CST 2003
> [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAC-DELL240-5  i386
> knap.sac(/home/sac1/petef) [260] >

Rev.1.67 of vm/vm_meter.c unbroke the sysctl that returns the number of
syscalls, but vmstat(1) accesses cnt.v_syscalls in kmem so it is still
broken.  systat(1) uses the sysctl so it was unbroken.  Using the sysctl
updates cnt.v_syscall, but programs that read it from kmem see a stale
value (the one made by the last call to the sysctl).

I use a different fix which restores the previous code for the SMP
case.  The SMP case remains broken: the count is stored in per-CPU
data (in all cases in -current but only in the SMP case in my version)
so that updating it doesn't require locking or expensive atomic
operations.  Thus there is never any up to date copy of the full count,
and programs that access it in kmem need to know how to assemble it.
None do.

Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RELENG_4 to RELENG_5_1

[Alexander Kabaev]

On Tue, 3 Jun 2003 12:56:01 -0700
"Crist J. Clark" <[EMAIL PROTECTED]> wrote:

> 
> Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I
> have been getting the same failure originally quoted when building
> HEAD on RELENG_4 for several days now.
> 
> I suggest that the original poster double-check that he has RELENG_5_1
> and not HEAD. And I do have buildworld logs. I'll send in a separate
> mail.

No need that. This is a bug and it needs to be fixed. I am working on
this. Thanks for the reports.

-- 
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Tue, 2003-06-03 at 18:19, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Paul Richards <[EMAIL PROTECTED]> writes:
> : I'm not sure that kobj actually needs to be MP safe if the kobj
> : struct is always embedded in a structure at a higher level i.e.
> : a use of kobj in say the device driver code will not interact with
> : it's use by say the linker code so the locking can be done on device
> : driver or linker level structs.
> 
> Lock lock data, not code.

Agreed, that's what I said :-) However, I was wondering if locking the
structure that the kobj was embedded in was enough to protect the kobj
itself. As you point out below, that's not the case.

> The kobj dispatch tables are shared between all instances of the
> object.  So if you have two instances of the driver, the driver locks
> protect softc for that driver.  However, both softc's reference the
> kobj structures, directly or indirectly, that are not MP safe.  If
> instance 1 takes out a lock, that doesn't prevent instance 2 from
> getting screwed by the following code:
> 
> #define KOBJOPLOOKUP(OPS,OP) do { \
>   kobjop_desc_t _desc = &OP##_##desc; \
>   kobj_method_t *_ce =\
>   &OPS->cache[_desc->id & (KOBJ_CACHE_SIZE-1)];   \
>   if (_ce->desc != _desc) {   \
>   KOBJOPMISS; \
> [1]   kobj_lookup_method(OPS->cls->methods, _ce, _desc);  \
>   } else {\
>   KOBJOPHIT;  \
>   }   \
> [2]   _m = _ce->func; \
> } while(0)
> 
> Notice how OPS has a cache array.  If instance 1 is calling the same
> ID as instance 2, modulo KOBJ_CACHE_SIZE, then a collision occurs and
> a race happens betwen [1] and [2]:
> 
> thread 1thread 2
> 
> _ce = ...
>   _ce = ...
> HIT
>   MISS
>   set's *_ce via kobj_lookup_method
> _m gets set
> _m called
>   _m set
>   _m called
> 
> 
> Notice how thread 1's _m gets set based on the results of the kobj
> lookup, and we have a race, even if thread1 and thread2 took out their
> driver instance locks.

That means we have to lock the dispatch table before every method is
looked up and hold it until the method returns (the alternative would be
to free it inside the method once it had been called but that'd be a
right mess).

Actually, in practice it doesn't matter, though that's an accident of
the kobjs we currently create. The reason being that the hashing
algorithm is really simple and just lops off some high bits of the
method id so unless we have more than 255 methods they always have an
unique slot. There's no mechanism to change the actual function
associated with the method at the moment. Even if there was, it might
not matter as long as the number of methods was still below 255, because
what you'd actually be doing is, say, changing which attach function to
call when you were indirecting through the attach method entry and by
the time thread 1 gets to actually call the method it might even be
considered correct for it to call the newly mapped one.

However, I take your point and we either have to implement locking of
the method table or redesign the caching mechanism to guarantee that
there's no race. I don't think anything other than _ce is a problem (is
there anything else?).

If we ensured that the cache entry couldn't have collisions (perhaps by
not having a hash and instead indexing a unique position in an array
using the method id) then only the latter race would exist (changing the
function associated with a method) and that might be acceptable
behaviour.

The tradeoff with using an index into an array is that there'd be a
heavy penalty for growing the array if an extra method didn't fit, but
that would be exceptionally rare and with our present usage we'd never
have that happen.

Incidentally, if we implement a lock on the method table we'd
effectively have code locks :-)

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: s4bios

[The Anarcat]

I put my test results in:

http://anarcat.ath.cx/acpi-test/

I have done other tests using a build made after the recent ACPI
import and bugfixes, and I will update the info there when completely
done.

A.

On Tue Jun 03, 2003 at 05:32:05PM +0200, Mark Santcroos wrote:
> Is there anyone that has succesfully used "acpiconf -s 4"?
> 
> I'm very interested in your reports. If you haven't tried yet, but are
> willing to help me, please report me your findings.
> 
> Thanks
> 
> Mark
> 
> -- 
> Mark SantcroosRIPE Network Coordination Centre
> http://www.ripe.net/home/mark/New Projects Group/TTM
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
> 
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RELENG_4 to RELENG_5_1

[Crist J. Clark]

On Tue, Jun 03, 2003 at 12:02:44PM -0400, Alexander Kabaev wrote:
> 
> On Tue, 03 Jun 2003 18:51:59 +0300
> Petri Helenius <[EMAIL PROTECTED]> wrote:
> 
> > I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make 
> > buildworld compiles
> > a while and then stops with:
> > 
> > Question is if this is supported and if yes, what should I do
> > differently?
> > 
> > Pete
> 
> Got your buildworld log saved somewhere? Could you send it to me please.

Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I
have been getting the same failure originally quoted when building
HEAD on RELENG_4 for several days now.

I suggest that the original poster double-check that he has RELENG_5_1
and not HEAD. And I do have buildworld logs. I'll send in a separate
mail.
-- 
Crist J. Clark | [EMAIL PROTECTED]
   | [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/| [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

s4bios

[Mark Santcroos]

Is there anyone that has succesfully used "acpiconf -s 4"?

I'm very interested in your reports. If you haven't tried yet, but are
willing to help me, please report me your findings.

Thanks

Mark

-- 
Mark SantcroosRIPE Network Coordination Centre
http://www.ripe.net/home/mark/New Projects Group/TTM
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: vmstat -s broken

[Pete Fritchman]

++ 03/06/03 20:47 +0200 - Pawel Worach:
| I don't know for how long this has been broken but vmstat
| always reports 0 (zero) for the number of system calls
| executed which is virtually impossible.
| 
| This is on a system built
| FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun  3 02:48:51
| CEST 2003
| 
| darkstar# vmstat -s | grep "system calls"
| 
| 0 system calls
| darkstar# uptime

FWIW, I also see this behaviour on -current built Feb 13th:

knap.sac(/home/sac1/petef) [258] > vmstat -s | grep system.calls
0 system calls
knap.sac(/home/sac1/petef) [259] > uname -a
FreeBSD knap.sac.fedex.com 5.0-CURRENT FreeBSD 5.0-CURRENT #0:
Thu Feb 13 16:26:14 CST 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/SAC-DELL240-5  i386
knap.sac(/home/sac1/petef) [260] > 

--pete
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

vmstat -s broken

[Pawel Worach]

I don't know for how long this has been broken but vmstat
always reports 0 (zero) for the number of system calls
executed which is virtually impossible.

This is on a system built
FreeBSD darkstar 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Tue Jun  3 02:48:51
CEST 2003

darkstar# vmstat -s | grep "system calls"

0 system calls
darkstar# uptime
 8:33PM  up 17:03, 8 users, load averages: 1.93, 1.63, 1.27

-- 
Pawel

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Native JDK with libthr/libkse

[Narvi]

On Mon, 2 Jun 2003, Sheldon Hearn wrote:

> On (2003/06/01 23:53), Narvi wrote:
>
> > > The absence of credible Java support in FreeBSD has lost us significant
> > > penetration in the past, and it would be disastrous if the perceptions
> > > of the past shaped the future.
> >
> > credible rather sounds like 'comes on the installation cd, doesn't have
> > significantly more bugs than linux/solaris/xxx version' 8-(
>
> And I think we'll get there.
>

I would really hope so, its increasingly a barrier.

> I'm currently doing some Java development on a FreeBSD-CURRENT
> workstation using a native jdk14.  It's good enough for testing
> components in a J2EE application server (JBoss), and performance is
> comparable to that seen on an equivalent Windows workstation.
>

java is not all just j2ee, though its an increasingly important niche. The
developer side is probably in the short term more important than the
number of servers deployed using it.

> Would I use FreeBSD as a production J2EE server reliant on 1.4.1?  No.
> But the time is coming, so don't write FreeBSD off just yet.
>

oh, i'm not writing off freebsd, its just not as ready in this regard as
competition. Running production j2ee servers is a level above having a
useful / credible java story - it would probably be something you'd do on
5.3 with a good jdk.

> Ciao,
> Sheldon.
>



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: viapropm doesnt like sys/dev/pci.c rev 1.214

[David P. Reese Jr.]

On Tue, Jun 03, 2003 at 01:54:36AM -0500, Conrad Sabatier wrote:
> 
> On 02-Jun-2003 Nicolas Souchu wrote:
> > On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote:
> >> 
> >> viapropm is seriously broken for other reasons and needs professional
> >> help.
> > 
> > What kind of breakage? Setting resources in probe? Right. Anybody having
> > the viapm driver loaded usually should please try the attached patch.
> 
> I'm sorry to report that those patches didn't fix the problem for me.  They
> all applied cleanly, I built a new kernel, but I still see the same
> messages at boot.  Couldn't enable port mapping.

The problem is a disagreement with the new io_method code and the viapropm
chip.  From Nicolas Souchu's previous email:

: The datasheet states that the command bits are RW but "fixed at 0".

A snip of code from sys/dev/pci/pci.c:pci_enable_io_method():

pci_set_command_bit(dev, child, bit);
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
if (command & bit)
return (0);
device_printf(child, "failed to enable %s mapping!\n", error);
return (ENXIO);

Because the viapropm's command register bits will always read as zero,
this code will always fail when trying to enable port mapping.

Whatever problems viapropm may have, it is the new pci code that prevents it
from attaching.  It is not the fault of anything in sys/pci/viapm.c.

-- 

   David P. Reese Jr.  [EMAIL PROTECTED]
   --
   It can be argued that returning a NULL pointer when asked to allocate
   zero bytes is a silly response to a silly question.
 -- FreeBSD manual page for malloc(3)
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: SU not working on fresh CVSUP

[Mike Loiterman]

 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday, June 03, 2003 9:09 AM Fernando Gleiser
 wrote:

> Did you run mergemaster(8) after buildworld/installworld ?

I did but, I must have skipped the pam file.  My fault.  Thanks for
the help.

- --
Email: [EMAIL PROTECTED]
PGP Key 0xD1B9D18E

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2
Comment: This message has been digitally signed by Mike Loiterman

iQA/AwUBPtzczGjZbUnRudGOEQJiaACgpGV5yhP/m0cDzEa8l1Gfscu6CqgAn0WJ
x1kgfeZ3E15g8pCTX5LEsIbb
=f3Yi
-END PGP SIGNATURE-

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Bryan Liesner]

On Tue, 3 Jun 2003, Scott Long wrote:

> > Actually, I think it's cam in general that's causing the panic with
> > these changes.
> >
> > Please see kern/52718
>
> I didn't see a backtrace in the PR.  Is there one that you can share
> with us?
>

It panics during boot and, unfortunately, no dump is produced.  The
best I could do is what's already there in the PR.  If there is
anything more I can do, just let me know.

I have (using cam) 2 atapi cdroms, a 100M zip disk, and a 40G USB hard
disk.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Paul Richards <[EMAIL PROTECTED]> writes:
: I'm not sure that kobj actually needs to be MP safe if the kobj
: struct is always embedded in a structure at a higher level i.e.
: a use of kobj in say the device driver code will not interact with
: it's use by say the linker code so the locking can be done on device
: driver or linker level structs.

Lock lock data, not code.

The kobj dispatch tables are shared between all instances of the
object.  So if you have two instances of the driver, the driver locks
protect softc for that driver.  However, both softc's reference the
kobj structures, directly or indirectly, that are not MP safe.  If
instance 1 takes out a lock, that doesn't prevent instance 2 from
getting screwed by the following code:

#define KOBJOPLOOKUP(OPS,OP) do {   \
kobjop_desc_t _desc = &OP##_##desc; \
kobj_method_t *_ce =\
&OPS->cache[_desc->id & (KOBJ_CACHE_SIZE-1)];   \
if (_ce->desc != _desc) {   \
KOBJOPMISS; \
[1] kobj_lookup_method(OPS->cls->methods, _ce, _desc);  \
} else {\
KOBJOPHIT;  \
}   \
[2] _m = _ce->func; \
} while(0)

Notice how OPS has a cache array.  If instance 1 is calling the same
ID as instance 2, modulo KOBJ_CACHE_SIZE, then a collision occurs and
a race happens betwen [1] and [2]:

thread 1  thread 2

_ce = ...
_ce = ...
HIT
MISS
set's *_ce via kobj_lookup_method
_m gets set
_m called
_m set
_m called


Notice how thread 1's _m gets set based on the results of the kobj
lookup, and we have a race, even if thread1 and thread2 took out their
driver instance locks.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Scott Long]

Bryan Liesner wrote:
On Mon, 2 Jun 2003, Jeff Roberson wrote:


If you have had issues with libthr on SMP or umtx panics, the following
patch may solve these issues.
http://www.chesapeake.net/~jroberson/umtxlocks.diff

This patch fixes several race conditions and other issues with umtx.


Actually, no it doesn't.  I was able to use kern_umtx v 1.3 only if I
removed atapicam from my kernel config.  These patches (now
committed?) panic the system whether I use atapicam or not.
With kern_umtx v1.2 there is no panic at all, with or without
atapicam.
Actually, I think it's cam in general that's causing the panic with
these changes.
Please see kern/52718
I didn't see a backtrace in the PR.  Is there one that you can share 
with us?

Scott

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: umtx/libthr SMP fixes.

[Bryan Liesner]

On Mon, 2 Jun 2003, Jeff Roberson wrote:

> If you have had issues with libthr on SMP or umtx panics, the following
> patch may solve these issues.
>
> http://www.chesapeake.net/~jroberson/umtxlocks.diff
>
> This patch fixes several race conditions and other issues with umtx.

Actually, no it doesn't.  I was able to use kern_umtx v 1.3 only if I
removed atapicam from my kernel config.  These patches (now
committed?) panic the system whether I use atapicam or not.
With kern_umtx v1.2 there is no panic at all, with or without
atapicam.

Actually, I think it's cam in general that's causing the panic with
these changes.

Please see kern/52718
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: RELENG_4 to RELENG_5_1

[Alexander Kabaev]

On Tue, 03 Jun 2003 18:51:59 +0300
Petri Helenius <[EMAIL PROTECTED]> wrote:

> I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make 
> buildworld compiles
> a while and then stops with:
> 
> Question is if this is supported and if yes, what should I do
> differently?
> 
> Pete

Got your buildworld log saved somewhere? Could you send it to me please.

-- 
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RELENG_4 to RELENG_5_1

[Petri Helenius]

I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make 
buildworld compiles
a while and then stops with:

Question is if this is supported and if yes, what should I do differently?

Pete

cc -fpic -DPIC -O -pipe -mcpu=pentiumpro -DPTHREAD_KERNEL 
-I/usr/src/lib/libpthread/../libc/include 
-I/usr/src/lib/libpthread/thread  
-I/usr/src/lib/libpthread/../../include 
-I/usr/src/lib/libpthread/arch/i386/include 
-I/usr/src/lib/libpthread/sys 
-I/usr/src/lib/libpthread/../../libexec/rtld-elf -fno-builtin 
-D_LOCK_DEBUG -D_PTHREADS_INVARIANTS -Wall  -c 
/usr/src/lib/libpthread/sys/lock.c -o lock.So
building shared library libkse.so.1
thr_libc.So: In function `sigaction':
thr_libc.So(.text+0x54): multiple definition of `_sigaction'
thr_sigaction.So(.text+0x0): first defined here
thr_libc.So: In function `sigprocmask':
thr_libc.So(.text+0x34): multiple definition of `_sigprocmask'
thr_sigprocmask.So(.text+0x0): first defined here
*** Error code 1

Stop in /usr/src/lib/libpthread.
*** Error code 1
Stop in /usr/src/lib.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.
*** Error code 1
Stop in /usr/src.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[Paul Richards]

On Tue, Jun 03, 2003 at 08:56:59AM -0600, M. Warner Losh wrote:
> In message: <[EMAIL PROTECTED]>
> Paul Richards <[EMAIL PROTECTED]> writes:
> : You should look at kobj, it's precisely this sort of dynamic
> : dispatching that it was designed to support.
> 
> Too bad it is a little slow and not MP safe in its implementation.

Yes, but it has the right design philosophy for this sort of
situation and should be researched as an example of how to solve
these sorts of problems.

I'm not sure the dispatch is slow enough to cause serious overhead in
the context of the tasks being performed and it maybe could be improved
a little.

I'm not sure that kobj actually needs to be MP safe if the kobj
struct is always embedded in a structure at a higher level i.e.
a use of kobj in say the device driver code will not interact with
it's use by say the linker code so the locking can be done on device
driver or linker level structs.

I think that's the case currently, though perhaps not something we've
defined as part of the API, but there's no reason we could not do so and
then that simplifies the use of kobj by avoiding having to add locks
right at the very bottom of the structure tree where they wouldn't be
needed.

-- 
Tis a wise thing to know what is wanted, wiser still to know when
it has been achieved and wisest of all to know when it is unachievable
for then striving is folly. [Magician]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

our compiler can't convert longlong to float? 5.1-RC1

[leafy]

I got this strange message and a core dump after installing 
5.1-RC1 cdrom iso

checking if c++ supports bool types... yes
checking if conversion of longlong to float works... Segmentation fault
(core du
mped)
no
configure: error: Your compiler cannot convert a longlong value to a float!
If you are using gcc 2.8.# you should upgrade to egcs 1.0.3 or newer and try
again

This happened when I tried to compile mysql-client

Jiawei Ye
-- 
"Without the userland, the kernel is useless."
   --inspired by The Tao of Programming
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.1-beta2 failed upgrade install

[Kevin Oberman]

> Date: Tue, 03 Jun 2003 23:52:38 +0900 (JST)
> From: Masachika ISHIZUKA <[EMAIL PROTECTED]>
> Sender: [EMAIL PROTECTED]
> 
>   Are there anybody who can upgrade to 5.1-RC1 successfully with Xeon
> or Pentium4 ?  I can newly install 5.1-RC1, but I can not upgrade from
> 5.1-BETA or 5.1-RC1 to 5.1-RC1 with Xeon or Pentium4 without panics.

I had exactly this problem on my IBM T30 (1.8 GHz P4). Random panics,
usually 4 or 12. Not repeatable.Oddly, many (most?) of the failures were
not during compiles, but doing rm or chmod or something similarly
trivial!  Very weird.

After trying for a while to get a clean build, I finally started
re-starting the buildworld with -DNOCLEAN (occasionally after deleting
something that was in progress) during the build.

Once I got a new system build, things were fine again. I immediately
rebuilt again, as it was possible that something had been messed up in
one of the panics and I missed it.

I could also not update some ports.

I have no idea of the cause, but I have not seen it again.

R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [EMAIL PROTECTED]   Phone: +1 510 486-8634
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.1-beta2 failed upgrade install

[Masachika ISHIZUKA]

>>   Are there anybody who can upgrade to 5.1-RC1 successfully with Xeon
>> or Pentium4 ?  I can newly install 5.1-RC1, but I can not upgrade from
>> 5.1-BETA or 5.1-RC1 to 5.1-RC1 with Xeon or Pentium4 without panics.
> 
> Here, here. I was doing installworld and got a double fault. After
> rebooting with the new kernel (5.1-RC1) and running fsck it installed
> fine. Funnyly enough, make was gone, so I had to run the one in
> /usr/obj. Otherwise seems to work fine so far.

  Thank you for mail.

  But I want to binary upgrade with CD-ROM.
  Is there anyone who can binary upgrade to 5.1-RC1 with CD-ROM image
from 
ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/5.1-RC1/5.1-RC1-i386-disc1.iso.

-- 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: VFS: C99 sparse format for struct vfsops

[M. Warner Losh]

In message: <[EMAIL PROTECTED]>
Paul Richards <[EMAIL PROTECTED]> writes:
: You should look at kobj, it's precisely this sort of dynamic
: dispatching that it was designed to support.

Too bad it is a little slow and not MP safe in its implementation.

Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: 5.1-beta2 failed upgrade install

[Miguel Mendez]

On Tue, 03 Jun 2003 23:52:38 +0900 (JST)
Masachika ISHIZUKA <[EMAIL PROTECTED]> wrote:

>   Are there anybody who can upgrade to 5.1-RC1 successfully with Xeon
> or Pentium4 ?  I can newly install 5.1-RC1, but I can not upgrade from
> 5.1-BETA or 5.1-RC1 to 5.1-RC1 with Xeon or Pentium4 without panics.

Here, here. I was doing installworld and got a double fault. After
rebooting with the new kernel (5.1-RC1) and running fsck it installed
fine. Funnyly enough, make was gone, so I had to run the one in
/usr/obj. Otherwise seems to work fine so far.

Cheers,
-- 
Miguel Mendez - [EMAIL PROTECTED]
EnergyHQ :: http://www.energyhq.tk
Tired of Spam? -> http://www.trustic.com


pgp0.pgp
Description: PGP signature

Re: 5.1-beta2 failed upgrade install

[Masachika ISHIZUKA]

  Are there anybody who can upgrade to 5.1-RC1 successfully with Xeon
or Pentium4 ?  I can newly install 5.1-RC1, but I can not upgrade from
5.1-BETA or 5.1-RC1 to 5.1-RC1 with Xeon or Pentium4 without panics.

-- 
[EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"