Re: PCMCIA modem is detected/attached only on second insertion
Hi All,
FYI:
Maxim Sobolev wrote:
> I had started observing this problem about a 1.5 months ago - my
> PCMCIA modem (EigerCom 33.6) is detected/attached only on second
> insertion, i.e. if I'm booting with the card inserted I have to
> manually eject it and put back, while if the machine boots with
> an empty slot I have to do insert-eject-insert procedure. At the
> same time, another PCMCIA card (ed0-compatible ethernet adapter)
> doesn't have this problem. Following is related kernel output
The funny thing is, I've got the opposite situation: I have to insert my
network card twice (Netgear - old version), but my modem card (Xircom) works
fine straight away. CURRENT, OLDCARD.
Regards,
Konstantin.
--
* * Konstantin Chuguev Francis House
* * Application Engineer 112 Hills Road
* Tel: +44 1223 302992 Cambridge CB2 1PQ
D A N T E WWW: http://www.dante.netUnited Kingdom
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Iomega Peerless USB supported?
Hi, Are Iomega Peerless USB drives supported in CURRENT? I assume they can be recognised as a generic SCSI-over-USB drive, but want to be sure they work OK. Thanks, Konstantin. -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.netUnited Kingdom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
USB Multimedia Card (MMC) readers supported?
Hello, Are USB MMC Card Readers (such as SanDisk ImageMate) supported in CURRENT? I suppose they can be treated as generic SCSI-over-USB drives, just want to be sure... Thanks, Konstantin. -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.netUnited Kingdom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Junior Kernel Hacker task: improve vnode->v_tag
Hi Maxim, Perhaps you meant: diff -d -u -r1.154 vnode.h --- sys/vnode.h 2001/08/27 06:09:55 1.154 +++ sys/vnode.h 2001/09/04 15:21:25 @@ -175,6 +175,7 @@ /* open for business 0x10 */ #defineVONWORKLST 0x20 /* On syncer work-list */ #defineVMOUNT 0x40 /* Mount in progress */ +#define VLOCKABLE 0x60 /* vnode supports locking */ ...should be +#define VLOCKABLE 0x80 /* vnode supports locking */ ? Regards, Konstantin. Maxim Sobolev wrote: > > In message <[EMAIL PROTECTED]>, Maxim Sobolev writes: > > >> > > >> In message <[EMAIL PROTECTED]>, Brent Verner writes: > > >> > > > >> >I've done a /cursory/ look over how this v_tag is used. I'm not sure > > >> >this is a simple/clean as you propose, since this is used in the > > >> >IS_LOCKING_VFS macro, as well as in union_subr.c... > > >> > > > Well, that is just too bad, because IS_LOCKING_VFS is wrong then. > > >> > > >> The places which inspect v_tag will have to be changed to use > > >> strcmp() then... > > > > > >I think that we can add a new vnode flag, say VCANLOCK, so that each > > >particular VFS can set it if it supports locking, which should allow > > >to remove pre-defined VFS list from the IS_LOCKING_VFS macro. I can > > >produce a patch if it sounds reasonably. > > > > Yeah, I think that makes a lot of sense. > > See attached. Please let me know if it is OK for you. > > -Maxim > > -- >Name: p >p Type: Plain Text (text/plain) >Encoding: 7bit > Description: ASCII C program text -- * * Konstantin Chuguev Francis House * * Application Engineer 112 Hills Road * Tel: +44 1223 302992 Cambridge CB2 1PQ D A N T E WWW: http://www.dante.netUnited Kingdom To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [CFR] OpenBSD install(1) fixes: atomic install, etc.
Hi, Ruslan Ermilov wrote: > The attached patch incorporates most of OpenBSD fixes to install(1). > It does not include manpage update. Most significant changes are: > > o New flag: -S (atomic install) > > : -SSafe copy. Normally, install unlinks an existing target before > : installing the new file. With the -S flag a temporary file is > : used and then renamed to be the target. The reason this is safer > : is that if the copy or rename fails, the existing target is left > : untouched. > Just curious: why not make this way of doing install default (i.e. always use it)? Regards, Konstantin. -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: x11/XFree86-4
Stephan van Beerschoten wrote: > I am having trouble compiling XFree86 from the ports tree.. I once > ever few weeks recompile several packages again because I run -CURRENT > and want to keep everything nicely sync'ed and updated in ports too.. > > But while compiling .. I got this error: > > LD_LIBRARY_PATH=../../exports/lib cc -o appres -ansi -pedantic -Dasm=__asm -Wal > l -Wpointer-arith -L../../exports/lib appres.o -lXt -lSM -lICE -lXext -lX11 > -L/usr/X11R6/lib -Wl,-rpath,/usr/X11R6/lib > ../../exports/lib/libXt.so: undefined reference to `pthread_cond_signal' > ../../exports/lib/libXThrStub.so.6: undefined reference to `_Xthr_zero_stub_' > Remove /usr/ports/x11/XFree86-4/files/patch-xthreads: it breaks compilation in CURRENT. This worked fine for me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Unicode support in cd9660 [patch for review]
"Michael C . Wu" wrote:
> As to the progress of iconv, we should have it soon, as soon as
> itojun and I work out how to import either the Citrus code
> or Konstantin's code.
>
As I could see from the CVSed Citrus code, it's a locale library rather than iconv,
and it's just got the stub calls of iconv functions. So I thought Citrus and iconv
complement each other and don't do the same. Am I wrong?
As for the iconv library itself, its userland part is complete. I'm really busy
these days despite Christmas and the New Year, but I expect to release v2.1 in 3
weeks with the following changes:
* the two patches from ports will be incorporated;
* a few charsets added (to provide compatibility with the libiconv port and to
be able to use glib-1.3 with iconv - the only port still depending on
libiconv);
* memory and file management functions moved into a separate file; then a
kernel-side iconv implementation can compile iconv with its own specific
memory and file management functions (from a different file).
I tried to write a kernel module, but I don't have enough knowledge of the kernel.
If anybody would like to do it, I am ready to help.
Regards,
Konstantin.
--
* *Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW:http://www.dante.net
N
'²æìr¸zǧvf¢Ú&j:+v¨· è® "¶§²æìr¸yúÞy» rêëz{bØ^nr¡ûazg¬±¨
Re: /etc/defaults/rc.conf
Chris Faulhaber wrote:
> On Tue, Nov 07, 2000 at 01:02:03AM +0200, Giorgos Keramidas wrote:
> > On Mon, Nov 06, 2000 at 03:37:01PM -0500, Forrest Aldrich wrote:
> > > It would be useful to have back the program specification variable for
> > > inetd. Currently we have:
> > >
> > > inetd_enable="YES" # Run the network daemon dispatcher (or NO).
> > > inetd_flags="-wW" # Optional flags to inetd
> > >
> > > and the /etc/rc.* files assume the use of the stock inetd. Where some
> > > people choose to use alternative inetd-like programs such as xinetd.
> > [...]
> >
> > Nice idea! And the fix is simple. The included patch will correct it :-)
> >
>
> You forgot the patch(es) to the port(s) this would affect (e.g. xinetd).
> The affected ports would need their ${PREFIX}/etc/rc.d files removed
> (otherwise you would start them twice) along with a message letting the
> installer know how to start it properly.
>
If xinetd has a startup script, why don't you just set inetd_enable="NO" and let
the /usr/local/etc/rc.d/xinetd.sh start normally? You need to edit no /etc/rc.*
files (except for rc.conf.local, obviously).
--
* *Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW:http://www.dante.net
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
platform byte order macros?
Hi,
AFAICS ntoh[ls] and hton[ls] defined as asm instructions. This prevents
using them in const variables initialisation.
I need to create a const unsigned char array[] (C source file) from quite
a big network byte ordered binary data. Although the data consists mainly
of bytes and 16- and 32-bit words, it is difficult in my case to use
u_char, u_int16_t and u_int32_t, as the order and the number of each type
does not fit to any possible C struct declaration.
Well, I can just create a network ordered byte array C declaration like
const unsigned char array[] = { , , ... };
But for more efficient processing I would like to have something like
const unsigned char array[] = {
_4bytes(, , , )
_1long(, , , )
_2shorts(, , , )
_1long(, , , )
_4bytes(, , , )
...
};
... i.e. platform independent source code which would compile into
platform dependent object file. _4bytes, _2shorts and _1long are macros
produced for byte sequence in appropriate byte order. The macros need to
know the platform byte order, theoretically it can be one of 1234, 4321,
2143.
In endian.h I can see just huge line of comparisons to *_386 et. al., but
I cannot find any macros clearly decsribing the byte order. Am I wrong?
Thanks,
Konstantin.
--
* *Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW:http://www.dante.net
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Which GCC in CURRENT? [Was: Re: Wine update]
Szilveszter Adam wrote:
> > > Hmmm. It is good that the problem got resolved, but I take both 4.1 and
> > > -CURRENT use the same gcc version... (2.95.2) Or am I missing something?
> >
> > AFAIK, -CURRENT uses a snapshot of GCC 2.96 which may have some bugs.
>
> It reports itself as 2.95.2.
>
There are two directories in CURRENT's src/contrib: gcc and gcc.295 (the former is
fresher). In src/gnu/{usr.bin|lib} appropriate Makefile.inc files set .PATH to
.../.../gcc.295.
There seems to be no way to switch to another GCC by editing just one line
somewhere.
Does anybody knows why there are two GCC in CURRENT?
Regards,
Konstantin.
--
* *Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW:http://www.dante.net
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ssh and scp fail connecting to a root account
Udo Schweigert wrote: > Hello all, > > after a fresh build of -current openssh does not work if connecting to the > root-user. For example (tested from a -stable machine, but the same from > 4.1-RELEASE): > > --- > --- > > The strange: both commands succeed if connecting to a non-root account. > > Are there any others with these problems? Any clues? > Yes, I've been seeing the same thing since the checkout of the SMPng stuff... No idea why it's happening. -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/proc & /dev/std* [Was: Fdescfs updates--coming to a devfs near you!]
Johnny Eriksson wrote:
> > [EMAIL PROTECTED] said:
> > :- The majority of these programs could be handled by adding knowledge of
> > :- "-" as a magic filename to fopen(3).
> >
> > Suppose I *want* a filename called "-"? My tough luck, huh?
>
> Could you settle for "./-"?
>
I think any "magic" name is not very good idea. To say more, it breaks POSIX.
File names are a tratitional UNIX way to access character and block devices;
in System V you can access much more via file names, using streams.
Magic numbers are for MS DOS (remember COM1 and LPT1? :-)
I am not sure /proc/ names are very useful, but
/dev/std{in|out|err} definitely are.
--
* *Konstantin Chuguev - Application Engineer
* * Francis House, 112 Hills Road
* Cambridge CB2 1PQ, United Kingdom
D A N T E WWW:http://www.dante.net
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Request for review: locale aliases support for libc
Alexey Zelkin wrote: > > > > You need to check LC_* existence corresponding to setlocale() request > > > > made. > > > > > > What to check if LC_ALL request is given ? > > > LC_ALL overrides all other LC_* variables. If it is set, there is no need to > > check anything else. > > > Then you should check all other LC_*, and then LANG. > > As I understand you're answering in concept, but we are talking about > exact case right now (see may patches attached to previous letter) > > I am trying to realize "is requested locale physicaly present on this system" > or it's just an alias. Currently I am just testing presence of > /usr/share/locale/$requested_locale/LC_CTYPE and make decision depends > on stat(2) return value. > Perhaps you should check presence of any of the following files in a locale directory: LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_TIME, and proceed if any of them has been found... -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Request for review: locale aliases support for libc
Alexey Zelkin wrote: > > You need to check LC_* existence corresponding to setlocale() request > > made. > > What to check if LC_ALL request is given ? > LC_ALL overrides all other LC_* variables. If it is set, there is no need to check anything else. Then you should check all other LC_*, and then LANG. -- * * Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People running with LOCALBASE set to something other than /usr/local?
"Jacques A. Vidrine" wrote: > On Wed, Aug 23, 2000 at 01:01:59AM -0500, Mike Meyer wrote: > > Um - why? If you removed the setting of LOCALBASE in that case, you > > wouldn't change the disk layout at all. > > I prefer installed executables, data files, and man pages to refer to > /opt. Duh. > Just wondering: what is the reason of using /opt instead of /usr/local, apart from Solaris influence? Do you use /usr/local for anything? -- * *Konstantin Chuguev - Application Engineer * * Francis House, 112 Hills Road * Cambridge CB2 1PQ, United Kingdom D A N T E WWW:http://www.dante.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeSSH
Pierre Beyssac wrote: > [ -security trimmed from Cc: ] > > On Wed, Oct 13, 1999 at 11:11:43AM -0400, Patrick Bihan-Faou wrote: > > >pkg_delete lp > > >pkg_delete yp > > > > > >Has anyone done/tried this in the past, and if so, what was the > > > reaction? Or what do people think? I realize this sounds a bit like the > > > "everything is an rpm or dpkg" methodology from Linux, but as long as the > > > 'base' packages are handled automatically, then it shouldn't impose the > > > same inconvenience. > > > > I think that it would be the next best thing since the package/ports system > > (as well as a logical step forward). I would love to see most of the things > > that installed with a "make world" be also registered in the package > > database. This would make things like upgrading bind, removing sendmail etc > > a lot easier. > > There are a _lot_ of pitfalls to this kind of approach, as I have > discovered using Linux Debian. This would probably open a can of > worms you have no idea of. IMHO, the single biggest mistake in > Debian is the all-encompassing package system which can make your > life miserable in no time. > > I have found this the hard way, because I have to administer a > network of Debian PCs. Any attempt to upgrade something, even a > minor application, rapidly turns into a dependency nigthmare forcing > you to update half of your system. This is made even worse by > endless changes in the glibc, itself included in the package system: > since you can code that dependency in the package system, many > packages require such and such version of the glibc. In turn, > frequent incompatible updates of the glibc are made by the developpers > with the excuse that it's all handled by the package system anyway... > > To that, you can add several other flaws (broken stable vs unstable > policy, no /usr/local, many installation scripts asking for > interactive input...). > > The bottom line is: I'm much happier with FreeBSD's use of > distributions for the base system than with a Debian-style package > system. > Well, what about having just the extended set of makefile variables in /etc/make.conf? We already have NOPROFILE, NOPERL, NOSUIDPERL, NOGAMES, NODOC. I would prefer to have two sets of such variables: one is something like BUILD_*, another is INSTALL_*; both for *_LP, *_YP, *_DEVEL, *_PERL etc. Of course there should be BUILD_ALL and INSTALL_ALL. And of course, some of the variables would define other ones implicitly. Then, you will still need to cvs the entire tree (and thus properly synchronized), but won't need to build or install all the stuff every time. And you will have just to choose the necessary subset for each your server, router and/or workstation. If it is done by making targets like build_* and install_* in the source tree, then there is an opportunity to make also the uninstall_* targets for removing unnecessary parts of the distribution. > > That is no to say there can be no good package system, but we have > to think twice before we implement anything like that, first and > foremost dependencies on system libraries. > > And, IMHO, package handling for general-purpose applications and > package handling for the core system are a very different problem > and should be handled in very different ways. > > The Solaris way, while far from perfect, is at least usable for > the most past to handle choice at installation and (not too frequent) > evolutions of system components. > -- > Pierre Beyssac [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Konstantin V. Chuguev. System administrator of Southern http://www.urc.ac.ru/~joy/ Ural Regional Center of FREEnet, mailto:[EMAIL PROTECTED]Chelyabinsk, Russia. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SQLed FreeBSD [Was: Re: LDAPed FreeBSD]
"Kurt D. Zeilenga" wrote: > This discussion is diverging a bit from this list's charter. Hence, > I'll be brief. > > Amancio Hasty wrote: > > True LDAP (v2 or v3) does not provide record locking . Now the question is > > does Novell's NDS 8 -- a native LDAP v3 -- , Oracle's Directory > > Server or Microsoft Active Directory does if they do then how ? > > Commonly through other directory (or database) access mechanisms. Or, What about using SQL: system services as SQL clients? SQL's advantages are locking, transactions, views, relative portability and extensibility. One can use MySQL server as a directory, another - Oracle or Postgres etc. Of course, there are some disadvantages (please, point out some...) > > possibly, though some private or experimental LDAPv3 control or extended > op they added to their client/servers (LDAPv3 is an extensible protocol). > > > Again my emphasis is on configuring network services or other system services > > if appropiate and to provide a HTML interface which is sufficiently rich to be > > user friendly. > OK. Then PHP comes to mind (again with SQL :-) -- Konstantin V. Chuguev. System administrator of Southern http://www.urc.ac.ru/~joy/ Ural Regional Center of FREEnet, mailto:[EMAIL PROTECTED]Chelyabinsk, Russia. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
T/TCP in FreeBSD-3.x
Hi! Has FreeBSD-3.x a correct implementation of T/TCP? There is some bug mentioned in Squid FAQ (http://squid.nlanr.net/Squid/FAQ/FAQ-14.html#ss14.2), about brokenness of T/TCP in FreeBSD-2.2.2. Why I'm asking about this, is because I recently read an advice in one of the FreeBSD mailing lists, about "Why my dial-up PPP connection from a FreeBSD box is so slow comparing with Windows NT (about ten times slower)?" And the advice was (without explanations): "Try to switch off the TCP_EXTENSIONS in /etc/rc.conf". So, is it safe to use T/TCP (at least for Squid) for RELENG_3? RELENG_2_2? And what about MBUF size (mentioned at the same page of the Squid FAQ)? Do I need to patch Squid as it shown at the page? Thanks. -- Konstantin V. Chuguev. System administrator of Southern http://www.urc.ac.ru/~joy/ Ural Regional Center of FREEnet, mailto:j...@urc.ac.ruChelyabinsk, Russia. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
