Re: Problem with xl driver (cvsup 2001-06-02)
On Sat, Jun 02, 2001 at 05:13:30PM +0100, Pete French wrote: > > But you're right, in fact 3com cards 3c905 and 3c905c are quite > > different. As far as I can see the general consensus is that we don't know yet ;) > It is the general consensu that this affect 3C905 cards only, not any of the > other 3COM cards that use the xl driver ? I have a 3C900B-TPO in a remote > machine that I was going to have a try at upgrading sometime in the near > future - which might provide some more information, but I;d like to > know if I have to plan to take an afternoon off to go to where the machine > is physically locate in case it does not come up properly. Difficult to say based on the limited amount of data we have at the moment. W/ -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) BultePowered by FreeBSD/alpha http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: time_t definition is worng
Hello,
From: "David O'Brien" <[EMAIL PROTECTED]>
Subject: Re: time_t definition is worng
Date: Sat, 2 Jun 2001 09:16:43 -0700
Message-ID: <[EMAIL PROTECTED]>
> On Sun, Jun 03, 2001 at 01:05:18AM +0900, Yoshihiro Koya wrote:
> > > Since on IA-32 int == long, the only issue is what ones uses in printf()
> > > and scanf(). I have not seen anyone having a problem with this yet.
> >
> > Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=27757
> > and the response to this PR.
>
> This PR seems to be a signed vs. unsigned issue. Maybe it is too early
> in the morning, so please explain why int(32-bit) vs. long(32-bit) [on
> x86] is an issue for this PR.
Yes. You are right. The PR itself isn't one related to int vs. long issue.
But the respose submitted by someone is closely related to this issue.
if (snprintf(buf, sizeof(buf),
- "%s:%s:%d:%d:%s:%ld:%ld:%s:%s:%s",
+ "%s:%s:%u:%u:%s:%ld:%ld:%s:%s:%s",
pw->pw_name, pw->pw_passwd, pw->pw_uid, pw->pw_gid, pw->pw_class,
pw->pw_change, pw->pw_expire, pw->pw_gecos, pw->pw_dir,
pw->pw_shell) >= sizeof(buf)) {
The pw->pw_chage and pw->pw_passwd are of time_t. But, in the above,
%ld is used for them.
koya
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: time_t definition is worng
On Sun, Jun 03, 2001 at 01:05:18AM +0900, Yoshihiro Koya wrote: > Hello, > > From: "David O'Brien" <[EMAIL PROTECTED]> > Subject: Re: time_t definition is worng > Date: Sat, 2 Jun 2001 08:52:37 -0700 > Message-ID: <[EMAIL PROTECTED]> > > > Since on IA-32 int == long, the only issue is what ones uses in printf() > > and scanf(). I have not seen anyone having a problem with this yet. > > Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=27757 > and the response to this PR. This PR seems to be a signed vs. unsigned issue. Maybe it is too early in the morning, so please explain why int(32-bit) vs. long(32-bit) [on x86] is an issue for this PR. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problem with xl driver (cvsup 2001-06-02)
> But you're right, in fact 3com cards 3c905 and 3c905c are quite > different. It is the general consensu that this affect 3C905 cards only, not any of the other 3COM cards that use the xl driver ? I have a 3C900B-TPO in a remote machine that I was going to have a try at upgrading sometime in the near future - which might provide some more information, but I;d like to know if I have to plan to take an afternoon off to go to where the machine is physically locate in case it does not come up properly. -pcf. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: time_t definition is worng
Hello, From: "David O'Brien" <[EMAIL PROTECTED]> Subject: Re: time_t definition is worng Date: Sat, 2 Jun 2001 08:52:37 -0700 Message-ID: <[EMAIL PROTECTED]> > Since on IA-32 int == long, the only issue is what ones uses in printf() > and scanf(). I have not seen anyone having a problem with this yet. Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=27757 and the response to this PR. I have no good idea to fix this problem. If someone decide what is the best for time_t, I can submit patch to solve this PR and the problem pointed out by its response. koya To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: time_t definition is worng
On Sat, Jun 02, 2001 at 01:23:05AM -0700, Matt Dillon wrote: > Yes, I know all that. The problem isn't that you couldn't have an > unsigned time_t, the problem is that there are vast amounts of software > already out there that would "break mysteriously" if you did. So, > like the int<->long problem, the best thing to do is not rock the boat. > That means for maximum portability time_t has to be a signed long. Not > int, not unsigned int, not unsigned long... just 'long'. There is not enough context here for me to get any idea what the issue is. This email argued signed vs. unsigned, and that has nothing to do with time_t being an int. Since on IA-32 int == long, the only issue is what ones uses in printf() and scanf(). I have not seen anyone having a problem with this yet. So I ask you to bring this up on [EMAIL PROTECTED] why time_t needs to be a long. If you had more multi-platform concerns you would understand why having as consistent defintions of things is best for FreeBSD. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problem with xl driver (cvsup 2001-06-02)
Hi, Am Sa , dem 02. Jun 2001, um 22:25 + Uhr schrubte K Karthik zum Thema [Re: Problem with xl driver (cvsup 2001-06-02)]: > No problems for me. My dmesg line: > *--* > xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x1000-0x107f mem > 0xf400-0xf47f irq 11 at device 13.0 on pci0 > *--* > > scanpci: > *--* > pci bus 0x0 cardnum 0x0d function 0x: vendor 0x10b7 device 0x9200 > 3COM Device unknown > *--* Look at the URL Wilko posted in the morning. But you're right, in fact 3com cards 3c905 and 3c905c are quite different. Riggs -- - Die Welt schläft tief schon lange Zeit | Sent with RiggiSmooth [tm] - -- Mich nur flieht die Dunkelheit| - -- --- Denn per Infrarot seh ich| just to fit your --- Die Nacht ist wirklich widerlich. | primitive screen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: lpd: Malformed from address
> On Sat, 2 Jun 2001 04:23:18 -0700
> "Morgan Davis" <[EMAIL PROTECTED]> said:
mdavis> After upgrading two different FreeBSD 4.2 systems to 4.3, they both
mdavis> began to exhibit trouble when trying to print to their lpd processes.
mdavis> Watching the raw traffic via tcpdump, both are failing immediately when
mdavis> lpd tries to resolve the connecting client's address in chkhost():
mdavis> error = getnameinfo(f, f->sa_len, NULL, 0, serv, sizeof(serv),
mdavis> NI_NUMERICSERV);
mdavis> if (error || atoi(serv) >= IPPORT_RESERVED)
mdavis> fatal(0, "Malformed from address");
mdavis> It can be exercised via telnet:
mdavis> # telnet golf printer
mdavis> Trying 205.163.23.102...
mdavis> Connected to golf.cts.com.
mdavis> Escape character is '^]'.
mdavis> lpd: Malformed from address
mdavis> Connection closed by foreign host.
mdavis> This happens on both systems, different kernels, one running named and
mdavis> one not. What in the world could be causing this?
When I ported IPv6 support into FreeBSD from NetBSD, I wrongly brought
reserved port checking code into FreeBSD. Originally, FreeBSD's lpd
didn't check validity of connection by checking if it comes from
reserved port.
However, since lpd relies on r-authentication, it should be expected.
Though it is easy to get rid of reserved port checking, we should have
some considerlation. Any suggestion?
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
HEADS UP: 3COM 3C905TX / xl driver broken in -stable
For those of you who have missed it: the xl driver (or rather miibus) is broken in -stable as far as the 3C905TX card goes. Maybe it also applies to other cards employing the DP83840 PHY chip. As the change in miibus that causes this problem seems to be done to fix something with the fxp driver I am not too sure how to proceed. A PR has been filed under reference kern/27722 Wilko -- | / o / / _ Arnhem, The Netherlandsemail: [EMAIL PROTECTED] |/|/ / / /( (_) BultePowered by FreeBSD/alpha http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problem with xl driver (cvsup 2001-06-02)
No problems for me. My dmesg line: *--* xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x1000-0x107f mem 0xf400-0xf47f irq 11 at device 13.0 on pci0 *--* scanpci: *--* pci bus 0x0 cardnum 0x0d function 0x: vendor 0x10b7 device 0x9200 3COM Device unknown *--* Don't know if "C" (3c905C) makes any difference for me. On Saturday 02 June 2001 11:29, Thomas Zander wrote: > Hi... > > my buildworld of this morning shows a little uncomfortable problem with > the xl driver: > > media: ... status: no carrier > > The card is a 3c905 - TX (scanpci: device 0x9050) and never made > problems before. kernel.old does its work, too. > > Has anyone encountered similar problems? > > So long > Riggs To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problem with xl driver (cvsup 2001-06-02)
Hi, Am Sa , dem 02. Jun 2001, um 11:51 + Uhr schrubte Wilko Bulte zum Thema [Re: Problem with xl driver (cvsup 2001-06-02)]: > This is most likely PR kern/27722 > > > http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27722 > > Wilko Yes, this was exactly the cure. Everything runs fine now, just as expected :-) Thanks a lot Riggs -- - Die Welt schläft tief schon lange Zeit | Sent with RiggiSmooth [tm] - -- Mich nur flieht die Dunkelheit| - -- --- Denn per Infrarot seh ich| just to fit your --- Die Nacht ist wirklich widerlich. | primitive screen. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: problem with chflags
On Sat, Jun 02, 2001 at 02:53:14PM +0300, Giorgos Keramidas wrote: > On Fri, 1 Jun 2001, Brooks Davis wrote: > > > If we really need to support people who don't know what to do in single > > user mode, the correct thing is to add instructions to do: > > > > fsck -p > > mount -a > > > > after the reboot into single user mode. > > Yes, that would be marvellous. I know that I need to mount my filesystems > after checking them, and I always do: > > # fsck -p > # mount -u -o rw / > # mount -a > > But these steps are not easy to guess, if one reads /usr/src/UPDATING. > They are implied, but for someone who is booting in single user mode for his > first time, they are also very hard to just come up with :-) One might also need to do swapon -a to use any swapspace. I forgot that once with the result that the installworld stopped half-way through with an out-of-memory error. Granted, that machine only have 8 MB RAM and a modern machine should have enough memory to not need any swap during an installworld but one should be aware of teh potential problem. -- Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: problem with chflags
On Fri, 1 Jun 2001, Brooks Davis wrote: > If we really need to support people who don't know what to do in single > user mode, the correct thing is to add instructions to do: > > fsck -p > mount -a > > after the reboot into single user mode. Yes, that would be marvellous. I know that I need to mount my filesystems after checking them, and I always do: # fsck -p # mount -u -o rw / # mount -a But these steps are not easy to guess, if one reads /usr/src/UPDATING. They are implied, but for someone who is booting in single user mode for his first time, they are also very hard to just come up with :-) -giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problem with xl driver (cvsup 2001-06-02)
This is most likely PR kern/27722 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27722 Wilko > Hi... > > my buildworld of this morning shows a little uncomfortable problem with > the xl driver: > > media: ... status: no carrier > > The card is a 3c905 - TX (scanpci: device 0x9050) and never made > problems before. kernel.old does its work, too. > > Has anyone encountered similar problems? > > So long > Riggs > > -- > - Die Welt schläft tief schon lange Zeit | Sent with RiggiSmooth [tm] - > -- Mich nur flieht die Dunkelheit| - -- > --- Denn per Infrarot seh ich| just to fit your --- > Die Nacht ist wirklich widerlich. | primitive screen. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-stable" in the body of the message with "unsubscribe freebsd-stable" in the body of the message -- | / o / / _ Arnhem, The Netherlands email: [EMAIL PROTECTED] |/|/ / / /( (_) Bultehttp://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
