SOLVED: Reading acpi memory from a driver attached to hostb
On Thu, 23-Jul-2009 at 16:06:11 -0400, John Baldwin wrote:
On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote:
John, apparently you sent me an email (thanks a lot) which I never
received (we have to blame our company's spam filters which I do
not control). I'll comment on it here in my reply to Doug...
Yes, I saw the bounces. Hopefully you see the list version of this.
| Did you try
| doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in
your
| driver that is a child of hostb0?
I tried this, well, something similar: I had to do 4 times
device_get_parent() to end up at acpi0:
mydriver - hostb0 - pci0 - pcib0 - acpi0
You don't actually need to do that. pci0 will pass the request up to acpi0
eventually. You just need to ask pci0 to allocate it for you and it will see
you are not a direct child and take the 'passthrough' case here:
struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
u_long start, u_long end, u_long count, u_int flags)
{
...
if (device_get_parent(child) != dev)
return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child,
type, rid, start, end, count, flags));
...
}
Rather than trying to allocate the whole chunk of the ACPI resource, I would
just do a specific allocation like so:
rid = 0;
res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, the real start address, the real
end address, the length, RF_ACTIVE);
I finally got it working. Many thanks to all, especially to Doug
and John. It should have worked all the time with John's code
above but due to a stupidity on my part (I specified end as
start + count and not as start + count - 1) the allocation
failed. It was Doug's suggestion to disable resource allocation
in acpi.c -- so the memory area was unused and I could allocate
it. After entering some debugging code into acpi_resource.c and
acpi.c, which do not forgive errors like the above, I found my
bug ;-)
No I learned a bit about acpi and found curious things like this:
When using
BUS_ALLOC_RESOURCE( device_get_parent(device_get_parent(dev)), ...
it is pci0 appearing in acpi_alloc_resource() to allocate the
resource with the parameters I specify (count == 0x4000).
When using only
BUS_ALLOC_RESOURCE( device_get_parent(dev), ...
it is hostb0 appearing in acpi_alloc_resource() but count
got changed to 0x80. However start and end remain unchanged
and do not match end = start + count - 1 anymore.
Thanks again,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
On Thu, 23-Jul-2009 at 16:06:11 -0400, John Baldwin wrote:
On Thursday 23 July 2009 1:53:51 pm Andre Albsmeier wrote:
John, apparently you sent me an email (thanks a lot) which I never
received (we have to blame our company's spam filters which I do
not control). I'll comment on it here in my reply to Doug...
Yes, I saw the bounces. Hopefully you see the list version of this.
Yes, I've been lucky this time.
| Did you try
| doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in
your
| driver that is a child of hostb0?
I tried this, well, something similar: I had to do 4 times
device_get_parent() to end up at acpi0:
mydriver - hostb0 - pci0 - pcib0 - acpi0
You don't actually need to do that. pci0 will pass the request up to acpi0
That's what I hoped as well.
eventually. You just need to ask pci0 to allocate it for you and it will see
you are not a direct child and take the 'passthrough' case here:
struct resource *
pci_alloc_resource(device_t dev, device_t child, int type, int *rid,
u_long start, u_long end, u_long count, u_int flags)
{
...
if (device_get_parent(child) != dev)
return (BUS_ALLOC_RESOURCE(device_get_parent(dev), child,
type, rid, start, end, count, flags));
...
}
Rather than trying to allocate the whole chunk of the ACPI resource, I would
just do a specific allocation like so:
rid = 0;
res = BUS_ALLOC_RESOURCE(device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, the real start address, the real
end address, the length, RF_ACTIVE);
OK, I have modified my driver exactly this way, but still no success.
It seems my code didn't make it to the list (the attachment
was stripped) so I include it inline now. Testing is quite
simple, every feedback is welcome:
1. check if devinfo -r spits out some free I/O memory addresses
ranges under acpi0 with at minimum 4 bytes length.
2. select one of them and assign its start address to rstart in
eccmon_probe() at the line which reads now
u_long rstart = 0xfed14000;
(this is the address I use for testing)
3. compile, kldload and dmesg. I always get the message
bus_alloc_resource() returned NULL.
Thanks,
-Andre
eccmon.c start -
#include sys/param.h
#include sys/systm.h
#include sys/module.h
#include sys/kernel.h
#include machine/bus.h
#include sys/bus.h
#include sys/rman.h
#include machine/pci_cfgreg.h
#include dev/pci/pcivar.h
#include dev/pci/pcireg.h
struct eccmon_softc {
device_t dev;
int res_set;/* flag if bus_set_resource() was used
successfully */
struct resource* res;
int rid;
};
/**/
/* eccmon_probe() */
/**/
static int eccmon_probe( const device_t const dev )
{
u_long rstart = 0xfed14000;
int ret;
struct resource* res;
int rid = 0;
device_printf( dev, probe: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
/*
* try to bus_alloc_resource the resource and give it back
*/
if( (res = BUS_ALLOC_RESOURCE( device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, rstart, rstart+4, 4, RF_ACTIVE )) == NULL ) {
device_printf( dev, bus_alloc_resource() returned NULL\n );
return ENXIO;
}
if( (ret = BUS_RELEASE_RESOURCE( device_get_parent(device_get_parent(dev)),
dev, SYS_RES_MEMORY, rid, res )) != 0 )
device_printf( dev, bus_release_resource() returned %d\n, ret );
return ENXIO;
}
/***/
/* eccmon_attach() */
/***/
static int eccmon_attach( const device_t const dev )
{
device_printf( dev, attach: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
return ENXIO;
}
/***/
/* eccmon_detach() */
/***/
static int eccmon_detach( const device_t const dev )
{
device_printf( dev, detach: started for %x:%x\n, pci_get_vendor( dev ) ,
pci_get_device( dev ) );
return 0;
}
/*/
/* eccmon_identify() */
/*/
static void eccmon_identify( driver_t *driver, device_t p )
{
device_printf( p, identify: start: %x %x\n, pci_get_vendor( p ),
pci_get_device( p ) );
device_printf( p, identify on: %s %d\n, device_get_name( p ),
device_get_unit(p) );
if( device_find_child( p, eccmon, -1 ) == NULL
strcmp( device_get_name( p ), hostb ) == 0
device_get_unit( p ) == 0 ) {
device_t child = device_add_child( p, eccmon, -1 );
device_printf( p, identify added child: %p\n, child );
}
}
/***/
/* driver(9) stuff */
/***/
static device_method_t eccmon_methods[] = {
DEVMETHOD( device_identify, eccmon_identify ),
DEVMETHOD( device_probe, eccmon_probe ),
DEVMETHOD
Re: Reading acpi memory from a driver attached to hostb
On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote:
Andre Albsmeier writes:
| On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote:
| On 18 Jul 2009, at 09:10, Andre Albsmeier wrote:
|
| On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote:
| Andre Albsmeier wrote:
| [CC'ing this to Rui Paulo since he tried to help me a while ago]
|
| Since my driver is a child of hostb0, I have no idea of how to
| access
| acpi0's memory area. Here is a devinfo -r to make things clear:
|
| ...
|
| Earlier, I was given the hint to attach as a child of acpi (see the
| old mail attached below) but in this case I didn't have access to
| the
| hostb registers which I need as well.
|
| The only thing I see is: Attach two drivers -- one as child of acpi
| and another as child of hostb and let them communicate somehow (no
| idea how to do this).
|
| I have also done crazy things like searching for acpi0 and trying
| to bus_alloc_resource() the memory I am interested in but this also
| failed.
|
| Or is it possible to free(!) somehow the address space from acpi0
| and pass it to hostb0 so I can bus_alloc_resource() it?
|
|
| You can probably make two drivers in one which cooperate to
| allow access to both sets of resources.
|
| Hmm, that's what I meant by: Attach two drivers -- one as child of
| acpi
| and another as child of hostb...
|
| And that's similar to Rui Paulo's suggestion a while ago:
|
| You'll probably need to create a fake ACPI child driver to access it.
|
| Create your identify routine with something like:
|
| static void mydriver_identify(driver_t *driver, device_t parent)
| {
| if (device_find_child(parent, mydriver, -1) == NULL
| mydriver_match(parent))
| device_add_child(parent, mydriver, -1);
| }
|
| mydriver_match() should check if you were given the acpi0 device.
|
| But in order to attach to acpi0, I need to say
|
| DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL,
| NULL );
|
| instead of
|
| DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL,
| NULL );
|
| This way I could attach to acpi but not to hostb anymore
|
| I have searched the net for solutions, I have read newbus-draft.txt
| and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all
| of these my driver is working on other mainboards where it doesn't
| have to access foreign memory) but didn't find anything.
|
| I'm out of ideas.
| John, do you know if this is a newbus limitation or if it can be
| worked around ?
|
| I assume it is possible somehow, I am just too stupid (it is the first
| driver I wrote). John, for easy reference, here is my initial message:
|
| http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html
|
| Please remember all, that I need the access to the acpi0 memory location
| only for a few reads during probing/attaching, not later.
|
| I have also read somewhere that, when resources are allocated, the
| system walks up the device tree until it finds the resource. Since
| my driver is below hostb0 and hostb0 is below acpi0 I thought it
| should work but it doesn't..
FWIW, you might look at ipmi(4) especially in some early states since
it can probe and attach in many ways (isa, acpi, pci etc.) and had to
figure out the best way to attach. Also it had various front ends.
If I recall correctly, I did a find for a driver (ie. acpi) then
select the first instance. Once you get that handle then you can
request device resources from it, get the info you need then release
that stuff. However, you won't get the module auto-loading part
that you would get if you created a module that depended on both.
That might get you enough of a hint. Also there are some generic
stuff to read various memory bits like SMBIOS areas etc. This is
used in ipmi(4) as well since the attachment can be defined in SMBIOS.
If you have a specific question, about why the driver did something
I should recall that. The ipmi(4) driver is in fairly clean. There
is some improvements I still need to do on probe/attachment that
causes a bogus ipmi1 at times.
Thanks a lot for this interesting information. I see, things are more
complicated than I thought. There is no easy way having a quick glance
at foreign memory during probing. Now I have to figure out how to get
the order of probing/attaching done. One thing I could do is:
1. attach mydriver_ACPI to acpi0
2. probe mydriver under hostb0, check if we need access to
sysresources from acpi0 (depends on the chipset found).
If no, goto 5.
3. ask mydriver_ACPI about stuff I want to know (HOW?)
4. tell mydriver to detach from acpi0 (HOW?)
5. attach mydriver to hostb0 and do my work
What I would like more is something like:
1. probe
Re: Reading acpi memory from a driver attached to hostb
John, apparently you sent me an email (thanks a lot) which I never received (we have to blame our company's spam filters which I do not control). I'll comment on it here in my reply to Doug... On Thu, 23-Jul-2009 at 07:25:40 -0700, Doug Ambrisko wrote: John Baldwin writes: | On Thursday 23 July 2009 2:08:35 am Andre Albsmeier wrote: | On Wed, 22-Jul-2009 at 09:48:56 -0700, Doug Ambrisko wrote: | Andre Albsmeier writes: | | stripping some elder stuff | | | | I assume it is possible somehow, I am just too stupid (it is the first | | driver I wrote). John, for easy reference, here is my initial message: | | | | http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html | | | | Please remember all, that I need the access to the acpi0 memory location | | only for a few reads during probing/attaching, not later. | | | | I have also read somewhere that, when resources are allocated, the | | system walks up the device tree until it finds the resource. Since | | my driver is below hostb0 and hostb0 is below acpi0 I thought it | | should work but it doesn't.. | | FWIW, you might look at ipmi(4) especially in some early states since | it can probe and attach in many ways (isa, acpi, pci etc.) and had to | figure out the best way to attach. Also it had various front ends. | If I recall correctly, I did a find for a driver (ie. acpi) then | select the first instance. Once you get that handle then you can | request device resources from it, get the info you need then release | that stuff. However, you won't get the module auto-loading part | that you would get if you created a module that depended on both. | That might get you enough of a hint. Also there are some generic | stuff to read various memory bits like SMBIOS areas etc. This is | used in ipmi(4) as well since the attachment can be defined in SMBIOS. | If you have a specific question, about why the driver did something | I should recall that. The ipmi(4) driver is in fairly clean. There | is some improvements I still need to do on probe/attachment that | causes a bogus ipmi1 at times. | | Thanks a lot for this interesting information. I see, things are more | complicated than I thought. There is no easy way having a quick glance | at foreign memory during probing. Now I have to figure out how to get | the order of probing/attaching done. One thing I could do is: | | 1. attach mydriver_ACPI to acpi0 | | 2. probe mydriver under hostb0, check if we need access to | sysresources from acpi0 (depends on the chipset found). | If no, goto 5. | | 3. ask mydriver_ACPI about stuff I want to know (HOW?) | | 4. tell mydriver to detach from acpi0 (HOW?) | | 5. attach mydriver to hostb0 and do my work | | What I would like more is something like: | | 1. probe mydriver under hostb0, check if we need access to | sysresources from acpi0 (depends on the chipset found). | If no, goto 3. | | 2. ask mydriver_ACPI to attach to acpi0, give me the info | I want, detach mydriver_ACPI (HOW?) | | 3. attach mydriver to hostb0 and do my work | | Did you try | doing 'bus_alloc_resource(device_get_parent(device_get_parent(dev))' in your | driver that is a child of hostb0? I tried this, well, something similar: I had to do 4 times device_get_parent() to end up at acpi0: mydriver - hostb0 - pci0 - pcib0 - acpi0 That should basically work since almost everything is a child of acpi. Thats what I hoped indeed. It would be a lot simpler than working with two drivers which have to communicate with each other. However, the depth could change so running through the device_get_parent and then checking the name might be good. I thought the same so I decided to lookup the acpi devclass and then acpi0 from there. To be sure, I compared the resulting pointers of acpi0 with the one found after the four device_get_parent(). They were the same. BTW, there is an example in sys/compat/linsysfs/linsysfs.c in which I run the entire bus tree via linsysfs_run_bus which is recursive and started from linsysfs_init. As John and I say, you don't need to attach to acpi just allocate what you need, access it, then release it. If you need to hold on it then it becomes more involved. Since you never attach then you don't need to dettach just release the resources you grabbed ( ie. bus_release_resource what you bus_alloc_resource). Well, then I still must be doing something wrong. I have attached my driver skeleton which does the following: 1. device_identify() which does a device_add_child() if needed 2. device_probe() which just tries to bus_alloc_resource() a SYS_RES_MEMORY resource from acpi0. If it works (which never does :-(), call bus_release_resource(). device_probe() always returns ENXIO so the whole driver never attaches. Especially in device_probe() I do
Re: Reading acpi memory from a driver attached to hostb
On Mon, 20-Jul-2009 at 14:05:34 +0300, Andriy Gapon wrote: on 18/07/2009 17:06 Julian Elischer said the following: Andre Albsmeier wrote: But in order to attach to acpi0, I need to say DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, NULL ); instead of DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, NULL ); try both with different devclass and other args. Just to expand on Julian's words. You can create eccmon and e.g. eccmon_acpi such that they are different drivers (on different buses) in newbus sense, but logically they can share data or otherwise cooperate. Very interesting code, I still haven't understood all of it but we will see... This could be the solution -- however, if somebody knows a more simple way, please let me know. Thanks, -Andre /sys/dev/cpufreq/ichss.c prior to rev. 177041 used to be like that. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Amateurs like Linux, but professionals prefer FreeBSD. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote:
Andre Albsmeier wrote:
[CC'ing this to Rui Paulo since he tried to help me a while ago]
Since my driver is a child of hostb0, I have no idea of how to access
acpi0's memory area. Here is a devinfo -r to make things clear:
...
Earlier, I was given the hint to attach as a child of acpi (see the
old mail attached below) but in this case I didn't have access to the
hostb registers which I need as well.
The only thing I see is: Attach two drivers -- one as child of acpi
and another as child of hostb and let them communicate somehow (no
idea how to do this).
I have also done crazy things like searching for acpi0 and trying
to bus_alloc_resource() the memory I am interested in but this also
failed.
Or is it possible to free(!) somehow the address space from acpi0
and pass it to hostb0 so I can bus_alloc_resource() it?
You can probably make two drivers in one which cooperate to
allow access to both sets of resources.
Hmm, that's what I meant by: Attach two drivers -- one as child of acpi
and another as child of hostb...
And that's similar to Rui Paulo's suggestion a while ago:
You'll probably need to create a fake ACPI child driver to access it.
Create your identify routine with something like:
static void mydriver_identify(driver_t *driver, device_t parent)
{
if (device_find_child(parent, mydriver, -1) == NULL
mydriver_match(parent))
device_add_child(parent, mydriver, -1);
}
mydriver_match() should check if you were given the acpi0 device.
But in order to attach to acpi0, I need to say
DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL, NULL );
instead of
DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL, NULL );
This way I could attach to acpi but not to hostb anymore
I have searched the net for solutions, I have read newbus-draft.txt
and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all
of these my driver is working on other mainboards where it doesn't
have to access foreign memory) but didn't find anything.
Thanks,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Reading acpi memory from a driver attached to hostb
On Sat, 18-Jul-2009 at 10:25:06 +0100, Rui Paulo wrote:
On 18 Jul 2009, at 09:10, Andre Albsmeier wrote:
On Fri, 17-Jul-2009 at 12:53:53 -0700, Julian Elischer wrote:
Andre Albsmeier wrote:
[CC'ing this to Rui Paulo since he tried to help me a while ago]
Since my driver is a child of hostb0, I have no idea of how to
access
acpi0's memory area. Here is a devinfo -r to make things clear:
...
Earlier, I was given the hint to attach as a child of acpi (see the
old mail attached below) but in this case I didn't have access to
the
hostb registers which I need as well.
The only thing I see is: Attach two drivers -- one as child of acpi
and another as child of hostb and let them communicate somehow (no
idea how to do this).
I have also done crazy things like searching for acpi0 and trying
to bus_alloc_resource() the memory I am interested in but this also
failed.
Or is it possible to free(!) somehow the address space from acpi0
and pass it to hostb0 so I can bus_alloc_resource() it?
You can probably make two drivers in one which cooperate to
allow access to both sets of resources.
Hmm, that's what I meant by: Attach two drivers -- one as child of
acpi
and another as child of hostb...
And that's similar to Rui Paulo's suggestion a while ago:
You'll probably need to create a fake ACPI child driver to access it.
Create your identify routine with something like:
static void mydriver_identify(driver_t *driver, device_t parent)
{
if (device_find_child(parent, mydriver, -1) == NULL
mydriver_match(parent))
device_add_child(parent, mydriver, -1);
}
mydriver_match() should check if you were given the acpi0 device.
But in order to attach to acpi0, I need to say
DRIVER_MODULE( eccmon, acpi, eccmon_driver, eccmon_devclass, NULL,
NULL );
instead of
DRIVER_MODULE( eccmon, hostb, eccmon_driver, eccmon_devclass, NULL,
NULL );
This way I could attach to acpi but not to hostb anymore
I have searched the net for solutions, I have read newbus-draft.txt
and newbus-intro.txt and Warner Losh's newbus-led.c (thanks to all
of these my driver is working on other mainboards where it doesn't
have to access foreign memory) but didn't find anything.
I'm out of ideas.
John, do you know if this is a newbus limitation or if it can be
worked around ?
I assume it is possible somehow, I am just too stupid (it is the first
driver I wrote). John, for easy reference, here is my initial message:
http://lists.freebsd.org/pipermail/freebsd-hackers/2009-July/029127.html
Please remember all, that I need the access to the acpi0 memory location
only for a few reads during probing/attaching, not later.
I have also read somewhere that, when resources are allocated, the
system walks up the device tree until it finds the resource. Since
my driver is below hostb0 and hostb0 is below acpi0 I thought it
should work but it doesn't..
Thanks again,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Reading acpi memory from a driver attached to hostb
[CC'ing this to Rui Paulo since he tried to help me a while ago]
I have written a driver that is a child of hostb (similar to agp) for
RELENG_7. However, on some chipsets (e.g. i975) it has to read some
memory locations (not pci configuration space) which were registered
by acpi as system resources.
Since my driver is a child of hostb0, I have no idea of how to access
this memory area. Here is a devinfo -r to make things clear:
nexus0
acpi0
Interrupt request lines:
9
I/O ports:
0x10-0x1f
0x22-0x3f
...
0x800-0x87f
I/O memory addresses:
0xc-0xd
0xe-0xf
0xf000-0xf3ff
0xfec0-0xfec00fff
0xfed13000-0xfed19fff --- the memory needed
0xfed1c000-0xfed1
0xfed2-0xfed3
0xfff0-0x
cpu0
coretemp0
acpi_throttle0
ACPI I/O ports:
0x810-0x813
cpufreq0
cpu1
coretemp1
pcib0
pci0
I/O ports:
0x170-0x177
0x376
hostb0
I/O memory addresses:
0xe400-0xe7ff
MYDRIVER0 --- my driver
agp0
pcib1
pci7
vgapci0
Interrupt request lines:
16
I had the same problem under RELENG_6 six month ago which could be
solved by a bus_set_resource() but since the driver now attaches to
hostb, this is not possible anymore.
Earlier, I was given the hint to attach as a child of acpi (see the
old mail attached below) but in this case I didn't have access to the
hostb registers which I need as well.
The only thing I see is: Attach two drivers -- one as child of acpi
and another as child of hostb and let them communicate somehow (no
idea how to do this).
I have also done crazy things like searching for acpi0 and trying
to bus_alloc_resource() the memory I am interested in but this also
failed.
Or is it possible to free(!) somehow the address space from acpi0
and pass it to hostb0 so I can bus_alloc_resource() it?
Thanks a lot for all ideas,
-Andre
--
Hello all,
I am writing a driver which needs to access memory at a
specific location. The location depends on what the BIOS
has configured into the host bridge. For example, my
current machine uses an Intel 975X chipset and the memory
location I am interested in has been set to 0xFED14000 and
is 16KB in size (this is MCHBAR of the 975X memory hub).
You probably just need to do something like:
rid = PCI_BAR(number);
res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, rid, RF_ACTIVE);
And then,
bus_read_4(res, offset from specified PCI BAR);
I have no idea how to access this space from my driver.
I have played around with bus_alloc_resource() but this
only gives me back NULL.
However, a devinfo -r gives me:
nexus0
npx0
acpi0
Interrupt request lines:
9
I/O ports:
0x10-0x1f
...
0x800-0x87f
I/O memory addresses:
0x0-0x9
0xc-0xd
0xe-0xf
0x10-0x7fff
0xf000-0xf3ff
0xfec0-0xfec00fff
0xfed13000-0xfed19fff---
0xfed1c000-0xfed1
0xfed2-0xfed3
0xfed5-0xfed8
0xfee0-0xfee00fff
0xffb0-0xffbf
0xfff0-0x
cpu0
...
The line marked with --- shows the range which includes
the location I am interested in. It is probably assigned
to the acpi0 device.
How do I proceed from this? Do I have to hack around in
the ACPI-Code? I don't hope so ;-)
You'll probably need to create a fake ACPI child driver to access it.
Create your identify routine with something like:
static void mydriver_identify(driver_t *driver, device_t parent)
{
if (device_find_child(parent, mydriver, -1) == NULL
mydriver_match(parent))
device_add_child(parent, mydriver, -1);
}
mydriver_match() should check if you were given the acpi0 device.
Regards,
--
Rui Paulo
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to detach a foreign driver from a device so my driver can attach?
On Wed, 21-Jan-2009 at 14:08:37 -0500, John Baldwin wrote:
On Tuesday 23 December 2008 12:33:22 pm Andre Albsmeier wrote:
On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote:
Hello all,
I am writing a driver which attaches to the Host-PCI bridge. When
compiled into the kernel or loaded by the loader everything works
and the driver gets attached. This is due to the fact that I return
BUS_PROBE_SPECIFIC in my probe routine which gains over the -1
returned by pci_hostb_probe() in i386/pci/pci_bus.c.
However, when I want to load my driver via kldload this fails since
the hostb device has already been attached during kernel load (when
my driver was not present):
hos...@pci0:0:0:class=0x06 card=0x11d510cf chip=0x35808086
rev=0x02 hdr=0x00
What can I do to make my driver load via kldload?
Is there a way to detach the hostb0 from the Host-PCI bridge?
Found the answer myself but will post it here in case anyone
got a similar problem one day: I added the device detach method
for the hostb driver to sys/i386/pci/pci_bus.c:
--- sys/i386/pci/pci_bus.c.ORI 2007-08-17 08:12:33.0 +0200
+++ sys/i386/pci/pci_bus.c 2008-12-23 13:34:35.0 +0100
@@ -619,10 +619,13 @@
return 0;
}
+static int pci_hostb_detach(device_t dev) { return 0; }
+
static device_method_t pci_hostb_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, pci_hostb_probe),
DEVMETHOD(device_attach,pci_hostb_attach),
+ DEVMETHOD(device_detach,pci_hostb_detach),
DEVMETHOD(device_shutdown, bus_generic_shutdown),
DEVMETHOD(device_suspend, bus_generic_suspend),
DEVMETHOD(device_resume,bus_generic_resume),
Now, when kldload'ing my driver, it can walk through all devices
and detach hostb using device_detach().
In the case of hostb, this is wrong however. You want to attach as a child
of
As I learned in the meanwhile, yes. But it was quite
interesting to learn how things work when you have
never been into FreeBSD driver hacking before ;-).
hostb as other devices (e.g. agp(4)) need to attach to host-pci bridges as
well.
Would this work in 6.x as well? You wrote in another mail that
in 7.0 agp attaches to hostb. This makes me think that in 6.x
things are handled differently.
If not, I will stick to my detaching while I am on 6.x
(don't need agp on my 440BXs) and do it right when
I have migrated to 7.x...
Thanks,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Writing device drivers: How to access a specific memory area?
On Thu, 25-Dec-2008 at 13:57:00 +, Rui Paulo wrote:
On 25 Dec 2008, at 09:53, Andre Albsmeier wrote:
Hello all,
I am writing a driver which needs to access memory at a
specific location. The location depends on what the BIOS
has configured into the host bridge. For example, my
current machine uses an Intel 975X chipset and the memory
location I am interested in has been set to 0xFED14000 and
is 16KB in size (this is MCHBAR of the 975X memory hub).
You probably just need to do something like:
rid = PCI_BAR(number);
res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, rid, RF_ACTIVE);
The problem was, that this memory belongs to acpi0
so I couldn't read it from my driver which has no
resources assigned to it. But, I found a way, see below...
And then,
bus_read_4(res, offset from specified PCI BAR);
I have no idea how to access this space from my driver.
I have played around with bus_alloc_resource() but this
only gives me back NULL.
However, a devinfo -r gives me:
nexus0
npx0
acpi0
Interrupt request lines:
9
I/O ports:
0x10-0x1f
...
0x800-0x87f
I/O memory addresses:
0x0-0x9
0xc-0xd
0xe-0xf
0x10-0x7fff
0xf000-0xf3ff
0xfec0-0xfec00fff
0xfed13000-0xfed19fff ---
0xfed1c000-0xfed1
0xfed2-0xfed3
0xfed5-0xfed8
0xfee0-0xfee00fff
0xffb0-0xffbf
0xfff0-0x
cpu0
...
The line marked with --- shows the range which includes
the location I am interested in. It is probably assigned
to the acpi0 device.
How do I proceed from this? Do I have to hack around in
the ACPI-Code? I don't hope so ;-)
You'll probably need to create a fake ACPI child driver to access it.
Create your identify routine with something like:
static void mydriver_identify(driver_t *driver, device_t parent)
{
if (device_find_child(parent, mydriver, -1) == NULL
mydriver_match(parent))
device_add_child(parent, mydriver, -1);
}
mydriver_match() should check if you were given the acpi0 device.
Found something easier: I just do a bus_set_resource() followed
by bus_alloc_resource_any(), access my host bridge registers,
and free things with bus_release_resource() followed by
bus_delete_resource().
I only need access to this memory location during the
probe of my driver to read some configuration data.
Is this pci configuration space ? If so, pci_read_config (man 9 pci)
Unfortunately not. As I wrote, it is a 16k memory window
where the 975x maps a part of its config registers. The
address of this window can be read by pci_read_config( dev, 0x44, 4 ).
Then you can access the bridge's cXdrcY registers through
this memory window which I needed to determine the
machines RAM layout.
Thanks anyway for your help,
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Writing device drivers: How to access a specific memory area?
Hello all, I am writing a driver which needs to access memory at a specific location. The location depends on what the BIOS has configured into the host bridge. For example, my current machine uses an Intel 975X chipset and the memory location I am interested in has been set to 0xFED14000 and is 16KB in size (this is MCHBAR of the 975X memory hub). I have no idea how to access this space from my driver. I have played around with bus_alloc_resource() but this only gives me back NULL. However, a devinfo -r gives me: nexus0 npx0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f ... 0x800-0x87f I/O memory addresses: 0x0-0x9 0xc-0xd 0xe-0xf 0x10-0x7fff 0xf000-0xf3ff 0xfec0-0xfec00fff 0xfed13000-0xfed19fff --- 0xfed1c000-0xfed1 0xfed2-0xfed3 0xfed5-0xfed8 0xfee0-0xfee00fff 0xffb0-0xffbf 0xfff0-0x cpu0 ... The line marked with --- shows the range which includes the location I am interested in. It is probably assigned to the acpi0 device. How do I proceed from this? Do I have to hack around in the ACPI-Code? I don't hope so ;-) I only need access to this memory location during the probe of my driver to read some configuration data. I do not need to access it later anymore... Thanks a lot for any hints, -Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: How to detach a foreign driver from a device so my driver can attach?
On Wed, 17-Dec-2008 at 00:04:30 +0100, Andre Albsmeier wrote:
Hello all,
I am writing a driver which attaches to the Host-PCI bridge. When
compiled into the kernel or loaded by the loader everything works
and the driver gets attached. This is due to the fact that I return
BUS_PROBE_SPECIFIC in my probe routine which gains over the -1
returned by pci_hostb_probe() in i386/pci/pci_bus.c.
However, when I want to load my driver via kldload this fails since
the hostb device has already been attached during kernel load (when
my driver was not present):
hos...@pci0:0:0:class=0x06 card=0x11d510cf chip=0x35808086 rev=0x02
hdr=0x00
What can I do to make my driver load via kldload?
Is there a way to detach the hostb0 from the Host-PCI bridge?
Found the answer myself but will post it here in case anyone
got a similar problem one day: I added the device detach method
for the hostb driver to sys/i386/pci/pci_bus.c:
--- sys/i386/pci/pci_bus.c.ORI 2007-08-17 08:12:33.0 +0200
+++ sys/i386/pci/pci_bus.c 2008-12-23 13:34:35.0 +0100
@@ -619,10 +619,13 @@
return 0;
}
+static int pci_hostb_detach(device_t dev) { return 0; }
+
static device_method_t pci_hostb_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, pci_hostb_probe),
DEVMETHOD(device_attach,pci_hostb_attach),
+ DEVMETHOD(device_detach,pci_hostb_detach),
DEVMETHOD(device_shutdown, bus_generic_shutdown),
DEVMETHOD(device_suspend, bus_generic_suspend),
DEVMETHOD(device_resume,bus_generic_resume),
Now, when kldload'ing my driver, it can walk through all devices
and detach hostb using device_detach().
-Andre
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
How to detach a foreign driver from a device so my driver can attach?
Hello all, I am writing a driver which attaches to the Host-PCI bridge. When compiled into the kernel or loaded by the loader everything works and the driver gets attached. This is due to the fact that I return BUS_PROBE_SPECIFIC in my probe routine which gains over the -1 returned by pci_hostb_probe() in i386/pci/pci_bus.c. However, when I want to load my driver via kldload this fails since the hostb device has already been attached during kernel load (when my driver was not present): hos...@pci0:0:0:class=0x06 card=0x11d510cf chip=0x35808086 rev=0x02 hdr=0x00 What can I do to make my driver load via kldload? Is there a way to detach the hostb0 from the Host-PCI bridge? I have been digging around in the sources but didn't find something similar. In case of any hints, please CC me since I am currently travelling and can't easily read the lists at home... Thanks, -Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kern.ngroups question
On Tue, 05-Jun-2007 at 11:49:44 -0500, Reuben A. Popp wrote: Hello all, Can someone explain to me the rationale behind having ngroups_max set to 16 by default? I came across this issue originally when working on our Samba implementation (samba-3 out of ports, running on 6-STABLE). We have some users that belong to a number of groups, some of whom need to belong to more groups than the defined hard limit. On doing a little research, I did come across the PR detailed in http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/108552, and continued reading the linked thread from March 2003, however this really doesn't explain why the limit is set to 16. Can one adjust the value in syslimits.h on a system and then rebuild world/ports with the expectation this will work, or is the issue more involved then that? Is (or has) there any discussion on raising that number to a larger value? About 2 years ago I changed it to 64 (all over the place) and recompiled world, kernels, ports and every programme on the boxes in question. Things worked well but NFS went mad (IIRC, NFS4 will do better here but I am not sure). Since I needed the groups in question to control file access, I reverted the change and switched to ACLs which is not so intrusive :-). -Andre Thanks in advance (doubly so if this is a lame question) Reuben -- Reuben A. Popp Systems Administrator Information Technology Department East Central College 1+ 636 583 5195 x2480 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- ech`echo xiun | tr nu oc | sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Sat, 01-Jul-2006 at 10:35:47 +0200, Matthias Andree wrote: Pat Lashley [EMAIL PROTECTED] writes: BUT, that said, the safest and most portable coding practice would be: // The C standard does not require malloc(0) to return NULL; // but whatever it returns MUST NOT be dereferenced. ptr = ( size == 0 ) ? NULL : malloc( size ) ; Safest (avoiding null derefence) would instead be: ptr = malloc(size ? size : 1); I hacked malloc.c to do exactly this automatically, just for testing. 15 Minutes after rebooting (and after doing a lot of desktop switching and opening and closing of windows) the X-server ran out of memory :-). I assume there are lots of programs out there which do malloc(0) but only firefox (and apparently seamonkey) dereference the returned non-NULL pointer and crash therefore. -Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Fri, 30-Jun-2006 at 12:15:21 -0400, Pat Lashley wrote: I went wandering through the C Working Group archives for the heck of it, and apparently a lot of people were confused over this, thinking either as you did or that unique meant it would a value unique to the usage of malloc(0). It's been clarified recently (and will be in the next revision of the standard) to the meaning you understood. ... This is wandering into -standards territory, though. In any case, the answer to thread's original question is mozilla should fix its code to not assume malloc(0)==NULL. Agreed. (With the usual observation that they, too, are a mainly volunteer-based project; and would probably appreciate the inclusion of a patch Well, I was unsure of the correct behaviour. That's why I came here:-). From all what I've read so far, I can summarize: - Returning a non-NULL value from malloc(0) is completely legal. - We return a non-NULL value which, when dereferenced, always make the application crash (as a warning). See the commit message of rev. 1.60 of malloc.c: snip -- phkmalloc-evilchecks++; If zero bytes are allocated, return pointer to the middle of page-zero (which is protected) so that the programme will crash if it dereferences this illgotten pointer. Inspired Urged by:Theo de Raadt [EMAIL PROTECTED] snap -- - What we do isn't 100% perfect since we always return the same value for each malloc(0). - It was firefox' fault to crash. - The manpage is heavily misleading. Firefox must be fixed but some stuff can be done in FreeBSD as well: - If we keep our current behaviour we have to change the manpage. (As I said before, I could do that if someone will commit it later.) - We could reverse the meaning of the V-flag (or, introduce a new flag to avoid confusion). This would mean that by default a malloc(0) will return NULL in future. The new flag can be used to change this behaviour to the way it was done before: We hand out the value which, when dereferenced, make the programme crash as a warning to the author. We note in the manpage that it is not 100% legal since we always use the same value. with the bug report. And, of course, that the original poster of this thread should file a bug report with the Mozilla project.) Please see: https://bugzilla.mozilla.org/show_bug.cgi?id=343283 It wasn't me who created this PR but the author of the extension which actually revealed the bug. -Andre -- UNIX is an operating system, OS/2 is half an operating system, Windows is a shell, and DOS is a bootsector virus. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Return value of malloc(0)
On Wed, 28-Jun-2006 at 16:19:35 -0400, Lowell Gilbert wrote:
Andre Albsmeier [EMAIL PROTECTED] writes:
The manpage makes me think that when malloc is called with 0
as argument (and no V-flag had been set) the pointer it returns
can actually be used (as a pointer to the so-called minimal
allocation). It seems, that firefox thinks the same way :-).
However, it is calculated in malloc.c as a constant and is
always 0x800 (on my architecture). Any access to this area
results in a SIGSEV.
The C standard explicitly allows both behaviours, and requires the
implementation to choose one of them. If it returns a non-NULL
pointer, though, that pointer can *only* be used for passing back to
free(). It may *not* be dereferenced. So firefox is wrong, and
actually broken.
Very good. I am glad this is clearly defined.
I assume the behaviour is meant to show up programming errors:
If you use malloc(0) and are crazy enough to access the 'allocated'
memory we give you a SIGSEV to show you how dumb you are :-).
Yes.
In this case the manpage is wrong (or, at least, mis-leading) and
should be fixed (I could give it a try if someone actually is willing
to commit it).
I don't see what you are claiming is wrong. Can you give a brief
It says:
The default behavior is to make a minimal allocation and return
a pointer to it.
This sounds as if it allocated some (!) bytes so the application
can use it. Yes, I know that 0 would be minimal as well :-). And
if you look into malloc.c you will see that, in fact, it doesn't
allocate anything at all:
} else if (!size) {
if (ptr != NULL)
ifree(ptr);
r = ZEROSIZEPTR;
r ist returned later and ZEROSIZEPTR is a constant.
description of you're suggesting.
Hmm, let's see:
The default behavior is to return a non-NULL pointer which may
be passed to free() but does not point to any memory which can
be used by the application.
Apart from that, I suggest, we should run firefox (and maybe other
mozilla apps) with MALLOC_OPTIONS=V.
That would be reasonable, particularly for the time being. However,
the firefox bug really should be fixed in the upstream sources.
In this case, yes, of course.
-Andre
Writing past the end of an allocated buffer (which is what the code
does, if you think about it) is a serious error.
Another position could be that firefox is wrong because it NEVER
may use ANY return value of a malloc(0), regardless of its content.
The C language standard agrees with this position...
--
Micro$oft: When will your system crash today?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Return value of malloc(0)
There is a nice extension for firefox called prefbar. However, newer versions of prefbar (=3.3) make firefox die with SIGSEGV, see http://bugzilla.mozdev.org/show_bug.cgi?id=13809 for details. The crash happens in libgklayout.so: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 100116)] 0x29a9599b in nsGlobalWindow::RunTimeout (this=0x8393500, aTimeout=0x8935000) at nsGlobalWindow.cpp:6378 6378 timeout-mArgv[timeout-mArgc] = Current language: auto; currently c++ (gdb) p timeout-mArgc $1 = 0 (gdb) p timeout-mArgv $2 = (jsval *) 0x800 (gdb) p timeout-mArgv[timeout-mArgc] Error accessing memory address 0x800: Bad address. The 0x800 are the result of an earlier malloc(0). When looking at the MALLOC(3) manpage, we can read (near the description of the flags): ... VAttempting to allocate zero bytes will return a NULL pointer instead of a valid pointer. (The default behavior is to make a minimal allocation and return a pointer to it.) This option is provided for System V compatibility. This option is incompatible with the ``X'' option. ... So I gave it a try by running MALLOC_OPTIONS=V firefox and firefox didn't crash anymore and prefbar was running :-). (Now malloc returns NULL and firefox doesn't interpret the result as a pointer to some allocated memory and therefore doesn't use it). The manpage makes me think that when malloc is called with 0 as argument (and no V-flag had been set) the pointer it returns can actually be used (as a pointer to the so-called minimal allocation). It seems, that firefox thinks the same way :-). However, it is calculated in malloc.c as a constant and is always 0x800 (on my architecture). Any access to this area results in a SIGSEV. I assume the behaviour is meant to show up programming errors: If you use malloc(0) and are crazy enough to access the 'allocated' memory we give you a SIGSEV to show you how dumb you are :-). In this case the manpage is wrong (or, at least, mis-leading) and should be fixed (I could give it a try if someone actually is willing to commit it). Apart from that, I suggest, we should run firefox (and maybe other mozilla apps) with MALLOC_OPTIONS=V. Another position could be that firefox is wrong because it NEVER may use ANY return value of a malloc(0), regardless of its content. Opinions, please... -Andre P.S.: If someone wants to know where the crash happens in firefox please see http://bugzilla.mozdev.org/show_bug.cgi?id=13809. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Making inheritance of group ID configurable
New items created on an ufs normally inherit their group ID from
the parent directory. I have the need for making this configurable.
Since the set-group-ID bit is not used for directories on BSD,
I would like to use it to decide on this: If it is set, the group
ID of the newly created item corresponds to the one of the creating
process. (Yeah, this is exactly the wrong way around compared to
what the Others do but I don't want to change the BSD default).
I am currently using this patch. It seems to work great but I would
like to know if I have forgotten something ;-)
--- sys/ufs/ufs/ufs_vnops.c.ORI Fri Jan 3 08:41:47 2003
+++ sys/ufs/ufs/ufs_vnops.c Mon Feb 9 16:32:46 2004
@@ -1276,6 +1276,11 @@
if (error)
goto out;
ip = VTOI(tvp);
+#ifdef ANDRE
+ if( (dp-i_mode ISGID) )
+ ip-i_gid = cnp-cn_cred-cr_gid;
+ else
+#endif
ip-i_gid = dp-i_gid;
#ifdef SUIDDIR
{
@@ -2070,6 +2075,11 @@
if (error)
return (error);
ip = VTOI(tvp);
+#ifdef ANDRE
+ if( (pdir-i_mode ISGID) )
+ ip-i_gid = cnp-cn_cred-cr_gid;
+ else
+#endif
ip-i_gid = pdir-i_gid;
#ifdef SUIDDIR
{
Any hints are welcome.
Thanks,
-Andre
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Making inheritance of group ID configurable
On Mon, 09-Feb-2004 at 16:45:11 +, David Malone wrote: On Mon, Feb 09, 2004 at 05:10:59PM +0100, Andre Albsmeier wrote: New items created on an ufs normally inherit their group ID from the parent directory. I have the need for making this configurable. Since the set-group-ID bit is not used for directories on BSD, I would like to use it to decide on this: If it is set, the group ID of the newly created item corresponds to the one of the creating process. (Yeah, this is exactly the wrong way around compared to what the Others do but I don't want to change the BSD default). Would making this a filesystem option be a good idea? You could have the default behaviour be as always and an option that makes the filesystem behave as you've described. Possibly. I intentionally didn't suggest this since I wanted to attract people to the technical aspects (and the correctness) of the patch and not to the political opinions :-). -Andre David. -- In a world without walls and fences, who needs windows and gates? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: i am looking for a 5 volt signal
On Sun, 27-Oct-2002 at 09:12:33 -0800, David Nicholas Kayal wrote:
I'm looking for a 5 volt signal.
I have wires plugged into pins 2 and 25 of the parallel port.
I have written a small program:
#include stdio.h
#include dev/ppbus/ppi.h
#include dev/ppbus/ppbconf.h
int main()
{
int fd;
while(1)
{
ioctl(fd, PPISDATA, 255);
}
}
I had at least one machine where I had to drive the STROBE signal
to actually get the data appear on the bus. The program attached
below did the trick. It does a little bit more so here is a quick
explanation:
I wanted to physically push the RESET button of another machine
(running Windoze, btw. :-)). To make things a bit more robust
I used all 8 lines of data which are attached to a HC 688 (iirc)
whose second 8 bit input is hardwired to the value 0x5A. Its
output drives an optocoupler whose output is connected to the
RESET connector of the Windoze box. The power was supplied by
all output capable lines of the parallel port (8 data, strobe,
some control lines) which are all connected via diodes and a
resistor to a capacitor. The program first drives the 8 databits
high to charge the capacitor for 5 seconds. It then puts the
0x5A word on the wire for one second. This is when the HC 688's
output goes high and drives the optocoupler to reset the windoze
box.
If you look at the program you'll find that every dataoutput
is surrounded by the apprpropriate STROBE action.
Hth,
-Andre
#include stdio.h
#include unistd.h
#include fcntl.h
#include err.h
#include sysexits.h
#include dev/ppbus/ppi.h
#include dev/ppbus/ppbconf.h
int Fd;
void send( u_int8_t byte )
{
u_int8_t myc, tmp;
printf( Sending %02X\n, byte );
if( ioctl( Fd, PPIGCTRL, myc ) == -1 ) // save old control
err( EX_IOERR, save control );
myc = ~STROBE ~PCD;// strobe high
tmp = myc;
if( ioctl( Fd, PPISCTRL, tmp )== -1 )
err( EX_IOERR, set control );
if( ioctl( Fd, PPISDATA, byte ) == 1 ) // set my code
err( EX_IOERR, set data );
tmp = myc | STROBE; // strobe low
if( ioctl( Fd, PPISCTRL, tmp )== -1 )
err( EX_IOERR, set control );
tmp = myc;
if( ioctl( Fd, PPISCTRL, tmp )== -1 )// strobe high
err( EX_IOERR, set control );
}
int main( int argc, const char* argv[] )
{
if( (Fd = open( /dev/ppi0, O_RDWR)) = 0 )
err( EX_IOERR, open /dev/ppi0 );
send( 0xFF ); // charge C
sleep( 5 );
send( 0x5A ); // send code
sleep( 1 );
send( 0xFF ); // disable code
return( 0 );
}
Re: 4.4-RC NFS panic
On Tue, 21-Aug-2001 at 09:35:34 +0100, David Malone wrote:
I've just done a further test. I've mounted a directory tree from
Vaio to Vaio using localhost (lo driver) and the test has run
smoothly. So chances would be good the bug is in the ep driver.
Unfortunately...
Andre Albsmeier, who's seeing various network problems, is using
the xe driver (also PCMCIA I think), but the problems go away if
he uses an Etherexpress card on the PCI bus of the same machine.
As I wrote in my PR (#29845), my problems also happen with
the 3C589 which uses the ep driver. So we can sum up to:
1.) Intel Etherexpress PRO/100 PCMCIA (xe driver) crashes
2.) 3Com 589D EtherLink III PCMCIA (ep driver) crashes
3.) Intel Etherexpress PRO/100+ PCI Card (fxp driver) works perfectly
-Andre
It seems unlikely to be PCMCIA related ('cos it has nothing to do
with the networking itself) it may just be triggered in machines
with slower networking.
David.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: 4.4-RC NFS panic
On Tue, 21-Aug-2001 at 03:07:33 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Andre Albsmeier writes: : As I wrote in my PR (#29845), my problems also happen with : the 3C589 which uses the ep driver. So we can sum up to: : : 1.) Intel Etherexpress PRO/100 PCMCIA (xe driver) crashes : 2.) 3Com 589D EtherLink III PCMCIA (ep driver) crashes : 3.) Intel Etherexpress PRO/100+ PCI Card (fxp driver) works perfectly Interesting. I'm not sure what to make of this. So do I. Ian Dowse already sent me a program to inspect the mbufs in the crashdumps. I don't know a lot about mbufs but the output appears really hosed... I will try it again using another PCMICA card I just got... -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.4-RC NFS panic
On Tue, 21-Aug-2001 at 03:07:33 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Andre Albsmeier writes: : As I wrote in my PR (#29845), my problems also happen with : the 3C589 which uses the ep driver. So we can sum up to: : : 1.) Intel Etherexpress PRO/100 PCMCIA (xe driver) crashes : 2.) 3Com 589D EtherLink III PCMCIA (ep driver) crashes : 3.) Intel Etherexpress PRO/100+ PCI Card (fxp driver) works perfectly Interesting. I'm not sure what to make of this. We can now add: 4.) D-Link DFE-650 PCMCIA (ed driver)freezes :-( Warner, I have seen your mails regarding pcic-44rc1.diff.1. My box has a TI PCI-1225 chip... I will try the patch... -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.4-RC NFS panic
On Tue, 21-Aug-2001 at 11:45:12 -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] David Malone writes:
: Andre Albsmeier, who's seeing various network problems, is using
: the xe driver (also PCMCIA I think), but the problems go away if
: he uses an Etherexpress card on the PCI bus of the same machine.
:
: It seems unlikely to be PCMCIA related ('cos it has nothing to do
: with the networking itself) it may just be triggered in machines
: with slower networking.
After talking with Ian Dowse, I think that we've hammered out what may
cause this. Basically, the problem is
code in net doing splnet()
interrupt here - pcic_pci_intr - netcard_intr - network code.
And we've interrupted the critical section, broken all kinds of
invariants.
Warner
P.S. I think that with Ian's other interrupt changes, we can do the
following w/o problems. This should fix the network problems, I
think.
Runs perfectly for about 10 minutes now under full load. It didn't
survive 10 seconds before :-)
I still have the hangs on a warm reboot but this is a different
story...
Thanks a lot for the quick help!
-Andre
Index: pcic_pci.c
===
RCS file: /cache/ncvs/src/sys/pccard/pcic_pci.c,v
retrieving revision 1.54.2.7
diff -u -r1.54.2.7 pcic_pci.c
--- pcic_pci.c2001/08/21 09:06:25 1.54.2.7
+++ pcic_pci.c2001/08/21 17:18:06
@@ -515,15 +515,6 @@
* in the CD change.
*/
sp-getb(sp, PCIC_STAT_CHG);
-
- /*
- * If we have a card in the slot with an interrupt handler, then
- * call it. Note: This means that each card can have at most one
- * interrupt handler for it. Since multifunction cards aren't
- * supported, this shouldn't cause a problem in practice.
- */
- if (sc-cd_present sp-intr != NULL)
- sp-intr(sp-argp);
}
/*
@@ -784,36 +775,6 @@
return (0);
}
-static int
-pcic_pci_setup_intr(device_t dev, device_t child, struct resource *irq,
-int flags, driver_intr_t *intr, void *arg, void **cookiep)
-{
- struct pcic_softc *sc = (struct pcic_softc *) device_get_softc(dev);
- struct pcic_slot *sp = sc-slots[0];
-
- if (sp-intr) {
- device_printf(dev,
-Interrupt already established, possible multiple attach bug.\n);
- return (EINVAL);
- }
- sp-intr = intr;
- sp-argp = arg;
- *cookiep = sc;
- return (0);
-}
-
-static int
-pcic_pci_teardown_intr(device_t dev, device_t child, struct resource *irq,
-void *cookie)
-{
- struct pcic_softc *sc = (struct pcic_softc *) device_get_softc(dev);
- struct pcic_slot *sp = sc-slots[0];
-
- sp-intr = NULL;
- sp-argp = NULL;
- return (0);
-}
-
static device_method_t pcic_pci_methods[] = {
/* Device interface */
DEVMETHOD(device_probe, pcic_pci_probe),
@@ -829,8 +790,8 @@
DEVMETHOD(bus_release_resource, bus_generic_release_resource),
DEVMETHOD(bus_activate_resource, pcic_activate_resource),
DEVMETHOD(bus_deactivate_resource, pcic_deactivate_resource),
- DEVMETHOD(bus_setup_intr, pcic_pci_setup_intr),
- DEVMETHOD(bus_teardown_intr,pcic_pci_teardown_intr),
+ DEVMETHOD(bus_setup_intr, bus_generic_setup_intr),
+ DEVMETHOD(bus_teardown_intr,bus_generic_teardown_intr),
/* Card interface */
DEVMETHOD(card_set_res_flags, pcic_set_res_flags),
--
BSD, from the people who brought you TCP/IP.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: 4.4-RC NFS panic
On Tue, 21-Aug-2001 at 23:44:40 -0600, Warner Losh wrote: In message [EMAIL PROTECTED] Andre Albsmeier writes: : I still have the hangs on a warm reboot but this is a different : story... Eh? what kind of hangs and when? Attached below is the dmesg... It hangs only when warm booting; after a power toggle everything is OK... Copyright (c) 1992-2001 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.4-RC #23: Wed Aug 22 07:21:34 CEST 2001 [EMAIL PROTECTED]:/src/obj-4/src/src-4/sys/schlappy Calibrating clock(s) ... TSC clock: 30160 Hz, i8254 clock: 1193146 Hz Timecounter i8254 frequency 1193146 Hz CPU: Pentium II/Pentium II Xeon/Celeron (366.66-MHz 686-class CPU) Origin = GenuineIntel Id = 0x66a Stepping = 10 Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134152192 (131008K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00325000 - 0x07febfff, 130838528 bytes (31943 pages) avail memory = 127590400 (124600K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f6230 bios32: Entry = 0xfd790 (c00fd790) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0x225 pnpbios: Found PnP BIOS data at 0xc00f6260 pnpbios: Entry = f:a34e Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ACPI: 000f61f0 Preloaded elf kernel kernel at 0xc02ff000. Pentium Pro MTRR support enabled pci_open(1):mode 1 addr port (0x0cf8) is 0x8000384c pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Using $PIR table, 7 entries at 0xc00fdf50 apm0: APM BIOS on motherboard apm: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard found- vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[10]: type 1, range 32, base f800, size 26 found- vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 found- vendor=0x8086, dev=0x7110, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 found- vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[20]: type 1, range 32, base fcd0, size 4 found- vendor=0x8086, dev=0x7112, revid=0x01 class=0c-03-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 intpin=d, irq=9 map[20]: type 1, range 32, base fce0, size 5 found- vendor=0x8086, dev=0x7113, revid=0x02 class=06-80-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[90]: type 1, range 32, base 2180, size 4 found- vendor=0x104c, dev=0xac1c, revid=0x01 class=06-07-00, hdrtype=0x02, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=10 found- vendor=0x104c, dev=0xac1c, revid=0x01 class=06-07-00, hdrtype=0x02, mfdev=1 subordinatebus=0secondarybus=0 intpin=b, irq=11 pci0: PCI bus on pcib0 pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0 found- vendor=0x10c8, dev=0x0005, revid=0x12 class=03-00-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=a, irq=10 map[10]: type 1, range 32, base f600, size 24 map[14]: type 1, range 32, base fe40, size 22 map[18]: type 1, range 32, base feb0, size 20 found- vendor=0x10c8, dev=0x8005, revid=0x12 class=04-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 intpin=b, irq=11 map[10]: type 1, range 32, base f780, size 22 map[14]: type 1, range 32, base fea0, size 20 pci1: PCI bus on pcib1 pci1: NeoMagic MagicMedia 256AV SVGA controller (vendor=0x10c8, dev=0x0005) at 0.0 irq 10 chip1: NeoMagic MagicMedia 256AX Audio controller mem 0xfea0-0xfeaf,0xf780-0xf7bf irq 11 at device 0.1 on pci1 isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xfcd0-0xfcdf at device 7.1 on pci0 ata0: iobase=0x01f0 altiobase=0x03f6 bmaddr=0xfcd0 ata0: mask=03 status0=50 status1=50 ata0: mask=03 ostat0=50 ostat2=50 ata0-slave: ATAPI probe a=14 b=eb ata0-master: ATAPI probe a=00 b=00 ata0: mask=03 status0=50 status1=00 ata0-master: ATA probe a=01 b=a5 ata0: devices=09 ata0: at 0x1f0 irq 14 on atapci0 ata1: iobase=0x0170 altiobase=0x0376 bmaddr=0xfcd8 ata1: mask=00 status0=ff status1=ff ata1: probe allocation failed pci0: Intel 82371AB/EB (PIIX4) USB controller (vendor=0x8086, dev=0x7112
Re: Acroread4
On Wed, 12-Apr-2000 at 21:33:34 +0200, Wilko Bulte wrote: On Wed, Apr 12, 2000 at 03:02:10PM -0400, Sean O'Connell wrote: Wilko Bulte stated: On Wed, Apr 12, 2000 at 10:38:04AM -0400, Vivek Khera wrote: "A" == Asmodai Jeroen writes: I don't think this is a 4.0 issue. I get the same on a couple of 3.4R systems, minus the locale message. A I can, on my 3.4-STABLE, get acroread4 to coredump time and again. I've never had acroread version 4 croak on my 3.4-STABLE system. It works just perfectly fine. Well... (just installed): acroread-4.05 gives: WKB ~acroread4 Floating point exception (core dumped) on 3.4-stable. Is this what Vivek is seeing? Wilko- I think you can get around this by installing the /sys/i386/include/npx.h (version 1.18) from RELENG_4,5 and rebuilding your kernel (this also helps with linux netscape/realplayer and a few other linux goodies). Hmm, interesting. Unfortunately it is no so simple as it appears. You also need globals.h which is not in 3.4-stable. Pulled that out of CVS. Now I see vm-machdep.c fail the compile.. Don't use the whole npx.h 1.18, only the latest patch which sets __INITIAL_NPXCW__ to 0x127F. This made it work for me... -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: desire for ftp.internat.freebsd.org mirror
On Wed, 05-Apr-2000 at 18:08:33 -0700, David O'Brien wrote: Access to ftp.internat.freebsd.org from the USA (and presumably elsewhere) is an abomination. Isn't there *anyone* with an permanate FTP server that could officially mirror the crypto bits from ftp.internat.freebsd.org? Try ftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/development/CTM-international -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix for quotas grace time when using chown and soft limits are hit again
Oops, I don't remember having sent this twice... -Andre On Wed, 01-Mar-2000 at 22:19:56 +0100, Andre Albsmeier wrote: Here is a problem with FreeBSD's quotas that I have observed for a long time now but finally found some time to track it down: Let's assume the following settings on a quota enabled system: soft limits : 100MB hard limits : 200MB grace period: 7 days ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fix for quotas grace time when using chown and soft limits are hit again
[follow up to myself...] On Wed, 01-Mar-2000 at 22:19:56 +0100, Andre Albsmeier wrote: Here is a problem with FreeBSD's quotas that I have observed for a long time now but finally found some time to track it down: Let's assume the following settings on a quota enabled system: soft limits : 100MB hard limits : 200MB grace period: 7 days ... --- /sys/ufs/ufs/ufs_quota.c Mon Aug 30 17:56:23 1999 +++ ufs_quota.c Wed Mar 1 21:27:14 2000 @@ -163,6 +163,10 @@ (void) tsleep((caddr_t)dq, PINOD+1, "chkdq2", 0); } dq-dq_curblocks += change; /* check if we hit the soft limits */ + if (dq-dq_curblocks = dq-dq_bsoftlimit dq-dq_bsoftlimit) /* check if we have been below the soft limits before */ + if (dq-dq_curblocks - change dq-dq_bsoftlimit) /* yes, update the timer */ + dq-dq_btime = time_second + + VFSTOUFS(ITOV(ip)-v_mount)-um_btime[i]; dq-dq_flags |= DQ_MOD; } return (0); @@ -279,6 +283,10 @@ (void) tsleep((caddr_t)dq, PINOD+1, "chkiq2", 0); } dq-dq_curinodes += change; /* same as above for inodes */ + if (dq-dq_curinodes = dq-dq_isoftlimit dq-dq_isoftlimit) + if (dq-dq_curinodes - change dq-dq_isoftlimit) + dq-dq_itime = time_second + + VFSTOUFS(ITOV(ip)-v_mount)-um_itime[i]; dq-dq_flags |= DQ_MOD; } return (0); Couldn't stand waiting any longer so I tried it on a test box and it seems to work :-). However, I am interested in hearing the opinion from the filesystem specialists if the issue: a) is really a bug b) can be fixed (changed) with the above patch properly Thanks to all in advance, -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fix for quotas grace time when using chown and soft limits are hit again
Here is a problem with FreeBSD's quotas that I have observed for a long time now but finally found some time to track it down: Let's assume the following settings on a quota enabled system: soft limits : 100MB hard limits : 200MB grace period: 7 days On day 1, the user U1 creates 150MB of data. The soft limits are reached but not the hard limits. The internal grace timer is set accordingly (to current_time + 7 days). On day 3, the user U1 removes 100MB. There are 50MB remaining and the grace period is no more important. From now on, the users U1's amount of data stays between 50 and 60 MB. On day 10, user U2 leaves system forever. He got 100MB of data and the admin decides that U1 has to take care of them. So he moves U2's data to U1's directory and runs a "chown -R U1" there. Now, U1 has around 150MB of data belonging to him. The admin tells U1 that he is now over the soft limit and has got 7 days time to inspect U2's data. This is where the problem starts: When examining the quotas for U1 we find that the grace period is already over and the soft limits have turned into hard limits. This only happens if U1 has been over the soft limit some time before. So far for the facts - now let's start the wild guess :-) I assume the problem appears because the system still uses the old grace timer (set to day 7) which is exceeded on day 10 when the files are given to U1. This was no problem before (on days 8 and 9) because the grace time is only used if we are over the soft limits. When root does his chown, the grace timer for U1 is not set to day 10 + 7 days. I think the problem can be fixed _somehow_ with the following patch to /sys/ufs/ufs/ufs_quota.c: (I have included some comments manually _after_ creating the patch) --- /sys/ufs/ufs/ufs_quota.cMon Aug 30 17:56:23 1999 +++ ufs_quota.c Wed Mar 1 21:27:14 2000 @@ -163,6 +163,10 @@ (void) tsleep((caddr_t)dq, PINOD+1, "chkdq2", 0); } dq-dq_curblocks += change; /* check if we hit the soft limits */ + if (dq-dq_curblocks = dq-dq_bsoftlimit dq-dq_bsoftlimit) /* check if we have been below the soft limits before */ + if (dq-dq_curblocks - change dq-dq_bsoftlimit) /* yes, update the timer */ + dq-dq_btime = time_second + + VFSTOUFS(ITOV(ip)-v_mount)-um_btime[i]; dq-dq_flags |= DQ_MOD; } return (0); @@ -279,6 +283,10 @@ (void) tsleep((caddr_t)dq, PINOD+1, "chkiq2", 0); } dq-dq_curinodes += change; /* same as above for inodes */ + if (dq-dq_curinodes = dq-dq_isoftlimit dq-dq_isoftlimit) + if (dq-dq_curinodes - change dq-dq_isoftlimit) + dq-dq_itime = time_second + + VFSTOUFS(ITOV(ip)-v_mount)-um_itime[i]; dq-dq_flags |= DQ_MOD; } return (0); As far as I understood things correctly, chkdq() is being called from the chown code in the kernel. When the amount of blocks (inodes) changes, there is no check being done if the soft limit is hit. In chkdqchg() we find the interesting part which I tried to bring into chkdq() with the above patch. I have no idea about vfs, ufs and all these things so maybe one of the more enlightened people (Matt, Alfred, ...) might be able to correct me. If the current behaviour is desired it would be nice if someone could tell me if my patch goes in the right direction if I want to fix it for me only. Thanks, -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CCD questions
On Mon, 01-Nov-1999 at 08:36:35 -0800, Doug White wrote: On Sun, 31 Oct 1999, Andre Albsmeier wrote: ccdconfig manufactures a disklabel when you create the stripe, so you don't need to adjust the disklabel. The subdisks must have disklabels, and you can't use the C partition since ccd only uses partitions of type 4.2BSD. Does that mean I should not use partition c as a 4.2BSD type? This is what I am currently doing on all disks (ccd'ed or single) if the whole disk is used as one big filesystem, e.g.: #size offsetfstype [fsize bsize bps/cpg] c: 4532264404.2BSD 1024 819216 # (Cyl.0 - 2810*) I've been admonished for using the c partition as a filesystem since it's somewhat magic. For regular disks the running recommendation is to make another partition (a or g or whatever) that is identical to the c partition information, and to newfs/mount that. I personally haven't run into problems but I've been warned that the c partition interface is subject to change. OK, I see. So I am going to use the a partition in future and leave c unused. Thanks, -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CCD questions
On Mon, 01-Nov-1999 at 10:42:21 -0500, Greg Lehey wrote: On Sunday, 31 October 1999 at 19:53:51 +0100, Andre Albsmeier wrote: On Fri, 29-Oct-1999 at 08:56:01 -0700, Doug White wrote: On Thu, 28 Oct 1999, Stephen J. Roznowski wrote: I'm looking at the tutorial on building CCDs at http://www.freebsd.org/tutorials/formatting-media/x205.html I am the author of said document ;) It seems that this page needs to be updated to include the FAQ entry between the ccdconfig and newfs. [I don't remember the error I had before I did the disklabel...] # ccdconfig ccd0 32 0 /dev/sd0c /dev/sd1c /dev/sd2c # disklabel ccd0 /tmp/ccd.label # disklabel -Rr ccd0 /tmp/ccd.label # newfs /dev/rccd0c Is this really the case? [If so, I'll send-pr a correction] ccdconfig manufactures a disklabel when you create the stripe, so you don't need to adjust the disklabel. The subdisks must have disklabels, and you can't use the C partition since ccd only uses partitions of type 4.2BSD. Does that mean I should not use partition c as a 4.2BSD type? Yes. This is what I am currently doing on all disks (ccd'ed or single) if the whole disk is used as one big filesystem, e.g.: 3 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 4532264404.2BSD 1024 819216 # (Cyl.0 - 2810*) I didn't have any problems for the last 3 years but if someone tells me that this is bad, danegerous or simply ugly, I will change that :-) It's bad, dangerous and ugly :-) OK, the author of vinum will know that :-) As I just said in another mail, I will use the a partition in future and leave c untouched... Seriously, you can normally get by this way, but it's confusing things, and there's no guarantee that you won't run into trouble in the future. Thanks, -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CCD questions
On Mon, 01-Nov-1999 at 10:15:01 -0800, Matthew Dillon wrote: :BTW, it's pretty trivial to change things. Run 'disklabel -e da0' (or :whatever your drive is), duplicate the line and change to, say: : : c: 453226440unused 1024 819216 # (Cyl.0 - 2810*) : e: 4532264404.2BSD 1024 819216 # (Cyl.0 - 2810*) : :Greg :-- CCD doesn't protect its own label area. It is safest to make your 'e' partition start at sector 16 and be 16 sectors smaller. e: 45322628 164.2BSD 1024 819216 # (Cyl.0 - 2810*) Ah, that's new to me. Thanks for the info. But anyway, I will switch to vinum as soon as I get a free saturday to copy all the GB's around :-) Thanks, -Andre -Matt Matthew Dillon [EMAIL PROTECTED] -- "Amateurs like Linux, but professionals prefer FreeBSD." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: CCD questions
On Fri, 29-Oct-1999 at 08:56:01 -0700, Doug White wrote: On Thu, 28 Oct 1999, Stephen J. Roznowski wrote: I'm looking at the tutorial on building CCDs at http://www.freebsd.org/tutorials/formatting-media/x205.html I am the author of said document ;) It seems that this page needs to be updated to include the FAQ entry between the ccdconfig and newfs. [I don't remember the error I had before I did the disklabel...] # ccdconfig ccd0 32 0 /dev/sd0c /dev/sd1c /dev/sd2c # disklabel ccd0 /tmp/ccd.label # disklabel -Rr ccd0 /tmp/ccd.label # newfs /dev/rccd0c Is this really the case? [If so, I'll send-pr a correction] ccdconfig manufactures a disklabel when you create the stripe, so you don't need to adjust the disklabel. The subdisks must have disklabels, and you can't use the C partition since ccd only uses partitions of type 4.2BSD. Does that mean I should not use partition c as a 4.2BSD type? This is what I am currently doing on all disks (ccd'ed or single) if the whole disk is used as one big filesystem, e.g.: andre@server:~disklabel da1 # /dev/rda1c: type: SCSI disk: SEAGATE label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 256 sectors/cylinder: 16128 cylinders: 2810 sectors/unit: 45322644 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 3 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 4532264404.2BSD 1024 819216 # (Cyl.0 - 2810*) I didn't have any problems for the last 3 years but if someone tells me that this is bad, danegerous or simply ugly, I will change that :-) Thanks, -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: [Hijacked from cvs-committers and cvs-all] On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote: I observed some kind of denial of service on -STABLE: I was playing with the new nmap and did a 'nmap -sU printfix'. inetd was running as "inetd -l" and started sucking all the CPU time even the nmap had been terminated long ago. What does "sucking all the CPU time" mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I suspect that the latter is true. It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. /var/log/messages file showed zillions of the following lines being added continously: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you "last message repeated X times". Unfortunately, the alternation of the messages makes this impossible. David Malone had a few ideas on "clever" handling of UDP. While what he suggests might help reduce the number of messages you receive under legitimate use, it won't help against DoS, since the sender of packets can simply randomize the origin addresses. Maybe you got an idea... I know exactly why you see what you see when you do what you do. All I can say is "don't do that", because I can't think of a why to cater for what you're doing in a sensible fashion. I think, I didn't describe the problem clearly so I will try again :-) 1. I run 'nmap -sU printfix' on the 192.168.17.100 machine. 2. After nmap has finished it shows me the open ports. 3. We wait , e.g. 1 minute 4. inetd, which runs with -l, continues logging to syslogd and never stops. Here is a top snapshot taken one minute later: last pid: 4040; load averages: 0.96, 0.56, 0.29 up 0+06:19:27 14:56:00 36 processes: 2 running, 34 sleeping CPU states: 54.3% user, 0.0% nice, 41.9% system, 3.9% interrupt, 0.0% idle Mem: 8500K Active, 37M Inact, 12M Wired, 3428K Cache, 7592K Buf, 532K Free Swap: 49M Total, 49M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 3748 root 58 0 956K 704K RUN 0:20 44.97% 44.97% inetd 122 root 2 0 848K 576K select 3:10 36.47% 36.47% syslogd 127 root 2 0 1588K 1228K select 0:05 0.00% 0.00% named 200 root 2 0 876K 524K select 0:02 0.00% 0.00% lpd 132 root 2 -52 1236K 732K select 0:02 0.00% 0.00% xntpd In case we start inetd without -l, it doesn't log to syslogd anymore and therefore consumes all the CPU for itself: last pid: 4397; load averages: 1.59, 1.10, 0.55up 0+06:22:14 14:58:47 111 processes: 2 running, 109 sleeping CPU states: 61.2% user, 0.0% nice, 38.0% system, 0.8% interrupt, 0.0% idle Mem: 10M Active, 30M Inact, 14M Wired, 3776K Cache, 7592K Buf, 3688K Free Swap: 49M Total, 49M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 4043 root 104 0 956K 740K RUN 1:33 97.66% 97.61% inetd 122 root 2 0 848K 576K select 3:16 0.00% 0.00% syslogd 127 root 2 0 1588K 1228K select 0:05 0.00% 0.00% named Remember that nmap has finished already a long time ago. I think, inetd is stuck in some loop which can be terminated only by killing and restarting it. -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23-Jul-1999 at 13:50:45 +0100, David Malone wrote: On Fri, Jul 23, 1999 at 02:29:19PM +0200, Sheldon Hearn wrote: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you "last message repeated X times". Unfortunately, the alternation of the messages makes this impossible. You could turn on wrapping and log them at a level at which syslog will ignore them. I'm not sure how much this would help with inetd chewing CPU time, but... I think, I expressed myself wrong. Not the logging appears problematic but the fact that inetd seems to be stuck in an endless loop even long time after the nmap has finished. -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:09:12 +0200, Sheldon Hearn wrote: On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote: But when inetd is run without -l it get 100%. Are you avoiding my question on purpose? :-) Sorry. The machine wasn't stressed by other programs so it was "the only significant user of CPU and so showed up at close to 100% CPU usage". But when I logged into it to kill and restart inetd the machine was responding very slow. On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: What does "sucking all the CPU time" mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I don't care how the usage is split over syslog and inetd. What I want to know is whether their combined usage of the CPU causes a serious problem for other CPU-bound processes. Yes. After all, you _have_ asked the inetd+syslog pair to do a lot of work. Why? I start nmap, it scans the ports and inetd has for sure a lot of logging work to do. But at some time, the scan is finished but inetd continues to consume CPU time endlessly. Maybe I am just confused and this behaviour is normal ... -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23-Jul-1999 at 14:16:19 +0100, David Malone wrote: On Fri, Jul 23, 1999 at 03:06:02PM +0200, Andre Albsmeier wrote: It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. Interesting - does it still answer requests during this time? Yes. I can still log in via the network and kill and restart inetd. Just found another syslog message (I didn't see it before because it disappeared in all the loge messages): Jul 23 15:20:51 daemon.err printfix inetd[5323]: chargen/udp server failing (looping), service terminated -Andre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:16:14 +0200, Dag-Erling Smorgrav wrote:
Sheldon Hearn [EMAIL PROTECTED] writes:
I know exactly why you see what you see when you do what you do. All I
can say is "don't do that", because I can't think of a why to cater for
what you're doing in a sensible fashion.
I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.
Comes in private email. It's about 130KB after which tcpdump crashed with:
zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp
But when I restart tcpdump again (while inetd still is going wild)
it is quiet.
-Andre
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:35:48 +0200, Dag-Erling Smorgrav wrote: Andre Albsmeier [EMAIL PROTECTED] writes: Comes in private email. It's about 130KB after which tcpdump crashed with: zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp Weird. Very weird. Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. It should be reproducible very easily by running "nmap -sU target_machine" where target_machine has the internal inetd services enabled. I attach my inetd.conf in case it might be interesting (nothing special in it): # $Id: inetd.conf,v 1.33.2.1 1999/07/21 19:28:25 sheldonh Exp $ # # Internet server configuration database # # @(#)inetd.conf 5.4 (Berkeley) 6/30/90 # ftp stream tcp nowait root/usr/libexec/ftpd ftpd telnet stream tcp nowait root/usr/libexec/telnetdtelnetd shell stream tcp nowait root/usr/libexec/rshd rshd login stream tcp nowait root/usr/libexec/rlogindrlogind finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd #exec stream tcp nowait root/usr/libexec/rexecd rexecd #uucpd stream tcp nowait root/usr/libexec/uucpd uucpd #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd # run comsat as root to be able to print partial mailbox contents w/ biff, # or use the safer tty:tty to just print that new mail has been received. #comsat dgram udp waittty:tty /usr/libexec/comsat comsat ntalk dgram udp waittty:tty /usr/libexec/ntalkd ntalkd #tftp dgram udp waitnobody /usr/libexec/tftpd tftpd /tftpboot #bootps dgram udp waitroot/usr/libexec/bootpd bootpd # # "Small servers" -- used to be standard on, but we're more conservative # about things due to Internet security concerns. Only turn on what you # need. # daytime stream tcp nowait rootinternal daytime dgram udp waitrootinternal timestream tcp nowait rootinternal time dgram udp waitrootinternal echostream tcp nowait rootinternal echodgram udp waitrootinternal discard stream tcp nowait rootinternal discard dgram udp waitrootinternal chargen stream tcp nowait rootinternal chargen dgram udp waitrootinternal # # Kerberos authenticated services # #klogin stream tcp nowait root/usr/libexec/rlogindrlogind -k #eklogin stream tcp nowait root/usr/libexec/rlogindrlogind -k -x #kshell stream tcp nowait root/usr/libexec/rshd rshd -k #kipstream tcp nowait root/usr/libexec/kipd kipd # # CVS servers - for master CVS repositories only! # #cvspserver stream tcp nowait root/usr/bin/cvscvs pserver #cvsstream tcp nowait root/usr/bin/cvscvs kserver # # RPC based services (you MUST have portmapper running to use these) # rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd rusersd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.rusersd rpc.rusersd walld/1 dgram rpc/udp wait root /usr/libexec/rpc.rwalld rpc.rwalld #pcnfsd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.pcnfsd rpc.pcnfsd #rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad sprayd/1dgram rpc/udp wait root /usr/libexec/rpc.sprayd rpc.sprayd # # example entry for the optional pop3 server # #pop3 stream tcp nowait root/usr/local/libexec/popper popper # # example entry for the optional imap4 server # #imap4 stream tcp nowait root/usr/local/libexec/imapdimapd # # Return error for all "ident" requests # #auth stream tcp nowait rootinternal # # example entry for the optional ident server # authstream tcp waitkmem:kmem /usr/local/sbin/identd identd -w -t120 # # example entry for the optional qmail MTA # #smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd # # Enable the following two entries to enable samba startup from inetd # (from the Samba documentation). # #netbios-ssn stream tcp nowait root /usr/local/sbin/smbd smbd #netbios-ns dgram udp wait root /usr/local/sbin/nmbd nmbd To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: [Hijacked from cvs-committers and cvs-all] On Fri, 23 Jul 1999 11:28:12 +0200, Andre Albsmeier wrote: I observed some kind of denial of service on -STABLE: I was playing with the new nmap and did a 'nmap -sU printfix'. inetd was running as inetd -l and started sucking all the CPU time even the nmap had been terminated long ago. What does sucking all the CPU time mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I suspect that the latter is true. It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. /var/log/messages file showed zillions of the following lines being added continously: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you last message repeated X times. Unfortunately, the alternation of the messages makes this impossible. David Malone had a few ideas on clever handling of UDP. While what he suggests might help reduce the number of messages you receive under legitimate use, it won't help against DoS, since the sender of packets can simply randomize the origin addresses. Maybe you got an idea... I know exactly why you see what you see when you do what you do. All I can say is don't do that, because I can't think of a why to cater for what you're doing in a sensible fashion. I think, I didn't describe the problem clearly so I will try again :-) 1. I run 'nmap -sU printfix' on the 192.168.17.100 machine. 2. After nmap has finished it shows me the open ports. 3. We wait , e.g. 1 minute 4. inetd, which runs with -l, continues logging to syslogd and never stops. Here is a top snapshot taken one minute later: last pid: 4040; load averages: 0.96, 0.56, 0.29 up 0+06:19:27 14:56:00 36 processes: 2 running, 34 sleeping CPU states: 54.3% user, 0.0% nice, 41.9% system, 3.9% interrupt, 0.0% idle Mem: 8500K Active, 37M Inact, 12M Wired, 3428K Cache, 7592K Buf, 532K Free Swap: 49M Total, 49M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 3748 root 58 0 956K 704K RUN 0:20 44.97% 44.97% inetd 122 root 2 0 848K 576K select 3:10 36.47% 36.47% syslogd 127 root 2 0 1588K 1228K select 0:05 0.00% 0.00% named 200 root 2 0 876K 524K select 0:02 0.00% 0.00% lpd 132 root 2 -52 1236K 732K select 0:02 0.00% 0.00% xntpd In case we start inetd without -l, it doesn't log to syslogd anymore and therefore consumes all the CPU for itself: last pid: 4397; load averages: 1.59, 1.10, 0.55up 0+06:22:14 14:58:47 111 processes: 2 running, 109 sleeping CPU states: 61.2% user, 0.0% nice, 38.0% system, 0.8% interrupt, 0.0% idle Mem: 10M Active, 30M Inact, 14M Wired, 3776K Cache, 7592K Buf, 3688K Free Swap: 49M Total, 49M Free PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 4043 root 104 0 956K 740K RUN 1:33 97.66% 97.61% inetd 122 root 2 0 848K 576K select 3:16 0.00% 0.00% syslogd 127 root 2 0 1588K 1228K select 0:05 0.00% 0.00% named Remember that nmap has finished already a long time ago. I think, inetd is stuck in some loop which can be terminated only by killing and restarting it. -Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23-Jul-1999 at 13:50:45 +0100, David Malone wrote: On Fri, Jul 23, 1999 at 02:29:19PM +0200, Sheldon Hearn wrote: Well, you did ask for them (inetd -l). :-) Jul 23 11:21:28 daemon.info printfix inetd[1743]: time from [...] Jul 23 11:21:28 daemon.info printfix inetd[1743]: daytime from [...] Usually syslog will give you last message repeated X times. Unfortunately, the alternation of the messages makes this impossible. You could turn on wrapping and log them at a level at which syslog will ignore them. I'm not sure how much this would help with inetd chewing CPU time, but... I think, I expressed myself wrong. Not the logging appears problematic but the fact that inetd seems to be stuck in an endless loop even long time after the nmap has finished. -Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:09:12 +0200, Sheldon Hearn wrote: On Fri, 23 Jul 1999 15:06:02 +0200, Andre Albsmeier wrote: But when inetd is run without -l it get 100%. Are you avoiding my question on purpose? :-) Sorry. The machine wasn't stressed by other programs so it was the only significant user of CPU and so showed up at close to 100% CPU usage. But when I logged into it to kill and restart inetd the machine was responding very slow. On Fri, 23-Jul-1999 at 14:29:19 +0200, Sheldon Hearn wrote: What does sucking all the CPU time mean? Does it mean that other programs were suffering, or does it mean that it was the only significant user of CPU and so showed up at close to 100% CPU usage? I don't care how the usage is split over syslog and inetd. What I want to know is whether their combined usage of the CPU causes a serious problem for other CPU-bound processes. Yes. After all, you _have_ asked the inetd+syslog pair to do a lot of work. Why? I start nmap, it scans the ports and inetd has for sure a lot of logging work to do. But at some time, the scan is finished but inetd continues to consume CPU time endlessly. Maybe I am just confused and this behaviour is normal ... -Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.
On Fri, 23-Jul-1999 at 14:16:19 +0100, David Malone wrote: On Fri, Jul 23, 1999 at 03:06:02PM +0200, Andre Albsmeier wrote: It's only nearly 50% because syslogd gets most of the other half :-) But when inetd is run without -l it get 100%. Interesting - does it still answer requests during this time? Yes. I can still log in via the network and kill and restart inetd. Just found another syslog message (I didn't see it before because it disappeared in all the loge messages): Jul 23 15:20:51 daemon.err printfix inetd[5323]: chargen/udp server failing (looping), service terminated -Andre To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:16:14 +0200, Dag-Erling Smorgrav wrote:
Sheldon Hearn sheld...@uunet.co.za writes:
I know exactly why you see what you see when you do what you do. All I
can say is don't do that, because I can't think of a why to cater for
what you're doing in a sensible fashion.
I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.
Comes in private email. It's about 130KB after which tcpdump crashed with:
zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp
But when I restart tcpdump again (while inetd still is going wild)
it is quiet.
-Andre
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
On Fri, 23-Jul-1999 at 15:35:48 +0200, Dag-Erling Smorgrav wrote: Andre Albsmeier andre.albsme...@mchp.siemens.de writes: Comes in private email. It's about 130KB after which tcpdump crashed with: zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp Weird. Very weird. Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. It should be reproducible very easily by running nmap -sU target_machine where target_machine has the internal inetd services enabled. I attach my inetd.conf in case it might be interesting (nothing special in it): # $Id: inetd.conf,v 1.33.2.1 1999/07/21 19:28:25 sheldonh Exp $ # # Internet server configuration database # # @(#)inetd.conf 5.4 (Berkeley) 6/30/90 # ftp stream tcp nowait root/usr/libexec/ftpd ftpd telnet stream tcp nowait root/usr/libexec/telnetdtelnetd shell stream tcp nowait root/usr/libexec/rshd rshd login stream tcp nowait root/usr/libexec/rlogindrlogind finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd #exec stream tcp nowait root/usr/libexec/rexecd rexecd #uucpd stream tcp nowait root/usr/libexec/uucpd uucpd #nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd # run comsat as root to be able to print partial mailbox contents w/ biff, # or use the safer tty:tty to just print that new mail has been received. #comsat dgram udp waittty:tty /usr/libexec/comsat comsat ntalk dgram udp waittty:tty /usr/libexec/ntalkd ntalkd #tftp dgram udp waitnobody /usr/libexec/tftpd tftpd /tftpboot #bootps dgram udp waitroot/usr/libexec/bootpd bootpd # # Small servers -- used to be standard on, but we're more conservative # about things due to Internet security concerns. Only turn on what you # need. # daytime stream tcp nowait rootinternal daytime dgram udp waitrootinternal timestream tcp nowait rootinternal time dgram udp waitrootinternal echostream tcp nowait rootinternal echodgram udp waitrootinternal discard stream tcp nowait rootinternal discard dgram udp waitrootinternal chargen stream tcp nowait rootinternal chargen dgram udp waitrootinternal # # Kerberos authenticated services # #klogin stream tcp nowait root/usr/libexec/rlogindrlogind -k #eklogin stream tcp nowait root/usr/libexec/rlogindrlogind -k -x #kshell stream tcp nowait root/usr/libexec/rshd rshd -k #kipstream tcp nowait root/usr/libexec/kipd kipd # # CVS servers - for master CVS repositories only! # #cvspserver stream tcp nowait root/usr/bin/cvscvs pserver #cvsstream tcp nowait root/usr/bin/cvscvs kserver # # RPC based services (you MUST have portmapper running to use these) # rstatd/1-3 dgram rpc/udp wait root /usr/libexec/rpc.rstatd rpc.rstatd rusersd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.rusersd rpc.rusersd walld/1 dgram rpc/udp wait root /usr/libexec/rpc.rwalld rpc.rwalld #pcnfsd/1-2 dgram rpc/udp wait root /usr/libexec/rpc.pcnfsd rpc.pcnfsd #rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad sprayd/1dgram rpc/udp wait root /usr/libexec/rpc.sprayd rpc.sprayd # # example entry for the optional pop3 server # #pop3 stream tcp nowait root/usr/local/libexec/popper popper # # example entry for the optional imap4 server # #imap4 stream tcp nowait root/usr/local/libexec/imapdimapd # # Return error for all ident requests # #auth stream tcp nowait rootinternal # # example entry for the optional ident server # authstream tcp waitkmem:kmem /usr/local/sbin/identd identd -w -t120 # # example entry for the optional qmail MTA # #smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd # # Enable the following two entries to enable samba startup from inetd # (from the Samba documentation). # #netbios-ssn stream tcp nowait root /usr/local/sbin/smbd smbd #netbios-ns dgram udp wait root /usr/local/sbin/nmbd nmbd To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD native xanim (was Re: Native Applixware for FreeBSD -- When? )
On Tue, 11-May-1999 at 11:50:04 -0700, Ted Faber wrote:
-BEGIN PGP SIGNED MESSAGE-
Bill Fumerola wrote:
How often do I see a author make a program and release _one_ FreeBSD
binary and about 5 different binaries depending on what linux libc format
you have.
On a related note, I don't know if people use xanim, a movie viewer in
the ports collection, but it's recently been upgraded to support
dynamically loadable codecs. The problem is that none of the codecs
are compiled for FreeBSD, although there are three Linux versions :-).
To use them (really to use the program at all) you have to compile a
Linux version of xanim and run under emulation (which works really well,
thanks
emulation guys!).
Yes, I've tried using the Linux codecs on the FreeBSD binary. No dice.
It works here with the FreeBSD binary. There are two things I have done:
1. copy the DLL's in the following order to /usr/X11R6/lib/X11/xanim
vid_iv32_2.1_linuxELFx86c5.xa
vid_iv41_1.0_linuxELFx86c5.xa
vid_iv50_1.0_linuxELFx86c5.xa
vid_cvid_2.0_linuxELFx86c5.xa
vid_cyuv_1.0_linuxELFx86c5.xa
vid_h261_1.0_linuxELFx86c5.xa
vid_h263_1.0_linuxELFx86c5.xa
2. run xanim through the following script (of course, you need the linuxemu).
#!/bin/sh
export XANIM_MOD_DIR=/usr/X11R6/lib/X11/xanim
export LD_LIBRARY_PATH=/compat/linux/lib
exec xanim.bin +Aev90 +Sr +Wp +Zper +v $@
BTW, there is a bug in the ports Makefile:
--- Makefile.ORIMon Apr 12 10:57:50 1999
+++ MakefileMon Apr 12 10:53:29 1999
@@ -18,8 +18,8 @@
EXTRACT_ONLY= ${DISTNAME}.tar.gz
USE_IMAKE= yes
MAN1= xanim.1
-MAKE_ENV= XA_IV32_DEF=-DXA_INDEO \
- XA_CVID_DEF=-DXA_CINEPAK \
+MAKE_ENV= XA_IV32_DEF=-DXA_IV32 \
+ XA_CVID_DEF=-DXA_CVID \
XA_CYUV_DEF=-DXA_CYUV
.include bsd.port.pre.mk
-Andre
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
