Re: Extending loader(8) for loading kerels/modules split across several disks
> > At any rate, my key point is that the splitting should be invisible, and > > *definitely* not pushed up into the loader. > > Ok, attached is the path, which does exactly what described. Please > review and if there are no objections I would like to commit it > shortly, so that our re@ team would be able to consider it for the > forthcoming 5.0-DP1 release. Sorry that it's taken so long to get you a reply - this is exactly what I had in mind, thanks! -- To announce that there must be no criticism of the president, or that we are to stand by the president, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. - Theodore Roosevelt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Need help with MII-bus driver
Hello -hackers!
I'm trying to fix the problems in kern/30836 and kern/35691 where an
integrated SIS 900 NIC is not working with an external Realtek PHY.
(10baseT (or non NWAY) mode does not work)
I have modified the dev/mii/rlphy.c driver to also recognize the RTL8201
PHY.
The problem is that in the rlphy_status function I need to know if this
is a integrated 8139 phy or an external 8201 how can I find this out
when all I have is a mii_softc* ?
Below are my changes that work fine with the SIS900 but breaks when
using a Realtek 8139 and not doing NWAY negotiation.
Please cc me on any answers so I won't have to wait for my hackers
digest to arrive.
/martin
*** rlphy.c Thu Mar 7 07:23:00 2002
--- rlphy.c.mn Sun Mar 17 13:00:43 2002
***
*** 80,85
--- 80,86
DRIVER_MODULE(rlphy, miibus, rlphy_driver, rlphy_devclass, 0, 0);
int rlphy_service __P((struct mii_softc *, struct mii_data *, int));
+ void rlphy_status __P((struct mii_softc *));
static int rlphy_probe(dev)
device_tdev;
***
*** 90,95
--- 91,103
ma = device_get_ivars(dev);
parent = device_get_parent(device_get_parent(dev));
+/* Realtek 8201L */
+ if (MII_OUI(ma->mii_id1, ma->mii_id2) == 0x20 &&
+ MII_MODEL(ma->mii_id2) == 0x20) {
+ device_set_desc(dev, "RealTek 8201(L) media interface");
+ return (0);
+ }
+
/*
* RealTek PHY doesn't have vendor/device ID registers:
* the rl driver fakes up a return value of all zeros.
***
*** 259,265
}
/* Update the media status. */
! ukphy_status(sc);
/* Callback if something changed. */
if (sc->mii_active != mii->mii_media_active || cmd == MII_MEDIACHG) {
--- 267,273
}
/* Update the media status. */
! rlphy_status(sc);
/* Callback if something changed. */
if (sc->mii_active != mii->mii_media_active || cmd == MII_MEDIACHG) {
***
*** 267,270
--- 275,353
sc->mii_active = mii->mii_media_active;
}
return (0);
+ }
+
+ void
+ rlphy_status(phy)
+ struct mii_softc *phy;
+ {
+ struct mii_data *mii = phy->mii_pdata;
+ int bmsr, bmcr, anlpar;
+
+ mii->mii_media_status = IFM_AVALID;
+ mii->mii_media_active = IFM_ETHER;
+
+ bmsr = PHY_READ(phy, MII_BMSR) | PHY_READ(phy, MII_BMSR);
+ if (bmsr & BMSR_LINK)
+ mii->mii_media_status |= IFM_ACTIVE;
+
+ bmcr = PHY_READ(phy, MII_BMCR);
+ if (bmcr & BMCR_ISO) {
+ mii->mii_media_active |= IFM_NONE;
+ mii->mii_media_status = 0;
+ return;
+ }
+
+ if (bmcr & BMCR_LOOP)
+ mii->mii_media_active |= IFM_LOOP;
+
+ if (bmcr & BMCR_AUTOEN) {
+ /*
+* NWay autonegotiation takes the highest-order common
+* bit of the ANAR and ANLPAR (i.e. best media advertised
+* both by us and our link partner).
+*/
+ if ((bmsr & BMSR_ACOMP) == 0) {
+
/* Erg, still trying, I guess... */
+
mii->mii_media_active |= IFM_NONE;
+
return;
+ }
+
+ if( anlpar = PHY_READ(phy, MII_ANAR) & PHY_READ(phy, MII_ANLPAR) ) {
+
if (anlpar & ANLPAR_T4)
+
mii->mii_media_active |= IFM_100_T4;
+
else if (anlpar & ANLPAR_TX_FD)
+
mii->mii_media_active |= IFM_100_TX|IFM_FDX;
+
else if (anlpar & ANLPAR_TX)
+
mii->mii_media_active |= IFM_100_TX;
+
else if (anlpar & ANLPAR_10_FD)
+
mii->mii_media_active |= IFM_10_T|IFM_FDX;
+
else if (anlpar & ANLPAR_10)
+
mii->mii_media_active |= IFM_10_T;
+
else
+
mii->mii_media_active |= IFM_NONE;
+
return;
+ }
+ /*
+* If the other side doesn't support NWAY, then the
+* best we can do is determine if we have a 10Mbps or
+* 100Mbps link. There's no way to know if the link
+* is full or half duplex, so we default to half duplex
+* and hope that the user is clever enough to manually
+* change the media settings if we're wrong.
+*/
+
+ /*
+* RTL8201 Link partner is not capable of autonegotiation.
+* Magic register (0x0019) found in Linux driver for SiS900
+*/
+ if( 1 /* Is this a 8201? */ ) {
+
if( PHY_READ(phy, 0x0019) & 0x01)
+
mii->mii_media_active |= IFM_100_TX;
+
else
+
mii->mii_media_active |= IFM_10_T;
+
Re: PR's in need of a home
On Sat, Mar 16, 2002 at 05:22:03PM -0600, Matthew D. Fuller wrote: > - docs/31265 - Documentation (and adjustment) of cron allow/deny file >formats > Best (IMO, but then, I wrote it ;) patch at end of audit trail. I committed a version of this. > - docs/35436 - Webpage update; don't push PAO > Patch in PR I'm not a web committed so I can't help here. > - docs/35575 - pw(8) manpage update: document /var/log/userlog > Patch in audit trail I've just noticed that the log file is mentioned in pw.conf(5), but it's default value, /var/log/userlog, is not mentoned. This probably means that pw.conf needs a patch to note the default value and that the changes to the pw man page should refer to pw.conf(5) when talking about the log file. I'll submit a followup to the PR mentioning this. > - bin/35505 - sed(1) feature: esed -> sed -E > bde doesn't like it. I like it, but not enough to fight more than > casual criticism of it. If anybody else cares enough, it could be > discussed; if not, the PR can just be closed. I wouldn't be that mad about it, so I'd be inclined to close it. Can you remind me to close it at some stage in the future if no interest materialises. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
STLPORT and gcc3 (openoffice porting)
Hi all, I'm desperatly looking for a way to compile the stlport with gcc3.2 or gcc3.1 from ports. If you know a way to do this, please tell me. If my understanding is right, I have to build the stlport within the openoffice port and cannot use the FreeBSD ports version, since this is compiled with old buggy gcc295. Ok, so I decided to make a build infrastructure for gcc32. But at the moment I'm stuck with this: cd ./unxfbsd.pro/misc/build/STLport-4.5/src && gmake -f gcc-3.0.mak && touch so_built g++32 -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O2 -fPIC dll_main.cpp -c -o ../lib/obj/GCCi386/ReleaseD/dll_main.o In file included from stlport_prefix.h:28, from dll_main.cpp:34: ../stlport/ctime:25:44: ../g++-v3/ctime: No such file or directory Making a symlink doesn't help: mkdir ./unxfbsd.pro/misc/build/STLport-4.5/src mkdir: ./unxfbsd.pro/misc/build/STLport-4.5/src: File exists cd ./unxfbsd.pro/misc/build/STLport-4.5/src && gmake -f gcc-3.0.mak && touch so_built g++32 -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O2 -fPIC dll_main.cpp -c -o ../lib/obj/GCCi386/ReleaseD/dll_main.o In file included from ../stlport/stl/_cwchar.h:31, from ../stlport/cwchar:24, from ../stlport/stl/char_traits.h:31, from ../stlport/stl/_iosfwd.h:22, from ../stlport/iosfwd:33, from ../stlport/stl/_string_fwd.h:23, from ../stlport/stl/_string.h:31, from ../stlport/string:42, from dll_main.cpp:45: ../g++-v3/cwchar:69: `mbstate_t' not declared I get a different error then ... Anybody knows what I could do ? Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: STLPORT and gcc3 (openoffice porting)
Martin Blapp wrote:
>
> Hi all,
>
> I'm desperatly looking for a way to compile the stlport with gcc3.2
> or gcc3.1 from ports. If you know a way to do this, please tell me.
>
> If my understanding is right, I have to build the stlport within the
> openoffice port and cannot use the FreeBSD ports version, since this
> is compiled with old buggy gcc295.
Ports that need to use C++ include files that came with the
compiler will not work with anything other than the native
C++ compiler.
This is because ports set DESTDIR. If you set "DESTDIR" and
you don't set "BOOTSTRAPPING", then the .mk files "bsd.lib.mk"
and "bsd.prog.mk" override both "CXXINCLUDES" and the library
path with the system include directory ${DESTDIR}/usr/include/g++,
and the system library path to "libgcc.a", which includes the
version specific code for handling things like RTTI and threads
exceptions stacks, and so on.
So you will think you are getting the ports installed versions
of these files, but in fact the DESTDIR setting will make sure
you get the "old buggy gcc295" versions of the files, which
came with your system.
> ../stlport/ctime:25:44: ../g++-v3/ctime: No such file or directory
[ ... ]
> ../g++-v3/cwchar:69: `mbstate_t' not declared
[ ... ]
> Anybody knows what I could do ?
You have to hack up your Makefiles and CXXINCLUDES and CFLAGS
to make the ports version of the headers files be seen first,
even though you have DESTDIR set.
The only way this will work is if you hack the Makefile(s) to
make sure that the absolute patch to the ports versions of the
paths occur on the command line before the system versions,
which is not as simple as just setting CXXINCLUDES or CFLAGS,
and it varies from application to application how you have to
do it, particularly if your port happens to use something
evil like "autoconf".
The only other way to deal with this is to deinstall the
system compiler, and replace it with the new compiler,
and then replace the system header files with the replacement
versions of the header files, so that when the DESTDIR crap
happens, it ends up ointing to the right include files instead
of the wrong ones.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: STLPORT and gcc3 (openoffice porting)
On Sunday 17 March 2002 08:18 pm, Terry Lambert wrote: > > ../stlport/ctime:25:44: ../g++-v3/ctime: No such file or > > directory > > [ ... ] > > > ../g++-v3/cwchar:69: `mbstate_t' not declared > > [ ... ] > > > Anybody knows what I could do ? > > You have to hack up your Makefiles and CXXINCLUDES and CFLAGS > to make the ports version of the headers files be seen first, > even though you have DESTDIR set. > > The only way this will work is if you hack the Makefile(s) to > make sure that the absolute patch to the ports versions of the > paths occur on the command line before the system versions, > which is not as simple as just setting CXXINCLUDES or CFLAGS, > and it varies from application to application how you have to > do it, particularly if your port happens to use something > evil like "autoconf". > > The only other way to deal with this is to deinstall the > system compiler, and replace it with the new compiler, > and then replace the system header files with the replacement > versions of the header files, so that when the DESTDIR crap > happens, it ends up ointing to the right include files instead > of the wrong ones. > > -- Terry Since the port of STLport is designed as a drop in replacement for the system STL, I've always used the -nostdinc++ option in my projects so that gcc won't even look at the default header files. This option should be used when building the port itself. As the STLport maintainer, I should have specified that. :-( -- Paul Marquis [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Need help!! Any FreeBSD users/hackers in Toronto??
Hi, The distributedfolding project (similar to SETI@home, it uses your free computer cycles to do something useful -- folding proteins) is planning to offer a FreeBSD client. However, they don't know how to setup a FreeBSD box. They are located in the Toronto area (Canada), so am I. But I don't have much FreeBSD experience. I installed a FreeBSD 4.3 box *without* networking support a while ago. Looks like there are some people planning to ship a FreeBSD box to them. However, I think the best would be having a person walking through the entire installation process, and answering questions related to FreeBSD. You can learn more about this project -- www.distributedfolding.org If no one is located in the Toronto area, then I will try my best to help. (I will find my 4.3 CD and do a clean reinstall on my own machine, and try to hook-up the Net -- but I know the help from you guys is always better) Thanks, Rayson P.S. The results from this project will be publicly available, and I am not directly related (employed) to this project. __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Working with CVS and FreeBSD?
Hi Folks, I'm about to try and do some work on some kernel code in FreeBSD and I'm thinking about ways to track my changes. I'm currently mirroring the CVS repository with CVSup (i.e. CVS mode not checkout mode) and am thinking of making a branch in my local repository. Is this how the rest of you work or do you import the kernel (or whatever code you're working on) into your own local repository with import? Thanks, George -- George V. Neville-Neil [EMAIL PROTECTED] Neville-Neil Consulting www.neville-neil.com "We should not be ashamed to acknowledge truth from whatever source it comes to us, even if it is brought to us by former generations and foreign peoples. For him who seeks the truth there is nothing of higher value than truth itself." al-Kindi (c 801-66) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: STLPORT and gcc3 (openoffice porting)
Paul Marquis wrote:
> Since the port of STLport is designed as a drop in replacement for
> the system STL, I've always used the -nostdinc++ option in my
> projects so that gcc won't even look at the default header files.
> This option should be used when building the port itself. As the
> STLport maintainer, I should have specified that. :-(
>From bsd.prog.mk:
.if defined(DESTDIR) && !defined(BOOTSTRAPPING)
CFLAGS+= -I${DESTDIR}/usr/include
CXXINCLUDES+= -I${DESTDIR}/usr/include/g++
.endif
That option does not good, if you set DESTDIR and use the BSD
.mk file system, which will put it right back in the options
list for the program being built.
You really do have to hack up the Makefile to list the port
compiler include path first, or this overrides it.
The typical way I do this for the includes is to redefine
the compiler to have a "-I/usr/local/" as part
of the command itself. It's generally harmless, otherwise.
Otherwise... don't set "DESTDIR", or explicitly set
"BOOTSTRAPPING". Both of these have side effects that
are harder to control than jamming the include path into
the compiler command.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Junior hacker test
Mark all the usage() functions in the tree __dead2. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
