Re: X11/C++ question
hi,
>> Does anyone (anyone, that is, who's coded X11 applications) know how you
>> handle X11 callbacks to C++ object methods?
>>
>> Thanks,
TDR> If you mean Xt (and possibly Motif) - the answer is "very carefully."
TDR> The Xt callbacks are C based, so you typically can't directly call a
TDR> C++ method.
TDR> But, you can have an extern "C" block that declares the call back
TDR> function (the extern "C" basically keeps any name mangling from going on)
TDR> and then, in that function, invoke the method as appropriate.
TDR> I believe you do something like:
TDR> class myclass {
TDR> void mymethod(void * arg1) {
TDR> cout << "Ha! I got to the class" << '\n';
TDR> };
TDR> }
TDR> extern "C" {
TDR> void
TDR> callback_function(arg1)
TDR> void *arg1;
TDR> {
TDR> /* Call the method */
TDR> myclass::mymethod(arg1);
TDR> }
TDR> }
Looks good except one point -- mymethod should be static, i.e.
static void mymethod (...) {
...
}
TDR> Then, you register "callback_function" as the Xt/Motif callback.
TDR> I've at least "heard" of doing that kind of thing before...
--
/* Alexey Zelkin && [EMAIL PROTECTED]*/
/* Tavric National University && [EMAIL PROTECTED] */
/* http://www.ccssu.crimea.ua/~phantom && [EMAIL PROTECTED] */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf problem (panic)--possibly related to Berkeley DB 2.7.7
On Tue, 26 Oct 1999, Steve Bishop wrote: > The scripts are designed to use the database a lot, and they also use a significant >amount > of network resources. The scripts sometimes can have up to 900 open tcp connections, > and consistently use almost 600. I have increased the number of mbuf clusters >(NMBCLUSTERS) > from 1024 to 4096. I have also increased maxusers to 64. 4096 isn't really that many mbufs. You should double or triple that. I think that large web hosting people use 2 mbufs. That eats a LOT of RAM, but at least you can shrug off the heaviest DoS attack. In fact, if you don't specify a number of mbufs in your kernel file, MAXUSERS set to 64 will probably give you more than 4096 mbufs! Tom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On Tue, 26 Oct 1999, Chris Costello wrote:
> On Tue, Oct 26, 1999, Thomas David Rivers wrote:
> > extern "C" {
> >
> > void
> > callback_function(arg1)
> > void *arg1;
> > {
> > /* Call the method */
> >myclass::mymethod(arg1);
>
>As far as I've seen, you can't directly call a class method
> without an object.
Sure you can. It won't have any access to "this" or any part thereof,
however.
>
> --
> |Chris Costello <[EMAIL PROTECTED]>
> |A closed mouth gathers no feet.
> `--
>
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
[EMAIL PROTECTED]`--'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On Tue, 26 Oct 1999, Bakul Shah wrote: > Allow me add something to what the FAQ-Xt says. > > I find it more convenient to immediately call a non-static > function as shown below (using a slightly modified example > from the FAQ). Just got out of the shower, where I was wondering why they didn't suggest the same thing. I was going to experiment with this way, since it fit more closely with the way I like to code C++ (I don't like to code C++, you understand, so my C++ code is always straining to look like C). Thanks, Bakul. This looks much better. Thanks, folks, for letting me pull hackers away from FreeBSD for a minute, but let's not let it get out of hand; we better stop before we strain other's patience. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
Allow me add something to what the FAQ-Xt says.
I find it more convenient to immediately call a non-static
function as shown below (using a slightly modified example
from the FAQ).
class Icon {
public:
Icon(Widget*);
private:
static void static_callback(Icon*);
inline void real_callback();
Widget* button;
int count;
...
};
Icon::Icon(Widget* parent): count(0)
{
button = XtVaCreateWidget("Boo!", xmPushButtonWidgetClass, parent, 0);
XtAddCallback(button, XmNselectCallback, &Icon::static_callback,
(XtPointer)this);
...
}
inline void
Icon::real_callback()
{
count++;
...
}
void
Icon::static_callback(Icon* icon)
{
icon->real_callback();
}
The reason for calling real_callback from static_callback is
to avoid having to specify icon->count etc. to reference
components of the Icon object. This makes a difference in
readability if your callback function does a bunch of stuff.
The reason for inlining to not incur the cost of an
additional call (if this matters -- usually it doesn't).
Inlining can get in your way during debugging (atleast gdb
loses its mind) so provide a way to disable it. BTW, this
idiom is useful pretty much any time you have to use C++
callbacks from C code, not just for X11.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On Tue, 26 Oct 1999 [EMAIL PROTECTED] wrote: > > Thomas David Rivers writes: > > If you mean Xt (and possibly Motif) - the answer is "very carefully." > [...] > > You're approach would probably work, but there's an easier way. > See topic 28 in the Xt FAQ. > > ftp://ftp.x.org/contrib/faqs/FAQ-Xt > > It's not name mangling causing problems, it's lack of "this" when the > method is invoked as a callback from Xt. Yes! This is the method! I like it, or at least, it's as close (in C++ code) to something I do like. Thanks very much, Ted. Nice catch. > > -Ted > Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
> Then you just stick a C wrapper function around every C++ callback you > want to register, is that it? Seems a bit inelegant, but I suppose, if > the ultimate test of elegance is that "it's the only one that works", then > it's perhaps elegant *enough*. I believe someone posted a better solution... from the Xt FAQ. - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On Wed, 27 Oct 1999, Daniel O'Connor wrote: > > On 27-Oct-99 Thomas David Rivers wrote: > > If you mean Xt (and possibly Motif) - the answer is "very carefully." > > Or you could just use a toolkit written for C++ or with C++ shims already.. ie > Qt or GTK.. If I wanted to just get X11 done, I would just call some toolkit. I didn't want to be told to go get something else that does it, I wanted to know the right way to do it myself. Thomas's post, at least, was really helpful. I wonder if that's really the way to go, but he surely did give me *one* method, and explained it easily enough so that I can *do* it. Boy, I sure wish Java compiled and ran natively. I'd stop using C++ forever. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On Tue, 26 Oct 1999, Thomas David Rivers wrote: > > > > Does anyone (anyone, that is, who's coded X11 applications) know how you > > handle X11 callbacks to C++ object methods? > > > > Thanks, > > If you mean Xt (and possibly Motif) - the answer is "very carefully." > > The Xt callbacks are C based, so you typically can't directly call a > C++ method. > > But, you can have an extern "C" block that declares the call back > function (the extern "C" basically keeps any name mangling from going on) > and then, in that function, invoke the method as appropriate. > > I believe you do something like: [example deleted] Then you just stick a C wrapper function around every C++ callback you want to register, is that it? Seems a bit inelegant, but I suppose, if the ultimate test of elegance is that "it's the only one that works", then it's perhaps elegant *enough*. Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
Thomas David Rivers writes: > If you mean Xt (and possibly Motif) - the answer is "very carefully." [...] You're approach would probably work, but there's an easier way. See topic 28 in the Xt FAQ. ftp://ftp.x.org/contrib/faqs/FAQ-Xt It's not name mangling causing problems, it's lack of "this" when the method is invoked as a callback from Xt. -Ted To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On Tue, Oct 26, 1999, Thomas David Rivers wrote:
> extern "C" {
>
> void
> callback_function(arg1)
> void *arg1;
> {
> /* Call the method */
> myclass::mymethod(arg1);
As far as I've seen, you can't directly call a class method
without an object.
--
|Chris Costello <[EMAIL PROTECTED]>
|A closed mouth gathers no feet.
`--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On 27-Oct-99 Thomas David Rivers wrote: > And, wasn't there a freely available C++ shim for motif floating around > at one time? I don't know.. My X experience begins and ends with Tk :) (Don't like Motif either ;) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
> > On 27-Oct-99 Thomas David Rivers wrote: > > If you mean Xt (and possibly Motif) - the answer is "very carefully." > > Or you could just use a toolkit written for C++ or with C++ shims already.. ie > Qt or GTK.. > Good point! Also - I think there were some articles on how to do this in the X11 journals... if you happen to have those lying around. And, wasn't there a freely available C++ shim for motif floating around at one time? - Dave R. - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
On 27-Oct-99 Thomas David Rivers wrote: > If you mean Xt (and possibly Motif) - the answer is "very carefully." Or you could just use a toolkit written for C++ or with C++ shims already.. ie Qt or GTK.. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: X11/C++ question
>
> Does anyone (anyone, that is, who's coded X11 applications) know how you
> handle X11 callbacks to C++ object methods?
>
> Thanks,
If you mean Xt (and possibly Motif) - the answer is "very carefully."
The Xt callbacks are C based, so you typically can't directly call a
C++ method.
But, you can have an extern "C" block that declares the call back
function (the extern "C" basically keeps any name mangling from going on)
and then, in that function, invoke the method as appropriate.
I believe you do something like:
class myclass {
void mymethod(void * arg1) {
cout << "Ha! I got to the class" << '\n';
};
}
extern "C" {
void
callback_function(arg1)
void *arg1;
{
/* Call the method */
myclass::mymethod(arg1);
}
}
Then, you register "callback_function" as the Xt/Motif callback.
I've at least "heard" of doing that kind of thing before...
- Dave Rivers -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
X11/C++ question
Does anyone (anyone, that is, who's coded X11 applications) know how you handle X11 callbacks to C++ object methods? Thanks, Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp related kernel panic
We have an application under development at Yahoo! which can provoke a similar crash on an N440BX-based system running 3.3-RELEASE in about half an hour. The application is both disk and network intensive--under test both are pretty close to being maxed out. Although crashes most frequently occur during fxp interrupts, this is not always the case; what IS always the case is that stack variables are getting clobbered. We've been able to compare identical configurations except for SCSI vs. IDE. Only the SCSI (using the on-board Symbios controller) system has failed so far. This failure has been replicated on several boxes (it's not just a single bad board). A 2.2.8 system with identical hardware (including SCSI) running the same application doesn't seem to be failing. More testing is required to establish this pattern with certainty, however. Peter Wemm is up here in Santa Clara and is studying the problem as I write. More information will be upcoming... -Ed Hall [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp related kernel panic
For the sake of experimentation, I'll throw in a *real* Pro-100B card and see if it happens again (it takes 8 days for the panic to happen). I can also measure the consistency of this "8 day" phenomena. As an aside, there's not much SCSI activity on this system. I've had very good results with 7200 RPM ATA-66 IDE drives, and kernel tweaks for the wd controller (flags 0xb0ffb0ff): wdc0: unit 0 (wd0): , LBA, DMA, 32-bit, multi-block-16 wd0: 26105MB (53464320 sectors), 3328 cyls, 255 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , LBA, DMA, 32-bit, multi-block-16 wd1: 26105MB (53464320 sectors), 3328 cyls, 255 heads, 63 S/T, 512 B/S These IDE drives, in a ccd array, are the ones that get pounded, compared to the "da0" SCSI system drive. Soft-updates are also enabled... (please forward to list if appropriate - I'm not a sub). % iostat 30 10 (truncated) ccd0 da0 wd0 cpu KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 27.61 124 3.34 7.80 108 0.82 19.31 91 1.72 19 0 15 8 57 32.06 115 3.60 7.92 72 0.56 21.26 88 1.83 18 0 13 8 60 25.95 110 2.79 7.99 63 0.49 18.46 81 1.46 15 0 11 6 68 24.84 111 2.70 7.86 55 0.42 17.29 84 1.42 13 0 10 7 71 27.77 118 3.21 7.98 67 0.52 19.18 86 1.62 17 0 13 8 62 25.78 106 2.68 8.05 61 0.48 18.07 77 1.36 13 0 11 7 70 23.61 121 2.79 8.00 71 0.55 16.45 88 1.42 15 0 12 7 66 David Greenman: > I think it is caused by the NCR/Symbios controller. It might be a side > effect of the NCR just using up a lot of PCI bandwidth, with the real > bug being in the fxp driver (though I've looked and haven't found one). > So I don't think putting in a real Pro/100 will have any effect on the > problem. Of course I don't really know what is causing it, so just > about anything is possible. --- Lew Payne Publishing, Inc. Dunn & Bradstreet listed 994 San Antonio Road DUNS # 055037852 Palo Alto, CA 94303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf problem (panic)--possibly related to Berkeley DB 2.7.7
On Tue, 26 Oct 1999, Steve Bishop wrote: > I am using FreeBSD 3.3-RELEASE, and it is running on a single processor PII 400. > > At first, I thought the problem was due to the network driver, so I swapped network > cards. But, the problem still continues to occur. At first, I used a DEC (de0) NIC. > Then, I switched to an Intel EtherExpress Pro 10/100B Ethernet (fxp0). > > My machine dies when it runs out of mbufs. Normally, one only associates mbufs with > network usage, and network (NIC) drivers. I have tried to investigate this >possibility, > as mentioned, but to no avail. Gah! wrap long lines please! > The problem is either a kernel problem, or is related to the Berkeley DB, and/or > perl module - BerkeleyDB-0.07.pm. I have written to Paul Marquess who is the > author of this perl module. He did not respond, and may not have any idea. The >latest > release of this perl module is a significant update to the perl support for the >latest releases of Berkeley DB. > It provides for concurrency and database integrity (consistency) between processes >sharing > or using the same database simultaneously. > > There are a number of scripts, I have written, in the system that run (as processes) >in parallel. > This is why I am using the Concurrent Access Method (CAM) to allow multiple >simultaneous > readers along with sequential write (one writer at a time) access. Berkeley DB >keeps everything > consistent. > > The scripts are designed to use the database a lot, and they also use a significant >amount > of network resources. The scripts sometimes can have up to 900 open tcp connections, > and consistently use almost 600. I have increased the number of mbuf clusters >(NMBCLUSTERS) > from 1024 to 4096. I have also increased maxusers to 64. please up maxusers to 256 and NMBCLUSTERS to 32768 or 16384 you may also want to increase the Kernel's memory area via kern.vm.kmem.size in the loader (see LOADER(8)). I would suggest upping maxusers, then NMBCLUSTERS and finally kern.vm.kmem.size in that order inclusive. good luck, -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp related kernel panic
>Hi David -- What if I install a *real* EtherExpress Pro-100B (or >whatever it's known as today) in the PCI slot, and use it instead >of the on-board (N440BX motherboard) fxp0 interface? > >Judging that you probably know the nature of the problem, do you >think this might circumvent it? I think it is caused by the NCR/Symbios controller. It might be a side effect of the NCR just using up a lot of PCI bandwidth, with the real bug being in the fxp driver (although I've looked and haven't found one). So I don't think putting in a real Pro/100 will have any effect on the problem. Of course I don't really know what is causing it, so just about anything is possible. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mbuf problem (panic)--possibly related to Berkeley DB 2.7.7
I am using FreeBSD 3.3-RELEASE, and it is running on a single processor PII 400.
At first, I thought the problem was due to the network driver, so I swapped network
cards. But, the problem still continues to occur. At first, I used a DEC (de0) NIC.
Then, I switched to an Intel EtherExpress Pro 10/100B Ethernet (fxp0).
My machine dies when it runs out of mbufs. Normally, one only associates mbufs with
network usage, and network (NIC) drivers. I have tried to investigate this
possibility,
as mentioned, but to no avail.
The problem is either a kernel problem, or is related to the Berkeley DB, and/or
perl module - BerkeleyDB-0.07.pm. I have written to Paul Marquess who is the
author of this perl module. He did not respond, and may not have any idea. The latest
release of this perl module is a significant update to the perl support for the latest
releases of Berkeley DB.
It provides for concurrency and database integrity (consistency) between processes
sharing
or using the same database simultaneously.
There are a number of scripts, I have written, in the system that run (as processes)
in parallel.
This is why I am using the Concurrent Access Method (CAM) to allow multiple
simultaneous
readers along with sequential write (one writer at a time) access. Berkeley DB keeps
everything
consistent.
The scripts are designed to use the database a lot, and they also use a significant
amount
of network resources. The scripts sometimes can have up to 900 open tcp connections,
and consistently use almost 600. I have increased the number of mbuf clusters
(NMBCLUSTERS)
from 1024 to 4096. I have also increased maxusers to 64.
The "panics" seem to occur when my scripts or processes prematurely exit without
shutting down Berkeley DB in the standard, proper fashion.
As I explained, I have upped the number of mbuf clusters from the default 1024, to
4096. The actual number
probably wouldn't matter a whole lot as long as it is sufficient to meet the needs of
the system were being met.
What I'm trying to say, is that when the script(s) crash, the system then begins to
use mbufs exponentially,
until they're completely exhausted within minutes. The system panics, and reboots.
I know the association is loose, but nothing else presents itself as the problem. Is
there some kernel
resource that Berkeley DB gets a hold of, and never properly releases due to an
improper, fatal termination
of my script, which could indirectly cause my system to run out of mbufs? I know that
the close_everything
routine in BerkeleyDB.pm still runs when perl exits, but perhaps, it doesn't work
properly in this case?
Any ideas or leads as to why this is occuring would be sincerely appreciated.
Thanks,
Steve Bishop
Developer
Verio, Inc.
verio.com -- the new world of business
PS Here's some more background info.
In perl, to setup Berkeley DB, I use the shared memory pool. Here is how I setup the
environment, and open my database.
$env = new BerkeleyDB::Env -Flags => DB_CREATE| DB_INIT_MPOOL| DB_INIT_CDB,
-ErrFile => "db-errors";
$DB = tie %db, 'BerkeleyDB::Btree', -Filename => 'servers.db',
-Mode => 0600,
-Flags => DB_CREATE,
-Pagesize => 4096, # default = 8192
-Env => $env
or
die "Cannot open db: $! $BerkeleyDB::Error";
I think I have discovered an association between my system crashes ("out of mbufs"),
and the
usage of Berkeley DB.
When my script prematurely crashes or exits without following the proper database
shutdown
procedure, as outlined below, it isn't very long before the machine crashes (usually a
few minutes).
undef($DB);
undef($env);
untie(%db);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp related kernel panic
Hi David -- What if I install a *real* EtherExpress Pro-100B (or whatever it's known as today) in the PCI slot, and use it instead of the on-board (N440BX motherboard) fxp0 interface? Judging that you probably know the nature of the problem, do you think this might circumvent it? Regards, Lew Payne > Let me guess...your system has an Intel N440BX motherboard, right? > If so, then it's a known problem with no solution yet. -DG > > David Greenman > Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org > Creator of high-performance Internet servers - http://www.terasolutions.com > Pave the road of life with opportunities. --- Lew Payne Publishing, Inc. Dunn & Bradstreet listed 994 San Antonio Road DUNS # 055037852 Palo Alto, CA 94303 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fxp related kernel panic
Let me guess...your system has an Intel N440BX motherboard, right? If so, then it's a known problem with no solution yet. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. >I have a 3.3-stable machine that I use as a news router (running diablo). The >fxp0 interface averages 10-15 Mbps bandwidth continously. > >About once a week the machine crashes & reboots. We enabled the debugger this time >and captured the following debug output: > > > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0x382e4641 >fault code = supervisor write, page not present >instruction pointer = 0x8:0xc01a372e >stack pointer = 0x10:0xc02523b0 >frame pointer = 0x10:0xc02523c0 >code segment= base 0x0, limit 0xf, type 0x1b >= DPL 0, pres 1, def32 1, gran 1 >processor eflags= interrupt enabled, resume, IOPL = 0 >current process = Idle >interrupt mask = net >kernel: type 12 trap, code=0 >Stopped at fxp_add_rfabuf+0x1de: movw%ax,0x4(%esi) >db> > >%uname -a >FreeBSD feeder.via.net 3.3-STABLE FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT 1999 >[EMAIL PROTECTED]:/usr/src/sys/compile/DIABLO i386 > >%dmesg >Copyright (c) 1992-1999 FreeBSD Inc. >Copyright (c) 1982, 1986, 1989, 1991, 1993 >The Regents of the University of California. All rights reserved. >FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT 1999 >[EMAIL PROTECTED]:/usr/src/sys/compile/DIABLO >Timecounter "i8254" frequency 1193182 Hz >Timecounter "TSC" frequency 498752616 Hz >CPU: Pentium III (498.75-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x672 Stepping = 2 > Features=0x387fbffOV,PAT,PSE36,,MMX,FXSR,> >real memory = 536870912 (524288K bytes) >avail memory = 519340032 (507168K bytes) >Preloaded elf kernel "kernel" at 0xc02ca000. >Pentium Pro MTRR support enabled >Probing for devices on PCI bus 0: >chip0: rev 0x03 on pci0.0.0 >ncr0: rev 0x37 int a irq 11 on pci0.13.0 >ncr1: rev 0x37 int b irq 10 on pci0.13.1 >fxp0: rev 0x05 int a irq 5 on pci0.15. >0 >fxp0: Ethernet address 00:a0:c9:fc:45:7f >chip1: rev 0x02 on pci0.18.0 >ide_pci0: rev 0x01 on pci0.18.1 >chip2: rev 0x02 on pci0.18.3 >vga0: rev 0x23 on pci0.2 >0.0 >Probing for PnP devices: >Probing for devices on the ISA bus: >sc0 on isa >sc0: VGA color <16 virtual consoles, flags=0x0> >atkbdc0 at 0x60-0x6f on motherboard >atkbd0 irq 1 on isa >sio0: configured irq 4 not in bitmap of probed irqs 0 >sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa >sio0: type 8250 >sio1: configured irq 3 not in bitmap of probed irqs 0 >sio1 not found at 0x2f8 >fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa >wdc0 at 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa >wdc0: unit 0 (wd0): , LBA, DMA, 32-bit, multi-block-16 >wd0: 26105MB (53464320 sectors), 3328 cyls, 255 heads, 63 S/T, 512 B/S >wdc0: unit 1 (wd1): , LBA, DMA, 32-bit, multi-block-16 >wd1: 26105MB (53464320 sectors), 3328 cyls, 255 heads, 63 S/T, 512 B/S >wdc1 not found at 0x170 >vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa >npx0 on motherboard >npx0: INT 16 interface >ccd0-3: Concatenated disk drivers >Waiting 15 seconds for SCSI devices to settle >changing root device to da0s1a >da0 at ncr0 bus 0 target 0 lun 0 >da0: Fixed Direct Access SCSI-2 device >da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled >da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) >WARNING: / was not properly dismounted > > > >Any ideas ? > >Thanks, > >Joe > > > >-- > >Joe McGuckin > >ViaNet Communications >994 San Antonio Road >Palo Alto, CA 94303 > >Phone: 650-969-2203 >Cell: 650-207-0372 >Fax: 650-969-2124 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
UNILOAD v.1.2 (boot loader/manager) is ready
I made some days ago UNILOAD v.1.2, the main feature of this version is the ability to load system from beyond 1024 cylinder mark. Here it is list of some changes: -- Changes in version 1.2 - UNILOAD uses IBM/MS INT 0x13 extensions and can load partitions beyond 1024 cylinder mark - install program checks if IBM/MS INT 0x13 extensions are supported, item 'Drive geometry' in install program can show right geometry - unknown type of partition is printed as hexadecimal number - length of highlighted bar in menu is equal to length of longest line -- Here it is some lines from README file: -- You shouldn't make any configuration to force the ability of UNILOAD to use LBA packet interface. At first time UNILOAD tries to use LBA packet interface to read sector. If that attempt failed then UNILOAD use standard INT 0x13 call. -- You can download it on following URL in 'Software' menu item: http://comsys.ntu-kpi.kiev.ua/~simon On this URL online documentation for UNILOAD is also available, *please read it before install UNILOAD on your system*. If you have problem with access to this site (our university has problem with outgoing channel) please inform me about it. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
fxp related kernel panic
I have a 3.3-stable machine that I use as a news router (running diablo). The fxp0 interface averages 10-15 Mbps bandwidth continously. About once a week the machine crashes & reboots. We enabled the debugger this time and captured the following debug output: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x382e4641 fault code = supervisor write, page not present instruction pointer = 0x8:0xc01a372e stack pointer = 0x10:0xc02523b0 frame pointer = 0x10:0xc02523c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = Idle interrupt mask = net kernel: type 12 trap, code=0 Stopped at fxp_add_rfabuf+0x1de: movw%ax,0x4(%esi) db> %uname -a FreeBSD feeder.via.net 3.3-STABLE FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/DIABLO i386 %dmesg Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.3-STABLE #7: Mon Oct 18 17:14:40 PDT 1999 [EMAIL PROTECTED]:/usr/src/sys/compile/DIABLO Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 498752616 Hz CPU: Pentium III (498.75-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x672 Stepping = 2 Features=0x387fbff,MMX,FXSR,> real memory = 536870912 (524288K bytes) avail memory = 519340032 (507168K bytes) Preloaded elf kernel "kernel" at 0xc02ca000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 ncr0: rev 0x37 int a irq 11 on pci0.13.0 ncr1: rev 0x37 int b irq 10 on pci0.13.1 fxp0: rev 0x05 int a irq 5 on pci0.15. 0 fxp0: Ethernet address 00:a0:c9:fc:45:7f chip1: rev 0x02 on pci0.18.0 ide_pci0: rev 0x01 on pci0.18.1 chip2: rev 0x02 on pci0.18.3 vga0: rev 0x23 on pci0.2 0.0 Probing for PnP devices: Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa sio0: configured irq 4 not in bitmap of probed irqs 0 sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 8250 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1 not found at 0x2f8 fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa wdc0 at 0x1f0-0x1f7 irq 14 flags 0xb0ffb0ff on isa wdc0: unit 0 (wd0): , LBA, DMA, 32-bit, multi-block-16 wd0: 26105MB (53464320 sectors), 3328 cyls, 255 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , LBA, DMA, 32-bit, multi-block-16 wd1: 26105MB (53464320 sectors), 3328 cyls, 255 heads, 63 S/T, 512 B/S wdc1 not found at 0x170 vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface ccd0-3: Concatenated disk drivers Waiting 15 seconds for SCSI devices to settle changing root device to da0s1a da0 at ncr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 4350MB (8910423 512 byte sectors: 255H 63S/T 554C) WARNING: / was not properly dismounted Any ideas ? Thanks, Joe -- Joe McGuckin ViaNet Communications 994 San Antonio Road Palo Alto, CA 94303 Phone: 650-969-2203 Cell: 650-207-0372 Fax: 650-969-2124 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW Improvements. (comments?)
check how the netatalk code expands a range in to teh minumm set of netmasks needed to cover that range. (somewhere in /sys/netatalk). On Tue, 26 Oct 1999, Chuck Youse wrote: > > > On Tue, 19 Oct 1999, Julian Elischer wrote: > > > > The real advantage is being able to do somethine like this: > > > > > > #!/bin/sh > > > dnservers=10.0.0.1,10.0.0.2,10.0.0.3 > > > smtpservers=10.0.0.4,10.0.0.5,10.0.0.6 > > > ipfw add pass udp from any to $dnservers 53 > > > ipfw add pass tcp from any to $smtpservers 25 > > > > > > ... and so on. > > but you need to store this somewhere.. > > the present system of fixed structures doesn't support this without an > > enormous waste of space...I'm not sure how useful it would be in > > practice.. > > Actually, for what he's describing, we could simply modify /sbin/ipfw to > add multiple rules. For example, the first ipfw example above would be > expanded to: > > ipfw add pass udp from any to 10.0.0.1 53 > ipfw add pass udp from any to 10.0.0.2 53 > ipfw add pass udp from any to 10.0.0.3 53 > > I'm not quite sure of the value of this in practice either (as one could > easily expand the rules by hand), but it's not too difficult to implement. > > Chuck Youse > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: module names
I, for one, like what was suggested a long time ago, by someone who I cannot really remember. It separated driver "classes" in /modules subdirectories. For instance, we could have a "net" for the if_foo drivers, "storage" for CAM/ATA/RAID/Vinum/CCD/etc., "periph" for various esoteric peripherals, "exec" for exec formats like svr4/linux/ ibcs2, "video" for vesa/*_saver, "fs" for filesystems (separate from storage), and "netsub" for ipfw/streams/loadable socket domains. I think that, perhaps, there should be a "bus" where pccard, usb, and SCSI cards would go (instead of "storage"). Currently, we don't have way too many modules, so I'm happy with what's here now. I definitely think there's room for improvement in how /modules is organized, but remember that the format came straight from what we used to have in /lkm. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver error messages - Still
At 01:25 AM 10/21/99 +, you wrote: >On 20 Oct 1999 17:42:58 -0400, in sentex.lists.freebsd.hackers you wrote: > >> >>Running a late 3.2-stable, im getting >> >>fxp0: warning: unsupported PHY, type = 0, addr = 0 >> >>the card has a GD82559 Intel part on it >> >> >>Is there an updated version of the driver that supports this? > >If this is the newer rev cards, I think > >$FreeBSD: src/sys/pci/if_fxp.c,v 1.59.2.4 1999/08/29 16:31:37 peter Exp $ > >addresses it. Nope, that version still get the error message. I guess Intel has "yet another" rev. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW Improvements. (comments?)
On Tue, 19 Oct 1999, Julian Elischer wrote: > > The real advantage is being able to do somethine like this: > > > > #!/bin/sh > > dnservers=10.0.0.1,10.0.0.2,10.0.0.3 > > smtpservers=10.0.0.4,10.0.0.5,10.0.0.6 > > ipfw add pass udp from any to $dnservers 53 > > ipfw add pass tcp from any to $smtpservers 25 > > > > ... and so on. > but you need to store this somewhere.. > the present system of fixed structures doesn't support this without an > enormous waste of space...I'm not sure how useful it would be in > practice.. Actually, for what he's describing, we could simply modify /sbin/ipfw to add multiple rules. For example, the first ipfw example above would be expanded to: ipfw add pass udp from any to 10.0.0.1 53 ipfw add pass udp from any to 10.0.0.2 53 ipfw add pass udp from any to 10.0.0.3 53 I'm not quite sure of the value of this in practice either (as one could easily expand the rules by hand), but it's not too difficult to implement. Chuck Youse To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[freebsdcon] slides for IPv6/IPsec talk
Due to troubles on my notebook PC:-), I was unable to show you the last dozen of slides to you at the event. I made the slides available at: http://www.itojun.org/diary/19991019/ It will also be included into to-appear freebsdcon proceedings webpage. BTW the blue-screen-of-death was due to my fault. I forgot to make clean before building a new kernel. itojun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
